Re: Problem with guile-2.9.1-prerelease
Thomas Morley writes:
> Hi,
>
> according to this post:
> https://lists.gnu.org/archive/html/guile-devel/2018-10/msg0.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 #)
> In ice-9/eval.scm:
>293:34 5 (_ #(#(#) #))
> 619:8 4 (_ #(#(#(#(#(#(#(#) …) …) …) …) …) …))
> In srfi/srfi-1.scm:
> 640:9 3 (for-each # …)
> In ice-9/eval.scm:
> 619:8 2 (_ #(#(#(#(#(# …) …) …) …) …))
> In ice-9/boot-9.scm:
> 826:9 1 (catch _ _ # …)
> 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): #) (origin
> . #))((display-methods # (a)>) (name . RestEvent) (iterator-ctor . # 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
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Problem with guile-2.9.1-prerelease
Hi,
according to this post:
https://lists.gnu.org/archive/html/guile-devel/2018-10/msg0.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 #)
In ice-9/eval.scm:
293:34 5 (_ #(#(#) #))
619:8 4 (_ #(#(#(#(#(#(#(#) …) …) …) …) …) …))
In srfi/srfi-1.scm:
640:9 3 (for-each # …)
In ice-9/eval.scm:
619:8 2 (_ #(#(#(#(#(# …) …) …) …) …))
In ice-9/boot-9.scm:
826:9 1 (catch _ _ # …)
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): #) (origin
. #))((display-methods #) (name . RestEvent) (iterator-ctor . #) (types event
rhythmic-event rest-event)) >
I'm not able to get meaningful info out of this.
Any insight?
Thanks,
Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Request PATCH to ensure LilyPond SVG compatibility with Scribus
I have joined this list today just for the purpose of facilitating a link between Scribus and LilyPond forums and posting one PATCH suggestion before next imminent release of lilypond. Over at the Scribus forum a small issue prevents svg output from lilypond commandline being rendered in Scribus the desktop publishing tool. PNG output works. The Scribus issue refers to SVG fill attribute "currentColor" being used instead of "black". Perhaps at this 11th hour before next release this might be looked at? LilyPond printing through Scribus would make a nice team. References: https://bugs.scribus.net/view.php?id=15454 http://lilypond.1069038.n5.nabble.com/rsvg-view-can-t-display-SVG-files-created-by-lilypond-tc191462.html#a191496 Here is a quote from a Scribus forum snr. member: "the lillypond authors seem to know about the issue but (probably) wrongly decided to do nothing... can somebody who uses lillypond try to post a bug report for this issue with jean's explanation from the bug tracker and telling them that this shortcut makes hard to import the svg in scribus? (i mean, they could keep track of the color used and always set it explicitly, instead of relying on a default value that seems not to be 100% standardized)." -- Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Am Do., 11. Okt. 2018 um 19:34 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Hi,
> >
> > according to this post:
> > https://lists.gnu.org/archive/html/guile-devel/2018-10/msg0.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 #)
> > In ice-9/eval.scm:
> >293:34 5 (_ #(#(#) #))
> > 619:8 4 (_ #(#(#(#(#(#(#(#) …) …) …) …) …) …))
> > In srfi/srfi-1.scm:
> > 640:9 3 (for-each # …)
> > In ice-9/eval.scm:
> > 619:8 2 (_ #(#(#(#(#(# …) …) …) …) …))
> > In ice-9/boot-9.scm:
> > 826:9 1 (catch _ _ # …)
> > 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): #) (origin
> > . #))((display-methods # > (a)>) (name . RestEvent) (iterator-ctor . # > 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 0x7369a700 (LWP 5765)]
[New Thread 0x72e99700 (LWP 5766)]
[New Thread 0x72698700 (LWP 5767)]
[New Thread 0x71ae8700 (LWP 5768)]
Processing `atest-80.ly'
Parsing...Backtrace:
6 (apply-smob/1 #)
In ice-9/eval.scm:
293:34 5 (_ #(#(#) #))
619:8 4 (_ #(#(#(#(#(#(#(#)
("atest-80.ly")) #) #f) #f) #f)
#))
In srfi/srfi-1.scm:
640:9 3 (for-each # ("atest-80.ly"))
In ice-9/eval.scm:
619:8 2 (_ #(#(#(#(#(# #f
# #f #f) "atest-80.ly") #f) "./atest-80") ((#
. #f) # # …)))
In ice-9/boot-9.scm:
826:9 1 (catch ly-file-failed # # …)
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): #) (origin
. #))((display-methods #) (name . RestEvent) (iterator-ctor . #) (types event
rhythmic-event rest-event)) >
[Thread 0x71ae8700 (LWP 5768) exited]
[Thread 0x72e99700 (LWP 5766) exited]
[Thread 0x7369a700 (LWP 5765) exited]
[Thread 0x77fc3740 (LWP 5761) exited]
[Inferior 1 (process 5761) exited with code 01]
(gdb) bt
No stack.
(gdb)
Iiuc, it's the same again...
Cheers,
Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Thomas Morley writes:
> Am Do., 11. Okt. 2018 um 19:34 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>>
>> > Hi,
>> >
>> > according to this post:
>> > https://lists.gnu.org/archive/html/guile-devel/2018-10/msg0.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 #)
>> > In ice-9/eval.scm:
>> >293:34 5 (_ #(#(#) #))
>> > 619:8 4 (_ #(#(#(#(#(#(#(#) …) …) …) …) …) …))
>> > In srfi/srfi-1.scm:
>> > 640:9 3 (for-each # …)
>> > In ice-9/eval.scm:
>> > 619:8 2 (_ #(#(#(#(#(# …) …) …) …) …))
>> > In ice-9/boot-9.scm:
>> > 826:9 1 (catch _ _ # …)
>> > 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): #) (origin
>> > . #))((display-methods #> > (a)>) (name . RestEvent) (iterator-ctor . #> > 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 $@. 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
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Karlin High writes: > On 10/11/2018 12:59 PM, David Kastrup wrote: >> we should be able to add code that will run under all versions. > > The guile-devel post linked in the OP indicates that Guile 3 should > have greatly improved performance over Guile 2. Maybe even better than > LilyPond's current Guile 1.8. > > What level of optimism is appropriate for that claim? Pretty much none I should think. The performance improvements are for algorithms implemented in Scheme. We don't really have them to significant degree: we do the time-consuming algorithmic stuff in C++. What gave us the large performance hit for Guile 2 was the interfacing between C++ and Scheme which we do really a lot. That has become quite slower with Guilev2, and part of the reason are strings which are now utf8-aware while Guilev2 natively does not store strings as utf8 but has to convert them into other presentations. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Thomas Morley writes: > Am Do., 11. Okt. 2018 um 21:54 Uhr schrieb David Kastrup : >> >> Thomas Morley writes: >> >> > Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup : >> >> >> >> Could you reinstate the regtest and try this untested patch? Not >> >> necessarily in that order since, well, the patch might well not even >> >> compile. Or work correctly. >> > >> > Will do, though I'll first wait for current 'make doc' to finish, >> > (which may end successful or with another error, ofcourse). This may >> > take some long time, because I do a one-processor run on my slow >> > laptop. >> >> What kind of processor? > > Probably bad wording, I wanted to say I did 'make doc' and not 'make > -j5 CPU_COUNT=5 doc'. > But to answer the question: > ~$ cat /proc/cpuinfo > [...] > model name: Intel(R) Pentium(R) CPU N3510 @ 1.99GHz > [...] Well, then I don't have anything better to offer you I guess. Heck, the system I am working on is the fastest I have (takes about 30 minutes for a 9-process make doc) and its processor is a thermal mismatch to the laptop, dissipating 6 times as much power as your CPU because it has the same number of cores: model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz The 2-core version it replaced takes only a bit more than 4 times the power of your processor. And, well, that's the system I got this year. Because the older system with a P9300 (already an upgrade) was becoming a bit long in the tooth. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
On 10/11/2018 12:59 PM, David Kastrup wrote: we should be able to add code that will run under all versions. The guile-devel post linked in the OP indicates that Guile 3 should have greatly improved performance over Guile 2. Maybe even better than LilyPond's current Guile 1.8. What level of optimism is appropriate for that claim? -- Karlin High Missouri, USA ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Thomas Morley writes:
> Am Do., 11. Okt. 2018 um 20:17 Uhr schrieb Karlin High :
>>
>> On 10/11/2018 12:59 PM, David Kastrup wrote:
>> > we should be able to add code that will run under all versions.
>>
>> The guile-devel post linked in the OP indicates that Guile 3 should have
>> greatly improved performance over Guile 2. Maybe even better than
>> LilyPond's current Guile 1.8.
>>
>> What level of optimism is appropriate for that claim?
>> --
>> Karlin High
>> Missouri, USA
>
> Well, I'll test that as soon as I have more success with 'make doc'.
> For now I've deleted said regtest and test how far it will go...
Could you reinstate the regtest and try this untested patch? Not
necessarily in that order since, well, the patch might well not even
compile. Or work correctly.
>From 6d974c4990f2bb4c34605908ba3b7ca1c21487cf Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Thu, 11 Oct 2018 20:52:19 +0200
Subject: [PATCH] Use different `values' implementation of Guilev2
---
lily/lexer.ll | 12
1 file changed, 12 insertions(+)
diff --git a/lily/lexer.ll b/lily/lexer.ll
index 421fea2734..f893715e8e 100644
--- a/lily/lexer.ll
+++ b/lily/lexer.ll
@@ -1107,6 +1107,13 @@ Lily_lexer::eval_scm (SCM readerdata, Input hi, char extra_token)
if (extra_token && SCM_VALUESP (sval))
{
+#if GUILEV2
+ size_t nvals = scm_c_nvalues (sval);
+
+ if (nvals > 0) {
+ while (--nvals) {
+SCM v = scm_c_value_ref (sval, nvals);
+#else
sval = scm_struct_ref (sval, SCM_INUM0);
if (scm_is_pair (sval)) {
@@ -1115,6 +1122,7 @@ Lily_lexer::eval_scm (SCM readerdata, Input hi, char extra_token)
p = scm_cdr (p))
{
SCM v = scm_car (p);
+#endif
if (Music *m = unsmob (v))
{
if (!unsmob (m->get_property ("origin")))
@@ -1135,7 +1143,11 @@ Lily_lexer::eval_scm (SCM readerdata, Input hi, char extra_token)
break;
}
}
+#if GUILEV2
+ sval = scm_c_value_ref (sval, 0);
+#else
sval = scm_car (sval);
+#endif
} else
sval = SCM_UNSPECIFIED;
}
--
2.17.1
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Am Do., 11. Okt. 2018 um 20:00 Uhr schrieb David Kastrup : > Sorry, I overlooked that you already boiled this down to a minimal > example using $@. 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. The use of $@ comes from the failed regtest which does work with guile-2.2.4 But stopped with guile-2.9.1 Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Am 11. Oktober 2018 20:17:45 MESZ schrieb Karlin High : >On 10/11/2018 12:59 PM, David Kastrup wrote: >> we should be able to add code that will run under all versions. > >The guile-devel post linked in the OP indicates that Guile 3 should >have >greatly improved performance over Guile 2. Maybe even better than >LilyPond's current Guile 1.8. > >What level of optimism is appropriate for that claim? I don't think that tells us very much. From 1.8 to 2 they added "significant improvements" that caused massive performance problems for our specific use case. And I woulcn't bet too much money that the improvements you mention specifically address these issues ... Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Carl Sorensen writes: > On 10/11/18, 12:35 PM, "lilypond-devel on behalf of Urs Liska" > li...@openlilylib.org> wrote: > > > > Am 11. Oktober 2018 20:17:45 MESZ schrieb Karlin High > : > >On 10/11/2018 12:59 PM, David Kastrup wrote: > >What level of optimism is appropriate for that claim? > > I don't think that tells us very much. From 1.8 to 2 they added > "significant improvements" that caused massive performance problems > for our specific use case. And I woulcn't bet too much money that the > improvements you mention specifically address these issues ... > > > On the other hand, the 3.0 test that they report on indicates that the > new JIT compile code is almost as fast as 1.8. That makes little to no sense since 1.8 was slower than Guile 2 for most compiled code. The only thing I can imagine is that they mean the new JIT compile code is almost as fast as programming in C while manipulating SCM data with the 1.8 API calls. > And the way around the performance issues with 2 was to use > precompiled bytecode because the compiler was slow. This new JIT > compile claims to not need bytecode, so I am optimistic Our problems is not code written in Scheme but passing stuff between C++ and Scheme. Let's hope your optimism turns out more vindicated than my pessimism. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > Am Do., 11. Okt. 2018 um 20:17 Uhr schrieb Karlin High > > : > >> > >> On 10/11/2018 12:59 PM, David Kastrup wrote: > >> > we should be able to add code that will run under all versions. > >> > >> The guile-devel post linked in the OP indicates that Guile 3 should have > >> greatly improved performance over Guile 2. Maybe even better than > >> LilyPond's current Guile 1.8. > >> > >> What level of optimism is appropriate for that claim? > >> -- > >> Karlin High > >> Missouri, USA > > > > Well, I'll test that as soon as I have more success with 'make doc'. > > For now I've deleted said regtest and test how far it will go... > > Could you reinstate the regtest and try this untested patch? Not > necessarily in that order since, well, the patch might well not even > compile. Or work correctly. > > > > -- > David Kastrup Will do, though I'll first wait for current 'make doc' to finish, (which may end successful or with another error, ofcourse). This may take some long time, because I do a one-processor run on my slow laptop. Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
On 10/11/18, 12:35 PM, "lilypond-devel on behalf of Urs Liska" wrote: Am 11. Oktober 2018 20:17:45 MESZ schrieb Karlin High : >On 10/11/2018 12:59 PM, David Kastrup wrote: >What level of optimism is appropriate for that claim? I don't think that tells us very much. From 1.8 to 2 they added "significant improvements" that caused massive performance problems for our specific use case. And I woulcn't bet too much money that the improvements you mention specifically address these issues ... On the other hand, the 3.0 test that they report on indicates that the new JIT compile code is almost as fast as 1.8. And the way around the performance issues with 2 was to use precompiled bytecode because the compiler was slow. This new JIT compile claims to not need bytecode, so I am optimistic Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Am Do., 11. Okt. 2018 um 21:54 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup : > >> > >> Could you reinstate the regtest and try this untested patch? Not > >> necessarily in that order since, well, the patch might well not even > >> compile. Or work correctly. > > > > Will do, though I'll first wait for current 'make doc' to finish, > > (which may end successful or with another error, ofcourse). This may > > take some long time, because I do a one-processor run on my slow > > laptop. > > What kind of processor? Probably bad wording, I wanted to say I did 'make doc' and not 'make -j5 CPU_COUNT=5 doc'. But to answer the question: ~$ cat /proc/cpuinfo [...] model name: Intel(R) Pentium(R) CPU N3510 @ 1.99GHz [...] Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Am Do., 11. Okt. 2018 um 20:17 Uhr schrieb Karlin High : > > On 10/11/2018 12:59 PM, David Kastrup wrote: > > we should be able to add code that will run under all versions. > > The guile-devel post linked in the OP indicates that Guile 3 should have > greatly improved performance over Guile 2. Maybe even better than > LilyPond's current Guile 1.8. > > What level of optimism is appropriate for that claim? > -- > Karlin High > Missouri, USA Well, I'll test that as soon as I have more success with 'make doc'. For now I've deleted said regtest and test how far it will go... Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
David Kastrup writes:
> 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.
lexer.ll:
if (extra_token && SCM_VALUESP (sval))
{
sval = scm_struct_ref (sval, SCM_INUM0);
I should very much be not surprised if that is the location throwing the
error. I'll take a look at what Guilev2 offers to use here instead.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Thomas Morley writes: > Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup : >> >> Could you reinstate the regtest and try this untested patch? Not >> necessarily in that order since, well, the patch might well not even >> compile. Or work correctly. > > Will do, though I'll first wait for current 'make doc' to finish, > (which may end successful or with another error, ofcourse). This may > take some long time, because I do a one-processor run on my slow > laptop. What kind of processor? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with guile-2.9.1-prerelease
Am Do., 11. Okt. 2018 um 21:25 Uhr schrieb Thomas Morley
:
>
> Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup :
> >
> > Thomas Morley writes:
> >
> > > Am Do., 11. Okt. 2018 um 20:17 Uhr schrieb Karlin High
> > > :
> > >>
> > >> On 10/11/2018 12:59 PM, David Kastrup wrote:
> > >> > we should be able to add code that will run under all versions.
> > >>
> > >> The guile-devel post linked in the OP indicates that Guile 3 should have
> > >> greatly improved performance over Guile 2. Maybe even better than
> > >> LilyPond's current Guile 1.8.
> > >>
> > >> What level of optimism is appropriate for that claim?
> > >> --
> > >> Karlin High
> > >> Missouri, USA
> > >
> > > Well, I'll test that as soon as I have more success with 'make doc'.
> > > For now I've deleted said regtest and test how far it will go...
> >
> > Could you reinstate the regtest and try this untested patch? Not
> > necessarily in that order since, well, the patch might well not even
> > compile. Or work correctly.
> >
> >
> >
> > --
> > David Kastrup
>
> Will do, though I'll first wait for current 'make doc' to finish,
> (which may end successful or with another error, ofcourse). This may
> take some long time, because I do a one-processor run on my slow
> laptop.
>
> Thanks,
> Harm
'make doc' (without rest-positioning.ly) now ended successfully (with
guile-2.9.1)
I then tried to apply your patch to my lilypond-git-guile-3.0 but I've got:
$ git apply 0001-Use-different-values-implementation-of-Guilev2.patch
error: patch failed: lily/lexer.ll:1107
error: lily/lexer.ll: patch does not apply
But implementing the changes from your patch manually worked [1], i.e.
'make' and compiling the minimal from above as well as the regtest
rest-positioning.ly.
Tomorrow I'll redo a full 'make doc'.
Testing your changes with guile-2.2.4 and guile-1.8 is postponed for
tomorrow as well.
Thanks,
Harm
[1]
Though I see no real difference:
$ git diff
diff --git a/lily/lexer.ll b/lily/lexer.ll
index 421fea2734..f893715e8e 100644
--- a/lily/lexer.ll
+++ b/lily/lexer.ll
@@ -1107,6 +1107,13 @@ Lily_lexer::eval_scm (SCM readerdata, Input hi,
char extra_token)
if (extra_token && SCM_VALUESP (sval))
{
+#if GUILEV2
+ size_t nvals = scm_c_nvalues (sval);
+
+ if (nvals > 0) {
+ while (--nvals) {
+ SCM v = scm_c_value_ref (sval, nvals);
+#else
sval = scm_struct_ref (sval, SCM_INUM0);
if (scm_is_pair (sval)) {
@@ -1115,6 +1122,7 @@ Lily_lexer::eval_scm (SCM readerdata, Input hi,
char extra_token)
p = scm_cdr (p))
{
SCM v = scm_car (p);
+#endif
if (Music *m = unsmob (v))
{
if (!unsmob
(m->get_property ("origin")))
@@ -1135,7 +1143,11 @@ Lily_lexer::eval_scm (SCM readerdata, Input hi,
char extra_token)
break;
}
}
+#if GUILEV2
+ sval = scm_c_value_ref (sval, 0);
+#else
sval = scm_car (sval);
+#endif
} else
sval = SCM_UNSPECIFIED;
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
