[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: T1055: Avoid using deprecated %module-public-interface in guile init

From: Ian Hulin
Subject: Re: T1055: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)
Date: Thu, 05 Aug 2010 00:13:51 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1

Hash: SHA1

Hi all,

On 01/08/10 22:37, Patrick McCarty wrote:
> On Sun, Aug 1, 2010 at 2:02 PM, Neil Puttock <address@hidden> wrote:
>> On 1 August 2010 21:49, Patrick McCarty <address@hidden> wrote:
>>> I think I found the problem.
>>> With Guile 1.9, `module-public-interface' doesn't return an interface
>>> for `the-scm-module', which we rely on:
>>>  scheme@(guile-user)> (module-public-interface the-scm-module)
>>>  $1 = #f
>>>  scheme@(guile-user)>
>>> I'll report this upstream.
>> OK.  I was just about to reply, since I've seen that error using 1.8
>> (trying to use `resolve-interface' instead of
>> module-public-interface).
> This is quite interesting.  :)
> I just did a little more research, and these three calls all return
> the same interface, but the last one doesn't work with Guile 1.9:
>   guile> (resolve-interface '(guile))
>   #<interface (guile) 7f3f91117840>
>   guile> (module-public-interface the-root-module)
>   #<interface (guile) 7f3f91117840>
>   guile> (module-public-interface the-scm-module)
>   #<interface (guile) 7f3f91117840>
>   guile>
> So, it looks like we might want to do this:
> -      SCM scm_module = ly_lily_module_constant ("the-scm-module");
> +      SCM scm_module = ly_lily_module_constant ("the-root-module");
I'll ensure this change is in the next patch set for T1055.

À propos of which, I've just hacked things so it gets through the
regression tests without the call using %module-public-interface woot! :-).

However, to do this I've had to change one regression test and one other
.scm file used in initialization to add
(use modules (scm clip-region)).

It looks like the reason is that we have been using a side-effect of the
call to %module-public-interface to pick up a call to the above
use-modules in  It looks like the side-effect was pick up not
only the public interface (all the (define-public) declarations etc. of
the current module, but also all the public interfaces on the uses list
for the current module [i.e. our sole and only (scm clip-region)]. This
allowed us to code as if all the public scheme declarations in
clip-region.scm had been declared in lily.scm - but they weren't.

I have hacked two .scm files input/regression/ and
scm/define-grob-properties.scm to include the calls.

The downside of this is the change to the regression test.  The upside
is that this module is being used as a module where it is needed.

Another possibility is that we forget using the module, and hurl all the
code from  clip-region.scm into a section of lily.scm. This feels messy
to me, and Han-Wen collected a consistent related set of procedures and
predicates in the guile module.

Another possibility is add a scm_c_use_module ("scm clip-region") call
to ly_make_module e.g.

  if (!safe)
      /* Look up (evaluate) Scheme make-module function and call it */

      SCM maker = ly_lily_module_constant("make-module");
      mod = scm_call_0 (maker);
      /* Look up and call Guile module-export-all! or Lilypond-defined
         compatible version when using Guile V1.8 */
      SCM module_export_all_x = ly_lily_module_constant
      scm_call_1 (module_export_all_x, mod);
      scm_c_use_module ("scm clip-region")
//    ************************************
      /* Evaluate Guile module "the-root-module",
         and ensure we inherit definitions from it and the "lily" module
         N.B. this used to be "the-scm-module" and is deprecated in
         Guile V1.9/2.0
      SCM scm_module = ly_lily_module_constant ("the-root-module");
      ly_use_module (mod, scm_module);
      ly_use_module (mod, global_lily_module);
      /* Evaluate and call make-safe-lilypond-module */
      SCM proc = ly_lily_module_constant ("make-safe-lilypond-module");
      mod = scm_call_0 (proc);
But this seems like untidy special-casing and we'd need a more extensive
and consistent mechanism in case we wanted to declare other modules
which were globally available to the lily code base, perhaps using an a
scheme list or alist.  Nice idea, but I think the subject of a separate
task and tracker if anyone thinks it's worth doing.

I'd like to go ahead with the hack I've got and I'll upload this for
review.  Please respond if you think this is a bad idea.



Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]