problem with module system in guile 1.6.x and post versions

problem with module system in guile 1.6.x and post versions

[stefan]

Hello Kevin!

Can you help me out with some knowledge on the new module system in Guile
1.6.x and post versions.  The issue is related to the GNU Serveez package
which I am maintaining.

The problem occurs to be:

 1. I have some symbols exported via scm_c_define_gsubr().  These I can
    use at top level, e.g. (serveez-version).
 2. The I have a 'test-suite.scm' file using

(define-module (test-suite))

(define (test)
 ...
 (serveez-version)
 ...
)

(export test)

 3. Then I use a 'binary-test.scm' where I

(use-modules (test-suite))
...
(test)

    This runs the (test) function which has been exported by the
    test-suite module... and fails using (serveez-version) be marked as
    'unbound-variable'.

This worked with Guile 1.4 versions.  Ok - I thought - play around with
the new module functions.  In the 'test-suite.scm' file added a procedure:

;; FIXME: Does this code import the public symbols of the guile-user
;; module into the current module?
(define (resolve-serveez-api)
  (module-for-each
   (lambda (symbol variable)
     (module-add! %module-public-interface symbol variable))
   (resolve-module '(guile-user))))

In fact I do get all of the api defined by scm_c_define_gsubr() but they
still not availabe in the test-suite module.

Can you please help us with that?

Thanks in advance,
	stefan@lkcc.org

Re: problem with module system in guile 1.6.x and post versions

[Marius Vollmer]

stefan <stefan@lkcc.org> writes:

>  1. I have some symbols exported via scm_c_define_gsubr().  These I can
>     use at top level, e.g. (serveez-version).

The definitions created with scm_c_define_gsubr are inserted into the
'current module'.  You should therefore make sure that the right
module is the current one when you call scm_c_define_gsubr, for
example by using scm_c_define_module or
scm_c_call_with_current_module.

Your current code will likely add the new binding to the
'(guile-user)' module because that module is the current one by
default.  In Guile 1.4, the core module '(guile)' was the default
current module.  '(guile)' is automatically used by all other modules
so you binding was automatically visible everywhere.


I recommend to make a new module that contains all the c level serveez
functions:

  void
  serveez_init_module_bindings (void *unused)
  {
    scm_c_define_gsubr ("serveez-version", ...);
    scm_c_define_gsubr ("bar", ...);
    ...
    scm_c_export ("serveez-version", "bar", ..., NULL);
  }

  void
  serveez_create_module ()
  {
    scm_c_define_module ("serveez builtin",
                         serveez_init_module_bindings, NULL);
  }

Then use that module where you need it:

  (define-module (test-suite)
    :use-module (serveez builtin))

  (define (test)
    ...
    (serveez-version)
    ...)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

Re: Re: problem with module system in guile 1.6.x and post versions

[stefan]

On 31 May 2003, Marius Vollmer wrote:

> Your current code will likely add the new binding to the
> '(guile-user)' module because that module is the current one by
> default.  In Guile 1.4, the core module '(guile)' was the default
> current module.  '(guile)' is automatically used by all other modules
> so you binding was automatically visible everywhere.
>
>
> I recommend to make a new module that contains all the c level serveez
> functions:
>
>   void
>   serveez_init_module_bindings (void *unused)
>   {
>     scm_c_define_gsubr ("serveez-version", ...);
>     scm_c_define_gsubr ("bar", ...);
>     ...
>     scm_c_export ("serveez-version", "bar", ..., NULL);
>   }
>
>   void
>   serveez_create_module ()
>   {
>     scm_c_define_module ("serveez builtin",
>                          serveez_init_module_bindings, NULL);
>   }
>
> Then use that module where you need it:
>
>   (define-module (test-suite)
>     :use-module (serveez builtin))
>
>   (define (test)
>     ...
>     (serveez-version)
>     ...)

Hm.  This somehow implies that

   (define-module (test-suite)
     :use-module (guile-user))

would be sufficient to solve the problem.  But in fact in does not.  Why
is this?

Even more confusing is that

  (display (current-module))

tells me '#<directory (test-suite) 80cb260>' outside functions (e.g. right
behind the (define-module ...) thingie).  But in a function exported by
the (test-suite) it tells me '#<directory (guile-user) 80cc500>'.

BTW: I am testing with Guile 1.6.3, if that matters...

Thanks in advance,
	stefan@lkcc.org

Re: [dev-serveez] Re: problem with module system in guile 1.6.x and post versions

[Marius Vollmer]

stefan <stefan@lkcc.org> writes:

> Hm.  This somehow implies that
> 
>    (define-module (test-suite)
>      :use-module (guile-user))
> 
> would be sufficient to solve the problem.  But in fact in does not.  Why
> is this?

Did you export your bindings?  That is, did you call 'scm_c_export' in
C or did you use 'export' in Scheme?

> Even more confusing is that
> 
>   (display (current-module))
> 
> tells me '#<directory (test-suite) 80cb260>' outside functions (e.g. right
> behind the (define-module ...) thingie).  But in a function exported by
> the (test-suite) it tells me '#<directory (guile-user) 80cc500>'.

Think of the current module simply as a global (per-thread) variable.
The current module is not associated with a place in the code.  It is
associated with a certain extent of time, like the values of all
global variables.

When a function is defined (more precisely, when a closure is
created), the current module (at the time of the definition) is
recorded in the lexical environment of the function.  All non-local
variable references within that function are resolved with that
recorded module.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: [dev-serveez] Re: problem with module system in guile 1.6.x and post versions

[stefan]

On 1 Jun 2003, Marius Vollmer wrote:

> > Hm.  This somehow implies that
> >
> >    (define-module (test-suite)
> >      :use-module (guile-user))
> >
> > would be sufficient to solve the problem.  But in fact in does not.  Why
> > is this?
>
> Did you export your bindings?  That is, did you call 'scm_c_export' in
> C or did you use 'export' in Scheme?

Oh well.  That did it.

> > Even more confusing is that
> >
> >   (display (current-module))
> >
> > tells me '#<directory (test-suite) 80cb260>' outside functions (e.g. right
> > behind the (define-module ...) thingie).  But in a function exported by
> > the (test-suite) it tells me '#<directory (guile-user) 80cc500>'.
>
> Think of the current module simply as a global (per-thread) variable.
> The current module is not associated with a place in the code.  It is
> associated with a certain extent of time, like the values of all
> global variables.
>
> When a function is defined (more precisely, when a closure is
> created), the current module (at the time of the definition) is
> recorded in the lexical environment of the function.  All non-local
> variable references within that function are resolved with that
> recorded module.

Thanks for this explanation.

Thus (module-for-each ... ) returns all variables, local and public ones,
right?

With your help I was able to solve the serveez problems.

Thanks,
	stefan@lkcc.org



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: [dev-serveez] Re: problem with module system in guile 1.6.x and post versions

[Marius Vollmer]

stefan <stefan@lkcc.org> writes:

> Thus (module-for-each ... ) returns all variables, local and public ones,
> right?

Yes.


We should make a FAQ entry out of this.  Would anyone like to put
forth a patch against docs/guile-faq.texi with tested code snippets?

(docs/guile-faq.texi is in the WWW CVS repo.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user