[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: GSB at MIT-MC
- Subject: patch-system hacking
- From: David L. Andre <DLA at MIT-AI>
- Date: Thu ,28 Jan 82 13:47:00 EDT
- Cc: DLA at MIT-AI, DLA at MIT-MC, BUG-LISPM at MIT-MC
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;
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.