Hmm, core-evaluation-test.arc seems to hang Anarki, as well as Arc 3.1.
Well, I've tried to run the tests that do work fine with 3.1 and Anarki under Arcueid and find a lot of issues. For starters, I had no idea that Arc treats symbols with |'s specially. Looks like more accidental behavior inherited from MzScheme/Racket. Scheme48 says that '|abc| contains illegal characters. Guile creates a symbol |abc|. I don't see anything in R^6RS that mandates any of this behavior. Heh, looks like I've got a lot of work to do!
Apparently the bars in symbols is a sort of convention when it comes to case sensitivity of symbols in Scheme. It seems that Arc, in its current implementation anyway, is unintentionally inheriting a lot of onions from MzScheme...
I don't think you really want the most actively developed branch, but rather the most stable branch. My Arcueid is very actively developed, but I would definitely not recommend you use it for a production site!
Unless Mr. Graham is presently using a new version of Arc that isn't publicly available to run this forum and Hacker News, the fact that these sites are running well should be a good sign. I think that unless there are extensions you need that the reference Arc 3.1 does not provide, you can't go very wrong there. I've been using the Anarki (nex3) branch as well, and it is fine.
Did a lot of fixes so now Arcueid can render news.arc more or less properly. Atstrings are now supported. I'll almost call it a 0.1.0 candidate release but not quite yet.
32-bit support needs a lot of work. Lots of stuff that works fine on 64-bit x86-64 is busted on x86.
Next steps will be to write a test suite for Arc, which is to validate the behavior of the run time and functions. Has anyone tried to make such a thing yet?
"Next steps will be to write a test suite for Arc, which is to validate the behavior of the run time and functions. Has anyone tried to make such a thing yet?"
Look at the *.t files in http://github.com/awwx/ar. They should also be good for a crazy simple test harness, and it's explicitly in an MIT license.
Such tests are essential for me, not just to ensure compatibility, but to ensure that when Arcueid gets ported to a new architecture everything still works. This is the big problem I'm having now as I try to get Arcueid to run properly on 32-bit architectures.
I plan to break up the test suites for Arcueid into two, one involving low-level tests that are run via GNU Check (which we have today), and more high-level tests run by some putative unit testing framework, perhaps your own or something derived from it, that should run on any Arc implementation. I may spin out the latter set of test suites into a separate project of its own.
Well, we finally have a version that can actually run news.arc, although it's still unstable and broken in many ways. Interaction between network I/O and threading still seems to have some problems. Do not try to put anything inside the static directory of your Arc server: serving static files is still broken and I'm not yet sure why. Well, at least we're moving, and things are now at a rather interesting point.
This is the first version of Arcueid that can actually run the code from the Arc Challenge. Still can't run news.arc itself though but we're almost there I hope.
Up next for version 0.0.11: memory management revamping, news.arc, and more...
Hmm, considering the behavior we're seeing, I think that the following is true: a continuation captured from a different thread will execute in the thread that invokes it, not in the thread it comes from, thus ccc doesn't have the ability to resurrect the dead, nor will it interrupt execution of the thread that is already running. This is the reason why invoking the continuation above from the REPL kills the REPL. The REPL thread was "possessed by the spirit of the continuation" so to speak, so when the continuation terminated so did it, and thus we got dumped into the Racket REPL. I suppose that what Arcueid should do in order to emulate this behavior is terminate when the continuation finishes execution, because its REPL thread would then exit when the continuation returned to nowhere.
I suppose endowing ccc with the power of necromancy is a little too much. XD
I notice that the levels don't include the kind of programming I used to do ten years or so ago. Back then I was doing low-level assembly language programming for 8-bit microcontrollers on embedded systems. The sort of programming where hardware knowledge is as important as software. Programming down to the bare metal is the colorful phrase for it I think.
Mostly I'm at levels 4, 5, 8 (Ruby finds you doing a lot of metaprogramming), and occasionally 9 (well, there is Arc and I sometimes do Ocaml and Erlang). I once had a glimpse of the mystery level which I suppose is inhabited by folks like Donald Knuth and Gregory Chaitin, but I had to drop my Master's in Computer Science when real work came calling.
This is the way I am revising the mechanism behind call-w/std(in|out) in Arcueid, by creating a general-purpose continuation mark system built on top of dynamic-wind. This is, of course not yet how Arcueid does it. In fact the code for this isn't even in the Git repository yet and only exists in my local machine, as it's not complete enough to even be compiled. Just wonder how sound the idea is.
Well, I added links to Arcueid to the wiki as soon as I learned of it, and will be adding links the wiki in Arcueid within the README and wherever else it makes sense to do so.
I see Wikipedia's article on Arc links to the wiki as well, although perhaps it should be amended to be more prominent than a single footnote citation.
