[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 |
Hi,
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.
Thus
http://lilypond.org/doc/v2.21/Documentation/contributor/updating-the-lsr-to-a-new-version
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)
(1)
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 `test.ly'...
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?
(2)
chord-names-alternative.ly
http://lsr.di.unimi.it/LSR/Item?id=102
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
(3)
custom-tuning-and-midi-rendering.ly
http://lsr.di.unimi.it/LSR/Item?id=785
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?
(4)
I suggest to simply delete
positioning-tuplet-numbers-close-to-kneed-beams.ly
http://lsr.di.unimi.it/LSR/Item?id=646
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.
Opinions?
(5)
multi-measure-rest-length-control.ly
http://lsr.di.unimi.it/LSR/Item?id=1103
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?
(6)
Two snippets need minor fixes.
Cheers,
Harm
- LSR current problems,
Thomas Morley <=