<div dir="ltr">Hi,<div><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>Erik.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 9:28 AM, Mark Evenson <span dir="ltr"><<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 17 Nov 2014, at 21:46, Robert Dodier <<a href="mailto:robert.dodier@gmail.com">robert.dodier@gmail.com</a>> wrote:<br>
><br>
> On 2014-11-17, Mark Evenson <<a href="mailto:evenson@panix.com">evenson@panix.com</a>> wrote:<br>
><br>
>> 1)  ASDF systems which do not declare all their source code necessary to run<br>
>> within the ASDF grammar don’t package according to this method.<br>
><br>
> How would I know if this is the case? Can I inspect the .asd file and<br>
> see if something is present or absent?<br>
<br>
</span>Essentially, you know if it doesn’t work upon testing.  Ensuring that you can<br>
inspect the output of a non-nil CL:*LOAD-VERBOSE* can help in determining what<br>
exactly is happening.  Manual inspection of ASDF definitions for use of<br>
[SHARPSIGN-DOT macros with open files such as in BORDEAUX_THREADS][1] gets most<br>
of the common errors.  Whether such a process could ever be automated is open<br>
to debate, but I tend to believe not.<br>
<br>
[1]: <a href="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" target="_blank">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</a><br>
<span class=""><br>
<br>
><br>
>> 2) Using the jar for the pre-compiled fasls does not work with the current<br>
>> incarnation of ASDF.  Instead, upon first use of the source packaged in the<br>
>> jar, ASDF will compile the fasls according to its output translations logic.<br>
><br>
> Hmm, are the fasls then written into the jar? or they are just sitting<br>
> in $HOME/.asdf-cache-something/something/something?<br>
<br>
</span>The FASLs are under control of the [ASDF output translation mechanism][2],<br>
which in its default configuration places compiled files under<br>
<file:~/.cache/common-lisp/IMPLEMENTATION/**> where ‘IMPLEMENTATION’ is a<br>
directory name derived from the implementation that ASDF is running under.<br>
<br>
[2]: <a href="http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-saves-compiled-files" target="_blank">http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-saves-compiled-files</a><br>
<span class=""><br>
><br>
>> Do you have an absolute need to load the pre-compiled FASLs from the jar, or<br>
>> can you take the hit of compilation on first use coupled with the requirement<br>
>> that the user have a writable home directory for your deployment scenario?<br>
><br>
> Well, my goal is load Maxima into a webapp (as managed by Jetty or<br>
> Tomcat). (By the way, if you have seen such a thing, I'd be interested<br>
> to hear about it.) So I don't know if it's crucial to load fasls from<br>
> the jar -- I had assumed that the webapp could only load stuff from<br>
> jars available to the webapp container, but maybe that's not so.<br>
<br>
</span>Surprisingly, for both Tomcat and Jetty, there are actually no restrictions on<br>
where the webapp can load/save files other than those that result from the user<br>
they are running under.  The Java Servlet documentation would have you believe<br>
otherwise, the APIs to get such access are not immediately apparent, and other<br>
servlet containers may have tighter restrictions, but [abcl-servlet][3]--my<br>
putative framework for making ABCL Java Servlet instances--serves as the bare<br>
scaffolding for such usage.  abcl-servlet is not currently exhaustively<br>
documented, but if you clone the basic app, get it to build the<br>
abcl-servlet.war, you should be able to make a barebones ABCL webapp that you<br>
can connect to via SLIME for further experimentation.  Feedback on improvements<br>
to the process is solicited.<br>
<br>
[3]: <a href="https://bitbucket.org/easye/abcl-servlet" target="_blank">https://bitbucket.org/easye/abcl-servlet</a><br>
<span class="im HOEnZb"><br>
--<br>
"A screaming comes across the sky.  It has happened before but there is nothing<br>
to compare to it now."<br>
<br>
<br>
<br>
<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Armedbear-devel mailing list<br>
<a href="mailto:Armedbear-devel@common-lisp.net">Armedbear-devel@common-lisp.net</a><br>
<a href="http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel" target="_blank">http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div>
</div>