Re: Problem with guile-2.9.1-prerelease

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 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.
>
> -dverbose gives not more info

Sorry, I overlooked that you already boiled this down to a minimal
example using address@hidden  I am sort-of sure that this will be due to the
internals of (values ...) having changed in some manner.  The "wrong
type argument" will be for trying to access elements here.

I think Guile-2.0 introduced some mechanism for doing so but retained
compatibility, and this compatibility has now gone out of the window.
So with some luck and some #ifdef GUILEV2 guard, we should be able to
add code that will run under all versions.  I'll take a look.

-- 
David Kastrup