Some of you may have noticed by now that this site is quite often down. I just wanted to give a brief explanation for this. This site certainly could be more robust, but, at least for the moment, I'm running a development instance of hunchentoot on one of the generally less-well supported SBCL platforms, FreeBSD, and am using things like my hunchentoot-cgi interface and nuclblog which certainly haven't been well tested, and probably aren't used by anyone else either. All this adds up to a lot of moving parts that occasionally fail in less-than-graceful ways.

In fact, just today the site crashed because SBCL ended up in LDB. I try to avoid this and try to reset the thing soon after this happens, but occasionally a good chunk of time passes. Until recently, I was seeing very frequent failures in which SBCL would run out of processes and the server would die. It turns out this was caused by hunchentoot-cgi and the way it was calling sb-ext:run-process. By calling sb-ext:run-process with :wait nil, the problem seemed to go away and all was right with the world for a couple of weeks. I'm not sure what's up with the latest failure and will keep on eye things to hopefully minimized the downtime if the server ends up back in LDB again.

Why am I using hunchentoot-cgi, you ask? Well, that seemed like the easiest way to use gitweb on my current setup. Hopefully it won't cause to many other problems. Thanks for your patience to this of you who actually might want to access the site.

[some years pass...] So, thanks to some gentle prodding and patches from Daniel Herring, I've finally gotten around to making clem and ch-image run on lisps besides SBCL. In particular, they both work on ccl and clisp, with ecl support hopefully not too far behind.

A combination of bogus things on my part, the occasional bug in the lisp implementation itself, and idiosyncrasies of the spec meant that various things didn't work right. The most-common offender was that I was assuming that things like double-float and fixnum defined classes, and that one could use these as method specializers. Apparently, the lisp spec says otherwise.

Also, there were a few bugs in ccl, especially in the 32-bit x86 version, that the ccl team fixed straightaway that allow trunk builds of ccl to load and run clem and ch-image. Thanks to R. Matthew Emerson for the prompt fixes and to Gary Byers for the helpful discussion about whether or not (setf (find-class 'foo) (find-class 'bar)) should create a new type for foo.

In any event, clem can be found at http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=clem.git and ch-image at http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=ch-image.git.

I should point out that these changes haven't found there way into official releases, per se, so if you want to use this stuff on ccl, clisp, ecl, etc... make sure you get the latest source from the git repo.

So now that I have more than a passing interest in chemistry (and therefore cheminformatics/chemi-informatics/chemoinformatics/whatever-you-call-it), I'd like to see what the state of the art is for representing chemical information and if there are any decent libraries for working with these representations. At first glance, I'm in luck. There's CML, the Chemical Markup Language, there's the Blue Obelisk set of projects for open source/open data/open standards in chemsitry, and there's the CDK, the Chemistry Development Kit. This all sounds promising. Let's dive in.

Working in reverse order, let's start with CDK. Google CDK and it shows up as the first hit -- even before the Cyclin Dependent Kinases. This is good. Now let's follow the link. Uh oh. It's a link to sourceforge. That's alright, we'll click through and hope for the best. Ah, not only is it on sf.net, but it's a wiki site: http://apps.sourceforge.net/mediawiki/cdk/index.php?title=Main_Page.

Ugh. Alright, I'll try to overcome my biases and keep plugging away. It's not that all wikis are bad, but rather that, IMO, they are a poor substitute for a properly designed web site for a project. They certainly have a place, but the idea that all web content gets wiki-ized can lead to some rather difficult-to-follow web pages, again, IMO. The wikipedia example is a good counterexample to my claim, but, most other wiki sites don't have the complete, polished feel of wikipedia. In any event, let's keep plugging ahead with CDK.

Ah, here we go. Two publications in the peer-reviewed literature. This should help give us an overview of what CDK has and where it is going. One is in the Journal of Chemcal Information and Modeling (although it seems that when the article was published it was called the Journal of Chemcal Information and Computer Sciences. Alright, sounds promising. Click through the DOI link, which takes us to a page of American Chemical Society, the world's largest scientific society. Surely, this being a paper about on open-source toolkit and ACS being a society for the betterment of society, this is going to be an open-access journal, right? Or at least an open-access publication in a mixed-access journal, right? Click on the link to get the PDF... Get PDF -- WRONG! $30 for 48 hours of access. Damn. Ok, well, let's get the other paper, there were two on the CDK wiki. The next one is in something called Current Pharmaceutical Design. Uh oh. This doesn't sound promising. And, sure enough: "The full text electronic article is available for purchase. You will be able to download the full text electronic article after payment. $55.10 plus tax." This isn't getting us anywhere. At least CDK is open source. Let's go get the source. Well, first let's browse the documentation anyway.

Click over to the documentation look on sourceforge: http://apps.sourceforge.net/mediawiki/cdk/index.php?title=Documentation. How is the documentation different than what I was looking at before, or what's the difference between the documentation and the main page? Who knows. In any case, this looks promising: "A great source of CDK documentation or introductory reading is the CDK News, the quarterly newsletter of the CDK team." Click through. Ok, there's a picture of the (presumably) most recent issue, which is a link to the table of contents and a note about getting the PDF: "The full issue can be downloaded as PDF from http://sf.net/projects/cdk/". Hmm... Ok, click through that... And we're back on sf.net. Oh wait, that's not a link. Just some text. Cut the URL and paste into the nav bar in the browser... Hmm. Now we're at another sf.net page. So far we've got the "main" page, the "documentation" page and now the, presumably, "project" page. But now that we're there, we see that there is no mention of CDK News on this page. Damn. Alright, let's start clicking and see what we find. Ok, under the "Download -- Browse All Packages" link we get to a page that has CDK News on it. Maybe now we're getting somewhere. Click through that and we have a nice list of the various "Releases" of CDK News (this seems like an abuse of the Release mechanism, if you ask me -- these aren't different versions of the same thing, rather distinct issues, all of which shoud live on, but, OK, I think I see what they did there). Let's start at the beginning. Click on 1/1. Hmm... That just expands the HTML a bit to show another link for cdknews1.1.pdf. Ok, click that. Ah yes, no I remember why I hate sf.net. Do I get the PDF in my browser? NO! I get a window with a whole bunch of orange reminding me the name of the web site I know hate so much, some links to "share" the project (whatever the hell that means!), for related stuff and for forums (yet another set of pages to not get the info I want?) some google ads and some guy who looks like he hasn't slept in a week carrying stacks of cash, presumably, in an ad for nortel. Oh, and I link telling me who's providing this oh-so-handy mirror. Oh, and I almost forgot, some nice sponsor links! As opposed to the ads, I suppose. Where's my damn PDF? Who knows. Ah, this is helpful. Please use this "direct link": http://voxel.dl.sourceforge.net/sourceforge/cdk/cdknews1.1.pdf. Why the hell didn't they just give me that link the first place??? Ok, finally got CDK News 1.1. I suppose a (direct) link off of the CDK home page (or at least one of them) would have been to helpful for irritating newbies like myself. Ok, time to go read the first CDK News, since I can't get the peer reviewed articles about the project. More later.

The TIFF image file format has been around a long time, and lisp even longer. Yet, I couldn't find any common lisp libraries for reading TIFF images. Perhaps there's one out there I missed, but the only one I could find was my previous attempt, tiff-ffi, which consists of some wrapper functions around FFI calls to libtiff. I wanted a native common lisp TIFF library that wouldn't require the libtiff library so, at Robert Strandh's urging, I wrote retrospectiff.

The retrospectiff git repository can be found here.

Currently, there is no support for writing TIFF files, and only a fraction of the TIFF image formats are supported, but RGB and ARGB images, both uncompressed and with LZW compression, can be read. Grayscale support should come next and, hopefully, support for writing TIFF files before too long.

Enjoy.

So, attempting to get on MUNI this morning, I had a fun experience trying to actually purchase a ticket. To recreate the problem, try buying a ticket to get on MUNI at the Embarcadero station with only a US $10 bill. Turns out, you need to pay for your ticket with coins only.

Ok, so how do you get coins? Well, there's a machine that takes $1 bills and gives you a $1 coin. Has to be the only change machine that doesn't in fact give you "change", at lost not as one might expect, but rather changes your bill into a coin. Oh, and the machine takes $5 bills as well. Great. But I've got a $10. Now what?

Well, let's ask the oh-so-helpful person on the other side of the bulletproof glass talking at me through the loudspeaker. Why they have bulletproof glass when they only accept coins is a mystery, but that seems to be the case. In any event, she tells me I have to go over to the BART change machines which only accept $10 and $20 bills and use those machines which, much to my surprise, actually give out $5 bills in exchange for the $10 and $20 bills. Again, a new twist on the change machine. I've never seen a change machine that takes bills and gives you more bills, just as I had never seen a change machine give you a dollar for a dollar, but, OK.

Great, now I've got a $5 bill. Now what? Ok, go back to the $1/$5 change machine and get 5 $1 coins. Perfect, but, with the BART transfer, I only need $1.25. What do I do now? Well, ask the oh-so-helpful lady, of course. And, of course, she sends me back to the BART change machines. Well, OK, not the BART change machines, but the BART ticket machines, where you put in your dollar coin and then hit cancel and, lo and behold, the machine gives you 4 $.25 pieces for your $1 coin. Amazing.

All of this instead of just being able to buy a card that would automagically charge my credit card when I got on the damn train. Well, I guess such a thing might exist, but you certainly can't buy it at the train station, at least not at Embarcadero. All you have is a BART ticket station with signs all over the place saying NO MUNI TICKETS. So, it's not like a bunch of other people haven't tried to show up there and buy MUNI tickets, but, instead of, oh, you know, figuring out how to sell MUNI tickets, they put up a sign telling you to f**k off and leave you to go talk to the scary people behind the glass in order to figure out how to use three change machines to get the exact (coin) change required for the train.

Look, I'm all for SUPERTRAINS, but perhaps we should start by firing whomever is in charge for the ticket collection at Embarcadero MUNI and then we can work on a decent rail system for the bay area.

From tonight's Kirin takeout: "You will be showered with good luck before your next birthday." Well, let's hope so anyway.

So, now that the presidential race is heating up, what, exactly does it mean to "play the race card"? The McCain camp is accusing Obama of doing this, but I don't know what this even means and everyone talks about it like it's obvious. What are they trying to say here?

This one is pretty funny:

Ok, after a couple of years... I've finally gotten around to incorporating (some of) my changes to the cl-jpeg library into the upstream sources. There's a new version (1.023) up on the common-lisp.net cl-jpeg site.

To go along with this, the latest git sources of ch-image now use cl-jpeg.asd instead of my hacked up jpeg.asd. My jpeg project will now disappear and should be replaced with the upstream sources.

I know, I know... Why on earth would you want to run CGIs from hunchentoot? Well, while it may seem counterintuitive, I've found a need for this as I want to run the gitweb cgi interface behind hunchentoot and don't feel like setting up apache as the front-end to an otherwise happy hunchentoot site (this one), so I rigged up a little CGI interface for hunchentoot.

To use, check out the hunchentoot-cgi::create-cgi-dispatcher-and-handler function.