Older blog entries for kwoo (starting at number 31)

GNU Smalltalk, part deux

Here's the current scoop. If there is a place to find more information, please let me know.

  • builds successfully on FreeBSD/x86 5.0rc1, but fails sigsegv stack overflow test
  • builds, tests, and installs successfully on Linux/x86 (Slackware 8.1, fresh install)
  • still not building on Linux/PPC (invalid character '^?' makes CFuncs.st barf)
  • uses libiberty.h, which Mac OS X.1 doesn't seem to include (and I'm too lazy to do a binutils install on it)

I'm thinking it's an issue with big-endian machines -- can anyone with a big-endian machine take a few minutes to build 2.0k and see if it works? If it's a generic issue with big-endian machines I think I can find it, but if not, I've still got a bit more digging to do.

GNU Smalltalk

Got the latest (2.0k) and set about compiling it. I was never able to get the earlier 2.0[:alpha:] versions to compile, but this time I've resolved to see it through to the end.

There are three languages that I really like -- Lisp, Ruby, and Smalltalk. I have working Lisp and Ruby interpreters, but would love to add GNU Smalltalk to the collection. Squeak is fun for playing with, but I find it hard to understand, and too graphically demanding.

The first problem was an include of the file siginfo.h in one of the sigsegv files. It turns out that file isn't necessary to include on Linux/PPC -- I commented out the include, and it worked just fine.

Unfortunately, I'm getting bit in the butt when it comes to CFuncs.st -- it's complaining of an invalid character ('^?'), and I'm trying to figure out where that's coming from.

More (and hopefully a patch) when I figure that out.

Software Engineering

I'm going through the 6.170 course materials from OpenCourseWare at MIT. So far (middle of the second lecture notes) things are very much as expected, but with a slightly different point of view than many of the books I've read on it.

Slackware 8.1

I just finished burning a Slackware 8.1 ISO to install on my old laptop. I had installed QNX on it just to see what was happening in that world, but QNX doesn't like a Celeron 366 with 32MB RAM too much -- but Linux will do just fine. I'm just going to run a cable from the office to the bedroom so I can do my thing while Ellen reads, but still hang out together.

Ruby and XML

After a brief search, I have come across nqxml, a pure Ruby non-validating XML parser. It misses a couple of things from the spec, but those things are documented, so I can be sure to avoid them.

I'm going to make a little tag-rewriting tool with it, and hopefully it won't turn out too bad. The only real worry I have is that it will turn out to be as confusing as XSL-FO. We'll see.

Trust metric presentation

raph: I read through your slides for CodeCon, and found it inspirational. Thank you for posting those. I had been messing around with ideas for authentication and whatnot for Blister, but I think it might be more interesting to integrate an Advogato-like trust metric instead -- it takes more effort, but it will be interesting effort that will teach me something.

XSLT and brethren

I've been reading up on XSLT and FO for the past couple of hours. On one hand I can see the "correctness" factor -- but on the other hand, it really seems like a bunch of academic masturbation.

That is not meant as a flame to supporters and/or implementers of the platform -- it's just a personal opinion. Rate me down if my opinion bothers you, but send flames to /dev/null. Responses to flames will be generated by /dev/zero. Or /dev/urandom if you're lucky. :-)

That being said, I don't like to complain about something without at least having a suggestion as to how to fix it. I don't have a fix right now, but I am going to focus my next few hours of reading on the DOM or SAX (whichever is best-supported by Ruby) and see if I can't throw something together for those of us that want little more than tag transforms.

Random question of the day

The Japanese language uses counter suffixes, and there are many of these counter suffixes for different types of items. Which counter suffix is used for lines of code, and which is used for files/directories in a filesystem? My Japanese isn't good enough to hit a Japanese programming page and find the answer on my own. Needless to say, my language texts are a little lean on answers to this one.


I have started a new project called Barter. It will be an on-line, community-based bartering system, implemented as Ruby CGI scripts with HTML templates. I plan to migrate the templates to XML as soon as I understand XSLT.

Barter is kind of a "warm-up" project for another project. The other project is much more complex, and I think I'll save time in the long run if I pull off a simple project to learn XSLT and beef up my Ruby skills rather than try to jump right in to the complex one.


Though there are now a few templates and some simple code written, I'm beginning to see that this is going to turn out to be a rather complex project. I have decided to develop Barter as a way of getting familiar with XSLT and Ruby, both of which I intend to use in Blister.

So far I have found two reasonable-looking XSLT toolkits -- Sablotron and Xalan/Xerces. I'll have to do a little bit of playing with them to figure out which one I get along with better.


