October 2004

You are currently browsing the monthly archive for October 2004.

More mGTK Progress

Henning and I have been working hard (leisure time hard, that is) on mGTK since my last mGTK progress report. We have ported all the interesting Gtk# examples from Mono: A Developer’s Notebook Chapter 4.

screenshot of four mGTK examples

Currently the only missing bits are better support for the lower levels of the library stack most notably GDK, but also Glib, ATK, and Pango. Which means that there are no pretty monkeys and the drag and drop example does not compile, yet. The source code for the examples can be found in the mGTK CVS.

Next up, is polish of the bindings generator for MLton which is currently not as well as the Moscow ML generator. The only thing missing is support for out-arguments. However, Henning is on the case, so the problems should be solved within days(?!?). A release is sooo close. That fells really good because it has taken three years to come this far.

callcc for Moscow ML

The last few days I have tried to recreate my implementation of callcc for Moscow ML. My original (incomplete) implementation was lost last fall when my old laptop was stolen (or it is still lurking somewhere in mess which is my old backup system).

The code almost works. For example, the following code, which just ignores the continuation value k:

3 + callcc (fn k => 2 + 1);

Gives 6, as it should.

However, the following more interesting example, which actually uses the continuation value:

3 + callcc (fn k => 2 + throw (k, 1));

Gives 67299815 and not 4. Ouch!

Likewise, given the following declaration of multiply:

fun multiply ints =
    callcc (fn ret =>
    let
        fun mult nil = 1
          | mult (0::_) = throw (ret, 0)
          | mult (n::ns) = n * mult ns
    in
	mult ints
    end)

The expression:

multiply [1,2,3,4,0,5];

evaluates to 67299810 and not 0. Double ouch!!

My guess is that I somehow mess things up when I restore the stack, and some pointer ends up on top of the stack. But I’m too tired to debug this futher tonight.

One nifty feature of my code (if I can get it to work) is that it is implemented using the Dynlib library. Which means that no changes are needed to the original Moscow ML code, it is all in a seperate library.