Re: Module/Namespace problems at scm_init_*_module time.

[Rob Browning]

Hate to follow myself up, but I think I figured out at least most of
the problem, and I have a suggested short-term solution, as well as a
proposed longer-term boot-9.scm patch (I'm cc-ing this to devel as
well -- which is why I'm including the original message below):

Basically, after monkeying around with boot-9.scm, I realized that the
module that's implicitly created when you're loading a module from a
dlopened dynamic library has an empty list for (module-uses module).
That's because these modules are never "beautified" via
beautify-user-module!.  This makes it very hard to do much other than
register procedures from your dynamic library.

If there's not a really good reason to avoid adding the standard
"uses" to these dynamic modules, and presuming there's some reason not
to just call "beautify" on the module then I'd suggest perhaps
changing boot-9.scm: init-dynamic-module as follows:

                     (lambda ()
                       (set-current-module mod)
                       (set-module-public-interface! mod mod)
                       (set-module-uses mod (list the-scm-module))
                       (dynamic-call (cadr modinfo) (caddr modinfo))
                       ))

Also, as a temporary measure, and for backward-compatibility, I found
that you can do the following in your dlopened shared libs at the top
of your module's registered "init" function to get the same effect:

    gh_call2(gh_lookup("set-module-uses!"),
             gh_call0(gh_lookup("current-module")),
             gh_list(gh_lookup("the-scm-module"),
                     SCM_UNDEFINED));

Oh, and if my analysis/solution isn't wrong, I'd be happy to write up
something for guile.info and send it in.

Thanks

Rob Browning <address@hidden> writes:

> I'm in the process of reworking a lot of g-wrap, and I'm adding
> fancier support for shared libraries, but I'm kind of stumped at the
> moment on what I suspect is a namespace issue.
> 
> Basically, I need to be able to invoke some scheme code from within a
> scm_init_*_module file, but as far as gh_eval_str is concerned,
> nothing is defined (i.e. not current-module, quote, newline,
> nothing...).  However, gh_lookup can find some things.
> 
> So my first question is, is there something I need to do in the
> scm*init function to get to the point of having a normal scheme side
> namespace?
> 
> My second question is related, but more specific to my current
> situation.
> 
> Presume I've got a module named (g-wrap runtime) that's implemented in
> g-wrap/runtime.scm, and it's defined as follows:
> 
>   (define-module (g-wrap runtime))
>   (define (some-scm-func-scm_init_runtime_wrappers_module-needs ...) ...)
>   ...
>   (use-modules (g-wrap runtime-wrappers))
> 
> so (g-wrap runtime-wrappers) won't load until after the scm side
> function it needs has been defined.
> 
> If I want for runtime-wrappers to be able to see the scm func that it
> needs (the one defined above), then I need to "use" (g-wrap runtime)
> from g-wrap/libruntime-wrappers.so somehow, but so far I haven't had
> any luck.
> 
> I tried to put a
> 
>   gh_eval_str("(use-modules (g-wrap runtime))");
> 
> in _init, but that failed claiming that use-modules isn't defined.
> 
> and I tried using 
> 
>     gh_display(gh_call1(gh_lookup("process-use-modules"),
>                         gh_list(gh_list(gh_symbol2scm("g-wrap"),
>                                         gh_symbol2scm("runtime"),
>                                         SCM_UNDEFINED),
>                                 SCM_UNDEFINED)));
> 
> directly, but that fails too, though it does appear to successfully
> call process-use-modules.
> 
> So is there a way to get this to work, or am I going to have to
> rethink my approach?
> 
> Thanks
> 
> -- 
> Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930
> 
> _______________________________________________
> Guile-user mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/guile-user
> 

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930