Well, I asked Ellen, and she did come up with two more points on the Blister suite's feature list. The feature list now looks something like:

  • seed tracking (source, info, germination rates, number planted, etc.)
  • garden organization (what goes where, beneficials, cross-pollenation, etc.)
  • crop rotation and fertilization
  • comprehensive labelling (mostly for seed starting)
  • a foods and recipe database
  • animal ancestry tracking (to avoid line breeding, etc.)

I also thought of one more point earlier, but I seem to have forgotten it.

The list also doesn't include common infrastructure -- user tracking, authentication, etc. When I add it all up, it is fairly compelling to adopt a web infrastructure for it, or at least a XML-over-HTTP architecture. I need to look into the default support for XML and CSS2 for common browsers on OS X, Linux, and the BSDs, which form the majority of my machines.

It's also tempting to use it as an avenue for exploring XSL. Is anyone still doing anything with XSL? I remember it (the early versions I played with a few years back) being rather on the obtuse side, but I need to have another look and see if it makes sense to me now.


I re-read the first section of The Ruby Way, in preparation for doing some prototyping work for Blister and for an on-line bartering forum. The parser is a little more hairy than I remember it being, but it does what I expect for my coding style. Though I am usually a bit put off by an enforced coding style in a project, I definitely see the point with Ruby -- there are a few gotchas that can be defeated by sticking to one style (begin-end and curly bracket subtleties, determining the receiver of a function, the unary '*' operator, and a few others).

Other stuff

My hand is doing much better now. Another couple of days and the burns will be gone.


The feature list for Blister has been growing and growing. I'm starting to have second thoughts on trying to integrate it all, and have several smaller programs instead. So far the major divisions are:

  • seed tracking (source, info, germination rates, number planted, etc.)
  • garden organization (what goes where, beneficials, cross-pollenation, etc.)
  • crop rotation and fertilization
  • comprehensive labelling (mostly for seed starting)

I'm sure if I asked Ellen, she would add another two or three points to the list.

I've decided on an XML back-end to the whole mess, simply for ease of parsing, and because it can be edited by hand. If I'm careful with the DTD creation, I can have a tagset that will compress well.

Other stuff

I have to hack together a XML tutorial for Ellen tomorrow while she's at work. She's a WordPerfect 5.1 veteran so the idea of tags is not entirely foreign to her. She's also a real trooper, learning Mac OS X and basic Unix -- she decided it was time to organize her system tonight, and she mastered the columns mode of the Finder in no time.

I also managed to burn my mousing hand preparing dinner this evening. The pain is keeping me awake, but not alert, so it's quite frustrating. Well, off to bed I go in hopes of sleep...

Re-install mania

Got frustrated with having no decent web browser, so it's back to Linux on the iBook. I must say that jigdo is a real life-saver -- it read the unchanged files from the old Debian CD, and downloaded the new ones. Much better than the multi-hour download session the first time through.


Currently frustrated in this area as I keep trying to find a job. If anyone knows of an opening in the lower mainland of Vancouver, BC, Canada, please let me know at kwoo@cpan.org.


Not a lot of work on Blister as of late. I did make the decision to shift from being CGI-based to FLTK-based, as I didn't want to hack together state saving for CGI (even if it isn't hard, it still isn't fun).

Learning about FLTK is great, though -- it's exactly what I want from a GUI library. It made more sense in the first hour than Motif did after a full day with the Motif Programming Manual (O'Reilly and Assoc.).

I've also been playing around with parrot again, now that my laptop is running OpenBSD/macppc. There are a few little issues, but so far it's still fun (as opposed to being annoyed by strange inconsistencies on Mac OS X).


Okay, so I'm an idiot. In my thrashing about trying to find a compromise between availability and usefulness in languages for Blister, I completely forgot about C++, which will save me a lot of time writing string and memory handling code.

In my own defense, here is the order of languages I considered:

  • Common Lisp (clisp, specifically)
  • Scheme (gauche or guile)
  • ML (O'Caml)
  • Objective C (using the Foundation framework)
  • Objective C (using frameworks of my own creation)
  • C

I should have considered C++ before C -- after all, I don't know of one non-embedded platform that lacks a C++ compiler. I do have a known fetish for complexity (it's often what keeps me interested in a project), but writing a lot of unnecessary code that has already been written by other (much smarter) people is just pointless.

Not to mention that the object-oriented nature of C++ fits the problem domain much better (keeping track of plants and collections of plants).

22 older entries...

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!