Installing clbuild

After frustration with using an older version of sbcl and using asdf-install, I decided to try clbuild.  clbuild is a shell script that allows me to keep my lisp environment updated.  It is a little different from asdf-install, because it does not download tarballs, it gets the source code directly from their respective source code repositories.

So, the first thing I did was to get clbuild itself.  For some reason, I did not have darcs installed, so I had to install that first on my Kubuntu laptop:

~$ sudo apt-get install darcs

After that, use darcs to get clbuild:

~$ darcs get http://common-lisp.net/project/clbuild/clbuild

Make clbuild executable:


~$ cd clbuild
~/clbuild$ chmod +x clbuild


As far as I can tell, you need to run clbuild from this directory. So, the next step is to do a system check:


~/clbuild$ ./clbulid check


Now, time to get an update to sbcl. With my system, sbcl is natively located in my bin directory:


~/clbuild$ which sbcl
/usr/bin/sbcl
~/clbuild$ sbcl --version
SBCL 1.0.18.debian


Now, using clbuild to download and compile the latest version of sbcl:


~/clbuild$ ./clbuild update sbcl
~/clbuild$ ./clbuild compile-implementation sbcl


After a long wait, an sbcl implementation was placed in ~/clbuild/target/bin. To run it, use clbuild again:


~/clbuild$ ./clbuild lisp
This is SBCL 1.0.38.5, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org&gt;.
*


So, clbuild is using the newest version, but my older implementation is still there. Next time, I will set up SLIME with Emacs to point to this new target.

Nested Map

I was in the #lisp chat room at Freenode when someone posed a question about performing a map function over a nested lists. This was an interesting problem, so I thought that I would cover it here.

Suppose there was a complex tree of numbers:

((1 2) (3 4))

And you want to map each to a function (let’s say a squaring function) and maintain its structure. This is where a good utility function would be in order. The function must be able to handle trees of an unknown structure. So, the only solution that I know would be to use recursion:

(defun nested-map (fn item)
    (cond ((null item) nil)
          ((atom item)   (funcall fn item))
          ((consp item) (cons (nested-map fn (car item))
                                 (nested-map fn (cdr item))))))

Even though it looks complex, the function seems correct:

CL-USER> (nested-map #'(lambda (x) (* x x))
           '((1 2) (3 4)))
((1 4) (9 16))
CL-USER> (nested-map #'(lambda (x) (* x x))
           '(1 2 (3 4 (5 6 7))))
(1 4 (9 16 (25 36 49)))

I think I’ll keep this in my utility toolkit. I am concerned about the performance, but I won’t worry too much about it until it becomes a problem.

An Emacs-like Editor for .NET?

Douglas Purdy recently mentioned on his blog that his team was hiring testers for a project within Microsoft informally described as Emacs.NET. I am going to take a step back and think about that for a second. In this stage, why would Microsoft invest in such a project? Microsoft products did have some basic capabilities before, like Emacs-style key bindings in Visual Studio to named commands and such. There must be something more.

Could be that Emacs is the most versatile editor out there? Emacs users know all too well how flexible Emacs is. Many hack their favorite programming language in Emacs, some like to use Emacs as an application interface, while the elite execute shells that make them never have to leave Emacs. Users can customize their key mappings, customize the look, or even code their own custom commands. There are hundreds of different modes out there that help users create and edit even the most arcane file types. It is available for Unix, Windows and MacOS X and most modes and extensions are very portable.

The absolutely coolest aspect of Emacs is the interactive programmable environment. Emacs the only editor that I know at this time that allows you to create extensions for editor from within the editor itself and apply them immediately the current session. This flexibility within Emacs is made possible it’s powerful, built-in Lisp execution environment. Here is a quick example that I hacked up in a minute. In the scratch buffer in Emacs, I create a simple function:


(defun my-hello (msg)
"Prints hello message"
(interactive "sDestination:")
(message "Hello %s" msg))


then I select the region containing the function and execute M-x eval-region. The function my-hello is now applied and I can now execute it using M-x my-hello.

My big question: would a .NET version do the same thing? I doubt that there any Lisp involved, but interactively applying extensions in .NET seem to be tricky to me. So, I would imagine that extensions will be compiled to IL assemblies. If Emacs.NET contains an interactive compiler, things in the Windows world could get very interesting.

Paragent on Agile Development in Lisp

On the Paragent blog today, the authors of the newly open-sourced IT organization software talked about agile Lisp development for an article on InfoQ. Common Lisp provides a unique environment for creating software fast, especially if you have the right tools. For me, the super code ninja editor GNU Emacs with SLIME works very well. The system allows me to edit, compile, and test Lisp code fairly quickly. Paragent, on the other hand, created Cusp, an Eclipse plug-in for Lisp development. It basically has the same functionality as SLIME with some interesting additions.

One subtle item that I realized while reading the post is the speed of executing tests in Lisp. The relative quickness to execute a complete test cycle in Lisp is very fast compared to the mainstream environments such as .NET or Java. On those environments, compiling still takes a relatively long time, even though compiler may use techniques such as incremental compilation. Using SLIME, I could compile and test particular functions or regions fairly quick. On top of that, the unit test execution on traditional environments takes time to start up and tear down. I notice that a lot when I am coding in Visual Studio .NET 2005 at work. The code-edit-test cycle can be painfully slow. So slow that I feel the need to lengthen my edit time to avoid performing the tests. It’s not very encouraging, in my opinion.

So, the post made very good points about Agile programming in Lisp. It looks like Paragent is going to be a shining poster child in both the Lisp community and the Agile community.

Common Lisp HyperSpec Search

I forgot to mention that I created a simple search engine for Firefox that does a limited search on Google geared torward the Common Lisp HyperSpec. I did make an anouncement on comp.lang.lisp, but I just forgot to mention it here.