Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!think.com!snorkelwacker.mit.edu!ai-lab!zurich.ai.mit.edu!mjh From: mjh@zurich.ai.mit.edu (Mark Hood) Newsgroups: comp.emacs Subject: no guarantees, but... Message-ID: Date: 20 Nov 90 20:51:06 GMT Sender: news@ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 71 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