Older blog entries for kwoo (starting at number 13)

The job

I didn't get it. No word on why not, but there are two possible reasons. The first is that the sample code I sent in sucked. Try writing code just for the sake of writing code someday -- it's quite a challenge. The second possible reason is that they found someone with a skill level more in line with the job they were offering, as it seemed to me that they might have been looking on the low end of the salary scale.

Whichever reason, it still sucks, but that's life.

Debian weirdness

I downloaded a netinst ISO for Debian today (can't remember which one -- the first on the list) to install on a x86 IBM eSeries server with a ServeRAID card. I tried everything to make it work, and it wouldn't -- not with the compact kernel, not with the regular, and not with bf24. Oddly enough, it worked with the vanilla kernel. Strange.


More playing with Squeak, installing stuff from SqueakMap. Unfortunately, the Atoms game is rather addictive.

On the plus side, I see that crypto stuff is being worked on, so I don't have to start from scratch. Methinks I'll go have a look at that...


I'm back to hacking about in Squeak. Partly hacking ST, and partly playing with Swiki and Comanche.

Swiki and Comanche are great, and I think that my earlier-mentioned pfft project would simply be a slightly modified Swiki, so if I decide to go in that direction, I will likely use Swiki as a base. I expected the Wiki markup to be more involved, but now that I see what Swiki expects, I don't see much of a need for templates, which would have been the single largest difference between a Wiki and pfft.

I'm beating my head against the wall over a couple of odd ST details, but I want to give it a bit more time before begging publically for a solution. If I don't figure it out, I'll likely check the tutorials, then ask here if I can't make heads or tails. I know that checking the tutorials would likely solve the problem, but I find I learn better if I hack something out the hard way.


I'm going to remove my "helper" status on Parrot. I really haven't done a lot, and my motivation is sucking.


A little bit of progress today -- starting on the framework for stock photograph management. I had been feeling unmotivated and whatnot, and finally realized that I did have something in mind to work on. I had simply forgotten it, as it has been sitting on the back burner for aeons.


Downloaded Bluefish (gtk+-2 port) and started brushing up on my HTML and CSS. The last time I looked at this was a bit after HTML 4.01 Transitional was proposed, so I'm surprised that I got a fair amount done. Eventually my website will be valid XHTML and CSS2, but it will take a bit more practice and stylesheet generation.


I had a peek through the "official" apps for the Cybiko Classic, and I'm fairly impressed. It's nice to see that some people can still write tight code. Something also tells me that the space overhead for an application archive is quite small, but a simple text editor in a little under 3KB is good for any system.

In short, I'm pretty happy with it, though I really do need to get to work writing some apps of my own for it.

I did also finally get around the problems transferring files to the Cybiko -- I used the computer I gave my girlfriend, which runs MacOS. If anyone has any insight as to making cyucon work under Linux (x86 or PPC) or FreeBSD (x86), please let me know.

Toy time

My mother sent me money for Christmas. I decided to spend half on something fun, and the other half on necessities. I got one of those little Cybiko units (kind of like a GameBoy on steroids, with a cute little RF unit built in).

So far, it looks like it will be quite useful. Though I'm not big into games, there are certainly many available for it. What won me over was the company offering a developer's kit for Linux (even though only x86 -- blech), the fact that the unit is expandable (68-pin cartridge bay) and while the batteries are built-in, they are easily accessible and fairly easy to find in parts catalogs.

I'll have a closer look at the dev kit and see if I can find some way of getting it to talk to a Linux box. If they have a dev kit for Linux, I'm assuming there is some way of doing it, even if it isn't pretty.


More of DES in Scheme on the brain, but not written yet. I'm nowhere near as motivated as I was a couple of years ago. I've got stuff to do tomorrow (or later today, if you prefer), but hopefully I'll be able to put thought to phosphor on Thursday.

Back online

One of the filters (happy little cylinders that keep you from getting the channels you don't pay for) on my cable line died (or did whatever dying filters do), so I've been off-line for over a week. I'm a little choked that it took them this long to send someone out to look at this, but lousy customer service from the local monopoly is pretty much par for the course.


I still haven't heard anything on the job front. I got in touch with the folks doing the hiring last week to let them know to contact me by phone, but that's the last I've heard from them. I'll hopefully hear something more soon.


Debian is working great on the iBook. I've figured out how to make WindowMaker do what I want it to (wrt. the dock and clip), so I'm a happy camper.


I've been somewhat productive with Scheme recently. I took a good, hard look at CLisp and Gauche side by side, and tried my best to evaluate each of them based on the features I actually use (rather than those I simply think are cool, or are the "right thing"). As it stands right now, Gauche is getting most of my attention.

After my review, it seems that most of the features I actually use in Common Lisp are present in Scheme through the SRFIs. Given that the portability of R5RS + SRFIs seems better than the portability of CLtLx and/or the ANSI spec between implementations of Common Lisp, it seems a natural choice.

I still find it annoying that there is no standard network/sockets interface, but that's something I'm willing to live with (for now).

All that being said, I started implementing DES in Scheme. DES is pretty useless, but I'm doing this as a learning exercise, rather than to generate useful code. So far I have got a lot of typing done (the permutation tables, the s-boxes, etc.), but not much that works. That comes after I finish writing the semi-weak-key list...


Perhaps it was just the boredom of not having a net connection, but for some reason, the long function/sf names don't bug me as much anymore. The other arguments still stand, though the SRFIs pretty much make them redundant.


raph: I'm sorry to hear about your community's loss. I must admit to not knowing much about your faith -- can you recommend a good introductory work, preferably on-line?

3 Dec 2002 (updated 3 Dec 2002 at 22:33 UTC) »
Pining and scheming

jdybnis: You are absolutely correct -- if my main problems with Scheme are long function and form names and a piddly standard library, it's easy enough to make Scheme what I want it to be.

Where I'm at right now is trying to decide if I want to bend CLisp or Gauche to doing my bidding. I just built Gauche, and I'm thrilled. It wouldn't build under Darwin, and I didn't have time to play with it.

Given that Gauche supports many of the SRFIs out of the box, the standard library problem is at least partially addressed. My last experience with the SRFIs was trying to get the reference code working with MzScheme, which was a nightmare.

Update: Four SRFIs go final

I just had a look at the Final SRFIs page, and four new SRFIs have been promoted. If you've been frustrated by the lack of exception/condition handling in Scheme, it's worth a look at these four.

GNUstep googling

I did a little bit of work with GNUstep to try to figure out the real differences between it and Cocoa. So far I haven't run into anything that couldn't be conditionally compiled. I know the last time I tried it on OS X (admittedly, from PB) it didn't like ifdefs for portability (such as switching between IBOutlet and id), but I'm sure that's something people would have complained about enough for them to fix.

My best friend so far has been Google (go figure). So far I haven't run into anything that couldn't be solved with Google, but then I haven't played with NSDistantObject yet.

Uncommon Lisp

I just compiled CLisp 2.30 and everything went just fine. I didn't compile libsigsegv to go with it, largely because I have traditionally had problems building it on PPC boxes. Besides, if I run into segfaults, I know I'm doing something wrong -- most of the time, at least.

I did a search for "Lisp DNS" and it turned up a couple of reasonable hits, but not enough to stop me from thinking about coding up a DNS server of my own. If I do any work in Common Lisp, it will likely target CLisp in the areas where it has to, as I don't know of another CLtL1+ Lisp that bootstraps from C. (Unless SBCL does now?)

Job front

Got some more work done on the Perl sample code for the possible job. They wanted to see a couple of examples, but I'm going to hand in about half a dozen small-to-medium files. I've purposely chosen things that are easy to test and the behaviours of which are well-known, but that does make it difficult to keep on task sometimes.

Fortunately, I don't have to send it in until early tomorrow morning, so I've got some time to play with it. I don't know whether to write more sample code or to write a test suite for what I've got already. The latter is probably better, so that's likely what I'll do next.


I've been quietly keeping up on the Parrot CVS tree, but I'm winding up with four test failures. It seems odd that Darwin would test clean, but Linux wouldn't. I'm pretty sure it's the GC that's messing things up (in this case, collecting something early, I'm pretty sure). I'll have a deeper look at it after I've got the sample code done.


Still no action on the Arc front. It's not that I doubt Paul Graham and company's ability to pull it off -- it's more that I doubt that it'll happen any time soon. If I had to put money on it, I would say it will likely become publically available in September 2003, though this is one time I'd love to be proven wrong.

I may still start work on an Arc-like language of my own, if for no other reason than to provide a loyal opposition on simple matters such as syntax. I definitely couldn't challenge Paul et al. in any significant way.

Pining, fjords, and all that

I've been through several "I'll hack up something like Arc/no I won't, 'cause I've got X" cycles, and it's only been recently that I've really figured out that I'm after. Or some approximation of that, at least.

What I'm after is a syntax-free (in the same way as Lisp) language that has a reasonable (as in not too big (Common Lisp) and not too small (Scheme)) standard library that includes sockets, as much interaction with the OS as the OS can support (system calls, environment, etc.), a decent garbage collector (even pure reference count would do -- I can break circular dependencies on my own), decent session scripting abilities, incremental compilation, a half-decent debugger and trace facilities, and can easily be built from sources (even if it takes an aeon).

My other big complaint with current implementations of Lisp and Scheme are the function and special form names. Don't get me wrong -- cons, car, cdr, let -- these are all great. call-with-current-continuation and concatenate are far too long, especially with how often the latter is used.

I have played around with a number of naming conventions, and I have to admit a preference towards an abbreviated version of the modern Scheme syntax -- call/cc is a good example, and substr/sh (instead of substring/shared) would be another good one. cat/sh is fine for a shared-string concatenation operation, with cat/cp as the copied string name would work, with plain old cat defaulting to one of the above.

I know that Lisp and Scheme evolved such long function and special form names under the assumption that LispMs and editors would automatically complete them. However, even with (G|X)Emacs, Jabberwocky and other projects out there that specialize in Lisp, we still don't have that.

Rather than trying to redefine computing to suit Common Lisp and friends (as much as I love most of them), I think it's more realistic to define a variant that works well with today's tools, rather than vice versa.

Memory leaks replaced with new memory leaks

I tried to recompile the Darwin kernel (mostly because ktrace is so useful, and not supported by default in X.1.5) and wound up with a kernel that wouldn't boot. The worst part is that the backup kernel I saved wouldn't boot, either.

That being said, I'm now running Debian, where I have strace and many other tools at my disposal that don't work so well on OS X.

Bug reports

I'm watching the back-and-froth (typo intentional) between MichaelCrawford and movement with a bit of interest. Though I am by no means a contributor to Mozilla (up 'til recently it wouldn't work on my platform), if I were, I would be somewhat offended to get a bug report that did more complaining than anything constructive. That being said, I would follow the issue up though personal mail after closing the bug report in Bugzilla, rather than posting publically. Different strokes for different folks, I guess.

I find myself in agreement with moshez, though -- well said, sir.


Re-restarted the sample code for the new job opportunity last night. I'm somewhat annoyed that I hadn't backed up before trying something dangerous, but I guess if you don't screw up for a while, you get cocky and wind up borking something or another.

The good news is that I managed to somewhat tighten up the code on the rewrite, and a structural change or two got made that I was planning to make anyway. I intend to turn in the sample code on Monday, so with any luck I'll have time to get some good testing in. I'm trying for a couple thousand lines of code, and if I can't get that from the main project (a Wiki-like system in Perl, with a few rather non-Wiki concepts worked in), I'm sure I can figure out something else to hack together to take up the slack.

Another item on the code front is getting used to the difference between Cocoa and GNUstep. I'll miss Interface Builder, but to be honest, I spent more time hacking in PB and doing "Read files..." in IB than the other way around. I still haven't done much of a search for UI building tools for GNUstep, so hopefully one will turn up.

Memory leaks somewhat solved

On a whim I decided to login via console and start X11 from there. What a difference, not running in rootless mode (over OS X)! I think that's where I'll likely spend most of my active development time. It's not as pretty as Aqua, but that seems to help me keep my focus -- a few xterms, a copy of XEmacs running, and no distractions.

Upon restarting Aqua, I noticed that the memory consumption (both physical and vm) had fallen way down. Methinks I'll have to make a habit of that.

Text editors, Eastern Orthodox style

I grabbed a copy of THE (The Hessling Editor) and installed it. Now we're talking nostalgia! I used to own an IBM System/36, so it felt just like home. However, I must admit that I really am quite rusty, and find XEmacs much nicer to use for day-to-day coding. Besides, I'd sooner use elisp than Rexx anyday.


Put in a bit more work on pfft today. The user auth and admin stuff is partly done, and I've got a few handy HTML functions blocked out and ready to fill in. I'm still trying to decide on a good scheme for indexing the data directory. I think simplicity is the way to go, so I'll probably hack together a few simple schemes and benchmark them to figure out which one is most friendly.

I tore out the last vestiges of DB_File and replaced it with much nicer code. I still need to have a boo through the sources for the BSDs and Linux and see where flock() and close() can fail. I know the conventional wisdom is to check everything, but I seem to remember someone wise saying not to check for an error condition you don't have a plan to handle...

For all of my railing against people using DBMSs for trivial applications, I guess I understand one part of it now -- the DBMS takes care of these things for you. Part of the point of pfft is to avoid such things, though. Not to mention that it's good to get a refresher in concurrency issues and race conditions every now and then.

Memory leak madness

Okay, I just might switch to OS X.2 after all -- if for no other reason than the hopes that its libs don't have the kind of memory leaks X.1 seems to. Under X.1 a process (in this case, XDarwin) will take 18 meg at start-up, and slowly balloon to 80 meg. No telling if it stops there, as I only have 384 meg of RAM on my regular machine, and don't let it get that far.

I'm going to try logging in on the console and starting X from there, and see if it's just Aqua and associated stuff leaking. I trust Apple not to have leaks in libc, libSystem, and libobjc, but what information I've been able to find on Aqua suggests that the problem may lay there.

Text editors, yet again

I got my hands on the XEmacs 21.5 sources, and while they compiled okay, it barfed on the floor when I went to use it. No problem -- I grabbed the 21.4 sources (and the sumo package), and everything was fine. Things are looking a lot better since 21.1, especially in the configuration menus.

I also spent a sickening amount of time looking for info on what controls syntax highlighting in Project Builder. If I could just get it to syntax highlight Ruby, Perl, Lisp and Smalltalk nicely, I would happily use it as my primary editor.

If anyone has any insight on syntax highlighting in PB, please let me know -- though I fear it is non-hackable (embedded in a NIB file, or somesuch).


A little more done on pfft (a Wiki-like system written in Perl), mostly realizing that with the overhead of using DB_File and trying to figure out locking issues, I may as well just use flat files and flock(). I pounded on my calculator a bit, and figured out I could handle logins and session IDs for 100k accounts pretty smoothly with flat text files, and ten million accounts if I abstracted the login and session functionality out to a daemon and queried from the CGI to get the info from the daemon. I may do a combination of the two (if the daemon can't be contacted, auth through flat files), but that will be in the "showing off" category, rather than the "working for 1.0" category.

4 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!