Re: snippet fails with 2.23.
Am Di., 17. Mai 2022 um 20:39 Uhr schrieb Jean Abou Samra : > > Le 16/05/2022 à 23:07, Thomas Morley a écrit :Well, I _am_ a LSR-editor. > > Though, sometimes it feels I am the only one (not really true, Werner > > does a lot but his focus is more on lsr-software and > > snippets-descriptions). > > We really need more active LSR-editors. > > > > This sounds like an advocacy problem, really. To give an outsider's > point of view, until this message I had no idea who was behind > the LSR approval process apart from you, and I wasn't aware that > you wished help. I still only have a vague idea of what kind of > work this entails. And I am following this list and the user list > closely for two years or so. If more volunteers are needed, I recommend > (1) documenting what work they should do and how, and (2) asking > for volunteers on the user list. > > (Please note that I am not proposing myself, I'm already busy > enough contributing to LilyPond.) > > Jean > Well, in the last about two (or three?) years, bugs in the lsr-software accumulated and Sebastiano was not really reponsive. Thus, there was not much what anyone could have done... Otoh, I once started lsr-update to 2.20. and did what I could to support both versions (2.18./2.20.). I was not able to finish it because of said bugs, though it was a very good base to start the 2.22. update. At least so far as lsr-snippets are concerned. Iirc, I did already the lsr-2.14-update. That lasted much longer ... Anyway, this is _not_ the duty of an lsr-editor, but the lsr-updater. But ofcourse an experienced lsr-editor has a better impression what needs to be done on questionable snippets, thus the lsr-editor may become the lsr-updater... That said, the main duties of an lsr-editor are described in CG 7.3 Approving snippets In the past we never had many lsr-editors, I could drop some names, but they are mostly retired or hardly active nowadays. Thus, yes we should ask on -user for volunteers, every experienced user would be welcome. Best, Harm
Re: snippet fails with 2.23.
Le 16/05/2022 à 23:07, Thomas Morley a écrit :Well, I _am_ a LSR-editor. Though, sometimes it feels I am the only one (not really true, Werner does a lot but his focus is more on lsr-software and snippets-descriptions). We really need more active LSR-editors. This sounds like an advocacy problem, really. To give an outsider's point of view, until this message I had no idea who was behind the LSR approval process apart from you, and I wasn't aware that you wished help. I still only have a vague idea of what kind of work this entails. And I am following this list and the user list closely for two years or so. If more volunteers are needed, I recommend (1) documenting what work they should do and how, and (2) asking for volunteers on the user list. (Please note that I am not proposing myself, I'm already busy enough contributing to LilyPond.) Jean
Re: snippet fails with 2.23.
Am Mo., 16. Mai 2022 um 09:52 Uhr schrieb Mats Bengtsson : > >Thanks for your work with this. I happened to stumble upon >[1]https://lsr.di.unimi.it/LSR/Item?id=1113, "Watermark" that most >likely does not do exactly what was intended. It belongs _not_ to the duties of the lsr-updater to check whether snippets print as supposed. A snippet should _compile_, that's enough. Otoh, it is no surprise that several snippets will need further adjustment/fixing. Ideally those flaws are reported (as you did) and get fixed by a LSR-editor. Well, I _am_ a LSR-editor. Though, sometimes it feels I am the only one (not really true, Werner does a lot but his focus is more on lsr-software and snippets-descriptions). We really need more active LSR-editors. That said, I followed your suggestion below. Not the time to dive into it more deeply... > The watermark is only >visible in the upper right corner of the page, but was probably meant >to appear over the full page. A quick fix is to replace > > \translate #'(-50 . 70) >by > \translate #'(-70 . -120) > >in the third line of the snippet, but hopefully there's a better >solution that doesn't require any magic numbers. > > /Mats > > References > >1. https://lsr.di.unimi.it/LSR/Item?id=1113 Best, Harm
Re: snippet fails with 2.23.
On 2022-05-15 22:48, Thomas Morley wrote: ... Btw, I found some other snippets worth fixing, currently returning programming errors or warnings: incipit.ly "programming error: Loose column does not have right side to attach to." using-marklines-in-a-frenched-score.ly a plethora of "programming error: cyclic dependency:..." using-tags-to-produce-mensural-and-modern-music-from-the-same-source.ly "Loose column ..." how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-2.ly and vertical-aligned-staffgroups-without-connecting-systemstartbar.ly return warnings for conficting rehearsal marks. Worth fixing ofcourse, though I decided not to postpone finishing lsr-update see !1360 And there's clip-systems.ly ... It fails always with: GNU LilyPond 2.23.9 (running Guile 2.2) Processing `clip-systems.ly' Parsing... Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems... Converting to `clip-systems-1.pdf'... Layout output to `clip-systems-1-from-2.0.1-to-4.0.1-clip.eps'... Converting to `clip-systems-1-from-2.0.1-to-4.0.1-clip.pdf'... Layout output to `clip-systems-1-from-0.0.1-to-4.0.1-clip.eps'... Converting to `clip-systems-1-from-0.0.1-to-4.0.1-clip.pdf'... Layout output to `clip-systems-1-from-0.0.1-to-6.0.1-clip.eps'... Converting to `clip-systems-1-from-0.0.1-to-6.0.1-clip.pdf'... Layout output to `clip-systems-1-from-0.0.1-to-6.0.1-clip-1.eps'... Converting to `clip-systems-1-from-0.0.1-to-6.0.1-clip-1.pdf'... Interpreting music... Preprocessing graphical objects... Interpreting music... Preprocessing graphical objects... fatal error: cannot find file: `clip-systems-1-from-2.0.1-to-4.0.1-clip.eps' [...] But it survives 'make doc' I don't understand ... Cheers, Harm Thanks for your work with this. I happened to stumble upon [1]https://lsr.di.unimi.it/LSR/Item?id=1113, "Watermark" that most likely does not do exactly what was intended. The watermark is only visible in the upper right corner of the page, but was probably meant to appear over the full page. A quick fix is to replace \translate #'(-50 . 70) by \translate #'(-70 . -120) in the third line of the snippet, but hopefully there's a better solution that doesn't require any magic numbers. /Mats References 1. https://lsr.di.unimi.it/LSR/Item?id=1113
Re: snippet fails with 2.23.
Thomas Morley writes: > Am So., 15. Mai 2022 um 21:44 Uhr schrieb Thomas Morley > : > fatal error: cannot find file: `clip-systems-1-from-2.0.1-to-4.0.1-clip.eps' > [...] > > But it survives 'make doc' > I don't understand ... I remember a recent report that fatal errors don't let LilyPond exit with nonzero status anymore. That may be the reason and in want of fixing. -- David Kastrup
Re: snippet fails with 2.23.
Am So., 15. Mai 2022 um 21:44 Uhr schrieb Thomas Morley
:
>
> Am So., 15. Mai 2022 um 14:11 Uhr schrieb Jean Abou Samra
> :
> >
> >
> >
> > Le 15/05/2022 à 14:01, Thomas Morley a écrit :
> > > Hi,
> > >
> > > the new doc-tagged LSR-snippet 'tambourine-example.ly'
> > > https://lsr.di.unimi.it/LSR/Item?id=1070
> > >
> > > %%
> > > \paper { tagline = ##f }
> > >
> > > #(define mydrums '((tambourine default #t 0)))
> > >
> > > \new DrumStaff \with { instrumentName = #"Tambourine" }
> > >
> > > \drummode {
> > >\set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
> > >\override Staff.StaffSymbol.line-positions = #'( 0 )
> > >\override Staff.BarLine.bar-extent = #'(-1.5 . 1.5)
> > >
> > >\time 6/8
> > >tamb8. 16 8 8 8 8 |
> > >tamb4. 8 8 8 |
> > >% the trick with the scaled duration and the shorter rest
> > >% is neccessary for the correct ending of the trill-span!
> > >tamb2.*5/6 \startTrillSpan s8 \stopTrillSpan |
> > > }
> > >
> > >
> > > works fine with 2.22. but fails with master even after a run of
> > > convert-ly, returning:
> > >
> > > fatal error: unrecognised percussion sign: "#t"
> > >
> > >tamb8. 16 8 8 8 8 |
> > >
> > > I don't get what's wrong.
> > > Hints?
> > >
> > > Thanks,
> > >Harm
> >
> >
> > It works if you replace '((tambourine default #t 0)) with
> > '((tambourine default #f 0)). That's in line with the documentation:
> >
> > """
> > Existing notations may be redefined as an association list
> > where each entry has to be comprised of four items:
> > a name, the note head style (or @code{default}), an
> > articulation sign if needed (or @code{#f} if not), and
> > the note head's position on the staff. That list must then
> > be converted into a Scheme hash table, using the
> > @code{alist->hash-table} function.
> > """
> >
> > This apparently changed with
> >
> > commit 61cd3bc1f3254b430bf04acd587c4082253602d4
> > Author: Lukas-Fabian Moser
> > Date: Mon Dec 27 01:25:43 2021 +0100
> >
> > Make articulation-type a symbol? instead of a string?
> >
> > which contains
> >
> > diff --git a/lily/drum-note-engraver.cc b/lily/drum-note-engraver.cc
> > index 7e6e3cef7a..d4078a2e3b 100644
> > --- a/lily/drum-note-engraver.cc
> > +++ b/lily/drum-note-engraver.cc
> > @@ -93,12 +93,12 @@ Drum_notes_engraver::process_music ()
> > if (scm_is_symbol (style))
> > set_property (note, "style", style);
> >
> > - if (scm_is_string (script))
> > + if (scm_is_true (script))
> > {
> > // Error out if script doesn't exist
> > if (scm_is_false (ly_assoc (script, get_property
> > (context (), "scriptDefinitions"
> > ev->origin ()->error (_f ("unrecognised percussion
> > sign: \"%s\"",
> > - ly_scm2string (script)));
> > + ly_scm_write_string (script)));
> >
> > Item *p = make_item ("Script", ev->self_scm ());
> > make_script_from_event (p, context (), script,
> >
> >
> >
> > Namely, instead of checking (string? the-second-element),
> > it just checks the-second-element, i.e. it searches the
> > script definition if the script is anything but #f.
> >
> > Jean
> >
>
> Hi Jean,
>
> thanks for the background.
> There were some other lsr-snippets with a #t-setting there, which had
> escaped my attention, bombing out 'make doc' after lsr-import.
>
> Next attempt now...
>
> Thanks,
> Harm
Btw, I found some other snippets worth fixing, currently returning
programming errors or warnings:
incipit.ly "programming error: Loose column does not have right side
to attach to."
using-marklines-in-a-frenched-score.ly a plethora of "programming
error: cyclic dependency:..."
using-tags-to-produce-mensural-and-modern-music-from-the-same-source.ly
"Loose column ..."
how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-2.ly
and
vertical-aligned-staffgroups-without-connecting-systemstartbar.ly
return warnings for conficting rehearsal marks.
Worth fixing ofcourse, though I decided not to postpone finishing
lsr-update see !1360
And there's clip-systems.ly ...
It fails always with:
GNU LilyPond 2.23.9 (running Guile 2.2)
Processing `clip-systems.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `clip-systems-1.pdf'...
Layout output to `clip-systems-1-from-2.0.1-to-4.0.1-clip.eps'...
Converting to `clip-systems-1-from-2.0.1-to-4.0.1-clip.pdf'...
Layout output to `clip-systems-1-from-0.0.1-to-4.0.1-clip.eps'...
Converting to `clip-systems-1-from-0.0.1-to-4.0.1-clip.pdf'...
Layout output to `clip-systems-1-from-0.0.1-to-6.0.1-clip.eps'...
Converting to `clip-systems-1-from-0.0.1-to-6.0.1-clip.pdf'...
Layout output to `clip-systems-1-from-0.0.1-to-6.0.1-clip-1.eps'...
Converting to
Re: snippet fails with 2.23.
Am So., 15. Mai 2022 um 14:11 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 15/05/2022 à 14:01, Thomas Morley a écrit :
> > Hi,
> >
> > the new doc-tagged LSR-snippet 'tambourine-example.ly'
> > https://lsr.di.unimi.it/LSR/Item?id=1070
> >
> > %%
> > \paper { tagline = ##f }
> >
> > #(define mydrums '((tambourine default #t 0)))
> >
> > \new DrumStaff \with { instrumentName = #"Tambourine" }
> >
> > \drummode {
> >\set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
> >\override Staff.StaffSymbol.line-positions = #'( 0 )
> >\override Staff.BarLine.bar-extent = #'(-1.5 . 1.5)
> >
> >\time 6/8
> >tamb8. 16 8 8 8 8 |
> >tamb4. 8 8 8 |
> >% the trick with the scaled duration and the shorter rest
> >% is neccessary for the correct ending of the trill-span!
> >tamb2.*5/6 \startTrillSpan s8 \stopTrillSpan |
> > }
> >
> >
> > works fine with 2.22. but fails with master even after a run of
> > convert-ly, returning:
> >
> > fatal error: unrecognised percussion sign: "#t"
> >
> >tamb8. 16 8 8 8 8 |
> >
> > I don't get what's wrong.
> > Hints?
> >
> > Thanks,
> >Harm
>
>
> It works if you replace '((tambourine default #t 0)) with
> '((tambourine default #f 0)). That's in line with the documentation:
>
> """
> Existing notations may be redefined as an association list
> where each entry has to be comprised of four items:
> a name, the note head style (or @code{default}), an
> articulation sign if needed (or @code{#f} if not), and
> the note head's position on the staff. That list must then
> be converted into a Scheme hash table, using the
> @code{alist->hash-table} function.
> """
>
> This apparently changed with
>
> commit 61cd3bc1f3254b430bf04acd587c4082253602d4
> Author: Lukas-Fabian Moser
> Date: Mon Dec 27 01:25:43 2021 +0100
>
> Make articulation-type a symbol? instead of a string?
>
> which contains
>
> diff --git a/lily/drum-note-engraver.cc b/lily/drum-note-engraver.cc
> index 7e6e3cef7a..d4078a2e3b 100644
> --- a/lily/drum-note-engraver.cc
> +++ b/lily/drum-note-engraver.cc
> @@ -93,12 +93,12 @@ Drum_notes_engraver::process_music ()
> if (scm_is_symbol (style))
> set_property (note, "style", style);
>
> - if (scm_is_string (script))
> + if (scm_is_true (script))
> {
> // Error out if script doesn't exist
> if (scm_is_false (ly_assoc (script, get_property
> (context (), "scriptDefinitions"
> ev->origin ()->error (_f ("unrecognised percussion
> sign: \"%s\"",
> - ly_scm2string (script)));
> + ly_scm_write_string (script)));
>
> Item *p = make_item ("Script", ev->self_scm ());
> make_script_from_event (p, context (), script,
>
>
>
> Namely, instead of checking (string? the-second-element),
> it just checks the-second-element, i.e. it searches the
> script definition if the script is anything but #f.
>
> Jean
>
Hi Jean,
thanks for the background.
There were some other lsr-snippets with a #t-setting there, which had
escaped my attention, bombing out 'make doc' after lsr-import.
Next attempt now...
Thanks,
Harm
Re: snippet fails with 2.23.
Le 15/05/2022 à 14:01, Thomas Morley a écrit :
Hi,
the new doc-tagged LSR-snippet 'tambourine-example.ly'
https://lsr.di.unimi.it/LSR/Item?id=1070
%%
\paper { tagline = ##f }
#(define mydrums '((tambourine default #t 0)))
\new DrumStaff \with { instrumentName = #"Tambourine" }
\drummode {
\set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
\override Staff.StaffSymbol.line-positions = #'( 0 )
\override Staff.BarLine.bar-extent = #'(-1.5 . 1.5)
\time 6/8
tamb8. 16 8 8 8 8 |
tamb4. 8 8 8 |
% the trick with the scaled duration and the shorter rest
% is neccessary for the correct ending of the trill-span!
tamb2.*5/6 \startTrillSpan s8 \stopTrillSpan |
}
works fine with 2.22. but fails with master even after a run of
convert-ly, returning:
fatal error: unrecognised percussion sign: "#t"
tamb8. 16 8 8 8 8 |
I don't get what's wrong.
Hints?
Thanks,
Harm
It works if you replace '((tambourine default #t 0)) with
'((tambourine default #f 0)). That's in line with the documentation:
"""
Existing notations may be redefined as an association list
where each entry has to be comprised of four items:
a name, the note head style (or @code{default}), an
articulation sign if needed (or @code{#f} if not), and
the note head's position on the staff. That list must then
be converted into a Scheme hash table, using the
@code{alist->hash-table} function.
"""
This apparently changed with
commit 61cd3bc1f3254b430bf04acd587c4082253602d4
Author: Lukas-Fabian Moser
Date: Mon Dec 27 01:25:43 2021 +0100
Make articulation-type a symbol? instead of a string?
which contains
diff --git a/lily/drum-note-engraver.cc b/lily/drum-note-engraver.cc
index 7e6e3cef7a..d4078a2e3b 100644
--- a/lily/drum-note-engraver.cc
+++ b/lily/drum-note-engraver.cc
@@ -93,12 +93,12 @@ Drum_notes_engraver::process_music ()
if (scm_is_symbol (style))
set_property (note, "style", style);
- if (scm_is_string (script))
+ if (scm_is_true (script))
{
// Error out if script doesn't exist
if (scm_is_false (ly_assoc (script, get_property
(context (), "scriptDefinitions"
ev->origin ()->error (_f ("unrecognised percussion
sign: \"%s\"",
- ly_scm2string (script)));
+ ly_scm_write_string (script)));
Item *p = make_item ("Script", ev->self_scm ());
make_script_from_event (p, context (), script,
Namely, instead of checking (string? the-second-element),
it just checks the-second-element, i.e. it searches the
script definition if the script is anything but #f.
Jean
Re: snippet fails with 2.23.
Am So., 15. Mai 2022 um 14:08 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Hi,
> >
> > the new doc-tagged LSR-snippet 'tambourine-example.ly'
> > https://lsr.di.unimi.it/LSR/Item?id=1070
> >
> > %%
> > \paper { tagline = ##f }
> >
> > #(define mydrums '((tambourine default #t 0)))
>
> What's the #t supposed to mean here? Should be a symbol or #f I think.
>
> --
> David Kastrup
Aargh, of course!
Thanks,
Harm
Re: snippet fails with 2.23.
Thomas Morley writes:
> Hi,
>
> the new doc-tagged LSR-snippet 'tambourine-example.ly'
> https://lsr.di.unimi.it/LSR/Item?id=1070
>
> %%
> \paper { tagline = ##f }
>
> #(define mydrums '((tambourine default #t 0)))
What's the #t supposed to mean here? Should be a symbol or #f I think.
--
David Kastrup
