Hi, I think maybe this topic has been covered before but I wonder what's the state of the art. I want to have a Java program load a compiled Lisp program contained in a jar so that I can then call functions in the Lisp code.
For the record, the program in question is Maxima. Calling Lisp functions worked fine when the compiled code was unpacked (i.e. just in a directory) but I seem to recall it is not simply a matter of packing it into a jar. Or is it? Thanks for any advice.
best,
Robert Dodier
PS. I apologize in advance for any gross misunderstanding on my part.
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Nov 15, 2014, at 07:34, Robert Dodier robert.dodier@gmail.com wrote:
Hi, I think maybe this topic has been covered before but I wonder what's the state of the art. I want to have a Java program load a compiled Lisp program contained in a jar so that I can then call functions in the Lisp code.
For the record, the program in question is Maxima. Calling Lisp functions worked fine when the compiled code was unpacked (i.e. just in a directory) but I seem to recall it is not simply a matter of packing it into a jar. Or is it? Thanks for any advice.
All of this should be handled with the [ASDF-JAR contrib][], but when I went to test, it seems [that the basic functionality of packaging is now broken on trunk][376].
I thought I remembered that there were problems with loading FASLs with jar files, but the docstrings seem to indicate that it would work.
In any case, I will try to figure out how to address [376][] on trunk as I have time.
[asdf-jar]: http://abcl.org/trac/browser/trunk/abcl/contrib/asdf-jar/README.markdown
[376]: http://abcl.org/trac/ticket/376
On 2014-11-15, Mark Evenson evenson@panix.com wrote:
All of this should be handled with the [ASDF-JAR contrib][], but when I went to test, it seems [that the basic functionality of packaging is now broken on trunk][376].
Thanks, Mark. I took a look at asdf-jar and after messing around with asdf path configuration, I was able to load it, and evaluate
(asdf-jar:package :maxima)
which ensures that all the files are compiled (so far, so good) but then fails with: Unsupported directory component "maxima".
A backtrace seems to show that it was trying to build the jar:
0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<FILE-ERROR {1FA0B27}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.Pathname.getDirectoryNamestring(Pathname.java:808) 4: org.armedbear.lisp.Pathname.getNamestring(Pathname.java:700) 5: org.armedbear.lisp.zip.execute(zip.java:220) 6: org.armedbear.lisp.zip.execute(zip.java:68) 7: org.armedbear.lisp.Symbol.execute(Symbol.java:814)
Any advice on what might be going on here?
By the way, I am working with version 1.3.1 and I didn't run into the bug which you mentioned.
best,
Robert Dodier
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Nov 16, 2014, at 02:24, Robert Dodier robert.dodier@gmail.com wrote:
On 2014-11-15, Mark Evenson evenson@panix.com wrote:
All of this should be handled with the [ASDF-JAR contrib][], but when I went to test, it seems [that the basic functionality of packaging is now broken on trunk][376].
Thanks, Mark. I took a look at asdf-jar and after messing around with asdf path configuration, I was able to load it, and evaluate
(asdf-jar:package :maxima)
which ensures that all the files are compiled (so far, so good) but then fails with: Unsupported directory component "maxima".
A backtrace seems to show that it was trying to build the jar:
0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<FILE-ERROR {1FA0B27}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.Pathname.getDirectoryNamestring(Pathname.java:808) 4: org.armedbear.lisp.Pathname.getNamestring(Pathname.java:700) 5: org.armedbear.lisp.zip.execute(zip.java:220) 6: org.armedbear.lisp.zip.execute(zip.java:68) 7: org.armedbear.lisp.Symbol.execute(Symbol.java:814)
Any advice on what might be going on here?
By the way, I am working with version 1.3.1 and I didn't run into the bug which you mentioned.
[As noted][1], ASDF-JAR:PACKAGE doesn’t work in 1.3.1 either.
[1]: http://abcl.org/trac/ticket/376#comment:1
Commit [14736][] on ABCL trunk enables ASDF-JAR:PACKAGE to complete.
I have not testing loading the falls from the jar yet, but will hopefully get to it later today.
[14736]: http://abcl.org/trac/changeset/14736
On 16 Nov 2014, at 11:19, Mark Evenson evenson@panix.com wrote:
Commit [14736][] on ABCL trunk enables ASDF-JAR:PACKAGE to complete.
I have not testing loading the falls from the jar yet, but will hopefully get to it later today.
After further testing, I can confirm that ASDF-JAR:PACKAGE and ASDF-JAR:ADD-TO-ASDF now “mostly” work on trunk.
“mostly” with the following two caveats:
1) ASDF systems which do not declare all their source code necessary to run within the ASDF grammar don’t package according to this method. An example of a system which exhibits this sort of failure is BORDEAUX-THREADS. For these sort of systems it is necessary to make the assumption that the “asd” file is in the top-most directory of the system source and to recursively copy. See [abcl-servlet][1] for an example of this strategy which shells out to rsync.
[1]: https://bitbucket.org/easye/abcl-servlet/src/b0e7e5353d6c92a1990ed1bb5500be1...
2) Using the jar for the pre-compiled fasls does not work with the current incarnation of ASDF. Instead, upon first use of the source packaged in the jar, ASDF will compile the fasls according to its output translations logic. This has to do with the special translations rules for ABCL for converting jar source locations, which are always included in the output translation logic, even if ASDF:DISABLE-OUTPUT-TRANSLATIONS is specifically called. As a hack—y workaround, executing the following form will completely disable ASDF’s caching mechanism which, when coupled with a non-nil value of *LOAD-VERBOSE*, will show that the FASLs are indeed being loaded from the jar:
(setf asdf::*output-translations* '(((T T))))
Do you have an absolute need to load the pre-compiled FASLs from the jar, or can you take the hit of compilation on first use coupled with the requirement that the user have a writable home directory for your deployment scenario?
On 2014-11-17, Mark Evenson evenson@panix.com wrote:
- ASDF systems which do not declare all their source code necessary to run
within the ASDF grammar don’t package according to this method.
How would I know if this is the case? Can I inspect the .asd file and see if something is present or absent?
- Using the jar for the pre-compiled fasls does not work with the current
incarnation of ASDF. Instead, upon first use of the source packaged in the jar, ASDF will compile the fasls according to its output translations logic.
Hmm, are the fasls then written into the jar? or they are just sitting in $HOME/.asdf-cache-something/something/something?
Do you have an absolute need to load the pre-compiled FASLs from the jar, or can you take the hit of compilation on first use coupled with the requirement that the user have a writable home directory for your deployment scenario?
Well, my goal is load Maxima into a webapp (as managed by Jetty or Tomcat). (By the way, if you have seen such a thing, I'd be interested to hear about it.) So I don't know if it's crucial to load fasls from the jar -- I had assumed that the webapp could only load stuff from jars available to the webapp container, but maybe that's not so.
Thanks very much for your help.
Robert Dodier
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
17.11.2014, 23:47, "Robert Dodier" robert.dodier@gmail.com:
Well, my goal is load Maxima into a webapp (as managed by Jetty or Tomcat). (By the way, if you have seen such a thing, I'd be interested to hear about it.)
This maybe helpful - https://github.com/filonenko-mikhail?tab=repositories - some Maxima related projects, in particular web interface for maxima (but not for java containers, I think for SBCL).
So I don't know if it's crucial to load fasls from the jar -- I had assumed that the webapp could only load stuff from jars available to the webapp container, but maybe that's not so.
Not necessarily, you can access any files, unless you run your java machine with some security restrictions.
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 17 Nov 2014, at 21:46, Robert Dodier robert.dodier@gmail.com wrote:
On 2014-11-17, Mark Evenson evenson@panix.com wrote:
- ASDF systems which do not declare all their source code necessary to run
within the ASDF grammar don’t package according to this method.
How would I know if this is the case? Can I inspect the .asd file and see if something is present or absent?
Essentially, you know if it doesn’t work upon testing. Ensuring that you can inspect the output of a non-nil CL:*LOAD-VERBOSE* can help in determining what exactly is happening. Manual inspection of ASDF definitions for use of [SHARPSIGN-DOT macros with open files such as in BORDEAUX_THREADS][1] gets most of the common errors. Whether such a process could ever be automated is open to debate, but I tend to believe not.
[1]: http://common-lisp.net/gitweb/?p=projects/bordeaux-threads/bordeaux-threads....
- Using the jar for the pre-compiled fasls does not work with the current
incarnation of ASDF. Instead, upon first use of the source packaged in the jar, ASDF will compile the fasls according to its output translations logic.
Hmm, are the fasls then written into the jar? or they are just sitting in $HOME/.asdf-cache-something/something/something?
The FASLs are under control of the [ASDF output translation mechanism][2], which in its default configuration places compiled files under file:~/.cache/common-lisp/IMPLEMENTATION/** where ‘IMPLEMENTATION’ is a directory name derived from the implementation that ASDF is running under.
[2]: http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-saves-c...
Do you have an absolute need to load the pre-compiled FASLs from the jar, or can you take the hit of compilation on first use coupled with the requirement that the user have a writable home directory for your deployment scenario?
Well, my goal is load Maxima into a webapp (as managed by Jetty or Tomcat). (By the way, if you have seen such a thing, I'd be interested to hear about it.) So I don't know if it's crucial to load fasls from the jar -- I had assumed that the webapp could only load stuff from jars available to the webapp container, but maybe that's not so.
Surprisingly, for both Tomcat and Jetty, there are actually no restrictions on where the webapp can load/save files other than those that result from the user they are running under. The Java Servlet documentation would have you believe otherwise, the APIs to get such access are not immediately apparent, and other servlet containers may have tighter restrictions, but [abcl-servlet][3]--my putative framework for making ABCL Java Servlet instances--serves as the bare scaffolding for such usage. abcl-servlet is not currently exhaustively documented, but if you clone the basic app, get it to build the abcl-servlet.war, you should be able to make a barebones ABCL webapp that you can connect to via SLIME for further experimentation. Feedback on improvements to the process is solicited.
[3]: https://bitbucket.org/easye/abcl-servlet
Hi,
Some time ago, I created infrastructure to be used by ASDF to compile an ASD definition file's resulting FASLs into a single artifact. Things like #.(read-some-file) in the ASD definition will work as well. If there are load-time or runtime forms referring to the original source tree, they won't, because the link to the source tree gets severed.
Unfortunately, I can't remember the name of the ASDF transform I implemented this for. What I do remember is that the resulting fasl can be loaded with a simple LOAD command, so ASDF won't be needed in the resulting image.
Regards,
Erik.
On Wed, Nov 19, 2014 at 9:28 AM, Mark Evenson evenson@panix.com wrote:
On 17 Nov 2014, at 21:46, Robert Dodier robert.dodier@gmail.com wrote:
On 2014-11-17, Mark Evenson evenson@panix.com wrote:
- ASDF systems which do not declare all their source code necessary
to run
within the ASDF grammar don’t package according to this method.
How would I know if this is the case? Can I inspect the .asd file and see if something is present or absent?
Essentially, you know if it doesn’t work upon testing. Ensuring that you can inspect the output of a non-nil CL:*LOAD-VERBOSE* can help in determining what exactly is happening. Manual inspection of ASDF definitions for use of [SHARPSIGN-DOT macros with open files such as in BORDEAUX_THREADS][1] gets most of the common errors. Whether such a process could ever be automated is open to debate, but I tend to believe not.
- Using the jar for the pre-compiled fasls does not work with the
current
incarnation of ASDF. Instead, upon first use of the source packaged in
the
jar, ASDF will compile the fasls according to its output translations
logic.
Hmm, are the fasls then written into the jar? or they are just sitting in $HOME/.asdf-cache-something/something/something?
The FASLs are under control of the [ASDF output translation mechanism][2], which in its default configuration places compiled files under file:~/.cache/common-lisp/IMPLEMENTATION/** where ‘IMPLEMENTATION’ is a directory name derived from the implementation that ASDF is running under.
Do you have an absolute need to load the pre-compiled FASLs from the
jar, or
can you take the hit of compilation on first use coupled with the
requirement
that the user have a writable home directory for your deployment
scenario?
Well, my goal is load Maxima into a webapp (as managed by Jetty or Tomcat). (By the way, if you have seen such a thing, I'd be interested to hear about it.) So I don't know if it's crucial to load fasls from the jar -- I had assumed that the webapp could only load stuff from jars available to the webapp container, but maybe that's not so.
Surprisingly, for both Tomcat and Jetty, there are actually no restrictions on where the webapp can load/save files other than those that result from the user they are running under. The Java Servlet documentation would have you believe otherwise, the APIs to get such access are not immediately apparent, and other servlet containers may have tighter restrictions, but [abcl-servlet][3]--my putative framework for making ABCL Java Servlet instances--serves as the bare scaffolding for such usage. abcl-servlet is not currently exhaustively documented, but if you clone the basic app, get it to build the abcl-servlet.war, you should be able to make a barebones ABCL webapp that you can connect to via SLIME for further experimentation. Feedback on improvements to the process is solicited.
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Nov 19, 2014, at 21:00, Erik Huelsmann ehuels@gmail.com wrote:
Hi,
Some time ago, I created infrastructure to be used by ASDF to compile an ASD definition file's resulting FASLs into a single artifact. Things like #.(read-some-file) in the ASD definition will work as well. If there are load-time or runtime forms referring to the original source tree, they won't, because the link to the source tree gets severed.
Unfortunately, I can't remember the name of the ASDF transform I implemented this for. What I do remember is that the resulting fasl can be loaded with a simple LOAD command, so ASDF won't be needed in the resulting image.
I believe that you are thinking of ASDF:BUNDLE-SYSTEM.
I’m not sure if this is still working, or at least it could stand to give clearer output if it is:
CL-USER> (setf asdf:*verbose-out* t) T CL-USER> (asdf:bundle-system :cl-ppcre) #<ASDF/BUNDLE:DELIVER-ASD-OP > #<ASDF/PLAN:SEQUENTIAL-PLAN {364EDC84}> CL-USER>
as I’m not sure where the monolithic FASL should be located, or what it should be called.
If the problem is the use of reader macros foiling introspection by ASDF-JAR, then probably Fare's addition of :FEATURE to the ASDF system definition language is just what you need.
:FEATURE is evaluated at load time, thus not messing up ASDF's knowledge of what is and isn't "really there" in the system. So you could try replacing use of #+ with :FEATURE and see if that makes your problems go away.
I stumbled on this in a case which sounds similar: I was re-loading a system into a dumped image, and the semantics of the reader macros was all wonky, because they were interpreted at image save time, not at the time that I was trying to load the system....
HTH
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 25 Nov 2014, at 23:47, Robert Goldman rpgoldman@sift.net wrote:
If the problem is the use of reader macros foiling introspection by ASDF-JAR, then probably Fare's addition of :FEATURE to the ASDF system definition language is just what you need.
My problem is more basic: how do I create a monolithic FASL? Where does it get created? There seems to be no documentation on this in the ASDF manual, and I haven’t had time to go through the mailing list and source to figure things out.
Section 13.2.12 of the ASDF manual mentions the obsolescence of associated symbols, but I don’t know how to use the symbols in the first place.
From looking at the ASDF source, my first guess at what I would execute to bundle a system, ASDF:BUNDLE-SYSTEM, seems marked as deprecated.
In lieu of better documentation, can somebody point me to an ASDF system that putatively uses this machinery that I may study and learn from?
Mark Evenson wrote:
On 25 Nov 2014, at 23:47, Robert Goldman rpgoldman@sift.net wrote:
If the problem is the use of reader macros foiling introspection by ASDF-JAR, then probably Fare's addition of :FEATURE to the ASDF system definition language is just what you need.
My problem is more basic: how do I create a monolithic FASL? Where does it get created? There seems to be no documentation on this in the ASDF manual, and I haven’t had time to go through the mailing list and source to figure things out.
Section 13.2.12 of the ASDF manual mentions the obsolescence of associated symbols, but I don’t know how to use the symbols in the first place.
From looking at the ASDF source, my first guess at what I would execute to bundle a system, ASDF:BUNDLE-SYSTEM, seems marked as deprecated.
In lieu of better documentation, can somebody point me to an ASDF system that putatively uses this machinery that I may study and learn from?
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?
I don't claim to understand these. 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.
For a conventional CL implementation I don't see the value of the monolithic fasls, although I suppose there would be some speed-up in loading. But I would guess that if that's what you care about, you would be better off using an image to load.
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.
I don't think there is a system that uses these operations, per se. I think it's intended that it be possible to apply them to any system.
Sorry I wasn't of more assistance.
Best, r
For a conventional CL implementation I don't see the value of the monolithic fasls, although I suppose there would be some speed-up in loading. But I would guess that if that's what you care about, you would be better off using an image to load.
We use the monolithic fasls a lot, as part of our standard Gendl and GDL build process. The rationale for doing so is outlined here (slightly outdated article, I need to start blogging again!):
http://gendl.blogspot.com/2013/03/saving-images-with-asdf3.html
Dave Cooper wrote:
For a conventional CL implementation I don't see the value of the monolithic fasls, although I suppose there would be some speed-up in loading. But I would guess that if that's what you care about, you would be better off using an image to load.We use the monolithic fasls a lot, as part of our standard Gendl and GDL build process. The rationale for doing so is outlined here (slightly outdated article, I need to start blogging again!):
http://gendl.blogspot.com/2013/03/saving-images-with-asdf3.html
That's very interesting. I'm particularly intrigued by the fact that you are using the monolithic fasl not as something valuable in and of itself, but as a kind of crude tree-shaker intermediate step to build an executable image.
For those who haven't read the (very interesting) blog post, the key idea is that when you build the monolithic fasl, you get the functionality you wanted, without a lot of the infrastructure (e.g., quicklisp) that got you to the point of having the functionality.
I'm not that familiar with the way the Java world works, but I get the sense that something additional is going on there, where loading from jars is preferred to loading in some other way. I suppose that part of the reason is that if you package up your ABCL jars together with the jars for your application, then it looks to your consumer as if there's simply a standard java world application: if your user doesn't care, s/he never need know that Common Lisp is involved....
cheers, r
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.
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.
I reran the bundle-test with ABCL from SVN, and all the tests pass now.
So I suspect what I should do is fix ASDF so that it checks for ABCL version 1.4 (my 1.3.1 from MacPorts still fails the test), and then turn the bundle ops and bundle tests on.
best, r
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 '#P"/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl"' in '#P"jar:file:/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl!/bundle-1--system._"'
Here's what looks like the interesting part of the backtrace:
16: (SIGNAL #<FILE-ERROR {447EAE5A}>) 17: #<JAVA-STACK-FRAME org.armedbear.lisp.Lisp.error(Lisp.java:382) {32BD8B9C}> 18: #<JAVA-STACK-FRAME org.armedbear.lisp.Load.load(Load.java:192) {3A18C8CA}> 19: #<JAVA-STACK-FRAME org.armedbear.lisp.Load.load(Load.java:726) {31266392}> 20: #<JAVA-STACK-FRAME org.armedbear.lisp.Load$_load.execute(Load.java:674) {4F531F73}> 21: #<JAVA-STACK-FRAME org.armedbear.lisp.Symbol.execute(Symbol.java:852) {5A35DFB4}> 22: #<JAVA-STACK-FRAME org.armedbear.lisp.LispThread.execute(LispThread.java:698) {6F1D0B1}> 23: #<JAVA-STACK-FRAME org.armedbear.lisp.load_1.execute(load.lisp:33) {6DBC1806}> 24: #<JAVA-STACK-FRAME org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) {57CD6A32}> 25: #<JAVA-STACK-FRAME org.armedbear.lisp.Symbol.execute(Symbol.java:803) {6EF725A6}> 26: #<JAVA-STACK-FRAME org.armedbear.lisp.LispThread.execute(LispThread.java:644) {23C8EE34}> 27: #<JAVA-STACK-FRAME org.armedbear.lisp.Lisp.funcall(Lisp.java:172) {5C8EAA46}> 28: #<JAVA-STACK-FRAME org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2825) {1A4D0923}> 29: (SYSTEM::%LOAD #P"/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl" T NIL T :DEFAULT) 30: (LOAD #P"/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl") 31: (APPLY LOAD #P"/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl" NIL) 32: (#<FUNCTION {3792E652}>) 33: (#<FUNCTION {D4F2DFF}>) 34: (JAVA:JRUN-EXCEPTION-PROTECTED #<FUNCTION {D4F2DFF}>) 35: (UIOP/UTILITY:CALL-WITH-MUFFLED-CONDITIONS #<FUNCTION {3792E652}> ("Overwriting already existing readtable ~S." #(#:FINALIZERS-OFF-WARNING :ASDF-FINALIZERS))) 36: (UIOP/LISP-BUILD:CALL-WITH-MUFFLED-LOADER-CONDITIONS #<FUNCTION {3792E652}>) 37: (UIOP/LISP-BUILD:LOAD* #P"/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl") 38: (ASDF/LISP-ACTION:PERFORM-LISP-LOAD-FASL #<ASDF/BUNDLE:LOAD-BUNDLE-OP > #<ASDF/SYSTEM:SYSTEM "test-asdf/bundle-1">)
When I look into that bundle file, I see this: $ jar tf /Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl file3/ file3/__loader__._ file1/ file1/__loader__._
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.
On 12/2/14 10:03, Mark Evenson wrote:
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.
Actually, [Dave Cooper's blog post][1] was enough for me to understand what is going on. Thanks Dave!
[1]: http://gendl.blogspot.com/2013/03/saving-images-with-asdf3.html
One difference for the current ASDF is that to view where the monolithic bundle gets written, one has to use the MONOLITHIC-COMPILE-BUNDLE-OP as follows:
(asdf:output-files 'asdf:monolithic-compile-bundle-op :cl-ppcre)
I would suggest that ASDF:BUNDLE-SYSTEM emit this sort of information as well.
armedbear-devel@common-lisp.net
-
Anton Vodonosov -
Dave Cooper -
Erik Huelsmann -
Mark Evenson -
Robert Dodier -
Robert Goldman -
Robert P. Goldman