Re: [frogs] T1224: Avoid using deprecated %module-public-interface in guile initialisation. (issue1160044)

[Ian Hulin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

This was the artist formerly known as tracker 1055.

Status so far.
The patch runs OK against guile V1.8,7.  I've now been able to run
against Guile 1.9.11 on a V M despite having to rebuild my machine
because the CPU ran hot and toasted itself.

Anyhow, building against V1.9.11 showed up Neil's concerns with the code
in lily.scm/simple-format-handler and /ergonomic-simple-format and I
have a fix for this.  It looks like the byte-compiler in Guile V1.9.11
is stricter than the interpreter in V1.8.7.

Anyhow, running up Lily with Guile V1.9.11 now barfs as follows in
when attempting to compile scm/display-lily.scm
the trace-back shows it doesn't like this code starting at
(define ((make-music (see below for error messages)

;;;
;;; music type predicate maker
;;;

(define (make-music-type-predicate . music-types)
  (define ((make-music-type-predicate-aux mtypes) expr)
    (if (null? mtypes)
        #f
        (or (eqv? (car mtypes) (ly:music-property expr 'name))
            ((make-music-type-predicate-aux (cdr mtypes)) expr))))
  (make-music-type-predicate-aux music-types))

I'm a bit puzzled by this code.  Even if we move the nested definition
out from within make-music-predicate, how does it work?  Variable
make-music-type-predicate is not declared anywhere else, and yet here we
appear to ask guile to resolve and call it before it is declared and
bound to anything?

Trying this in guile V1.8.7 repl with a dummy for ly:music-property and
it will work as written, but in V1.9.11 it always fails with
ERROR: in procedure macro-expand:
ERROR: source expression failed to match any pattern in (define
((make-music-type-predicate-aux mtypes) expr)  (if (null? mtypes) #f (or
(eqv? (car mtypes) (ly:music-property expr 'name))
((make-music-type-predicate-aux (cdr mtypes)) expr))))

V1.9.11 throws the error whether or not the repl is called with
- --no-auto-compile.  It also doesn't help to try and un-nest the inner
(define and declare it at top-level.

If anyone can throw any light on why this procedure is written this way
and any work-rounds or fixes this would be good. Nicolas, your name
seems to be on the source module, can you shed any light?

Patrick and Neil, do I have to fix all the compatibility problems in all
the scm files loaded by lily.scm in order to push what we have so far?

I now seem to be finding compatibility problems not directly related to
replacing %module-public-interface, and I'd rather tackle these as
smaller, more discrete items of work.

Cheers,

Ian Hulin






-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMeWBsAAoJEBqidDirZqASHmgIAL+9hEYrtv3T/HMqgM+V1iem
xZYFJYTXTEPMDtOqwgtI9J4A2mYZtn0az0T98Zqp5JZWR05JhxgAZ9iI7HWW91K/
4fuaREV8MnnKMcfy/inwOc/oZBnC8GVYkhQFRwuW48qBLvSgIt95Ds8ApyQdrJGK
M1p0Ygw34gHGNr/I4l8jU7rrKKP7VxCkkwX1knbm8Zo1ALFMbxW4dNuKOUZhAKmo
ofXU1bXSnsHx6iv45Y1vlFW49TjVP27BElGrufYcH8Oaj4qU9QqP1wRtw5O2OTQw
zrYw8aYOMUOUptg/b5Mlhf/4Ty9lWLYjCP4OcUrdBeqve3Ue/B6J4neEzM98A2g=
=7S/4
-----END PGP SIGNATURE-----