[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: dynamic loading of native code modules]
From: |
Neil Jerram |
Subject: |
Re: address@hidden: dynamic loading of native code modules] |
Date: |
13 Apr 2002 09:50:22 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Thien-Thi" == Thien-Thi Nguyen <address@hidden> writes:
Thien-Thi> guile-1.4 supports extending module name semantics to allow
mapping also
Thien-Thi> to .so in addition to .scm files (albeit low level uses dyn*
directly --
Thien-Thi> could use update (patches welcome)). 1.6 does not at the moment
(it was
Thien-Thi> removed). grep "dyn" reveals 1537 hits since 2000-01. anyone
have
grep "dyn" where?
Thien-Thi> specific pointers for removal rationale? where is that refbot?
I think just that the scm_init_xxx - scm_register_module_xxx -
scm_init_module_xxx was thought rather awkward, and that too much of
the boot-9.scm code was trying to be cleverer than it could justify.
I recall an email from Marius saying this, but I don't have a specific
pointer.
Thien-Thi> it is possible to provide support again in `resolve-interface',
but this
Thien-Thi> support should not be put in boot-9.scm. instead,
resolve-interface
Thien-Thi> ought to add a user hook somewhere, or be tunable in some other
way.
Thien-Thi> this allows users to customize their concept of "interface" in a
Thien-Thi> well-defined environment (entirely :-) suited for such
customization.
Thien-Thi> instantiable modules can be supported, etc.
Thien-Thi> in parallel w/ this change is of course revival of (use-modules
FOO)
Thien-Thi> possibly resolving to .../libfoo.so.x.y.z, using the above hook
and the
Thien-Thi> modern load-extension interface. the previous mapping proc needs
Thien-Thi> rationalization and some design to keep weird use-cases in check.
Yes, I think this would be good, actually, and that the
mechanism/hooks that you suggest are exactly the right approach.
The description you gave of the Emacs patch glossed over one detail -
what's the name of the function that gets called to initialize the
dynamically loaded module? I think it would be acceptable to derive
it algorithmically from the module name (and obviously impose this as
a requirement on the module coder).
If we can agree this, it would be good to do it in 1.6, for
continuity. (Of interface, I mean; module coding would change
slightly, as just stated.)
Thien-Thi> another runner in the race is replacing lowest levels of the
module
Thien-Thi> system w/ environments, using the above hook (or similar
internal hook)
Thien-Thi> for implementation. getting load-extension and environments
together,
Thien-Thi> basically.
Sounds orthogonal to me; is it?
Thien-Thi> alternatively, we need to document *why* 1.6 chooses to rob the
users
Thien-Thi> so, at least to ourselves. "This has been found to be too
tricky, and
Thien-Thi> is no longer supported" is, although not dis-honest, still
pretty lame.
Upon reflection, I agree.
More generally, looking back through mailing list history, it's
actually astonishing how much support for various stuff that Guile has
_lost_ along the way. My overall impression is that we (collectively)
have been too glib about this.
Neil
- address@hidden: dynamic loading of native code modules], Thien-Thi Nguyen, 2002/04/11
- Re: address@hidden: dynamic loading of native code modules],
Neil Jerram <=
- Re: address@hidden: dynamic loading of native code modules], Rob Browning, 2002/04/13
- Re: address@hidden: dynamic loading of native code modules], Neil Jerram, 2002/04/14
- Re: address@hidden: dynamic loading of native code modules], Rob Browning, 2002/04/15
- Re: address@hidden: dynamic loading of native code modules], Neil Jerram, 2002/04/16
- Re: address@hidden: dynamic loading of native code modules], Rob Browning, 2002/04/17
- Re: address@hidden: dynamic loading of native code modules], Thien-Thi Nguyen, 2002/04/20
- Re: address@hidden: dynamic loading of native code modules], Neil Jerram, 2002/04/20
- Re: address@hidden: dynamic loading of native code modules], Marius Vollmer, 2002/04/15
- Re: address@hidden: dynamic loading of native code modules], Neil Jerram, 2002/04/16
- Re: address@hidden: dynamic loading of native code modules], NIIBE Yutaka, 2002/04/16