(This blog entry is outdated. The currently recommended way to get lisp software and its dependencies is quicklisp). Outdated information It has been brought to our attention that asdf-install is still thought to be the preferred way to install cool lisp software. I would like to use this space to advertise an alternative tool that too few people know about, and that allows you to almost instantly (OK, as fast as your computer can install the required software and download & build the packages) get you up and running with and get you updates of the newest in cool lisp packages.

ASDF(reference manual) is a fine piece of software: I like to use it, and find some of the design choices in it to be very good (besides, it’s the thing that has allowed things like clbuild and asdf-install to grow). However, it is now in wide enough use that people are looking at its internals and are scratching their heads when finding some not-so-very-good design choices. Here’s a selection of the things that I think would be good candidates for review in a new version of ASDF (bsdf?

I recently discovered that several of my (programming) friends know no string search algorithms other than the naïve left-to-right, one character at a time scan. There are much better algorithms out there, among them the one by Boyer-Moore. When I first heard about Boyer-Moore, it made me realize how easy it is to overlook opportunities for optimization – I hadn’t thought it feasible to speed up string search, either. In order to allow others to see the beauty of it, I made a little CLIM visualizer app for string search algorithms, to use in a little intro session to good string matching code.

I gave in and updated my lisp hacking-related emacs configuration today. These three snippets make my life easier now: Turning off the “unsafe local variable” warning for common lisp source files. Several packages use the -*- convention to set the major mode; some also set variables like Package, Base and Syntax. Emacs 22 doesn’t know that they’re harmless and prompts almost every time I open a new lisp file. Ugh. Use this: (put 'package 'safe-local-variable 'symbolp) (put 'Package 'safe-local-variable 'symbolp) (put 'syntax 'safe-local-variable 'symbolp) (put 'Syntax 'safe-local-variable 'symbolp) (put 'Base 'safe-local-variable 'integerp) (put 'base 'safe-local-variable 'integerp) and remove all those unnecessary safe-local-variable-values customizations.

I’ve announced the git repository a few weeks ago. Here’s something very nice you can do with it: Run a binary search on revisions to find out the version of SBCL that caused a bug. This helps enormously when searching for the cause of bugs. You can use the CVS repository for this, too, but it doesn’t include any of the nice functions I mention in this tutorial; you need a start time and an end time, and do month/day/hour/minute calculations yourself.

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)

My workplace just gave me permission to open-source two projects I did for them. One is screen-scraper, a rudimentary (but extensible) vt100 terminal emulator for lisp (BSD licence, sans advertising). The other is debian-security-updates, a netsaint/nagios plugin and debian security update SNMP agent adaptor (GPL). Wow. Lots of nouns in that last sentence.