[Armedbear-devel] How to load compiled Lisp stuff from a jar
ehuels at gmail.com
Wed Nov 19 20:00:08 UTC 2014
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
On Wed, Nov 19, 2014 at 9:28 AM, Mark Evenson <evenson at panix.com> wrote:
> > On 17 Nov 2014, at 21:46, Robert Dodier <robert.dodier at gmail.com> wrote:
> > On 2014-11-17, Mark Evenson <evenson at panix.com> wrote:
> >> 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.
> > 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
> inspect the output of a non-nil CL:*LOAD-VERBOSE* can help in determining
> exactly is happening. Manual inspection of ASDF definitions for use of
> [SHARPSIGN-DOT macros with open files such as in BORDEAUX_THREADS] gets
> of the common errors. Whether such a process could ever be automated is
> to debate, but I tend to believe not.
> >> 2) Using the jar for the pre-compiled fasls does not work with the
> >> incarnation of ASDF. Instead, upon first use of the source packaged in
> >> jar, ASDF will compile the fasls according to its output translations
> > 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],
> 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
> >> that the user have a writable home directory for your deployment
> > 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
> they are running under. The Java Servlet documentation would have you
> otherwise, the APIs to get such access are not immediately apparent, and
> servlet containers may have tighter restrictions, but [abcl-servlet]--my
> putative framework for making ABCL Java Servlet instances--serves as the
> 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
> can connect to via SLIME for further experimentation. Feedback on
> to the process is solicited.
> : https://bitbucket.org/easye/abcl-servlet
> "A screaming comes across the sky. It has happened before but there is
> to compare to it now."
> Armedbear-devel mailing list
> Armedbear-devel at common-lisp.net
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the armedbear-devel