Posted 2010-01-19 08:42:00 GMT

Investigated a great bug reported by Vikram Bhandoh on manardb under ClozureCL trunk.

Common Lisp implementations all(?) have a fasl (fast load) file format so you needn't recompile a source file from scratch if it has not changed. This generally has no effect on the program, but sometimes you run into problems like this message from SBCL for this short program: (funcall #.(lambda ()))

 Objects of type FUNCTION can't be dumped into fasl files.  

That means there are restriction the sort of constants you can splice into the output of the reader with #. notation (see *read-eval*), and the output of macros. You can work round it in general by forcing the offending contents to be compiled each time the file is loaded. The types of objects that can be dumped vary for each Lisp (see the hyperspec section 3.2.4.1 Externalizable Objects — for example ClozureCL can dump functions).

In the case reported by Vikram, the problem was that when the FASL containing a manardb class definition is loaded, the existing metaclass instance is clobbered but does not lose its class-finalized-p status. As ASDF does compile-file and then loads the file, this happens in practice. It results in this error on manardb when running the test-suite:

Slot MANARDB::WRITER-FUNCTION is unbound in #<MM-EFFECTIVE-SLOT-DEFINITION for memory slot PACKAGE-NAME #x30200143716D>
   [Condition of type UNBOUND-SLOT]

One solution is simply to restart the Lisp image. As long as you just load the FASL once you will be fine. Another work-around would be to change ensure-finalize-inheritance to finalize-inheritance in the definition of defmmclass, so that finalize-inheritance is always called.

However, ClozureCL is generally very quick to resolve bugs and I've given them a simple testcase so this hopefully won't be a problem for long.