Nuking unexec

[Darryl Okahata]

"Stephen J. Turnbull" <stephen at xemacs.org> wrote:

>     Darryl>      This may already be possible (sorry, I haven't
>     Darryl> checked ;-), but it would be *REALLY* nice if plain users
>     Darryl> could make their own, private dumps.  You could
>     Darryl> significantly speed up startup, by preloading a lot of
>     Darryl> user-specific junk from ~/.xemacs/init.el and then dumping
>     Darryl> that.
> 
> In one sense they can, see lisp/site-load.el.  But then they'd need a
> private binary.

     While a separate dump file is preferable, from a disk space
standpoint (perhaps, compressing it, too?), a private binary is fine.
Disk space is cheap.  ;-)  You just have to make sure that the private
binary can tell where the XEmacs installation is.

[ Well, if you're on a multi-user system, then there may be issues ...  ;-)  ]

> I don't think that's what you have in mind.

     Well, while a private binary isn't optimal, it's a perfectly usable
solution.

> So the question is "What
> should the user interface look like?"  Then we can think about the
> API;

Given that this is -- at least initially, until we have more experience
with it -- something of an "advanced feature", we probably don't need a
nice interface.  Here are some wild ideas, to which I've given virtually
no thought ;-):

* Plan A:

	Press a button, and the current state of the running XEmacs gets
	dumped (just like a real, old-fashioned lisp workspace ;-).  All
	of it.  At this point, the user can rename ~/.xemacs/init.el and
	try running the newly-dumped XEmacs (the normal loading of
	init.el and custom.el will still continue).

	[ I can't help but wonder if a lot of additional work is
	  required for this.  I haven't looked, but can the existing
	  pdump code handle dumping an XEmacs with an active GUI?  ]

* Plan B:

	The user runs XEmacs in batch mode (just like today), but the
	contents of init.el (by default) is included in the dump.  A
	different file other than init.el can be optionally specified.

	[ Virtually all of the code needed to do this should already
	  exist.  The only issue that comes to mind is if the user has
	  added interactive code to his init.el (i.e., code that prompts
	  him for something at startup).  ]

> I suspect that most of the implementation is already in
> src/dumper.c.

     Yup.

-- 
	Darryl Okahata
	darrylo at soco.agilent.com

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.