Re: Problem with modules in Guile 2.0

[Gubinelli Massimiliano]

Hi Mark,
 thanks again. I start to understand better the Guile 2 compile system. I 
decided to dig into boot-9.scm to have a more precise idea of the ecosystem 
around my scripts. Unfortunately it seems that the basic TeXmacs scripting 
infrastructure need a major change to be run into Guile 2.0 and I'm afraid not 
to be sufficiently proficient in scheme to do this in a short time. Is there 
anyone on this list which would like to assist me to port GNU TeXmacs to Guile 
2.0. Currently the code in svn builds fine against 2.0 so the problem is just 
to adapt the scheme scripts which rely on a customized module system. If you 
are interested you can contact me privately. In the meantime I will dig into 
the code hoping to find illumination among parentheses….

best
max


On Mar 8, 2012, at 3:01 AM, Mark H Weaver wrote:

> Gubinelli Massimiliano <address@hidden> writes:
> 
>> Thanks for the prompt reply to both of you. However the proposed
>> solution do not work in my case.
> 
> I think it _did_ solve your original problem, but now you have moved on
> to other unrelated problems.
> 
>> After implementing the
>> begin-for-syntax alternative I now get
>> 
>> scheme@(guile-user)> (load "main.scm")
>> ;;; compiling /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm
>> ;;; note: source file 
>> /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm
>> ;;; newer than compiled
>> /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm.go
>> ;;; compiling /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm
>> ;;;
>> /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:15:34:
>> warning: possibly unbound variable `compile-interface-spec'
> 
> Note that 'compile-interface-spec' was an undocumented internal
> procedure of Guile 1.x, and no longer exists in Guile 2.
> 
>> ;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:32:11: 
>> warning: possibly unbound variable `:use'
>> ;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:33:11: 
>> warning: possibly unbound variable `:inherit'
>> ;;; /Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm:34:11: 
>> warning: possibly unbound variable `:export'
> 
> In order to use the shorter keyword syntax ':use' (instead of '#:use'),
> you must set the prefix keywords reader option.  Put the following at
> the beginning of your 'begin-for-syntax' form:
> 
>  (read-set! keywords 'prefix)
> 
>> ;;; compiled 
>> /Users/mgubi/.cache/guile/ccache/2.0-LE-8-2.0/Users/mgubi/t/build-64-guile-2.0/test-modules/test-modules.scm.go
>> ;;; WARNING: compilation of 
>> /Users/mgubi/t/build-64-guile-2.0/test-modules/main.scm failed:
>> ;;; ERROR: No variable named %module-public-interface in #<directory (sub 
>> mymodule) 10507ed80>
>> ERROR: In procedure scm-error:
>> ERROR: No variable named %module-public-interface in #<directory (sub 
>> mymodule) 10507ed80>
>> 
>> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) [1]> 
>> 
>> if I understand correctly this backtrace it seems that the module is
>> not completely loaded at compile time and there is not public
>> interface available. How can I force the evaluation of the loaded
>> modules in order to get a list of exported symbols?
> 
> I cannot reproduce this.  When I try using your example code, Guile
> 2.0.5 tries to compile (sub mymodule).  Are you sure that you remembered
> to set GUILE_LOAD_PATH during this test run?
> 
> This is what I see:
> 
>  GNU Guile 2.0.5
>  Copyright (C) 1995-2012 Free Software Foundation, Inc.
> 
>  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>  This program is free software, and you are welcome to redistribute it
>  under certain conditions; type `,show c' for details.
> 
>  Enter `,help' for help.
>  scheme@(guile-user)> (load "main.scm")
>  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
>  ;;;       or pass the --no-auto-compile argument to disable.
>  ;;; compiling /home/mhw/guile-modules/main.scm
>  ;;; compiling /home/mhw/guile-modules/./test-modules.scm
>  ;;; test-modules.scm:15:34: warning: possibly unbound variable 
> `compile-interface-spec'
>  ;;; compiled 
> /home/mhw/.cache/guile/ccache/2.0-LE-4-2.0/home/mhw/guile-modules/test-modules.scm.go
>  ;;; compiling /home/mhw/guile-modules/sub/mymodule.scm
>  ;;; sub/mymodule.scm:1:0: warning: possibly unbound variable `texmacs-module'
>  ;;; sub/mymodule.scm:1:16: warning: possibly unbound variable `sub'
>  ;;; sub/mymodule.scm:1:16: warning: possibly unbound variable `mymodule'
>  ;;; compiled 
> /home/mhw/.cache/guile/ccache/2.0-LE-4-2.0/home/mhw/guile-modules/sub/mymodule.scm.go
>  ;;; WARNING: compilation of /home/mhw/guile-modules/main.scm failed:
>  ;;; ERROR: In procedure module-lookup: Unbound variable: texmacs-module
>  sub/mymodule.scm:1:0: In procedure #<procedure 1058ebb0 ()>:
>  sub/mymodule.scm:1:0: In procedure module-lookup: Unbound variable: 
> texmacs-module
> 
>  Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>  scheme@(#{ g435}#) [1]> 
> 
> and the problem here is that the compilation of sub/mymodule.scm fails
> because the 'texmacs-module' macro was used before it was imported into
> that module.  Initially, a module imports only the (guile) module.  If
> you want to use a non-standard module declaration like 'texmacs-module'
> at the top of a module, you'll need to add that binding to the (guile)
> module.
> 
>    Best,
>     Mark