Older blog entries for kwoo (starting at number 29)

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.

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.

Blister

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.

Reading

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...

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.

Code

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).

Got a little more done on Blister. Nothing much, just some string-handling and the unit tests for it. I still need to work out a proper unit-testing framework, but I might just settle for a function or three to print out test summaries or just use good old diff(1).

Code

Is there a naming convention for C functions in the open source world for destructive functions (that modify their argument(s))? I've been using the n-prefix (as per Common Lisp) and there's nothing wrong with that, but I'm trying to make the code as readable for others as it is for me.

Server-less CGI

One person e-mailed me regarding my claim that lynx (the text-mode browser) supports CGI without a webserver present. Just in case there are more people wondering what kind of drugs I'm on, grep the lynx_help directory in the distribution for lynxcgi, and that should answer the basic questions.

I still can't remember the name of the Mozilla-derived browser that does CGI on its own, though.

Spam

Am I the only one that got the spam for Hong Kong fax lines? They claimed they "found out about my company on Advogato.org". Admittedly, it's my own fault for posting my e-mail address here, but if they found my e-mail address, they should figured out that spamming the denizens of Advogato might not be such a hot idea.

Backed off the strict Mac OS X requirement for Blister. Indeed, I will be doing the UI in the GUI that I know best -- HTML 3.2. The benefits to making it a CGI application are arguable, but if someone really wants to run it stand-alone, there are at least two browsers I can think of (lynx and one Mozilla-derived one I can't remember the name of) that allow running CGIs without a web server present.

With that decision comes the decision to avoid dependencies on too many external things. Unfortunately, this means I can't count on folks having an Objective C compiler available, so development will be in ANSI C, using only ANSI and POSIX functionality.

Really, this means I've got a case of NIH, so I started writing CGI-handling code first. I find it somewhat amusing that although I haven't coded in straight-up C for a long while, I seem to be better at it than I was before.

Personal

My new personal diary is at http://slashdot.org/~kwoo/journal/. Say what you will about Slashdot, but they do have a nice journal interface, and I don't want to clutter the recentlog here with entries about gardening.