mjh@zurich.ai.mit.edu (Mark Hood) (11/21/90)
marc@ibmpa.awdpa.ibm.com (Marc Pawliger) says:
> There is a rumor that an unexec that does work has been done.
First of all, I speak for neither IBM nor FSF nor MIT, and I offer this
information only for the potential interest of fellow RS6000 users.
The above rumor may be true. I am using a variant of 18.54 in which the
unexec function does work, with the following problems:
A new executable file is NOT created. Instead, both pure and impure
data are saved by the dump function and automatically reloaded
during process initialization.
You must run temacs and redump this data (``make xemacs'' in the src
directory) every time the 6000 is rebooted. Due to unknown weird
problems, one very occasionally must do this after mucking about
with the system even when it doesn't involve a reboot (I wish I
could reliably reproduce this). When this happens *every* emacs
running on the machine is hosed.
The dumped data is placed in a file called .emacs.data. temacs
should be copied to a directory in the user's path and renamed
emacs. When the renamed emacs is run, it picks up the data in
.emacs.data and starts up with preloaded lisp just like a normal
dumped emacs. However, the makefile doesn't understand how to do
any of this and bombs out trying to create xemacs, so this copying
and renaming stuff is currently done by hand. In addition, the path
for .emacs.data is hard-coded into the source (minor problems, but
annoying).
The dumped data is only valid for the machine it was created on.
Thus, every 6000 on a network has to have its own local copy of the
data and the executable.
Shell mode job control (C-c C-c, C-c C-z, etc) does not work if the
emacs is started from an mwm menu. Something somewhere complains
about not having a controlling tty, and ``therefore no job control
in this shell''. One can kludge around this by making mwm launch an
xterm which then runs emacs: f.exec "aixterm -i -e emacs &"
I have no doubt that other problems remain that I haven't noticed. I've
passed on trying to fix any of the above. I find the emacs to be quite
usable for all of my purposes as it is, and it starts up FAST. I've been
using it for a couple of months now.
Questions:
Should I create a diff of this version against the distributed 18.55
and somehow make it available with all its bugs, no guarantee about
anything, in the hope that it may be useful to others?
Since the version under discussion here is an offshoot of 18.54 I
figure the diffs will amount to at least 250K. (I don't have an
18.54 to diff it against). How should such a large thing be
distributed? Is it worth it for some users despite the bugs and the
fact that no one can guarantee that it will work at all on a random
6000 system?
Are RS6000/emacs users by and large content with loading all the
lisp at startup and waiting for an ``official'' unexec from FSF?
Would FSF rather not have a weird buggy emacs running around that
could possibly harm their reputation? Is distributing this diff a
Bad Thing?
I don't really want to do the work of putting together a package, but I
volunteer to do so if there is demand and it won't step on anybody's toes.
--
Mark Hood
mjh@zurich.ai.mit.edu