Posted 2010-01-19 08:42:00 GMT
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 126.96.36.199
Externalizable Objects — for example ClozureCL can dump
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.
Post a comment