Working on callbacks; another server problem fixed

I've started implementing callbacks from C code to Factor. They are defined like so:

: foo-callback ( -- xt )
    "void" { "int" "int" } [ + . ] alien-callback ;

Once compiled, the foo-callback word will push an address on the stack. This address is a compiled code block which uses C calling conventions and may be passed to C library functions expecting a function pointer as an argument. I took care of the interaction with continuations by invoking callbacks inside a nested "context" with initially-empty stacks. Continuations may be saved and restored while a callback is in progress, and the only restriction is that a continuation saved inside a callback must only ever return to the top level while it is inside that callback. Another potential issue is that if the callback quotation throws an unhandled exception, the C stack will unwind all the way up the top-level exception handler, thus the interveined C code may leak memory or have other problems.

Callbacks are not complete yet -- there's some corner cases that are not supported, and I have not got things working on anything other than PowerPC. On x86, callbacks which do not take arguments work.

Once callbacks are working, I will continue hacking away at the Cocoa bindings. I'm still trying to come up with a clean way to integrate message sends with Factor syntax. The current scheme of defining words like [initWithFrame:backingStore:defer:] is temporary. At present, I'm leaning towards something like this:

[ foo #initWithFrame bar #backingStore 0 #defer ] send

Where the #... words would be automatically-generated when Cocoa classes are imported, simply by splitting selector names. I still need to work out how this will end up being compiled efficiently. I certainly do not want all Objective C message sends to be dynamically looked up; so under the hood, it will still rely on one compiled optimized alien call word per class/method.

In other news, we found and fixed another stability issue on the factorcode.org server. This time the problem was in the continuation-based web framework.