[Openmcl-devel] save-application questions.

[Gary Byers]

On Tue, 14 Feb 2006, Michael Price wrote:

> I have a Mac OS X lisp app that just uses the terminal -- no gui. I'd
> like to use ccl:save-application to make a binary. How much of the
> following is correct and am I missing anything?
>
> 1. Subclass ccl::application.
> 2. Add a ccl::toplevel-function method.
> 3. Add a ccl::application-error method,.
> 4. Add a ccl::parse-application-arguments method that just returns nils.
> 5. Handle ccl::*command-line-arguments-list* myself.
> 6. ccl::save-application.
>

Calling CCL:SAVE-APPLICATION with an :APPLICATION-CLASS argument
will arrange that an instance of the specified class is the value
of CCL:*APPLICATION* in the resulting image.

> I'm having trouble finding documentation for save-application. The
> above was condensed from an email to this list from almost 3 years
> ago.
>

I'll clearly have to spend less time at the racetrack and more time
writing documentation.

(Aside from the temptations and bright lights of the big city, I
think that one other reason that this hasn't been documented is the
lingering sense that some of it is not-quite-ready-for-prime-time, in
design, implementation, or both.  That creates something of a vicious
cycle: it's never a priority to fix these things because few people
seem to be using them, it's never a priority to document them because
they need to be fixed, few people use them because they aren't documented.)

> I don't know what some of the keyword arguments to save-application
> do. Specifically, what do :error-handler, :clear-clos-caches, :purify,
> :impurify, :mode, and :prepend-kernel do?

:error-handler is an example of something that's probably not too well
thought out.  There -is- a fairly reasonable idea behind it: if an otherwise
unhandled error happens in a "lisp development system", a break loop is
entered.  If an error happens in some other type of application, other
behavior (logging a message and continuing, sending an HTTP error response,
...) would be more appropriate.  It's clear that it's desirable to have
a few simple ways to specify what a specific type of application should
do (in general) in lieu of entering a break loop; it's less clear that
this argument to SAVE-APPLICATION is a good way to specify this.

:CLEAR-CLOS-CACHES ... clears (some) caches maintained by CLOS (I -think-
that the caches in question are maintained by generic functions and keep
track of the effective methods that have been computed for the arguments
that the GF has recieved so far.) A long time ago, clearing the cached
information before saving the image made the image ~50K bytes smaller,
which (in those days) might have been the difference between fitting
on a 1.44MB floppy or not.  Maybe this should be revisited when people
have to worry about fitting on a CD-R instead of a DVD-R, and I honestly
don't know what the space/time tradeoff is these days.

:PURIFY and :IMPURIFY are (as one might imagine) inverses of each other.
To "purify" the image in OpenMCL is to arrange for immutable, likely
long-lived objects (the "code-vector" components of functions and the
pnames of interned symbols, currently) be copied to a read-only ("pure")
section of memory.  There are some memory-management benefits related
to this (pure/read-only memory is easier on the OS's VM system and
OpenMCL's GC can mostly ignore that stuff), but in some circumstances
it may be necessary or desirable to undo this (making everything slosh
around in the Big Dynamic Memory Pool.)

:MODE denotes the UNIX access privileges to be given to (at least)
newly-created output files.  One often sees these values expressed
as 3-digit octal numbers, like "#o755" or "#o600".

:PREPEND-KERNEL sticks a copy of the lisp kernel on the front of the
image (or, if you prefer, appends the image to the end of a copy of
the lisp kernel)  If no --image-name argument is present, the kernel
will try to find a heap image embedded in itself and will try to load
that image if it appears to be present.  This may make it a little
simpler to distribute and/or install the application, though distributing
or installing two files (and maybe a shell script) isn't necessarily
much harder.
>

Seriously, I -do- understand that some documentation would be better
than nothing, and that one way of breaking the vicious cycle is to
provide -some- documentation so that people are encouraged to use it
more.  I think it's likely that the more it's used, the more problems
(in both design and implementation) will be encountered.  Those problems
are more likely to be addressed if people are actively trying to use
this stuff and encountering them and thinking about them than if the
problems are just (somewhere) in the back of my mind, as they have
been for at least a few years.

> Thanks.
>
> Michael
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>