Re: Beware of modules.

> > 3- Modules and undumping aren't really compatible > > > > Undumping requires loading a lot of lisp. Said lisp uses most of the > > functions that would end up in modules, hence all the modules will > > have to be loaded. Worse, the data and bss sections of these modules > > will have references to the lisp code. Do we want to write a module > > undumper? > Eh? I dont understand this objection at all. Why do you want to undump > something that is dynamic? Please expand on this more so that I can > understand the objection / limitation. XEmacs isn't an editor written in C. XEmacs is written in emacs lisp. The C part is constituted of: - the core lisp engine - all the basic tasks involving the environment (accessing files, drawing to screen...) - some functions that could have been written in lisp, but would have been too slow as a result Part of the building process of XEmacs is called the undumping. A bunch of lisp is loaded which "plugs" into the C level through static variables (the staticpro'ed ones) and then a new executable is created which includes said lisp. If you use modules for parts of the engine, you will need to find some way to link back said static variables to the lisp code. I wouldn't even know where to start.

For the people out there who don't understand modern VMs very well, let me outline two scenarios where a user wants to use for the first time a DB function: a- monolithic executable: - the function is called - page fault, the code is loaded in memory. A bit of read-ahead of the code is done before and after the function - the function runs b- module - the program sees that the function is not in memory - the module is found and the function table is loaded (but not the function code itself, usually) - the function pointers are updated - the function is eventually called. Go to a. Guess who's fastest ?