LISPFUN() in external modules ought to be created in
any package, esp. FFI, EXT or SYS, or even new
packages, e.g. GDI.
This reduces the need for .mem and TO_PRELOAD files
which only do (MAKE-PACKAGE "GDI")
1. package lock status must be restored
2. it must be checked that the symbol being interned is not
there yet, i.e., that we are not clobbering some system
functionality.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ad 1. package lock must be restored by the programmer,
either in module_initfunc1(), or in Lisp code loaded later.
It cannot be restored after installing the SUBR, since
unlocking is also the door opener for the module_object_tab,
where the package is unknown. Without that, the patch has
little utility for module writers.
E.g. SUBR walked thtough first -> unlock e.g. GDI, then no
problem creating symbols there, then module_initfunc1 locks
again or gdi.lisp code locks package again.
Ad 2. Nice idea - but maybe somebody specifically *wants*
that?
Anyway, this safe-guard protection is a new functionality
(modules existed for 7 years without it), to be patched
separately.
DEFUN doesn't complain when you overide something (except
package-locks). Why should module's LISPFUN be different?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
let's step back.
why is the lock problem here at all?!
a module _should_ live in it's own package, and all new
packages are created unlocked (they _should_ be locked after
the module is created, indirectly, by being pushed on
*sustem-package-list* - I should mention this in the docs!).
SO: what is that package we are unlocking?!
Another issue is the automatic package creation.
I don't like it either (what if you misspell the package
name? you will get an extra package, which you will notice
until much later, and some weird errors that will take
forever to debug).
What about supplying new packages in modules.h?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I consider this issue still open, but low-priority.
I need to analyse why Kaz (was it him?) was able to build a
Lisp without package problem. I believe it worked without
patch due to the way the clisp-link script works,
constructing temporary images in between or something like
that.
When attempting to work with few images and initialize
modules as needed, like I explain in my "extending CLISP"
text, one is still hit by this issue, I'm sure.
I've focussed my priorities right now on finishing easy
things: ffi-malloc, with-foreign-string (RSN) and then
finally the dlopen() stuff (whose high-level API I've still
not completely fixed).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Joerg, I am marking this as "pending".
this means that you have 2 weeks to decide if
you still think that this patch is worth pursuing,
and, if you decide to pursue it,
you will need to add a comment here
that would explain why you think we need to auto-create
packages when building modules when READ does not auto-create
packages on (READ-FROM-STRING "FOO:BAR").
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, my recent experiment with dynload-modules
reinforced the impression that auto-creation is TRT.
Improvements might come along with adding an extra symbol to
module__xyz: the package name. This one would be filled by
DEFMODULE. It's my newest idea. It's different from the
patch in that it allows for one package only (& requires
incompatible changes to all module files).
Having this slot might then allow to relock the package
afterwards, possibly -- or to wait until the subsequent Lisp
file does it.
Concerning redefinitions, I think that a warning is
appropriate (instead of silent overide). I'll have to check
the current behaviour of CLISP. I think continuable errors
are problematic in the early initialisation phase of CLISP.
>building modules when READ does not auto-create
>packages on (READ-FROM-STRING "FOO:BAR")
Oops, did I miss something? Normally that would signal an
error in CL. Auto-creation from READ?!?
Additional complexity comes from modern/case-insensitive
packages (PARI is the only example in
modules/*/preload.lisp). That was not present in 2002.
Feature interaction :-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>>building modules when READ does not auto-create
>>packages on (READ-FROM-STRING "FOO:BAR")
>Oops, did I miss something? Normally that would signal an
>error in CL. Auto-creation from READ?!?
what I am saying is that (READ-FROM-STRING "FOO:BAR")
will signal an error instead of creating a new package,
and interning and exporting a symbol from it.
I see no reason for modules to be any different.
if you insist on not using TO_PRELOAD,
you might want to try the init1 function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
of course, init1 is too late, you would have to add init0
which is real real real ugly.
in short, there are two alternatives to preload:
1. auto-unlocking/auto-creation -- totally un-Lispy
2. init0 -- yuky & ugly.
in fact, init1 is yuky already.
it's bootstrap C code that we are forced to carry around in
production executables!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=5735
1. package lock status must be restored
2. it must be checked that the symbol being interned is not
there yet, i.e., that we are not clobbering some system
functionality.
Logged In: YES
user_id=377168
Ad 1. package lock must be restored by the programmer,
either in module_initfunc1(), or in Lisp code loaded later.
It cannot be restored after installing the SUBR, since
unlocking is also the door opener for the module_object_tab,
where the package is unknown. Without that, the patch has
little utility for module writers.
E.g. SUBR walked thtough first -> unlock e.g. GDI, then no
problem creating symbols there, then module_initfunc1 locks
again or gdi.lisp code locks package again.
Ad 2. Nice idea - but maybe somebody specifically *wants*
that?
Anyway, this safe-guard protection is a new functionality
(modules existed for 7 years without it), to be patched
separately.
DEFUN doesn't complain when you overide something (except
package-locks). Why should module's LISPFUN be different?
Logged In: YES
user_id=5735
let's step back.
why is the lock problem here at all?!
a module _should_ live in it's own package, and all new
packages are created unlocked (they _should_ be locked after
the module is created, indirectly, by being pushed on
*sustem-package-list* - I should mention this in the docs!).
SO: what is that package we are unlocking?!
Another issue is the automatic package creation.
I don't like it either (what if you misspell the package
name? you will get an extra package, which you will notice
until much later, and some weird errors that will take
forever to debug).
What about supplying new packages in modules.h?
Logged In: YES
user_id=5735
Joerg, did you abandon this patch?
should we close it?
Logged In: YES
user_id=377168
I consider this issue still open, but low-priority.
I need to analyse why Kaz (was it him?) was able to build a
Lisp without package problem. I believe it worked without
patch due to the way the clisp-link script works,
constructing temporary images in between or something like
that.
When attempting to work with few images and initialize
modules as needed, like I explain in my "extending CLISP"
text, one is still hit by this issue, I'm sure.
I've focussed my priorities right now on finishing easy
things: ffi-malloc, with-foreign-string (RSN) and then
finally the dlopen() stuff (whose high-level API I've still
not completely fixed).
Logged In: YES
user_id=5735
TO_PRELOAD is here to stay.
<http://article.gmane.org/gmane.lisp.clisp.devel/10121>
Logged In: YES
user_id=5735
If it ain't broken, don't fix it.
TO_PRELOAD is not broken.
I will not handle this issue.
Logged In: YES
user_id=5735
Joerg, I am marking this as "pending".
this means that you have 2 weeks to decide if
you still think that this patch is worth pursuing,
and, if you decide to pursue it,
you will need to add a comment here
that would explain why you think we need to auto-create
packages when building modules when READ does not auto-create
packages on (READ-FROM-STRING "FOO:BAR").
Logged In: YES
user_id=377168
Actually, my recent experiment with dynload-modules
reinforced the impression that auto-creation is TRT.
Improvements might come along with adding an extra symbol to
module__xyz: the package name. This one would be filled by
DEFMODULE. It's my newest idea. It's different from the
patch in that it allows for one package only (& requires
incompatible changes to all module files).
Having this slot might then allow to relock the package
afterwards, possibly -- or to wait until the subsequent Lisp
file does it.
Concerning redefinitions, I think that a warning is
appropriate (instead of silent overide). I'll have to check
the current behaviour of CLISP. I think continuable errors
are problematic in the early initialisation phase of CLISP.
>building modules when READ does not auto-create
>packages on (READ-FROM-STRING "FOO:BAR")
Oops, did I miss something? Normally that would signal an
error in CL. Auto-creation from READ?!?
Additional complexity comes from modern/case-insensitive
packages (PARI is the only example in
modules/*/preload.lisp). That was not present in 2002.
Feature interaction :-(
Logged In: YES
user_id=5735
>>building modules when READ does not auto-create
>>packages on (READ-FROM-STRING "FOO:BAR")
>Oops, did I miss something? Normally that would signal an
>error in CL. Auto-creation from READ?!?
what I am saying is that (READ-FROM-STRING "FOO:BAR")
will signal an error instead of creating a new package,
and interning and exporting a symbol from it.
I see no reason for modules to be any different.
if you insist on not using TO_PRELOAD,
you might want to try the init1 function.
Logged In: YES
user_id=5735
please do not modify DEFMODULE.
add another macro DEFPACKAGE instead.
the macro should translate into code in init1.
Logged In: YES
user_id=5735
of course, init1 is too late, you would have to add init0
which is real real real ugly.
in short, there are two alternatives to preload:
1. auto-unlocking/auto-creation -- totally un-Lispy
2. init0 -- yuky & ugly.
in fact, init1 is yuky already.
it's bootstrap C code that we are forced to carry around in
production executables!
Logged In: YES
user_id=5735
you might consider making modprep generate the preload file.
I am not sure this actually buys you much though...
please see how I handle redefining srror.d:sys::strerror in module syscalls
(patch 15522:eafb54143f18)