[armedbear-devel] [REVISED 20090830a] Loading Lisp from JAR Files
evenson at panix.com
Sat Aug 29 23:23:40 UTC 2009
Attached is a revised patch for loading ABCL FASLs from jar files.
Now loading unpacked and packed FASLs work, so it is considerably easier
to package things.
To use the packed FASL variant:
0) For 'bar.lisp' containing
(defun foo ()
(format t ("Foo here!"))
1) Compile normally with COMPILE-FILE
CL-USER(1): (compile-file "bar.lisp")
2) Package the resulting packed FASL ('*.abcl') with JAR (or zip):
cmd$ jar cfv baz.jar bar.abcl
You can add as many packed FASLs to the jar archive as you want.
To load issue
CL-USER(1): (load "jar:file:baz.jar!/bar")
Note that you can't currently specify "bar.abcl" explicitly in the load
form (a bug).
The code needs some refactoring love, and much further testing, but I
wanted to show some progress to get feedback. Other than both
Load.load() and Lisp.loadCompiledFunction() getting seriously hard to
understand, there is a conceptual problem with expressing "the sub-entry
of a zipped entry of a zip file" with Lisp pathnames that if someone
could suggest a way around, it would clear things up. ABCL uses the
trick that if a pathname has a device component and the device is
actually a pathname, then the entire pathname represents a entry in a
zip file with device refering to the enclosing zip file, with the
enclosing pathname directory, name, and type components identifying
which entry within the zip file. If we could figure out a way to
specify the sub-entry of an entry it would help out the abstraction.
Does it make sense to use the device component recursively something like:
I think that helps, but it's late, so I'll check back later to see if
this still makes sense.
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the armedbear-devel