[Armedbear-devel] How to load compiled Lisp stuff from a jar

[Erik Huelsmann]

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 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
> 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.git;a=blob;f=bordeaux-threads.asd;h=655b68da372ede3d7a32bde596f0ce9da9d25eea;hb=HEAD;js=1#l32
>
>
> >
> >> 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.
> >
> > 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-compiled-files
>
> >
> >> 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
>
> --
> "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 at common-lisp.net
> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>



-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20141119/619d4b86/attachment.html>