Re: Problem with guile-2.9.1-prerelease
Am So., 14. Okt. 2018 um 11:22 Uhr schrieb Thomas Morley : > > Am Fr., 12. Okt. 2018 um 01:45 Uhr schrieb Thomas Morley > : > > > Tomorrow I'll redo a full 'make doc'. David, I forgot to mention: A new run of a full 'make doc' with your patch "Use different `values' implementation of Guilev2" and my guile-2.9.1 lily-version was successful. 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 Fr., 12. Okt. 2018 um 01:45 Uhr schrieb Thomas Morley : > 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. To facilitate testing I had to change my local setup to compare multiple combinations of guile-versions with lilypond. Sorry for the delay, compiling guile-versions is very time-consuming... So, here my setup, in the end I tested with 5 lilypond-versions: (1) LilyPond 2.19.82 from the installer, i.e. with guile-1.8 Below 4 selfcompiled versions out of commit ea638182bcc87414c7f186d40f376bbbf560f5d1 Author: David Kastrup Date: Wed Oct 3 14:20:45 2018 +0200 Issue 5423: First separator for subassignments must be '.' This pares down syntax supported since issue 4790 to match the allowed usage from issue 4797. Permitting ',' here seemed particularly strange. (2) LilyPond 2.21.0 with guile-1.8.8 (3) LilyPond 2.21.0 with guile-2.0.14 (4) LilyPond 2.21.0 with guile-2.2.4 (5) LilyPond 2.21.0 with guile-2.9.1 (3) to (5) have the attached patches applied to make them work with guilev2 on top of (2) - (5) David's patch from this thread: Use different `values' implementation of Guilev2 is applied. It is in the attached archive as well. Results: David, your patch always works and does as desired. How about putting it up for review? Karlin et all, here some performance-values (always taken from a second of two runs) with $ time >From a file with close to no user-generated guile-code (resulting in a 40-pages-pdf) ad (1) real1m19,297s user1m16,390s sys0m1,883s ad (2) real1m10,707s user1m9,220s sys0m1,336s ad (3) real4m13,883s user5m7,904s sys0m1,474s ad (4) real4m3,027s user5m10,502s sys0m1,697s ad (5) real3m34,525s user4m34,974s sys0m1,613s >From a file with huge amount of user generated guile-code (resulting in a 8-pages-pdf) (1) real0m24,107s user0m23,002s sys0m1,101s (2) real0m21,689s user0m20,740s sys0m0,923s (3) real1m20,443s user1m33,126s sys0m0,918s (4) real0m45,537s user0m52,817s sys0m0,991s (5) real0m40,445s user0m46,441s sys0m0,955s So there _is_ some improvement, but all in all not overwhelming, imho. Additionally, I've probably found a new small issue with guilev2, but this is worth another thread. As said above the used guilev2-patches are attached, if someone wants to join testing. Be aware some of them (especially my own ones) are more workarounds than proper fixes. Hints are always welcome. 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 21:25 Uhr schrieb Thomas Morley > : > > '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 A complete commit is applied using git am not git apply. -- 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
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
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
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 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
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
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
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
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 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
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
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
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
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 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
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:
> 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
