Factor 0.80 web server now live; AMD64 FFI progress

http://factorcode.org is now running Factor 0.80. I've also been working on the AMD64 FFI. Calling functions with integer and floating point arguments now works. Functions taking more than 7 parameters do not work, however; I haven't implemented stack parameter spilling yet. However, it is not too hard; I just have to adapt the existing PowerPC code that performs this task.

A release of 0.80 is just around the corner. As soon as the AMD64 FFI works well enough to run the Factor UI, I will release it.

Test instance of Factor HTTPD 0.80

I'm running a testing instance of Factor 0.80 on factorcode.org. You can access it via port 8889: http://factorcode.org:8889/.

There is a new responder of interest:
http://factorcode.org:8889/responder/help

The help responder for browsing articles. The help responder uses some JavaScript to implement expandable outliners. Thanks to Chris Double for implementing the "AJAX" code that does the trick.

The browser responder has also been overhauled and now shows word documentation:
http://factorcode.org:8889/responder/browser

The help and browser responders still have a few wrinkles. Once they're sorted out, and if I'm happy with the stability of the test server, I will make it the primary server.

The web site has seen 10,000 hits over the last 10 days. To date I haven't had a single issue with the Factor HTTP server. It is not a huge load, but it looks like the server is working okay.

I should mention my workflow when writing web code in Factor. I develop web apps locally on my workstation. I have the jEdit plugin run a Factor instance. I start the HTTP server in this instance, and while working on a responder, reload the source files with a jEdit command and immediately test the changes.

When I'm ready, I copy a bootstrapped image with the HTTP server loaded to my Linode box. On the Linode server, the Factor HTTP server runs inside a detached 'screen' instance. I can log in to the server, run screen -r, and I'm looking at the Factor listener. I can reload code and inspect server objects, all without restarting or 'redeploying' anything.

Being able to reload code in a running server without downtime is important. Look at the Java situation:

Here's the situation. I have a project that runs in JBoss. In normal/non-debug JBoss takes about a minute to startup and get ready to receive requests. In debug mode we're talking 2.5-3 minutes to startup even when no debugger has been attached. Given the severe difference in startup time I tend not to run the server in debug mode until I really really need to debug something. But then if I need to make a change and restart the server (hot-deploy and redeploy do not cover nearly enough) it's frustratingly slow!

Problem with GCC 4.0 and -fschedule-insns

The random compiler tester found another problem, and this time the problem is with GCC! On GCC 4.0, enabling -fschedule-insns (which is implicitly enabled by -O2 and -O3) miscompiles the bits>double, bits>float, float>bits and double>bits primitives.

If you're using GCC 4.0, please do not use anything higher than -O1 to compile the Factor runtime until further notice.

Random compiler tester finds first bug

Doug Coleman's random compiler tester managed to generate a very large number of failing test cases, which are all found to be symptoms of the same bug: the overflow check for the fixnum-shift primitive was wrong, thus certain large negative fixnums, when shifted to the left, would not be upgraded to a bignum and instead overflow, Java-style. This bug manifested itself on x86 in a pretty bad way: because the x86 assembler uses bit shifting to assemble instructions, large negative literal fixnums in colon definitions would not compile correctly. This bug would have been hard to discover by hand since it is rare to find literal integers in code, other than the usual 0, -1, 1 and 2. Now the overflow bug is fixed.

Factor 0.80 already has a large number of fixes for compiler bugs which I found with manual testing, and now that we have an automated test case generator, I hope it finds many more. :)

Factor 0.80 almost ready

I'm considering the new help system done for now. The new handbook doesn't cover everything the old handbook did, however I'll take care of that over time. I'm currently working on HTML rendering for the help markup language; this will be ready shortly, and soon I'll update the Factor HTTP server instance running at factorcode.org to allow online browsing of documentation, which is a first since formely the handbook was only available in PDF format.

In other news, Trent Buck is the newest member of the Factor community. He's working on a Debian package, and he's also done a lot of cleanup of the contributed library code to make sure it loads and works with the language changes made in Factor 0.80.

Doug Coleman who has already contributed quite an amount of code is working on a random compiler tester. It generates random quotations, and compares compiled and interpreted output. It has already found some rather obscure bugs.

3D graphics in Factor

Eduardo Cavazos has implemented a Factor program for rendering Lindenmayer Systems.

Here is a screenshot:


Eduardo is the latest Factor contributor. So far he's implemented a set of X11 bindings, an X11 window manager in Factor, and a series of graphical demos like this one. Factor 0.81 will use the X11 bindings for an UI backend in place of SDL.

Objective-C library interface with Apple text-to-speech example

In only a couple of hours, I managed to develop an interface to Objective-C libraries. This is now included in the Factor core. Objective-C is a static language with a runtime supporting limited introspection - you can list all defined classes, list all methods defined on a class, define new methods and classes at runtime, and invoke methods on objects dynamically. While it is not a great language, what makes it interesting is that, of course, the Cocoa API for Mac OS X is written in it.

The Factor interface is slightly awkward because method selectors have to be defined with parsing words first.

What follows is an example that uses Apple's text-to-speech library to speak a string.

We start by defining classes and methods we need.

OBJC-MESSAGE: id alloc ;
OBJC-CLASS: NSString
: NSASCIIStringEncoding 1 ; inline
OBJC-MESSAGE: id initWithCString: char* encoding: uint ;
OBJC-CLASS: NSSpeechSynthesizer
OBJC-MESSAGE: id initWithVoice: id ;
OBJC-MESSAGE: bool startSpeakingString: id ;

Then, a utility word to create new NSStrings:

: <NSString> ( string -- alien )
    NSString [alloc]
    swap NSASCIIStringEncoding [initWithCString:encoding:] ;

Finally, we can use the above words to speak a string:

NSSpeechSynthesizer [alloc]
f [initWithVoice:]
dup "Hello from Factor" <NSString> [startSpeakingString:]

I'm still trying to come up with a more natural way to fit this into Factor syntax. Merging the selector into a single word name is pretty tacky.

In a future release, probably 0.81, I will write a Cocoa bindings and a Mac OS backend for Factor's UI.

In other news, I'm slowly converting the handbook from LaTeX into the Factor online help markup. I guess I'm about half-way through.