Problem with guile-2.9.1-prerelease

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Problem with guile-2.9.1-prerelease

Thomas Morley-2
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?

Thanks,
  Harm

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

David Kastrup
Thomas Morley <[hidden email]> 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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Thomas Morley-2
Am Do., 11. Okt. 2018 um 19:34 Uhr schrieb David Kastrup <[hidden email]>:

>
> Thomas Morley <[hidden email]> 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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

David Kastrup
Thomas Morley <[hidden email]> writes:

> Am Do., 11. Okt. 2018 um 19:34 Uhr schrieb David Kastrup <[hidden email]>:
>>
>> Thomas Morley <[hidden email]> 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 $@.  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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

David Kastrup
David Kastrup <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Thomas Morley-2
In reply to this post by David Kastrup
Am Do., 11. Okt. 2018 um 20:00 Uhr schrieb David Kastrup <[hidden email]>:

> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Karlin High
In reply to this post by David Kastrup
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Thomas Morley-2
Am Do., 11. Okt. 2018 um 20:17 Uhr schrieb Karlin High <[hidden email]>:

>
> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Urs Liska-3
In reply to this post by Karlin High


Am 11. Oktober 2018 20:17:45 MESZ schrieb Karlin High <[hidden email]>:
>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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Carl Sorensen-3


On 10/11/18, 12:35 PM, "lilypond-devel on behalf of Urs Liska" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> wrote:

   
   
    Am 11. Oktober 2018 20:17:45 MESZ schrieb Karlin High <[hidden email]>:
    >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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

David Kastrup
In reply to this post by Karlin High
Karlin High <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

David Kastrup
In reply to this post by Thomas Morley-2
Thomas Morley <[hidden email]> writes:

> Am Do., 11. Okt. 2018 um 20:17 Uhr schrieb Karlin High <[hidden email]>:
>>
>> 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

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

0001-Use-different-values-implementation-of-Guilev2.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

David Kastrup
In reply to this post by Carl Sorensen-3
Carl Sorensen <[hidden email]> writes:

> On 10/11/18, 12:35 PM, "lilypond-devel on behalf of Urs Liska"
> <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of
> [hidden email]> wrote:
>
>    
>    
>     Am 11. Oktober 2018 20:17:45 MESZ schrieb Karlin High <[hidden email]>:
>     >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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Thomas Morley-2
In reply to this post by David Kastrup
Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup <[hidden email]>:

>
> Thomas Morley <[hidden email]> writes:
>
> > Am Do., 11. Okt. 2018 um 20:17 Uhr schrieb Karlin High <[hidden email]>:
> >>
> >> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

David Kastrup
Thomas Morley <[hidden email]> writes:

> Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup <[hidden email]>:
>>
>> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Thomas Morley-2
Am Do., 11. Okt. 2018 um 21:54 Uhr schrieb David Kastrup <[hidden email]>:

>
> Thomas Morley <[hidden email]> writes:
>
> > Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup <[hidden email]>:
> >>
> >> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

David Kastrup
Thomas Morley <[hidden email]> writes:

> Am Do., 11. Okt. 2018 um 21:54 Uhr schrieb David Kastrup <[hidden email]>:
>>
>> Thomas Morley <[hidden email]> writes:
>>
>> > Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup <[hidden email]>:
>> >>
>> >> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Thomas Morley-2
In reply to this post by Thomas Morley-2
Am Do., 11. Okt. 2018 um 21:25 Uhr schrieb Thomas Morley
<[hidden email]>:

>
> Am Do., 11. Okt. 2018 um 20:57 Uhr schrieb David Kastrup <[hidden email]>:
> >
> > Thomas Morley <[hidden email]> writes:
> >
> > > Am Do., 11. Okt. 2018 um 20:17 Uhr schrieb Karlin High <[hidden email]>:
> > >>
> > >> 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<Music> (v))
                                {
                                        if (!unsmob<Input>
(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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

David Kastrup
Thomas Morley <[hidden email]> writes:

> Am Do., 11. Okt. 2018 um 21:25 Uhr schrieb Thomas Morley
> <[hidden email]>:
>
> '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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problem with guile-2.9.1-prerelease

Thomas Morley-2
In reply to this post by Thomas Morley-2
Am Fr., 12. Okt. 2018 um 01:45 Uhr schrieb Thomas Morley
<[hidden email]>:

> 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 <[hidden email]>
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 <lilypond-command> <file.ly>

From a file with close to no user-generated guile-code
(resulting in a 40-pages-pdf)

ad (1)
real    1m19,297s
user    1m16,390s
sys    0m1,883s

ad (2)
real    1m10,707s
user    1m9,220s
sys    0m1,336s


ad (3)
real    4m13,883s
user    5m7,904s
sys    0m1,474s


ad (4)
real    4m3,027s
user    5m10,502s
sys    0m1,697s

ad (5)
real    3m34,525s
user    4m34,974s
sys    0m1,613s


From a file with huge amount of user generated guile-code
(resulting in a 8-pages-pdf)

(1)
real    0m24,107s
user    0m23,002s
sys    0m1,101s

(2)
real    0m21,689s
user    0m20,740s
sys    0m0,923s

(3)
real    1m20,443s
user    1m33,126s
sys    0m0,918s

(4)
real    0m45,537s
user    0m52,817s
sys    0m0,991s

(5)
real    0m40,445s
user    0m46,441s
sys    0m0,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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

patches-for-guile-2-9-1.zip (24K) Download Attachment
12