Re: displayLilyMusic and guilev2

[David Kastrup]

Thomas Morley <address@hidden> writes:

> Am So., 9. Feb. 2020 um 00:23 Uhr schrieb David Kastrup <address@hidden>:
>>
>> Thomas Morley <address@hidden> writes:
>>
>> > Am Sa., 8. Feb. 2020 um 23:59 Uhr schrieb David Kastrup <address@hidden>:
>> >>
>> >> Thomas Morley <address@hidden> writes:
>> >>
>> >> > Hi,
>> >> >
>> >> > one problem with guilev2 are anonymous procedures. Like how to get
>> >> > nice output for
[...]
>> >> > \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 }
>> >> > which is nice again and the same as in 2.19.84 with guile-1.8
>> >> >
>> >> > Does anybody knows whether it's a guile- or lily-improvement?
>> >>
>> >> No idea.  It might be a different compilation option or environment or
>> >> eval setting that is at work here because I have ostensibly also a 2.2.6
>> >> and your commits on top of the tag don't look like they could make a
>> >> difference.
>> >
>> > To be sure, you still get:
>> > \new Voice { \applyContext ##f b4 }
>> > ?
>>
>> dak@lola:/usr/local/tmp/lilypond$ out/bin/lilypond scheme-sandbox
>> GNU LilyPond 2.21.0
[...]
>
> Because of other strange results I trashed my previous build and
> started from scratch.
> With the new build out of
> 7362fcde45 (HEAD -> master, origin/master, origin/HEAD) Issue 5733/4:
> int->vsize in Dot_column
> I've now got the same results from compiling a ly-file.
>
> But in scheme-sandbox:
> scheme@(#{ g161}#)>  (void (displayLilyMusic #{ \new Voice {
> \applyContext #(lambda (ctx) (display ctx)) b4 } #}))
> While compiling expression:
> unhandled constant #<procedure embedded-lilypond (a b c d)>
> scheme@(#{ g161}#)>
>
>
> No clue

Oh, that one is


commit 49b57b4406c9e1a2b420248d2b4a401b02f31436 (HEAD -> issue5744)
Author: David Kastrup <address@hidden>
Date:   Sat Feb 8 18:23:54 2020 +0100

    Issue 5744: parser-ly-from-scheme: Make #{ compilable
    
    For better or worse, Guile 2 has problems byte-compiling function
    values.  Factor out the previous internal function
    read-lily-expression-internal and refer to it by (module-relative)
    name rather than value in Guile 2.

just fresh in the issue tracker.

It's probably the (now more aggressive?) compilation that makes the
source go away.  Or it is retained when errors occur?  What do I know.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".