fe[nl]ix's blog

Common Lisp, programming et aliƦ

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:

;; 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 common-lisp.net 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.