[armedbear-devel] Deploying compiled ABCL apps/elements
alessiostalla at gmail.com
Tue Jul 21 19:10:21 UTC 2009
On Tue, Jul 21, 2009 at 8:46 PM, Matt Lamari<matt.lamari at gmail.com> wrote:
> What's the planned endgame for the system? Is saved-memory-image
> remotely feasible? Or a jar with coded that would create the image? Or
> something else?
Disclaimer: I'm speaking for myself and not on behalf of abcl
developers in general, since as far as I know this issue has not been
discussed in detail and so no official position exists.
I see two possible options to resolve the issue.
One is to implement save-image using Java serialization. I made an
attempt at this some time ago, but stopped for a number of reasons -
the most prominent is that, as far as I can tell, abcl's compiler
should not rely on temporary files as it does now, or serializing
compiled functions is not feasible. There's interest in me and others
to do this change to the compiler for other reasons too, but it's not
a trivial change and so far it's not the most important issue, so it's
not high priority.
The other solution, maybe less optimal but much easier imho, is to
expose the api for loading files from jars and integrate it with LOAD
(that is, with Lisp pathnames), and maybe provide a nice function to
package a bunch of compiled Lisp files (say, from a given directory)
into a jar to be deployed together with abcl.jar. I haven't thought
about this in depth so there might be conceptual problems, I don't
know. But if it can be done, it's not hard to do.
The two solutions are not mutually exclusive and could be both
implemented. As far as I'm concerned, I'm currently concentrating on
other things but in future I'd like to try both solutions, because I
think abcl would greatly benefit from them.
> Alessio Stalla wrote:
>> ABCL currently can not save a memory image, so you're stuck with
>> loading compiled files (perhaps with asdf or similar, if it accepts
>> the absence of source files). ABCL has the capability to load files
>> from a jar archive, but I think it's internal machinery and not
>> exposed through a public API, though I might be wrong on this point.
>> However, loading files from a jar probably forces you to drop asdf and
>> any other system definition facility and manually load files in the
>> correct order.
>> On Tue, Jul 21, 2009 at 2:52 PM, Matt Lamari<matt.lamari at gmail.com> wrote:
>>> What is the mechanism for converting source code or an in-memory image
>>> (or fragment thereof) into a deployable unit? Just point me at a
>>> function name/document and I can take it from there. . . .
>>> armedbear-devel mailing list
>>> armedbear-devel at common-lisp.net
More information about the armedbear-devel