Older blog entries for deven (starting at number 33)


I was so focused on getting the initial release out the door that I plum forgot the most important thing! I forgot to test the release! Damn thing didn't even compile. D'oh!

The reason is simple; there was a class named Assoc which implemented hashes (which used to be better known as "associative arrays", hence the Assoc name). Before the release, I decided I should rename the class to Hash to avoid confusion in terminology. I fixed all occurences of "Assoc" of course -- but I failed to notice that there was a Hash() function in the class. It was a private class method used for the hash function, but of course the C++ compiler thought it was a constructor, since I inadvertantly created that collision. I've fixed it now, renaming the Hash() method to HashFunction() to remove the conflict. Unfortunately, this makes the initial release a "brown paper bag" release -- not an auspicious start. *sigh*

This underscores the exact reason why I released it as a beta version (1.0.0.beta.1) instead of as a stable release (1.0.0) -- I didn't want any stable release to ever have a dumb mistake like this in it, so I decided that by policy, a stable release would always be identical to a development release, except for the version number.

There have been several serious bugs in the Linux kernel "stable" series which slipped through because untested code was added to the "stable" release. I wanted to avoid that. And I did -- even though the basic codebase is very stable, there were changes in the released version from the tested-but-unreleased version. Most of the changes were in the comments at the start of the files, but some involved actual code changes. Simple ones (like renaming some source files, occurrences of the system name, Assoc->Hash, etc.) but obviously not completely immune to error.

I guess I've proven the value of my stable release policy, but I wish I had been alert enough to remember to build and test the server before posting the release. Oh well. The new release (1.0.0.beta.2) does compile and run correctly. I tested it this time.

I still need to write more documentation, of course...


Well, I finally managed to put together the initial release for Gangplank. A basic homepage is online along with the initial tarball. I've created an Advogato project page, and submitted the information for a Freshmeat project page, but that hasn't been processed just yet. If anyone gives it a try, please let me know in email, since I may not notice diary entries...

Life is always so busy, but the driving impetus to finish it today (well, yesterday now that it's past midnight) was because original development of the code started 9 years ago today, on November 30, 1992. (Well, I released it on November 30; I didn't get around to dealing with Advogato and Freshmeat until after midnight, so nobody heard of it on the day of release!)

In the end, I decided to abandon the complex versioning scheme that I worked so hard on -- it was all-numeric, and required too much knowledge of what significance different numbers had. I've discussed this with others, and came to the conclusion that I'll use all-numeric version numbers for stable releases only, and always have alpha characters in development/test releases to differentiate them and allow for complex yet comprehensible information in the version number (ok, string). The initial release is 1.0.0.beta.1 -- eventually, 1.0.0 will follow (a stable release) as a re-release of a 1.0.0.beta.x release.

I still have a lot of documentation I need to write, but I get tired just thinking about the scope of that task! I'll have to get to it before I'll be willing to declare a 1.0.0 stable release, however...


My former employer laid off 30 employees yesterday (including most of upper management!), including the one (geoffeg) who I've kept most in contact with since I left in March 2000. He's now looking for a job at a time when they're much harder to find than they used to be...

Egads. My certification is back to "Journeyer". How confusing. Oh well; as long as it's not "Observer", I don't really care what it says.

I've had a busy month for various reasons, and was out of town for a while, so I haven't made any progress on getting together an initial release of Gangplank. I'm still a little unsure how I'm going to handle the release version numbering, and I hate the idea of changing the versions after the initial release. I'd much prefer to nail down the scheme I'm going to use first, but I keep dithering on it.

In any case, I'd better get back to this soon...

A long day, and no progress today. Had to take the dog to the vet, which took a couple hours, then the search for food even took another hour. No time to do anything useful tonight...


Well, I was hoping to get a release together in time for the nice simple release date of August 1, but it didn't work out that way. It's taken more effort than I expected. Oh well, so much for nice simple dates!

I've wasted too much time contemplating version numbering schemes, for one thing. I've come up with a scheme that I think would be neat for the Linux kernel, but it's serious overkill for my project. Nevertheless, I'm gonna use it anyway. Something's gotta be the guinea pig! I've got a good description written up for it now; it's amazing how many hours this part alone took... (I'm sure it's too complex for my own good, but I wanted to give it a try.)

I still need to review the code to make sure I don't release anything overly brain-damaged to the world. I have a couple known kludges that I'm considering trying to clean up before the release, such as having the help text hardcoded into strings in the executable! There was a good reason for this; I've been extremely wary of the possibility of blocking file I/O, since the server is single-threaded. However, there's nothing to stop me from reading it in during the server initialization code (except lack of Round Tuits). It would be cleaner that way...

And there are the more mundane things, like renaming the system internally, stripping old RCS log messages from the source code (should I keep using $Log$, I wonder?) and applying the QPL license to each module. (Yes, I'm starting with the QPL, at least for now.)

Then there's documentation, of course. The only documentation that I have at the moment is the description of the versioning system, which turned out to be fairly difficult to write up in any sort of comprehensible fashion. (It's hard enough to read now, but the earlier drafts were much worse.) I still need to write at least some basic documentation. (A code overview would be nice too.)

And I haven't even gotten as far as worrying about things like CVS, a web site, mailing lists, or any other auxiliary things. I'm just trying to come up with the initial tarball! *sigh*

I suppose this was inevitable; the project is nearly nine years old, and I never really expected it to be easy to put together a clean release archive. But I wish it were easy, all the same!


I still haven't had a chance to work on this initial release, largely because my grandmother is here from out of town. Besides, I've concluded that I shouldn't post it today, even if I had it ready by now. I'm going to be out of town from Monday morning through Friday afternoon, and I may not have Internet access. To be on the safe side, I'd rather not release it until I'm back, since I wouldn't want to appear unresponsive to anyone that might try to contact me about it!

I've been trying to get an initial release of "Gangplank" together for close to a week now, but it's been more complex than I expected. I need to review all the source files briefly to check for anything that shouldn't go out as is, change the name throughout the program, decide whether to fix a couple kludges before it's seen, try to write some basic documentation, etc. What a mess!

I'll probably try to minimize the initial work by making a pre-1.0 release first, and add documentation from there in later releases. Of course, I've got to decide even how to number the releases! While I could punt and do something typical, I've been thinking of ideas for complex-yet-informative version numbering. I was originally thinking in terms of the Linux kernel, but I figure it could be used for any project, so I might as well experiment on mine! (Of course, the numbering scheme I'm coming up with is so terribly complex that it's really only appropriate for a large, complex project, but what the hey...)

Well, I'll get there sooner or later here.

Lots of birthdays this week. Besides hacker on Monday, one of my best friends hada birthday on Tuesday, my wife's birthday was yesterday, and my brother's birthday is tomorrow! (Nobody that I can think of for today, though!)

hacker: Happy birthday!
vab: Actually, the original name of the system was "conf", back when it was still a single-module C program. Now it's C++ in a number of modules, but I did change the name in the source when I decided to use "Phoenix" instead of "conf".

Anyway, I am going to just release it, but I'm not sure about exactly how I should package it, and what release number to give it. Plus, I'm not sure if it would be auspicious to release it today, being Friday the 13th. :-)

I think I'll make some sort of 0.9 release. I would call it 1.0, since the current codebase has been in production use (albeit very lightly!) for years now. However, there's probably enough rough edges that 0.9 makes more sense for the moment.

By the way, vab -- you're marked as an Observer, though you were listed as a Journeyer two days ago. You're not alone, either...

Here's everyone who's been downgraded since Wednesday:

ewan: Journeyer -> Observer
jbowman: Journeyer -> Apprentice
vab: Journeyer -> Observer
gmc333: Apprentice -> Observer
opiate: Journeyer -> Observer
jlf: Journeyer -> Observer
rao: Journeyer -> Observer
sphair: Journeyer -> Observer
zodiac: Journeyer -> Observer
mhatta: Journeyer -> Apprentice
larva: Journeyer -> Observer
philhunt: Journeyer -> Observer
mml: Journeyer -> Observer
PhOeNiX: Apprentice -> Observer
jamie: Journeyer -> Observer
andrewmuck: Journeyer -> Apprentice
jorrit: Journeyer -> Observer
hv: Journeyer -> Observer

I don't want to debate this again; I'm just presenting the information. (There were also 10 people who jumped from Observer to Journeyer during the same time period.)

dmerrill: Thanks for being fair. I'm still not sure how it helps anyone to spread an inconsequential vote thin. I know it doesn't count certs from non-Masters to determine who becomes a Master, but do those Master certs drain away "capacity" when calculating the lower levels? After all, the Masters will often be best-known and most-certified; if much of the voting power drifts back up to the Master level, does that explain why there are fewer Apprentices? (Just a guess...)

I think LDP is an important project, and I can write decent documentation, but it's draining and really not one of my favorite things to do. I have yet to write the full user documentation for my conferencing system, for example. If there's something particularly interesting that I know well where there's a vacuum, maybe I'll contribute some docs, but I'd be more likely to contribute on the code side usually.

As for what projects to volunteer for, I don't really know. I'm wary of overcommitting my time, but I'm also not sure how to pick a project -- what makes any given project more worthy of time and attention than the next? Unfortunately, it probably comes down to working on whatever captures your attention and "seems like a good idea at the time". The advantage of finding something sufficiently interesting to work on is that you might find more time to work on it, if it's fun...

If you have specific coding projects/tasks to suggest, I'll certainly listen. I'll tell you that my coding inclination tends to run more towards building solid infrastructure (often reinventing the wheel even if I don't need to) rather than worry about making things flashy. I'd rather have a no-nonsense piece of code that is rock-solid and robust than a fancy, pretty interface to unstable flaky code that may crash at any time, for little to no reason.

I often prefer to write new things from scratch, since I often find that I don't like a lot of the existing code out there. Much of it seems poorly designed and/or poorly implemented, and it often seems easier to toss it out and write it from scratch than to fix the myriad problems that are often found in existing code. (Like Mozilla had to throw things out and start over, for example.)

So, I'm more likely to be interested in implementing code where a small project would be created to solve something, or where some clearly-defined module in a larger project needs to be created from scratch or rewritten. I can also debug and enhance existing code, but it's often much more frustrating, because I'll keep running into things that bother me about the code...

dyork: Yes, let's drop it. At first, I was interested in discussing it on a theoretical basis, because it sets Advogato apart -- there are interesting questions about how well the system works and how it might be improved, but I'm tired of debating it.

Basically, I don't care about certification either; I'm interested in the certification system as an architectural feature of this site, and I'd like to see it work "correctly", whatever that ultimately means. I couldn't care less what level I'm certified at, but I would prefer to remain certified, given the restrictions when you're not. It's because I had been certified long ago that it seemed that something was amiss; if I was still waiting for certification, it wouldn't have concerned me. Oh well...

Thanks for the opinion about "gangplank". I still think it's an odd name, but that's not necessarily a bad thing. I think you're right; I've got the domain, I might as well just run with it. (And if a better name really does come along, I'll just have to decide at that point whether to rename the project...)

I think I'll just go ahead and release it under the name "gangplank" since I have no better ideas. It will take a little effort to prepare an initial release, but I'll post a note here when I release it...

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