Bluish Coder

Real-time Wiki

From the Erlang mailing list comes a pointer to 'Real-time Wiki'.

It's a Google Summer of Code project that allows using XMPP (ie. Jabber) from a browser based client. Values can be changed from the server and the change is broadcast to the clients and instantly updated. It seems that the application for this is a Wiki that updates automatically when others change it.

The implementation on the server side uses ejabberd, a Jabber server written in Erlang.

Playing around with Minix

I like the idea of writing device drivers and operating system components in other languages, as mentioned in a previous post about Haskell and Minix.

I installed Minix 3 and ran it under qemu to try it out. It's very functional but doesn't have much in the way of software or 'nice to have' features yet. But the source is all there and its very easy to build and follow.

I went looking for the book describing the internals of Minix, Operating Systems, Design and Implementation, and it's about $105 US online. Ouch. I tried a few Wellington bookstores and Capital Books had a copy for $110 NZ. They're probably the only bookstore in Wellington that was even likely to have a copy as they are specialists in technical books.

Now the task is to build/port some of the language implementations under Minix and try a simple driver. As I know very little about Minix I'm documenting the user aspects (setting it up, porting software, etc) in a weblog I setup for that purpose.

The interesting thing about that weblog is I'm hosting it on a Minix 3 system, running 'httpd' which comes with Minix. It's also running under 'qemu' on the same user mode linux machine as this weblog. There are some issues with doing that but it'll be interesting to see how it works - and it gives me a network facing Minix machine to experiment with. I suspect, due to the multiple levels of indirection, it's unlikely to handle load too well but we'll see.

Unenterprisey Languages meeting

There's an 'Unenterprisey Languages meeting' at 4pm this Saturday (the 10th of June) in Wellington, New Zealand. It's being held in the L2 boardroom at Catalyst, Level 2, 150 Willis St.

Speakers so far are:

• Robert Strandh, who will probably be talking about Common Lisp and the G# score editor
• Jonathan Wright who will be talking about the Io programming language.
• Geoff Cant, who will be talking about Erlang and maybe Sisc scheme.
• And me, but I have no idea what I'm going to talk about just yet.

Last time there was a gathering like this (A Lisp users gathering) I talked about Aviarc, the web development product I work on for my day job, and its underlying continuation based web server written in Scheme. I haven't decided what to talk about this time...and I'm running out of time!

Associative Arrays and Javascript

Andrew Dupont has a post about Associative Arrays in Javascript. He makes the good point that you shouldn't use the Array object for this functionality, instead use 'Object'.

Unfortunately using 'Object' has its own set of pitfalls. Try the following code in your favourite Javascript implementation:

var x = {}
x["toString"]

This will display details on the toString method on 'Object'. So we can't use a plan Object as an associative array as it has some default entries in it already obtained from its prototype.

This can be worked around by using the Javascript standard function 'hasOwnProperty'. So you could write a simple Hashtable object with a 'get' method that does:

function Hashtable() { }
Hashtable.prototype.get = function(key) {
  if(this.hasOwnProperty(key))
    return this[key];
  else
    throw "No such key";
}

Now the following code works:

var x = new Hashtable();
x.get("toString");
 => uncaught exception: No such key
x["blah"] = 5;
x.get("blah");
 => 5

It has a subtle bug too though. This breaks:

x["get"] = 5;
x.get("get");
 => TypeError: x.get is not a function

Oops, we overwrote our 'get' method. So the Hashtable object really needs to store its data in an internal object:

function Hashtable() { this.table = new Object }
Hashtable.prototype.get = function(key) {
  if(this.table.hasOwnProperty(key))
    return this.table[key];
  else
    throw "No such key";
}
Hashtable.prototype.put = function(key, value) {
  this.table[key] = value;
}

The following code now works as expected:

var x = new Hashtable();
x.put("get", 5);
x.get("get");
 => 5
x.get("toString");
 => uncaught exception: No such key

The trap of using a basic Object as an associative array is seductive but as you can see it has pitfalls. They are easy to work around but it's easy to forget. Dojo's current implementation of Dictionary (as of 0.3) has this problem for example. There's a thread on the mailing list at the moment about fixing it (raised by me).

Migrating Javascript Threads

A while ago in my old weblog I posted some Sisc Scheme code to demonstrate a thread migrating from one Sisc session to another. Since Rhino, the Java based Javascript implementation, has serializable continuations I decided to try porting it to Javascript.

The code demonstrating it is in migrate.js. Loading this into a Rhino session provides a function called 'messageListener' that starts up a socket server that listens for incoming objects on a port. The object should be a function or continuation. When received it's called on a seperate thread.

The 'send' function will send a function to a running message listener. This can be on the same machine or across the network. 'migrateThread' will migrate the currently running thread to another message listener, again this could be on another machine across the network. For example:

Machine A:
js> load("migrate.js")
js> messageListener(10000)

Machine B:
js> load("migrate.js")
js> messageListener(20000)
js> send("host.running.A", 10000, function() { print("Hello A!"); });

This will result in the message 'Hello A!" appearing on machine A. The function is serialised, sent across the network and deserialized and called on A. An example function that does thread migration:

function pingPong(host1, port1, host2, port2) {
  while(1) {
    print("ping\n");
    java.lang.Thread.sleep(1000);
    migrateThread(host2, port2);
    print("pong\n");
    java.lang.Thread.sleep(1000);
    migrateThread(host1, port1);
  }
}

If run on Machine A, specifying the host and port for machines A and B it will first print 'ping', then sleep for 1,000 milliseconds. Then the thread will migrate to machine B, print 'pong', sleep and migrate back to A, etc.

The code has a workaround for the fact that Rhino doesn't deserialize and serialize to a stream. Instead the functions only work on files. So I serialize to a file first, then read that file and write it to the stream. For deserialisation it reads from the stream, writes it to a file then deserialises from that file. For real world code this should be changed to actually operate on the stream itself, or use random temporary files and clean them up afterwards.

To run the code you'll need to use both js.jar (The Rhino implementation) and xbean.jar (for serializing some of the Javascript objects). An easy way of just getting these to try it out is to use the jars from the Server Side Javascript example and run it with:

java -cp js.jar:xbean.jar org.mozilla.javascript.tools.shell.Main

For Windows, replace the ':' with a ';'.

This was one of the things I talked about and demonstrated at the Unenterprisey Languages Meeting in Wellington on Saturday.