The biggest install I know of is http://hubski.com. Perhaps we should keep a list somewhere. But really what we seem to care about here is thinking about alternative stacks. That and helping beginners to programming in general or arc in particular :)
By the way, I discovered it with my tool, which I'm writing in Arc to learn this language. This tool crawls GitHub starting from Anarki repository, to find other interesting projects, written in Arc.
I think all the errors you're seeing are due to running out of heap. How much memory do you have? Is there some per-process limit, perhaps to RLIMIT_AS?
Edit 35 minutes later. I can reproduce that it dies for me at the precise same iteration as you. And RLIMIT_AS is infinity, so that's not the issue. I've pinged the author for comment.
Thank you. But now I think it would be wise not to complain about the issue on the forum, but rather to create an issue on the project's github. Will do it now.
Well, thanks for the bug report. Well, I'll look into it when I have the time: the work which pays my bills has caught up with me once again and I don't have a lot of time to do hobby development. :)
The assertion error is a stack overflow. :) At present Arcueid makes use of a fixed-size stack within its virtual machine, and since the compiler still can't properly optimise tail recursion, your code overflows the stack.
That was what I thought :) Is there a place where I can increase the size of the fixed stack? I looked for the limit in the code, but couldn't find it.
Does it make sense to resize it on the fly when we discover we've overflowed the stack? Or are there potentially continuation pointers into the stack that would be non-trivial to track down?
Well, I haven't tried to run crawler with large depth setting yet. I discovered, that it have strange problems with threading and almost unable to process in parallel. Then I tried to investigate why. Will make a separate post on it, when will get some valuable information.
I don't know how to answer it :) There's a lot of code in the world. I can help answer questions on some of it, but I have no idea what's most promising.
I upvoted you because I was happy to see the list, and I'd be interested in other people's answers.
Well, probably I should ask another question, addressed to the different implementations' authors: "Why do you started to write your own implementation instead of making efforts to improve Anarki?" :)
Historically speaking, Arc was put forward as a language for experimentation. If you want to package up code in a squeaky clean format for others to use who don't care about implementation details, you're doing something other than experimentation; you're publishing a product people would supposedly rely on.
Moreover. not even the Arc language is stable (or so this website has always said). If it encouraged people to package up their stable code, that would prove deceptive once the whole foundation fell away. This happened to Anarki when Arc 3 was released; the community had built up lots of Arc 2 code, and not much of that was ported to work on Arc 3.
However, Arc is not without module systems. The first thing I did in Arc was build some namespace macros with explicit imports and exports for my own benefit (Lathe). Andrew Wilcox made "the hackinator" which I think could download Arc programs from a Web-hosted manifest file, most often from GitHub.
More recently, Arc/Nu is an Arc implementation with rich support for first-class namespaces, along with several utilities for modular loading of Arc code that's written in the usual sequence-of-commands style. Arc/Nu is probably the best platform to publish stable modules for, since it can load alternate namespaces to achieve backwards compatibility.
