[Gcl-devel] Re: Problems with the 'On Lisp' development model ...

[Camm Maguire]

The following message is a courtesy copy of an article
that has been posted to comp.lang.lisp as well.

Greetings, and thanks for your reply!

"Will Hartung" <address@hidden> writes:

> "Camm Maguire" <address@hidden> wrote in message
> news:address@hidden
> > Somehow, it appears that what is needed is a lisp heap in an external
> > shared library, with copy-on-write pages handling the modifications,
> > and instructing #'save-system to write only dirty pages to disk and
> > properly overlay the shared lib on re-execution.  This would appear
> > really intractable in a copying garbage collector system -- thank
> > goodness this is not the case for the bulk of the GCL heap.
> 
> I don't know GCL, but most of the other Lisps are basically "heap" based
> using compiled FASL files. When you wish to send out a delta change, you
> basically send a delta FASL that gets loaded when the system starts up as a
> patch.
> 
> I also think that systems like Allegro will allow you to load FASL files as,
> essentially, "read only" so that you can share them across multiple Lisp
> processes, but save space much like a shared library.
> 
> Now, all I've heard about GCL is basically "it creates C with is compiled by
> GCC", so I don't know what the resulting files are like for a GCL
> application, and I don't know if the kind of behaviors I've described are
> possible/practical with a GCL application.
> 

All of this is applicable to GCL and programs compiled on top of it --
thanks!  

I'm still wondering how this would be done in practice in a
distribution setting like Debian, though.  The mechanism you describe
above is an overlay of previously distributed code with the incorrect
behavior.  Should these compiled FASL files (standard ELF .o files in
GCL's case with appended lisp initialization code) be packaged
separately, and installed into some known directory, with gcl, maxima,
acl2, and axiom searching this on startup and loading in the overlay?.
Or should there be a one time process which runs on patch installation
which would load the module into any installed maxima, acl2, or axiom
images present and resave the heap in place.  This could be
problematic keeping track of future package installations, etc.

With shared libraries, everything is so simple.  Upgrade libc, and
every dependent program has the fix on next execution, no overlay, no
bookkeeping. 

Am I missing something?

Am also interested in Allegro's read-only policy.  Can users not
change the functions therein, or are the old definitions preserved
while new ones are added elsewhere and fbound to the proper symbols,
the former being exempted from garbage collection and effectively
serving as dead allocated memory?

Take care,

> Regards,
> 
> Will Hartung
> (address@hidden)
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah