[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

LSR current problems

From: Thomas Morley
Subject: LSR current problems
Date: Mon, 4 Jan 2021 18:11:29 +0100


with upcoming 2.22.0 in mind I had a closer look at the LSR and the
work needed to upgrade it.

Currently there is something buggy there: The downloadable tarball is
not complete.
does not work.
Thanks a lot to Werner and his perl-script making it possible to get
all snippets and pointing me in the correct direction.

I stumbled across some problems while upgrading all snippets to 2.20.0
(probably better to skip 2.20.0 and go directly to 2.22.0)

Some snippets use nested define-music/scheme-functions and convert-ly
fails to do a proper job.

A silly example:
\version "2.18.2"

foo =
#(define-music-function (parser location m1)(ly:music?)
 (let ((blub
         (define-music-function (parser location m2) (ly:music?)
           #{ \tweak color #red $m2 #})))
    #{ $m1 $blub $m1 #}))

\foo c'4

converty-ly returns:

convert-ly (GNU LilyPond) 2.20.0

convert-ly: Processing `'...
Applying conversion: 2.19.2, 2.19.7, 2.19.11, 2.19.16, 2.19.22,
2.19.24, 2.19.28, 2.19.29, 2.19.32, 2.19.40, 2.19.46, 2.19.49,
2.19.80, 2.20.0

\version "2.20.0"

foo =
#(define-music-function (m1)(ly:music?)
 (let ((blub
         (define-music-function ((*parser*) (*location*) m2) (ly:music?)
           #{ \tweak color #red $m2 #})))
    #{ $m1 $blub $m1 #}))

\foo c'4

Can this be fixed?

is a doc tagged snippet, it demonstrates among other styles banter-chords.

Shouldn't we delete it?
In 2.20.0 it errors anyway with
fatal error: symbol chordNameExceptionsFull redefined


It fails in 2.20.0 because of:
#(ly:load "define-note-names.scm")
Unbound variable: define-session-public

Well, inserting
#(define define-session-public define)
#(ly:load "define-note-names.scm")
makes it compile.

But hmmmmmmmm...

Other suggestions?

I suggest to simply delete
It was meant to cure a bad positioning, but 2.20.0 does a good job per default.
Thus no need for it anymore, imho.


uses code _not_ implemented in 2.18.2, it shouldn't have been approved at all.
I lean towards unapproving it.

Alas, it's doc-tagged (and works with 2.20.0), will unapproving be a problem?

Two snippets need minor fixes.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]