Older blog entries for rotty (starting at number 1)

Status of Scheme48 hacking

Over the last months, I've started several hacks on Scheme48. My interest in Scheme48 was initially sparked by Jivera, who started to bring a Pika-style C API to Scheme48.

The features/projects I've been working on:

  • The new buildsystem: it is now easily possible to build Scheme48 completely from scratch, bootstrapping it with another Scheme48 installation.
  • R5RS-compatible keywords (e.g. #:foo). There seems to be some controversy about the usefulness and "good taste" of keywords, but I need them for my GOOPS-compatible TinyCLOS version.
  • Relaxed string escaping, i.e. allow e.g. (display "Hello World!\n").
  • A scheme48 executable that allows command-line access to the exec language; you can do

    scheme48 -cl packages.scm -o mystructure

    which is equivalent to typing:

    ,config ,load packages.scm
    ,open mystructure

    at the Scheme48 prompt.

  • Some initial work on a PLTish FFI. See Foreign Interface for PLT Scheme for how this FFI looks like. The cool thing about it is that you don't have to delve into C for creating bindings anymore.
  • Porting Kali Scheme. This has just started; so far, I've been able to get the Kali VM to build on top of Scheme48 1.2, but it is probably far from working.

Most of the above is still not polished and not ready for release or even sending patches upstream. I have, however, submitted some very simple patches to the Scheme48 mailing list, and got no response from the maintainers. Should working with them not work out, I might have to create my own fork of Scheme48. In fact I have forked already, but if I can't get (parts) of my stuff into mainline Scheme48, I might start to actively push my fork as "extended Scheme48" or with a new name.

13 Jun 2005 (updated 13 Jun 2005 at 21:27 UTC) »
GNOME for Scheme48

I've decided to laying the foundation for creating bindings of the GNOME software stack for Scheme48, specifically: create bindings for GLib/GObject.

At the core of GNOME, there is the GLib Object System (GObject), on top of which GTK+ and the rest of the developer platform are built. Thanks to the header scanning tool h2def.py, which creates a S-Expression representation of the API, you are able to create bindings for any GObject-based library, once you got the core bindings right.

I have a rough plan how to do this; basically I plan to fork guile-gnome and reuse the existing infrastructure (e.g. .defs processing). The Guile-GNOME fork will drive a G-Wrap that's capable of emitting code for the upcoming Scheme48 FFI. Work on G-Wrap/Scheme48 has already progressed to a degree where it's possible to turn to the GObject bindings and fill out the holes as needed in the process.

The plan is also to make the resulting bindings "mostly compatible", so that programs written for Guile-GNOME will also work with Scheme48-GNOME and vice versa. Since Scheme48 has no built-in object system, and the object system would have to be compatible with GOOPS (Guile's object system) anyway to achieve source-compatibility between the bindings, I started working on a GOOPS-compatible version of TinyCLOS.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!