Re: Problem with guile-2.9.1-prerelease

[Thomas Morley]

Am Do., 11. Okt. 2018 um 19:34 Uhr schrieb David Kastrup <address@hidden>:
>
> Thomas Morley <address@hidden> writes:
>
> > Hi,
> >
> > according to this post:
> > https://lists.gnu.org/archive/html/guile-devel/2018-10/msg00000.html
> > guile prepares to release 3.0 soon.
> >
> > I tried to test LilyPond with the guile-2.9.1-prelease.
> > Checking out our dev/guile-v2-work-branch, rebasing, applying several
> > patches (working with guile-2.2.4) as well as editing configure.ac and
> > aclocal.m4 to accept this guile-version I've got a successful 'make'
> >
> > Though, 'make doc' fails soon with 'input/regression/rest-positioning.ly'
> > I boiled it down to this minimal:
> >
> > \version "2.21.0"
> > $@(make-list 2 #{ r1 #})
> >
> > I get:
> >
> > $ lilypond-git-guile-3.0 atest-80.ly
> > GNU LilyPond 2.21.0
> > Processing `atest-80.ly'
> > Parsing...Backtrace:
> >            6 (apply-smob/1 #<catch-closure 560bc9932720>)
> > In ice-9/eval.scm:
> >    293:34  5 (_ #(#(#<directory (lily) 560bc9a165a0>) #<variable 5…>))
> >     619:8  4 (_ #(#(#(#(#(#(#(#<directory (lily) …>) …) …) …) …) …) …))
> > In srfi/srfi-1.scm:
> >     640:9  3 (for-each #<procedure 560bcae4a5e0 at ice-9/eval.scm:3…> …)
> > In ice-9/eval.scm:
> >     619:8  2 (_ #(#(#(#(#(#<directory (lily) 560bc9a1…> …) …) …) …) …))
> > In ice-9/boot-9.scm:
> >     826:9  1 (catch _ _ #<procedure 560bcb002540 at ice-9/eval.scm:…> …)
> > In unknown file:
> >            0 (ly:parse-file "atest-80.ly")
> >
> > ERROR: In procedure ly:parse-file:
> > In procedure struct-ref: Wrong type argument in position 1 (expecting
> > struct): #<Prob: Music C++: Music((duration . #<Duration 1 >) (origin
> > . #<location atest-80.ly:629:2>))((display-methods #<procedure method
> > (a)>) (name . RestEvent) (iterator-ctor . #<procedure
> > ly:rhythmic-music-iterator::constructor ()>) (types event
> > rhythmic-event rest-event)) >
> >
> > I'm not able to get meaningful info out of this.
> > Any insight?
>
> Try with -dverbose ?  Sometimes that improves the backtrace.  Sounds
> like some incompatible change of internals behavior but I have problems
> guessing just what may be involved here.
>
> --
> David Kastrup

-dverbose gives not more info

Using gdb:

(gdb) run atest-80.ly
Starting program:
/home/hermann/lilypond-git-guile-3.0/build/out/bin/lilypond
atest-80.ly
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
GNU LilyPond 2.21.0
[New Thread 0x7ffff369a700 (LWP 5765)]
[New Thread 0x7ffff2e99700 (LWP 5766)]
[New Thread 0x7ffff2698700 (LWP 5767)]
[New Thread 0x7ffff1ae8700 (LWP 5768)]
Processing `atest-80.ly'
Parsing...Backtrace:
           6 (apply-smob/1 #<catch-closure 555555de1720>)
In ice-9/eval.scm:
   293:34  5 (_ #(#(#<directory (lily) 555555ec55a0>) #<variable
5555572fa1c0 value: ("atest-80.ly")>))
    619:8  4 (_ #(#(#(#(#(#(#(#<directory (lily) 555555ec55a0>)
("atest-80.ly")) #<variable 5555572fa050 value: ()>) #f) #f) #f)
#<procedure han…>))
In srfi/srfi-1.scm:
    640:9  3 (for-each #<procedure 55555612f720 at
ice-9/eval.scm:333:13 (a)> ("atest-80.ly"))
In ice-9/eval.scm:
    619:8  2 (_ #(#(#(#(#(#<directory (lily) 555555ec55a0> #f
#<procedure handler (a b)> #f #f) "atest-80.ly") #f) "./atest-80") ((#
. #f) # # …)))
In ice-9/boot-9.scm:
    826:9  1 (catch ly-file-failed #<procedure 555557401580 at
ice-9/eval.scm:330:13 ()> #<procedure 555557401540 at
ice-9/eval.scm:386:13 (a . r…> …)
In unknown file:
           0 (ly:parse-file "atest-80.ly")

ERROR: In procedure ly:parse-file:
In procedure struct-ref: Wrong type argument in position 1 (expecting
struct): #<Prob: Music C++: Music((duration . #<Duration 1 >) (origin
. #<location atest-80.ly:629:2>))((display-methods #<procedure method
(a)>) (name . RestEvent) (iterator-ctor . #<procedure
ly:rhythmic-music-iterator::constructor ()>) (types event
rhythmic-event rest-event)) >

[Thread 0x7ffff1ae8700 (LWP 5768) exited]
[Thread 0x7ffff2e99700 (LWP 5766) exited]
[Thread 0x7ffff369a700 (LWP 5765) exited]
[Thread 0x7ffff7fc3740 (LWP 5761) exited]
[Inferior 1 (process 5761) exited with code 01]
(gdb) bt
No stack.
(gdb)


Iiuc, it's the same again...

Cheers,
  Harm