> On 17 Nov 2014, at 21:46, Robert Dodier <robert.dodier@gmail.com> wrote:
>
> On 2014-11-17, Mark Evenson <evenson@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@common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel