patch-system hacking

[David L. Andre <DLA at MIT-AI>]

    GSB@MIT-MC 01/28/82 11:50:27 Re: patch-system hacking
    To: DLA at MIT-MC
    CC: (BUG LISPM) at MIT-MC
    I've had per-minor-version-number system-statuses for some time now
    in the kludge i maintain for Maclisp.  They are essentially just that;
    each of the entries in the patch-directory can have a field which is
    the new system-status for that minor version.
I like this, because it doesn't break programs which rely on the version
number being the CAR of every patch entry.

    About the only other thing i found i just had to add was a protocol for
    changing the system status out from under a dump.  Essentially, the
    dumped maclisp job has to call a function which looks at the patch directory
    and re-reads the system status for its exact version number.  This
    of course is hidden away in stuff which does jcl parsing and init file
    loading;  but it is fairly important if, say, it is discovered that
    something is broken after it has been installed.  (Things like load-patches
    automatically do this update since they are accessing the patch-directory.)
I don't think it's reasonable yet to have the system load-patches for
you.  What are other people's thoughts on this?

    p.s.  there should be a function to nicely print the out-of-core stuff,
    somewhat like print-system-modifications.  I called it print-system-history;
    in ml:lsb1;ppatch
At least, a useful extension to LOAD-PATCHES would make you able to view
all the unloaded patches (Perhaps by answering V to the question),
before loading them.