I just finished hacking up a new feature to boinkmarks. It now has an atom feed that reports significant changes (that is, more than 2s) in SBCL benchmarks. It should be on planet.sbcl.org soon. If you want to watch SBCL performance yourself, subscribe to http://sbcl.boinkor.net/bench/atom/ with your favorite RSS/Atom feed reader.

(roughly alphabetical) The problem of Arch is that its main implementation was once a shell script and is now a C program. The problem of Darcs is that once you get over the QUANTUM PHYSICS shock, it’s just another version control system. The problem of CVS is that you don’t want to know why it works. The problem of Subversion is more of the same.

It’s not like Muse is a bad program or anything, but in the last year of using it, I’ve had a few (HTML) compliance issues too many. Another problem was that there are a few things that are really hard to express in a plain text file —- there are better user interfaces for things like a change date (and a creation date). Anyway, I installed movabletype now. I think I should I feel a little guilty now for using something non-lispy (in fact, dumping something lispy for a perl thing).

McCLIM 0.9.1 was released today. I have hopes that the next (time-boxed) releases will work as well as this one. That means it is time for you, dear reader/hacker, to write neat McCLIM-using applications. Making one that does useful things is really easy.

Kevin Rosenberg is putting 100 debian packages up for adoption. That means that, among other packages, these are now without an official debian maintainer: cl-asdf cl-interpol cl-irc cl-pdf cl-ppcre langband sbcl You can get a full list of packages in his weblog entry. If you are a debian maintainer or you plan on becoming one, there’s a lot of (high-quality, and high-profile) stuff available for you to take on.

I’m registered for the Amsterdam Lisp Meeting . You should come, too.

At last I managed to release Autobench, the incremental benchmark runner that powers http://sbcl.boinkor.net/bench/. Get it at http://boinkor.net/lisp/autobench/autobench-0.4.tar.gz. This version includes support for benchmarking CMUCL and SBCL. The README should tell you most of what you need to know. By the way, it’s nice to know that the protocol I mentioned in the 2004-11-22 entry is sustainable. The implementation of the benchmark protocol for cmucl snapshots is about 90 lines of lisp code (which unfortunately is pretty ugly, due to some suboptimalities in cmucl snapshot packages).

Upgrading McCLIM (or even hacking on it) is hard work for your computer. That’s due to the use of :serial t in the system definition that manages to be compatible to ASDF (which has an idea of “real” dependencies) and other defsystems (for example, MK:DEFSYSTEM and the ones in LispWorks and Allegro CL) because of this. So whenever you update a file, your defsystem must recompile all the files that are listed after it in the McCLIM system definition.

Today, Kevin Rosenberg asked on IRC how to prevent code insertion when READing data from a string. A solution to that problem is binding *READ-EVAL* to NIL in code using READ. Now, that got me wondering: which other security pitfalls are there in lisp? These are the other READ-related ones that came up in the discussion that followed: READ can intern symbols in packages other than the one you want it to (could lead to bugs further down in the application)

A few months ago, Christophe suggested that autobuilding/autobenchmarking of CLisp would be nice to have in Boinkmarks. I tried, but couldn’t make it fit into the ugly bunch of shell scripts. This was when I decided to rewrite them in Common Lisp, and to add a nice web interface using araneida. That is now finished. See the results at http://sbcl.boinkor.net/benchmark/ (old version, for contrast). So, was it worth it? The rewrite doesn’t bring me that much closer to my goal of actually benchmarking CLisp; but adding that functionality is now much easier with the new CLOS-based protocol for building/caching/benchmarking implementation binaries (especially when compared to these ugly shell constructs).