[armedbear-devel] In-memory compilation status

[John Pallister]

Hi Alessio, thanks for your quick response.

So, from reading your message the options would seem to be:

1. Fix COMPILE so it no longer produces "unexpected behaviour". In
what way was it (mis-)behaving, and how was this unexpected?

2. Alter COMPILE so it just uses the some code as COMPILE-FILE, only
with output to a byte stream instead of a file stream. Is this what
you were doing? If so, how did you get on?

3. Alter COMPILE-FILE so that it doesn't use files for local
functions. (This would be required for 2 above, I guess.) From your
comments, this sounds like it might be tricky. Are the files just used
as a cache, or are they re-loaded again at a later date?

4. Add some sort of "VFS factory" that can provide either the real
file I/O calls or some "in-memory JAR" thing, and then modify
COMPILE-FILE to use that. This would imply a performance penalty for
the current "use real files" case due to the additional layer of
indirection.

This boils down to "remove the need for files during compilation" vs.
"remove the need for a file system during compilation". Obviously one
would be much easier than the other.

It sounds like you and I would be interested in an ABCL that didn't
rely on files for compilation, but I don't know whether that would be
considered a Good Thing by everyone else.

Re: Clojure, it looks OK, but I'd be happy to stick with good old Lisp
for now (especially since my JVM target has no threads as well as no
file system, so all its concurrency benefits are moot). And having to
hack Java to get ABCL to work is OK, as long as I'm on the right path
(and not inadvertently forking the project).

Cheers,

John :^P

P.S. I'm talking about Google App Engine, in case anyone hasn't guessed yet.
--
John Pallister
john at johnp.net
john at synchromesh.com