Native TravisCI Support for Common Lisp

Being used to Continuous Integration at work, I wanted to use it for my Lisp projects too. Looking around, the choice was pretty easy: TravisCI is a very nice platform developed by a company in Berlin, which offers free testing for open-source projects hosted at Github.

I saw that Luís Oliveira preceded me, so I followed the instructions at cl-travis and created a .travis.yml for all my libraries. Cl-travis contains a script that is run in the setup phase of the test and relies on CIM to provide a wrapper for common command line parameters of Lisp compilers. For the task at hand CIM works very well. Unfortunately, cl-travis has a few shortcomings:

  • it hard-codes the implementation versions, so you can’t test on multiple versions, e.g. the one you use at work for internal projects, and the latest one for the benefit of open-source developers
  • it has to install a few system packages required for running the Lisp implementations, which means it forces the test to use the old infrastructure based on VMs that are setup for every single test, taking a few minutes to boot. If we can avoid installing packages from within the .travis.yml file, we can use the new infrastructure based on light-weight containers which are spawn almost instantaneously
  • it lacks integration with the TravisCI UI, e.g. to distinguish between the implementation used for a test run and proper build parameters

All that works, but there could be better because Travis allows adding community support for a language, for which there is an excellent documentation. In short, a group of at least three people are required to guarantee support, given that Travis generally updates the base image every three months. Extensions must be written in Ruby(for the core build infrastructure) and CoffeeScript(for the UI). I’m looking for help so if you’re interested I’ve opened a mailing list and a Github project.

Update: Fernando Boretti also blogged here about using cl-travis

Controlling Compiler-macro Expansion

One of my projects, static-vectors, makes extensive use of compiler macros which I need to test in addition to the main function definition. As far as I know, there’s no standard way to inhibit or force compiler-macro expansion and mucking with INLINE, NOTINLINE and SPEED declarations may or may not work, so are there implementation-specific ways to achieve that ?

I could cleverly use (FUNCALL (COMPILER-MACRO-FUNCTION …)) to test the compiler macro, but in testing the main function there’s no guarantee that a compiler won’t use the compiler-macro in a (FUNCALL #’FUNCTION) or (FUNCALL (FDEFINITION ‘FUNCTION). Ideas ?

IOLib@ILC2012 Slides

I’m at ECLM in Madrid and I realized that I didn’t publish the slides from the IOLib talk at ILC 2012, so here they are.

The Why of version.lisp-expr

In all projects I manage, instead of including the version string verbatim in .asd files, I relegate it to an external file named version.lisp-expr which I then include in all .asd files, typically at least two:

Defining system version
;; foo.asd
(asdf:defsystem :foo
:version #.(with-open-file (f (merge-pathnames "version.lisp-expr"
(or *compile-file-pathname*
(read f))
;; and version.lisp-expr
;; -*- lisp -*-

Q: Why this approach ?
A: Because it’s script-friendly: I have a generic release script that overwrites version.lisp-expr before committing and tagging, and it’s much safer to do it this way rather than using sed to replace the version string in .asd files. Also because this way the version info says in one place, instead of duplicating it in multiple files.

Q: Why use cl:read ?
A: Because it allows me to add comments to the file. Since I use #. to include the version, the format must be a CL string.

Q: Why .lisp-expr instead of .lisp ?
A: To make it obvious that the file isn’t meant to be compiled, but that the syntax is CL. It’s technically unnecessary.

Q: Where did I get this idea from ?
A: SBCL. Its build system includes version.lisp-expr only in release tarballs and computes the version using git-describe in source checkouts, but for most needs that’s unnecessarily complex.

The Future of FiveAM

FiveAM is my favorite and one of the best testing frameworks for Common Lisp; it has gone undeveloped for the past 3 years but now its author, Marco Baringer, has kindly accepted to let me take over the project and continue its development.

I created a new project for it on with its own mailing list, converted the sources to git and put them on github.

I’ll slowly integrate the various forks and patches I found around so if you have feature requests or you’re just interested join fiveam-devel.