Re: Problems with the 'On Lisp' development model ...

From: Will Hartung (willh_at_msoft.com)
Date: 11/09/04 

Date: Tue, 9 Nov 2004 11:03:09 -0800

"Camm Maguire" <camm@enhanced.com> wrote in message
news:54sm7r9e3i.fsf@intech19.enhanced.com...
> 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.

You could do it both ways, of course.

You could treat maxima as a single application, and load it independently
into your running Lisp image (much like you load an .exe into your system
when you want to run a program).

Or you could load maxima once, and then save the entire image as a whole.

Another thing you could do is put some startup code in your maxima
application that looks in a specified place for updates.

So, perhaps, you have Maxima ver. 3.0 (I don't know anything about maxima,
I'm making this up out of whole cloth...).

You can have maxima look in ~/.maxima/fasl for files named
"patch_3.0_*.fasl", and load them automatically at start up.

When you roll out a new version, it can look for updates in
"patch_3.1_*.fasl", or whatever.

This means that there is a start up cost to load the patches each time. You
could also, of course, save an image with the current patches at anytime,
and have the patch "patch" the loader to change where it starts to look for
future patches (i.e. what version number, say "patch_3.0_27")

This gives you the flexibility of automatic updates for which the user must
do nothing to get them, (save place them in the proper directory) yet if
they want that extra bleem of performance and forgo the patching process on
startup, they can take the extra step of creating a new image. IME, fasl
patches tend to be small and load quickly, however.

And, of course, you can always provide "pre-patched" images to any version
level you'd like.

So, what you get, "for free", is the ability to incrementally patch your
applications easily, yet also provide the latest and greatest. This also
make it easy for folks to make custom changes to their local version, yet
still load the incremental patches that are released from "Official"
versions. Assuming they don't conflict, that means you get to keep you local
changes and still be up to date. Obviously there can be issues with this,
but they are probably less of a problem than you might think.

> 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?

Certainly at a monolithic level, the shared library has its benefits (and
its curse vis-a-vi "DLL Hell"). But Lisp is a bit more organic that way, and
interdepdencies can get very ugly very quickly. When you have an image of
the system at your beck and call, you tend to leverage its capability,
giving you higher levels of integration. But it can certainly make
rebuilding difficult...

Also, with the mini-patches, you don't have to worry as much (IMHO) about
having the wrong version. Typically, you'd need "all" of the versions, and
they're all named properly. Whereas with a typical .so, they all share the
same name, "libxyz.so", regardless of the version (unless you do something
clever like use a link).

When you look in your "patch" directory, it's fairly obvious what the latest
version is (since they're all named that way). Also makes it easy to add
"optional" patches as well, something that is difficult with a shared
library.

Finally, its very easy to undo changes by removing the incremental bits. So,
in case the "new patch" "breaks something", it's easy to undo.

> 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?

My understanding is that the read-only sections are just big blocks of
compiled Lisp that the image mounts and make available. You can redefine
anything you want that specified within the read-only image, because the new
binding will take place in your local read-write memory. Kind of like the
way the old Mac OS would patch the ROMs. The look up vectors were in RAM,
even though the routines were in ROM. You could change the RAM vector of a
routine to point to a new RAM version.

The idea was that if you had big chunks of Lisp that was fairly static, you
could save overal system memory across processes by sharing this code ala a
Shared Library, but since the symbols are in local RAM, you could redefine
them all you wanted. Caveat, I've never actually used this system, it's just
my understanding of how it works.

> Take care,

Regards,

Will Hartung
(willh@msoft.com)

Relevant Pages

  • Re: [rfc][patch] sched: remove smpnice
    ... appended patch) too but was n't much bothered as active load balance ... And the reason is the code still assumes that a unit load is ... I've mistakenly assumed that busiest ... int local_group; ...
    (Linux-Kernel)
  • Re: i was arranging crowns to wrong Edna, whos noding since the predators coach
    ... whilst Yosri smartly highlights them too. ... outcome in Chris's patch might load some abysmal engines. ...
    (sci.crypt)
  • Re: Maintenance Manuals
    ... maxima that's between the true and buckled states. ... I suspect the energy in the structure at this point is ... With a vertical load present, ... vertical load plus the energy of the critical prestress to also be ...
    (rec.bicycles.tech)
  • Re: problems with KB951746
    ... Also, if this were a firewall issue, I think it would be there all the time, ... not just when the system is under load. ... I doubt the patch, or SBS, is the problem here. ... different forwarders, different DNS servers, and root hints only. ...
    (microsoft.public.windows.server.sbs)
  • Re: [PATCH (update 3)] timer: Run calc_load halfway through each round_jiffies second
    ... (I've removed the other CC:s for now to avoid annoying them - assuming removing them from the CC: list doesn't do that). ... I still don't know why you think it may change the computation of load, and it's not really complex at all. ... After an initial sync the patch does not change how often the calc_load computation is run or how it works, it will still be run exactly the same way and every 5*HZ ticks as before. ...
    (Linux-Kernel)