2015-07-28T18:22:29+02:00http://blog.cddr.org/Octopress2015-07-28T00:04:13+02:00http://blog.cddr.org/2015/07/28/native-travisci-support-for-common-lispBeing 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.

]]>2013-08-13T16:35:00+02:00http://blog.cddr.org/2013/08/13/controlling-compiler-macro-expansionOne 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 ?

]]>2013-06-02T11:25:00+02:00http://blog.cddr.org/2013/06/02/ilc-2012-slidesI’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.
]]>2013-04-17T16:54:00+02:00http://blog.cddr.org/2013/04/17/a-legal-analysis-of-the-llgplEli Greenbaum’s analysis here is the first legal commentary on the LLGPL I’ve encountered.
]]>2012-06-05T11:47:00+02:00http://blog.cddr.org/2012/06/05/the-why-of-version-dot-lisp-exprIn 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

;; foo.asd</p>

<p>(asdf:defsystem:foo

:version#.(with-open-file(f(merge-pathnames“version.lisp-expr”

(or<em>compile-file-pathname</em>

<em>load-truename</em>)))

(readf))

…)</p>

<p>;; and version.lisp-expr</p>

<p>;; -<em>- lisp -</em>-

“0.0.1”

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.