Hi!
As we discussed, I'd write FASL concatenation support for ABCL. I'm nearly done, however I'm running into a snag caused by ASDF:
Normally, a file "package.lisp" is compiled into a fasl "package.abcl" which is basically a zip with at least one entry: "package._". The "._" file contains instructions for loading the fasl and may contain references to other files in the same zip.
My FASL concatenation code currently uses the assumption that the "._" file has exactly the same name as the enclosing package. However, FASLs generated using ASDF violate that assumption: the ._ file in the fasl isn't called "package._" but it's called "package-ASDF_TMP._".
How does ABCL know about the suffix when ASDF is loading the FASL "package.abcl" with the suffixed file in it in the regular situation?
Bye,
Erik.
On 4/3/13 10:39 PM, Erik Huelsmann wrote:
Hi!
As we discussed, I'd write FASL concatenation support for ABCL. I'm nearly done, however I'm running into a snag caused by ASDF:
Normally, a file "package.lisp" is compiled into a fasl "package.abcl" which is basically a zip with at least one entry: "package._". The "._" file contains instructions for loading the fasl and may contain references to other files in the same zip.
My FASL concatenation code currently uses the assumption that the "._" file has exactly the same name as the enclosing package. However, FASLs generated using ASDF violate that assumption: the ._ file in the fasl isn't called "package._" but it's called "package-ASDF_TMP._".
How does ABCL know about the suffix when ASDF is loading the FASL "package.abcl" with the suffixed file in it in the regular situation?
The code in the java implementation of CL:LOAD, in Load.java:175 ff. makes an attempt to match a pathname with a wild NAME component if the fasl has been renamed.
Hi Mark,
Thanks for your reaction. I have a better idea which always works and works without searching for the entry: let's call the main entry point a constant name: __loader__._
Actually in my local working copy, I already have done this and it works like a charm even with the renaming scheme ASDF employs. Will commit in a bit. Which probably means we can remove the fallback code (yay! simplicity!)
Agreed?
Bye,
Erik.
On Wed, Apr 3, 2013 at 11:16 PM, Mark Evenson evenson@panix.com wrote:
On 4/3/13 10:39 PM, Erik Huelsmann wrote:
Hi!
As we discussed, I'd write FASL concatenation support for ABCL. I'm nearly done, however I'm running into a snag caused by ASDF:
Normally, a file "package.lisp" is compiled into a fasl "package.abcl" which is basically a zip with at least one entry: "package._". The "._" file contains instructions for loading the fasl and may contain references to other files in the same zip.
My FASL concatenation code currently uses the assumption that the "._" file has exactly the same name as the enclosing package. However, FASLs generated using ASDF violate that assumption: the ._ file in the fasl isn't called "package._" but it's called "package-ASDF_TMP._".
How does ABCL know about the suffix when ASDF is loading the FASL "package.abcl" with the suffixed file in it in the regular situation?
The code in the java implementation of CL:LOAD, in Load.java:175 ff. makes an attempt to match a pathname with a wild NAME component if the fasl has been renamed.
--
"A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."
armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
armedbear-devel@common-lisp.net
-
Erik Huelsmann -
Mark Evenson