Subject: Re: [clisp-list] module support

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Fri Apr 26 04:22:08 2002

Peter,

> I have to ask: What did Napoleon say???
approximately "N'attribuez pas a la malice ce qui peut etre explique par l'incompetence." -- don't believe wisdom is involved when a simpler explanation may be incompetence or ignorance.

About modules and package locks:
Dan Stanger's GDI has a file to preload which reads as follows: (MAKE-PACKAGE "GDI"). That's all - 1MB for that. Then you must dump an image with an old lisp, then you must create a lisp.exe with the module, then you can make use of it.

The extra image (of little added value) until now cannot be avoided. This waters
the recommendation in my article on modules, where I explain that it's much better (on disk space and flexibility) to have a single original image, as module initialization time is negligible.
With such an old image, you can later create any lisp.exe with as many modules as you want and never have CLISP complain "this image was not generated with this version of CLISP".

With the current state, this is broken,
 - for extensions to the FFI because of locking (dynload),
 - for new packages because they must be created first (GDI, LDAP)

> A "works for me" patch is fine.  Anyway, it will help anyone who
> writes or wants to write modules by hand.  I hope to get around to
> hand-written modules real soon now (TM) :-)
It would indeed help Dan. His GDI would not need an extra image anymore before lisp.run can start.

I'll submit a patch to
a) create package if needed
b) unlock package for every LISPFUN found in the module.

> In an attempt to recreate the problem, so I could experiment with
> using mark_pack_unlocked.  But it all compiles fine, with no
> complaints about locked packages!!!! And with
> #'foreign-address-function, etc in "FFI".
> What the fuck is going on?

I have an explanation. It all depends on the order in which you compiled the successive CLISP's with and without modules, created the images etc.
Here's how:
Start with a virgin lisp.run, without -M: Package FFI is there, unlocked.
Recompile to use module dynload.
Create image using this lisp: lisp-with-dynload.run -x (load "init.fas")
-> module is initialized first, FFI is not locked.
-> image is created, with all packages locked.
But dynload is already there, and it's in package FFI.

So with the FFI package, you happen to be safe. Not so for new packages, e.g. GDI, because they were not created.

Now the other scenario: user has lisp.exe and old lispinit.mem
Recreate lisp.exe with dynload.d
lisp-with-dynload.exe -M lispinit.mem => attempt to add to locked FFI package error
lisp-with-dynload.exe without -M : no error
lisp-with-dynload.exe -x (load "init.fas"): can create new image with DYNLOAD in it.
lisp-with-dynload.exe -M newimage: no error, already initialized

So depending on the path taken by the user, s/he might see errors or not...
I hate this inconsistent (to the user) behaviour.

Regards,
	Jorg Hohle.