Monolithic fasls (Was Re: [Armedbear-devel] How to load compiled Lisp stuff from a jar)

Robert P. Goldman rpgoldman at
Tue Dec 2 17:07:07 UTC 2014

Mark Evenson wrote:
> On 11/28/14 21:16, Robert P. Goldman wrote:
> […]
>> I'm a little confused: doesn't ABCL use ASDF-JAR *instead* of Fare's
>> monolithic-<foo> operations? So are you looking to harmonize the two in
>> some way?
> We attempt to support both methods, and are not currently looking to
> harmonize.  ASDF-JAR originated from the JVM host for ABCL:  since the
> jar file is the unit of distribution for most Java applications, it
> seemed natural to be able to distribute ABCL applications in such units.
>  Monolithic fasls came from ASDF's support for ECL which Erik saw as
> easy to support with a small amount of additional work on ABCL.
>> I don't claim to understand [monolithic fasls].  Faré put them in before I took over,
>> I believe mostly for the benefit of ECL. My attempts to use them with
>> ABCL (as you know) have always failed for me: on the Mac the jar
>> pathnames get garbled in ways I don't understand.  We had some
>> correspondence about this, but I don't think either of us were able to
>> figure it out.
> Hmm, I can't find the record of our correspondence.  From what I
> remember, I eventually traced the error you encountered down to OS X's
> use of a symlink for the temporary directory root, and fixed ABCL.  A
> fair amount of wall clock time elapsed (on the order of months) before I
> managed to figure out what was wrong, so I think ASDF has dropped the
> failing test, as you had, understandably, moved on.

I just checked test-bundle, and it still fails for me on Mac OS X:

TEST ABORTED: Loadable FASL not found for

Here's what looks like the interesting part of the backtrace:

17: #<JAVA-STACK-FRAME org.armedbear.lisp.Lisp.error(
18: #<JAVA-STACK-FRAME org.armedbear.lisp.Load.load(
19: #<JAVA-STACK-FRAME org.armedbear.lisp.Load.load(
org.armedbear.lisp.Load$_load.execute( {4F531F73}>
org.armedbear.lisp.Symbol.execute( {5A35DFB4}>
org.armedbear.lisp.LispThread.execute( {6F1D0B1}>
23: #<JAVA-STACK-FRAME org.armedbear.lisp.load_1.execute(load.lisp:33)
org.armedbear.lisp.Symbol.execute( {6EF725A6}>
org.armedbear.lisp.LispThread.execute( {23C8EE34}>
27: #<JAVA-STACK-FRAME org.armedbear.lisp.Lisp.funcall(
30: (LOAD
32: (#<FUNCTION {3792E652}>)
33: (#<FUNCTION {D4F2DFF}>)
("Overwriting already existing readtable ~S." #(#:FINALIZERS-OFF-WARNING

When I look into that bundle file, I see this:
$ jar tf

>> As far as symbol obsolescence, what's going on is that we decided the
>> original names weren't very clear, so the operations got renamed.
>> Unfortunately, there had already been a release, so instead of just
>> renaming them, we kept both names, with the old names left around and
>> deprecated.  I'll probably blow them away whenever ASDF 3.2 rolls around.
> There should be some documentation for monolithic fasls, somewhere, at
> some point, which, once I figure things out, I will be happy to
> contribute.
> Do monolithic FASLs work on MKCL, since ECL is effectively dead?  If
> not, then we should probably document things in the ABCL manual.  But
> then that approach is a little odd, as the majority of the code resides
> in ASDF.  But it seems a bit out of place to document something in the
> ASDF manual that only applies to one, and possibly two, Common Lisp
> implementations.

As far as I know, the bundle operations run on MKCL, at least to the
extent that it passes all the tests.

I think actually the bundle operations mostly work everywhere, it's just
that I'm not sure what they're for!

That part of this discussion should probably get moved to ASDF-devel,
where Faré can weigh in.

More information about the armedbear-devel mailing list