GuICU: Guile Unicode v0.0 released

And he said, Who art thou, Lord? And the Lord said, I am Jesus whom thou persecutest: it is hard for thee to kick against the pricks. And he trembling and astonished said, Lord, what wilt thou have me to do? And the Lord said unto him, Arise, and go into the city, and it shall be told thee what thou must do.

Late last night, I finally uploaded the first alpha of the my Guile Unicode library to SourceForge. There is more to do, of course, but, I had to released it lest it ruin Christmas. I've got gingerbread to bake and vacuuming to do, and I couldn't do it with the release unfinished.

I originally intended to do a straight wrapping of IBM's icu4c, but, it is heavily UTF-16, and most of the non-Java GNU open source world tends to be moving toward UTF-8. So, in a act of bravado, I started my own Unicode library from scratch in Scheme. But that Unicode standard is hundreds and hundreds of pages. I would die before I completed anything.

So, back to ICU I went. I've tried to hide the underlying UTF-16 nature of ICU by having the wrapped functions deal primarily in full codepoints, UTF-32. It looks fairly effortless on the Guile side, but, under the hood, it is class-A Jerry-rigging.

So a couple of days ago, I knew the code was decent. Nothing left but the autotools crap. Autotools is an beautiful hack. It is amazing until you want to deviate from its expected norms, and then it becomes hateful. In a way, getting autotools (specifically automake) working is like a good Christian's relationship to God. You have to humble yourself to automake. It is not "how do I make automake do what I want". It is "how to I humble myself to the will of automake so that I am not punishing myself."

When "make check" began working, I knew I do the code-fu. Hi-yah!

How long have I been sitting here? I'm not sure I remember a life before unit test and documentation and autotools...

GNU Purity

So in my attempt to put together a coding project that achieves GNU purity, I am experiencing that sinking feeling that I usually get once I dig further into free software. As always, I know exactly where the finish line is, but, I soon realize that the starting line is much earlier than I thought.

To recap: I've chosen a project, made a list of the component technologies (the GNU C compiler, the GNU C library, Guile, project GNU's extension language, the GNU m4 macro processor, GNU Autoconf, GNU Make, the GNU New Curses library, GNU libtool, Texinfo, the GNU documentation system, and the Concurrent Versioning System), read all their manuals, brushed up on the GNU coding standards and philosophy, and started coding on the system I had lying around. The system I had available was Cygwin running on my Windows XP box.

Then, as I began hacking, I started to see that starting line move further and further back.

First, the NCurses binding for Guile didn't really work for me, and it wasn't as complete as I'd hoped.

So I tried to wrap the NCurses quickly using G-Wrap, but, version 1.9.9 doesn't build on Cygwin.

So, I wrapped it all myself with a bit of GNU Awk craziness. It looked pretty good, so I though I was ready to build my library and test it.

This lead to the problem of making dl-openable libraries on Cygwin. Being a Microsoft platform, dl-openable libraries are DLLs. Making a DLL on Cygwin with Libtool and Autoconf is complicated and doesn't work as expected. I found a good reference to do it raw, sans Libtool, but, I wanted Libtool to work for me. I'm still looking for the perfect documentation on Libtool on Cygwin.

Whilst trying to get my Guile module to load a DLL, I got one of the greatest error messages I've ever seen from Guile.

ERROR: no error.

So, screw Cygwin. I started to move to are the platforms onto which this is supposed to be compilable. The coding standard suggests that GNU/Linux and GNU (Hurd) are the minimum set. Okay. I have Slackware 12.0 CDs. Installing that was easy enough, sort of. Networking still not working.

Then I moved onto the Hurd install. Utter crapflood of installation badness.

No matter. I am stubborn. I can work it all out.

Look for the alpha to be ready early in the 2020s. ;-)

Guile and Online Code Libraries

Havok Pennington has been talking up the ideal on the online desktop. Essentially, he sees the future of the desktop to be something like XBOX Live or Google Desktop, where private data is stored centrally and is available for use from any computer. Each computer becomes a thin client.

A couple of outlines of his argument can be found at this interview, and in his GUADEC presentation.

In broad terms, this is not a new idea, obviously. "The network is the computer" is the central idea behind, for example, telnet, X, Java, Google Desktop, and XBox Live. There are Java-based OS projects, Mozilla-based OS projects. What makes it interesting is that the Fedora kids now have enough components lying around to actually accomplish such an effort with their GNOME infrastructure. To paraphrase his argument, a Live CD and a network connection should be all that is required to access much of the functionality of your desktop machine. Preferences could be stored online so that the look, feel, and functionality of one's desktop can be reproduced at any machine.

Let me quote his GUADEC slides.

IMPLEMENTATION

SEARCH AND DESTROY everything that leaves my data stranded on a single computer.

INTEGRATE the best web applications with the desktop.

RETHINK the user experience to take advantage of live connections to friends on the net.

CHANGE THE DEFAULTS so naïve users taking no special action will create collaborative, backedup, online data rather than local files.

The Guile project, a GNU project scheme interpreter, is somethat that I play with sometimes. I started thinking about how this sort of idea can be fused with something like Guile. I think one way to touch base with this concept is in the Guile Module system. The Guile interpreter has a small subset of the language hard coded in the libguile, and then loads further functionality from a set of modules upon initialization. Some of these modules are C-code objects with Guile wrapper scripts. Some are pure Scheme.

It would, I believe, be quite trivial to convince libguile to seek out its modules from an online repository upon initialization instead of from the local drive.

A rough outline of the simplest TODO might be as follows.

1. Move the %load-path to a GConf variable instead of a hard-coded value, and change it into a URI instead of a standard file path. This would allow one to set a %load-path such as "http://foobar.com/guile/1.8/".

2. Incorporate Gnome-vfs into libguile so that module loading can use any URI-style location.

3. Update the /usr/bin/guile executable to allow it to run scripts stored by URI.

4. Maybe update /usr/bin/guile to preprocess a file to seek a %load-path before initializing Guile.

There would need to be a division between what "core" Guile and module-loadable guile should be.

This alone might be useful, but, there are some fun questions that couldn't be answered by this framework.