From: SourceForge.net <no...@so...> - 2005-12-22 18:15:18
|
Patches item #549049, was opened at 2002-04-26 08:33 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301355&aid=549049&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: None Priority: 5 Submitted By: Jörg Höhle (hoehle) Assigned to: Nobody/Anonymous (nobody) Summary: unlock or create packages for modules Initial Comment: 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") Regards, Jörg Höhle. ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2005-12-22 13:15 Message: 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. ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-12-22 12:33 Message: 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 :-( ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-12-22 11:58 Message: 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"). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2004-07-12 08:57 Message: 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. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2003-07-23 15:57 Message: Logged In: YES user_id=5735 TO_PRELOAD is here to stay. <http://article.gmane.org/gmane.lisp.clisp.devel/10121> ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2003-01-31 10:49 Message: 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). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2003-01-31 09:57 Message: Logged In: YES user_id=5735 Joerg, did you abandon this patch? should we close it? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2002-04-30 21:03 Message: 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? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2002-04-30 13:01 Message: 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? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2002-04-26 12:46 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=301355&aid=549049&group_id=1355 |