#6 unlock or create packages for modules

open
Jörg Höhle
None
5
2011-08-19
2002-04-26
Jörg Höhle
No

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.

Discussion

<< < 1 2 3 > >> (Page 2 of 3)
  • Sam Steingold
    Sam Steingold
    2005-12-22

    • status: open --> pending-rejected
     
  • Sam Steingold
    Sam Steingold
    2005-12-22

    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").

     
  • Jörg Höhle
    Jörg Höhle
    2005-12-22

    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 :-(

     
  • Jörg Höhle
    Jörg Höhle
    2005-12-22

    • status: pending-rejected --> open-later
     
  • Sam Steingold
    Sam Steingold
    2005-12-22

    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.

     
  • Sam Steingold
    Sam Steingold
    2005-12-22

    • status: open-later --> open
     
  • Sam Steingold
    Sam Steingold
    2005-12-22

    Logged In: YES
    user_id=5735

    please do not modify DEFMODULE.
    add another macro DEFPACKAGE instead.
    the macro should translate into code in init1.

     
  • Sam Steingold
    Sam Steingold
    2005-12-22

    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!

     
  • Sam Steingold
    Sam Steingold
    2005-12-22

    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...

     
  • Sam Steingold
    Sam Steingold
    2011-08-19

    please see how I handle redefining srror.d:sys::strerror in module syscalls
    (patch 15522:eafb54143f18)

     
<< < 1 2 3 > >> (Page 2 of 3)