Re: hel-arabic.ly
Werner LEMBERG writes: > I see that there is a severe language barrier, making it apparently > difficult for you to communicate properly in English. However, given > that today automatic translation engines like 'Google Translate' > provide excellent results in most cases – especially for Arabic, since > this was the very first language supported by this service –, this is > no longer an excuse. I disagree with the premise that a computer translation can consider the degree to which some content may be culturally acceptable in a global environment communicating in the target language. But there is no necessity for finding a culprit or assigning blame when something doesn't work out. Whether this involves code or human interaction. Mathematical/computing problems tend to be more of a fixed target, so there is more of a point in trying to find a solution guaranteed to work. Human relations are both more flexible and more elusive. There is no guarantee anything will work or fail other than trying and doing one's best in recovering gracefully from failure. -- David Kastrup
Re: hel-arabic.ly
hassan.elfat...@free.fr writes: > Good morning > Before offering hel-arabic.ly, I tested it for 4 years, > it worked with all versions of lilypond. I have the impression that > individuals > have sabotaged my work or they are going to sabotage it in the latest > version of lilypond 2.25.13, You need to stop using inflammatory language and accusations here. If you are incapable of doing so, your contribution is not suitable for inclusion in LilyPond. This is basic project hygiene. That being said, the whole reason this is happening is because changes in LilyPond elsewhere broke hel-arabic.el and people have made the necessary changes to keep hel-arabic.ly working in newer versions of LilyPond you never had any possibility to test hel-arabic.ly with. Without useful regression tests contributed by you and without an active user base offering feedback in a polite manner, their fixes may well have been incomplete. It is not the first time this has happened, it will not remain the last time. If we get this shitstorm every time LilyPond changes in a manner where hel-arabic.ly is affected, there are two solutions: stopping to develop LilyPond, or removing hel-arabic.ly and refusing to support it in future. As it only serves a limited user base, it isn't worth sacrificing LilyPond's future for its sake. > I know that lilypond depends on volunteers, of course. Then consider the consequences of your behavior. To other developers, and to the future of hel-arabic.ly. -- David Kastrup
Re: hel-arabic.ly
hassan.elfat...@free.fr writes: > I'm sorry ! > Do you lack intellectual honesty? > I intended to propose an abc2lyarbic.py file which covers an abc file > with Arabic notes into a lilypond file with Arabic notes, but I will > not propose it, given your lack of intellectual honesty What goal would be achieved by willful obstruction? You are talking about volunteer work on a style not useful to the person working on it. Putting aside for a moment that those changes were actually suggested by yourself, why should anybody bother with integrating your work and having it distributed as part of LilyPond when they get called names for maintaining your contribution? LilyPond depends on volunteers, and a primary motivation for volunteers is that the work is fun to do. If the maintenance of some contribution exposes volunteers repeatedly to insults, we are better off removing that contribution than allowing it to contribute to a toxic work environment driving more contributors away than it will draw in new users. Please try to do your part in keeping LilyPond pleasant to work with and to work on. Thank you -- David Kastrup
Re: 5th anniversary conference? :)
Kieren MacMillan writes: > Hello, Pond! > > I was just waxing nostalgic about that fabulous Salzburg conference in > 2020, and noted that in Jan 2025 — just under a year from now! — it > will have been five years since we got together, talked > music/notation, and raised [more than] a few pints together. > > Any chance for a repeat? :) > > Just throwing it out into the Universe. I'm just throwing out that my subletter has bought a house elsewhere and moves out end of April. The owner has let me know that I can stay here till the end of June (he gets some rent and someone who feeds the horses on most days). I'm still looking for a new place, and it's not quite clear how long I'll need. That would not be a university setting. It would also not be the first time, though there is little personal overlap. <https://web.archive.org/web/20130304040840/http://news.lilynet.net/?The-LilyPond-Report-28#impressions_from_the_waltrop_meeting> There would be enough room to throw down sleeping bags. Near Dortmund, within about 1.5hr of train distance from Düsseldorf and Cologne. It reeks like a foolish idea, for sure. If your question hadn't had this impeccable timing, I'd not have mentioned it. Talk about waxing nostalgic! -- David Kastrup
Re: numbers
Werner LEMBERG writes: >>> Can you imagine any other use for `+` right before numbers? >>> Otherwise I suggest to make it work, to provide the least surprise >>> for users. >> >> Do we say anywhere that `+` is a sign in LilyPond syntax? Where >> does the surprise come from? > > Well, both `#+3` and `#-3` work, so it might be tempting to assume > that `+3` and `-3` also work (outside of `\markup`). So does ##e+3.0 and so does #3/1 so should we be supporting those as well? -- David Kastrup
Re: numbers
Werner LEMBERG writes:
>>> This works:
>>>
>>> ```
>>> { \ottava -1 c }
>>> ```
>>>
>>> while this fails:
>>>
>>> ```
>>> { \ottava +1 c'' }
>>> ```
>>>
>>> Is there a technical reason for it?
>>
>> As far as LilyPond is concerned, `+` is not a part of numbers. Is
>> there a compelling argument for wasting syntactic elements on doing
>> nothing?
>
> I think that 'wasting' is too harsh a statement. In comparison to
> other syntactical elements (together with the interpretation of Scheme
> code), a change to support `+` has no significant impact, AFAICS.
It makes + inelegible for other purposes. + as a sign does nothing, so
the language does not gain anything at all.
You could potentially require its use for disambiguating durations from
numbers, but I don't think requiring people to type + all the time is
going to be a crowd pleaser.
`-` is used within chords. So is `+`. `-` is specially lexed in chords
because of syntactic conflicts. That comes with its own bunch of
problems. `+` isn't. Yet.
`-` can become a part of numerical tokens in certain syntax modes, so it
isn't just the parser that is involved here but also the lexer.
> Can you imagine any other use for `+` right before numbers? Otherwise
> I suggest to make it work, to provide the least surprise for users.
Do we say anywhere that `+` is a sign in LilyPond syntax? Where does
the surprise come from?
--
David Kastrup
Re: numbers
Werner LEMBERG writes:
> This works:
>
> ```
> { \ottava -1 c }
> ```
>
> while this fails:
>
> ```
> { \ottava +1 c'' }
> ```
>
> Is there a technical reason for it?
As far as LilyPond is concerned, `+` is not a part of numbers. Is there
a compelling argument for wasting syntactic elements on doing nothing?
--
David Kastrup
Re: FingerGlideSpanner disappears if listened
Thomas Morley writes:
> Am Mo., 25. Dez. 2023 um 20:55 Uhr schrieb David Kastrup :
>>
>> Probably. Articulation events with a listener are removed (and
>> separately broadcast) from the articulations on a non-chord NoteEvent
>> before it is passed to its own engravers.
>
> I'd never expected something could vansih, if listened to; and there
> seems to be no hint in CG 10.11.3 Listening to music events.
Probably worth mentioning somewhere.
> Furthermore the following feels inconsistent:
>
> mus = {
> b2-\rightHandFinger #2 \5-\glide -1 -\accent
> b-\rightHandFinger #2 \5-1 -\accent
>
>
>
> }
>
> <<
> \new Voice
> \mus
>
> \new Voice
> \with {
> \consists
> #(lambda (ctx)
> (make-engraver
> (listeners
> ((finger-glide-event this-engraver event) '())
> ((fingering-event this-engraver event) '())
> ((string-number-event this-engraver event) '())
> ((stroke-finger-event this-engraver event) '())
> ((articulation-event this-engraver event) '())
> )))
> }
> \mus
>>>
>
> Why does Fingering and accent survive? Isn't at least the accent an
> articulation?
It is listened to by Script_engraver . The "don't remove if unlistened
to" behavior is what allows things like string numbers to appear even
outside of chords.
--
David Kastrup
Re: FingerGlideSpanner disappears if listened
Jean Abou Samra writes: > Probably related to the code and comment in lily/rhythmic-music-iterator.cc. Probably. Articulation events with a listener are removed (and separately broadcast) from the articulations on a non-chord NoteEvent before it is passed to its own engravers. -- David Kastrup
Re: [RFC] Transition to Guile 3.0
Jean Abou Samra writes: > What I don't really understand is why you want to add compatibility > with Guile 3.0.x for small x. Upstream completely breaks the normal > expectation from what you would find in a point release, by putting > features and even severely backwards incompatible changes (like > cross-module inlining in 3.0.8 *cough*), so I think this is definitely > going to be more work to keep supporting (in particular: testing) than > with dependencies that don't have this peculiarity. I'd rather define > a minimum version in the 3.0.x series that we want to support. I have not checked recently, but last time I looked, Guile's versioning system more or less worked so that the development branch (and the corresponding versions) was Andy Wingo's playground. It was not concerned with APIs in any manner. Any API development and corresponding changes consequently had to be done in the stable branch and eventually forwardported into the development branch. If that is still how things are done, the kind of feature/API stability we can depend on from distributions based on how much they can depend on being able to rely on version numbers for stability choices is limited. We use Guile as infrastructure, not as a Scheme hacking playground. But while Guile is historically sold as infrastructure, its community setup does not accommodate it. And for resolving that mess, we as the likely most competent party with an interest in that mess will be tasked with the consequences, for better or worse. -- David Kastrup
Re: Multiple clefs in one Staff
David Kastrup writes:
> Werner LEMBERG writes:
>
>>> Inspired by
>>> <https://music.stackexchange.com/questions/132340/lilypond-different-clefs-for-each-voice-on-one-staff>
>>>
>>> Should we be offering something like that?
>>
>> What exactly do you mean with 'offering'?
>
> Provide it as core functionality called with dedicated commands.
>
>> Having this functionality is certainly useful for Piano music.
>> However, it's quite rare, and an LSR snippet should be sufficient
>> (possibly integrated into LilyPond's documentation).
>
> I see that you have shown an example that repeats the clef for every
> measure. If that's the convention, the approach in my code is not
> likely helpful.
Correction: it is easy to make it do that.
\version "2.24.2"
\language "italiano"
\header {
tagline = ##f
}
\layout {
\context {
\Staff
\accepts PseudoClefStaff
}
\context {
\name PseudoClefStaff
\type Engraver_group
\alias Staff
\accepts Voice
\consists Clef_engraver
\override Clef.font-size = #-4
\override Clef.break-align-symbol = #'cue-clef
\override Clef.break-visibility = #end-of-line-invisible
}
}
\midi {
\context {
\Staff
\accepts PseudoClefStaff
}
\context {
\name PseudoClefStaff
\type Performer_group
\alias Staff
\accepts Voice
}
}
pseudoClef =
#(define-music-function (offset clef-type) ((number?) string?)
#{ \new PseudoClefStaff = "pseudo" \with { firstClef = ##f } { }
\change Staff = "pseudo"
#(if offset #{ \override Staff.Clef.Y-offset = #offset #})
\clef #clef-type
#})
% Any ideas for an automated endPseudoClef?
\score {
\new Staff = "lower" {
\key re \minor
\numericTimeSignature
\time 3/4
\clef bass
\relative do' {
\voices 1,""
<<
{
s2. r4 r8. \clef treble
\tuplet 3/2 16 { sol'32 (la sib }
do8.) do16--
do16-- sib sol la
sol8.
\omit TupletBracket
\tuplet 3/2 16 { fa32 (sol la }
sib8.) sib16
} \\
{
re,,,8.-- re16-- re2--~ 2.~
\pseudoClef #-3 "bass"
\voiceTwo
2.~ \break 2.~2.
\oneVoice
\change Staff = "lower" % change back to standard staff
}
>>
}
}
}
--
David Kastrup
Re: Multiple clefs in one Staff
Werner LEMBERG writes: >> Inspired by >> <https://music.stackexchange.com/questions/132340/lilypond-different-clefs-for-each-voice-on-one-staff> >> >> Should we be offering something like that? > > What exactly do you mean with 'offering'? Provide it as core functionality called with dedicated commands. > Having this functionality is certainly useful for Piano music. > However, it's quite rare, and an LSR snippet should be sufficient > (possibly integrated into LilyPond's documentation). I see that you have shown an example that repeats the clef for every measure. If that's the convention, the approach in my code is not likely helpful. If there is some common convention, that might be useful to give native support to, to the degree where a user's source reflects mostly musical content rather than code detracting from the readability. On the other hand, I think I have seen some mensural(?) clef that combined two equal-weight different clefs (possibly both C clefs on different staff lines) in order to put two singing voices into one staff. That's sort of a related problem space but with a differently-weighted solution. I think that one would be more special, though. -- David Kastrup
Multiple clefs in one Staff
Inspired by
<https://music.stackexchange.com/questions/132340/lilypond-different-clefs-for-each-voice-on-one-staff>
Should we be offering something like that?
\version "2.24.2"
\language "italiano"
\header {
tagline = ##f
}
\layout {
\context {
\Staff
\accepts PseudoClefStaff
}
\context {
\name PseudoClefStaff
\type Engraver_group
\alias Staff
\accepts Voice
\consists Clef_engraver
\override Clef.font-size = #-3
\override Clef.break-align-symbol = #'cue-clef
}
}
\midi {
\context {
\Staff
\accepts PseudoClefStaff
}
\context {
\name PseudoClefStaff
\type Performer_group
\alias Staff
\accepts Voice
}
}
pseudoClef =
#(define-music-function (offset clef-type) ((number?) string?)
#{ \new PseudoClefStaff = "pseudo" { }
\change Staff = "pseudo"
#(if offset #{ \override Staff.Clef.Y-offset = #offset #})
\clef #clef-type
#})
% Any ideas for an automated endPseudoClef?
\score {
\new Staff = "lower" {
\key re \minor
\numericTimeSignature
\time 3/4
\clef bass
\relative do' {
\voices 1,""
<<
{
s2. r4 r8. \clef treble
\tuplet 3/2 16 { sol'32 (la sib }
do8.) do16--
do16-- sib sol la
sol8.
\omit TupletBracket
\tuplet 3/2 16 { fa32 (sol la }
sib8.) sib16
} \\
{
re,,,8.-- re16-- re2--~ 2.~
\pseudoClef #-3 "bass"
\voiceTwo
2.~ \break 2.
\oneVoice
\change Staff = "lower" % change back to standard staff
}
>>
}
}
}
--
David Kastrup
Re: Scheme: Using brackets in addition to parentheses
Jean Abou Samra writes: > AFAIK, this is seldom used by Guile coders, though some other Scheme > communities do use this style by convention. > > I wouldn't embark on rewriting lots of code/documentation for this; I > don't think the effort pays off. I don't really like it and I don't think it is our job to promote a different style. -- David Kastrup
Re: How some "Joe Users" perceive LilyPond installation
Werner LEMBERG writes: >> Below is the copy of a discussion on the LilyPond Facebook group >> that I found interesting. Just food for thought. [...] > > Thanks, Jean. I was almost tempted to answer on Facebook some hours > ago, but I refrained because my answer would not have being useful in > any way :-) Let's just conclude that there is going to be one more > happy Dorico user. > > What you have already implemented in Frescobaldi, i.e., an > auto-installer for LilyPond, is the way to go, I believe. BTW, can > you estimate a release date of Frescobaldi that has this new feature? Well, there always is the question of how happy people will be with having to write a wall of text to represent their music when they are not open to dealing with writing stuff for installation. But this particular person mentioned having installed LilyPond 10 years ago. Feels like Carl Benz complaining about stick shift: just makes you question your customer model. -- David Kastrup
Re: unnecessary line in `define-context-properties.scm`?
Werner LEMBERG writes: > I wonder whether line 35 in file `define-context-properties.scm` is > necessary. AFAICS, the `map` call in functions > `all-user-translation-properties` and > `all-internal-translation-properties`, together with the following > > ``` > (define-public all-translation-properties > (append all-user-translation-properties > all-internal-translation-properties)) > ``` > > completely construct `all-translation-properties`. Why the additional > `set!`? Looks like an oversight in commit 7b22eeeee2505be517e58c3f922ddc53f1b7b0bd -- David Kastrup
Re: dowloading git-cl, connection timed out
pubabhervegueg...@free.fr writes: > Hi all fellow developers, > > My name is Gerard and I want to seek if I can do something about > traditional Japanese notations. > > As the subject is rare and difficult (such as vertical writing and > quite many different notations depending on instrument schools), I do > no expect to find a community already or wishing to work on the > subject up now. > > But I face a beginner's problem: timeout on git-cl download > > I am following 2.25.7 Lilypond Contributor's guide, > I Installed the proposed Debian 11 from zip on Oracle VM Virtualbox, > my host is Windows10 secured by default Windows Defender. > > When running ./setup.sh, I get the following error message: > > Cloning into git-cl... > fatal: unable to connect to github.com: > github .com[0: 140.82.121.4]: errno=Connection timed out Uh-oh. It's been now several years since git-cl has no place whatsoever in our workflow. I cannot find any reference to git-cl in our current documentation, so can you figure out where you got a reference to it? Thanks -- David Kastrup
Re: fix-docsize errors in build-doc.sh
ge not accessible from
> /build/out-www/online-root/Documentation/{web-big-page.ca.html,web-big-page.de.html,web-big-page.es.html,web-big-page.fr.html,web-big-page.html,web-big-page.it.html,web-big-page.ja.html,web-big-page.zh.html}
> fix-docsize.sh: usage-big-page not accessible from
> /build/out-www/online-root/Documentation/{web-big-page.ca.html,web-big-page.de.html,web-big-page.es.html,web-big-page.fr.html,web-big-page.html,web-big-page.it.html,web-big-page.ja.html,web-big-page.zh.html}
> fix-docsize.sh: web-big-page not accessible from
> /build/out-www/online-root/Documentation/{web-big-page.ca.html,web-big-page.de.html,web-big-page.es.html,web-big-page.fr.html,web-big-page.html,web-big-page.it.html,web-big-page.ja.html,web-big-page.zh.html}
>
>
> Is that expected?
It looks to me like the "not accessible" file names are without any file
extension. That would make it unlikely that their size can be
determined. Something appears rotten.
--
David Kastrup
Re: No applicable method for #< - (4)> in call
Jean Abou Samra writes: > Le dimanche 09 juillet 2023 à 12:39 +0200, David Kastrup a écrit : >> The build isn't broken unless you use bytecode compilation. Do we do >> this in general? > > > Depends on who is "we". I for one always build with bytecode because LilyPond > is > quite slow without it, especially the startup. > >> Do we have a way of installing bytecode? > > See "make install-bytecode". (Bytecode is shipped in the lilypond.org > binaries.) Ugh. Looks like our test pipeline setup would warrant including testing about this, then. Sorry, I had not followed this development, or obviously it would have been proper to test this with a patch like that. I do not consider this a great fix: I implemented a workaround for negation after all instead of just removing it from operator support, with the consequence of "supporting" decidedly weird forms of subtraction that can hopefully get removed again at some point of time. This is really experimental, and the scope may still change depending on experiences. -- David Kastrup
Re: No applicable method for #< - (4)> in call
Jean Abou Samra writes: > For the record, there is now a patch > at https://gitlab.com/lilypond/lilypond/-/merge_requests/2057 > > It LGTM. What do you think of fast-tracking it, to unbreak the build for > everyone? The build isn't broken unless you use bytecode compilation. Do we do this in general? Do we have a way of installing bytecode? -- David Kastrup
Re: No applicable method for #< - (4)> in call
Jean Abou Samra writes: > Le vendredi 07 juillet 2023 à 14:43 +0200, Jean Abou Samra a écrit : >> Le vendredi 07 juillet 2023 à 14:15 +0200, David Kastrup a écrit : >> > Yikes. Looks like the bytecode compiler/optimizer/whatever converts (- ) >> > or >> > something like it into (- 0 ) >> Indeed. > > > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64508 > > Maybe try just overloading (- ). Otherwise just revert the > patch. Ok, here is the deal: I think it probably is sanest to just ditch the operator for ly:pitch-negate and the equivalent for Moment. That being said, I've also found incorrect manual conversions in some code. The question is whether it is better to address this with a bulk fix, or with reverts and redo of what turns out a number of co-dependent commits. -- David Kastrup
Re: No applicable method for #< - (4)> in call
Dan Eble writes: > I'm hitting this on master after (roughly) autogen.sh; make; make bytecode. > > ``` > $ out/bin/lilypond ~/lilypond-src/input/regression/other/display-lily-tests.ly > GNU LilyPond 2.25.7 (running Guile 2.2) > Processing > `/home/user/lilypond-src/input/regression/other/display-lily-tests.ly' > [...] > /home/user/lilypond-src/input/regression/other/display-lily-tests.ly:252:8: > error: Guile signaled an error for the expression beginning here > \test # >#[ \key e \minor #] > No applicable method for #< - (4)> in call (- 0 #) > /home/user/lilypond-src/input/regression/other/display-lily-tests.ly:252:7: > error: wrong type for argument 2. Expecting pair, found > # > \test##[ \key e \minor #] > […] > ``` Yikes. Looks like the bytecode compiler/optimizer/whatever converts (- ) or something like it into (- 0 ) Without checking, this looks like a Guile problem, but that's not going to help us. Huh. So this needs either a workaround or a revert of the operator patch or some partial undo. I'll try to figure out more. I haven't yet worked with bytecode. -- David Kastrup
Re: Getting beam subdivision working
David Kastrup writes: > Dan Eble writes: > >> On Jun 16, 2023, at 19:13, Jason Yip wrote: >>> >>> minSubdivideInterval and maxSubdivideInterval. They are both >>> Rationals. Their numerator and denominator must be a power of 2. For >>> each power of 2 (including negative powers of 2 of course) > > That's redundant. It just means minSubdivideInterval and > maxSubdivideInterval must be an integral power of 2 (including > negative). > >>> between those two values, the beam can be subdivided by that >>> interval. minSubdivideInterval can be 0 for no minimum limit, >>> maxSubdivideInterval can be infinity for no maximum limit. >> >> Setting the representation aside, is the following another way of >> describing what you have in mind? >> >> * These properties are independently optional. >> * The allowed values are integer powers of two (including negative powers). > > That sounds like it would make more sense to specify those values in the > form of a "duration log", like the first argument to a ly:make-duration > call. Or just use a duration in the first place. First iterations would likely only use the duration-log info while I consider it conceivable that in the context of tuplets, ultimately also the factor may get used. -- David Kastrup
Re: Getting beam subdivision working
Dan Eble writes: > On Jun 16, 2023, at 19:13, Jason Yip wrote: >> >> minSubdivideInterval and maxSubdivideInterval. They are both >> Rationals. Their numerator and denominator must be a power of 2. For >> each power of 2 (including negative powers of 2 of course) That's redundant. It just means minSubdivideInterval and maxSubdivideInterval must be an integral power of 2 (including negative). >> between those two values, the beam can be subdivided by that >> interval. minSubdivideInterval can be 0 for no minimum limit, >> maxSubdivideInterval can be infinity for no maximum limit. > > Setting the representation aside, is the following another way of > describing what you have in mind? > > * These properties are independently optional. > * The allowed values are integer powers of two (including negative powers). That sounds like it would make more sense to specify those values in the form of a "duration log", like the first argument to a ly:make-duration call. -- David Kastrup
Re: Use of dev/ branches in Gitlab and GSOC
Han-Wen Nienhuys writes: > On Wed, May 31, 2023 at 5:12 AM Carl Sorensen > wrote: > >> After reading all of this, I believe I should recommend to Jason that he >> not have his gsoc repository be on the main GitLab repository for two >> reasons: 1) We really want the dev/ branches on GitLab to be used only for >> merge requests; and 2) We want the dev/ branches on GitLab to be temporary, >> but GSOC wants a permanent repository of the student's work. >> >> Am I making a mistake in giving Jason this advice? I'd welcome any >> comments. >> > > I think you are right. Creating a fork is slightly more cognitive > overhead, but it's not prohibitive, and if GSOC wants a permanent home > for work that is not merged, then the fork is the right place. I think I disagree in this particular context because the commitment from GSOC is a temporary one, and a fork is not a "permanent home for work that is not merged" in the GSOC context because it can just disappear along with the original account. That does not mean that I am against the use of forks in general. But for "unfinished work passing into general project reponsibility", maintaining it under accounts with a possibly diverging interest (where deletion is an extreme form of a diverging interest) does not appear like the best policy to me. -- David Kastrup
Re: music-font-encodings option
Jean Abou Samra writes: > Le dimanche 02 avril 2023 à 18:20 +, Werner LEMBERG a écrit : >> Essentially, this option switches between the `show` and `glyphshow` >> PostScript operators to access Emmentaler glyphs. The former is >> considered the 'standard' method for accessing glyphs in a PS file >> (according to the GS developers); however, it needs properly set up >> encoding vectors (which can't exceed a size of 256 glyphs each). The >> latter is slower, AFAIK, and apparently not as well supported with GS >> (at least, we filed some bug reports, IIRC). > > Thanks, that helps. However, I still don't understand what impact on > size this makes. Do the two result in different PDF primitives? I seem to remember that the second variant allowed Ghostscript to merge subsetted fonts from included separate files. -- David Kastrup
Re: some objects not clickable
Werner LEMBERG writes: >> The ligature is apparently not printed by a `VaticanaLigature` but >> by a `NoteHead` (try `\override NoteHead.color = blue`). A bit >> disconcerting. > > Interestingly, adding > > ``` > \addLink NoteHead "writing-pitches" > ``` > > doesn't help for `VaticanaLigature` (but works for normal note heads). > This looks like a problem deep in `vaticana-ligature-engraver.cc` (and > `mensural-ligature-engraver.cc`, which has exactly the same problem > for `MensuralLigature`). Clickability comes from make_spanner/make_item calls' second argument. If it is in itself a clickable grob or a stream event with a traceable origin, the ultimate origin gives the point-and-click position. It also has some relation to whether you can tweak the grob by using \tweak on the music expression creating the stream event (grobs reaching the originating event only via another grob need a directed tweak explicitly stating their grob name). -- David Kastrup
Re: Musings on the font-encoding property
Werner LEMBERG writes: >> >>> AFAICS, the only limitation is that an ordinary text font with a >>> family name 'music' cannot be used. >> >> No :-) unlike what its name suggests, the `font-family` property is >> a family symbol, not a font string (yes, it's another misnamed thing >> in font handling). The `font-family` values recognized by default >> are `'roman`, `'sans` and `'typewriter`. Nothing prevents you from >> doing > > Ah. Well, this makes the issue even more straightforward. > >> The practical impact of the change is mostly a syntax modification >> that is not easy to convert-ly (the removal of `\text`, which should >> be replaced with `\roman`, `\sans` or `\typewriter` depending on the >> case). > > We could make `\text` a no-op (it's rather seldom used, I reckon) and > `convert-ly` emit a warning. A default conversion of \text to \roman would likely match more than 90% of the current uses. -- David Kastrup
Re: Is it time to update the Finale 2008 sample in Essay?
Han-Wen Nienhuys writes: > On Mon, Mar 20, 2023 at 5:27 PM Abraham Lee > wrote: > >> Thanks, Jean, for doing that. I was hoping for a more public discussion to >> see if creating an issue is even warranted. The essay is a historical >> document, to be sure, so updating the comparison files might not be needed >> at all. > > I agree to this. It is better to simply put a small intro to the essay > that gives the context. > > We could then add an updated preface/postscriptum that puts it in > context for 2023. To note, a lot of modern music engravers have taken > inspiration from the LilyPond attitude to engraving. The Dorico blog > posts have been quite explicit about it, and maybe we could ask the > MuseScore folks for comments too. For better or worse, I think the main selling point of LilyPond these days is not as much quality as workflow. -- David Kastrup
Re: Anybody else with an interest in parser wrangling?
John Wheeler writes: > On 3/19/23 11:51, David Kastrup wrote: >> So how to better involve others? > > Maybe a good place to start is by asking a few questions. > > What you would like these others to do? Well, we are talking about core maintenance and rearchitecting here. The main objective in my book is making more people able to solve their own problems with confidence without ever having to touch the core. That involves making sure that "the way things are done" is straightforward and coherent and does not require to interact with any non-obvious bits and pieces. > What qualifications would they need? The taste and tenacity to leave something cleaner behind than what they started with. But that sounds like the qualifications for a single person, and there might be incentive for some small team to work on stuff with distributed responsibilities. -- David Kastrup
Re: Anybody else with an interest in parser wrangling?
John Wheeler writes: > On 3/19/23 11:51, David Kastrup wrote: > > When I was becoming familiar with the LilyPond manuals, it seemed to > me one manual that was missing was a concise specification of the > LilyPond language, something paralleling the R5RS for the Scheme > language. I spend a lot of time studying the lexer.ll/parser.yy code > trying to put together something along those lines for own use. Right > now that work is stuck at a *rough* draft. The notation reference at one point of time included the bison grammar. Because so much functionality has been migrated to music functions, and because the music function parsing works so much with synthetic tokens not corresponding to user input, this has been discontinued: it is not really helpful. For the purpose of parsing LilyPond files, it would be an idea to convert music functions based on their signatures into ad-hoc syntax rules and generate a syntax based on that that can be used for parsing/coloring/editing/whatever LilyPond input files. > Given that effort, I think I have a fair idea of how the lexer/parser > functions. I would be happy to contribute in this area. > > How can I be of service? I think the document to spell this out in would be the contributor's guide. It is a document of rather mixed quality and mixed coverage. But it's probably the best place to point people to anyway. -- David Kastrup
Re: Anybody else with an interest in parser wrangling?
Jean Abou Samra writes: > Le lundi 20 mars 2023 à 00:15 +0100, David Kastrup a écrit : > >> The MYBACKUP and MYPARSE stuff messes with the input in order to trigger >> syntactic decisions based on expression values. That's a bit more than >> usually expected from a Bison-generated parser. > > > Yes, I understand the basic way Bison parsers work. What I don't > understand is what other “effects” the lookahead can have, and why > having caused the reduction of the current rule is never a > problem. AFAIU, the parser works as a loop > > - Get next token from lexer. > > - Decide whether to shift or to reduce some rule. Use a lookahead > token if necessary. > > - Do the shift or the reduction and execute the semantic action. > > The lookahead token gets switched during the semantic action. Isn't it > a problem if the previous lookahead token says the current rule should > be reduced, but the new one would have required shifting? Or is that > just not a useful use of MYBACKUP/MYREPARSE? Well, if you feel you should not touch that code until you confidently know the answer to that question, let me assure you that the principal justification for that code is that I needed it to work. The equivalent in football is called a "Hail Mary pass" I believe. -- David Kastrup
Re: Anybody else with an interest in parser wrangling?
Jean Abou Samra writes: > Le dimanche 19 mars 2023 à 17:51 +0100, David Kastrup a écrit : >> >> So how to better involve others? The parser may be one of those >> areas with an awful amount of shoestring and glue, namely fiddling >> around until things happen to work. All that fiddling happens in >> private before commits end up in master, meaning that it has no >> opportunity to end up contagious the way it happens now. >> >> That's not really fabulous regarding the "bus factor" in that area. > > I would feel a lot more comfortable with modifying the parser if there > was an explanation, in code comments or in the CG, of how the > parser/lexer interplay works, when lookahead is OK or bad, and how to > avoid it when necessary. Things like the comment above MYBACKUP > > ``` > // The following are somewhat precarious constructs as they may change > // the value of the lookahead token. That implies that the lookahead > // token must not yet have made an impact on the state stack other > // than causing the reduction of the current rule, or switching the > // lookahead token while Bison is mulling it over will cause trouble. > ``` > > are obscure to me. Well, Bison creates LALR(1) parsers. That means that the parser always is in a certain state. It looks at the next token, the "lookahead" token (only one, that's what the 1 in LALR(1) is about) and then transitions into another state while either shifting the current state onto some stack, or by using a rule for reducing the current stack into a production. The above comment is fearsome about the possibility that the statemachine processes the current lookahead token without eating it, but then getting the lookahead token switched out under its radar and ending in a state that is not able to process the switched-out token. So far, the fears expressed in that comment have not materialized. The parser is only able to process a certain subset of languages. Since the parser makes deterministic progress by either consuming a lookahead token while growing the stack by 1 or by consuming stack material, it ends up O(1), namely efficient with regard to the size of its input. When the parser applies a rule, you can specify code that will be executed in the reduction. The MYBACKUP and MYPARSE stuff messes with the input in order to trigger syntactic decisions based on expression values. That's a bit more than usually expected from a Bison-generated parser. -- David Kastrup
Re: Anybody else with an interest in parser wrangling?
David Zelinsky writes:
> David Kastrup writes:
>
>> But while my desire for work on user-pointing and internal design and
>> architecture at that time sort of unfolded mostly in a vacuum, the years
>> since then have not seen a lot of uptake.
> [...]
>> There also is a lot of potential for making ping-pong progress. I
>> realize that I am not exactly the most fun person to be working with,
>> but also I tend to get stuck on boring or repetitive tasks to an
>> inordinate degree.
> [...]
>> So how to better involve others? The parser may be one of those areas
>> with an awful amount of shoestring and glue, namely fiddling around
>> until things happen to work. All that fiddling happens in private
>> before commits end up in master, meaning that it has no opportunity to
>> end up contagious the way it happens now.
>
> I've been interested in finding ways I can contribute to Lilypond,
> beyond the couple of minor merge requests I've had accepted. I don't
> know much about parsers. I read the dragon book years ago, and have
> written some seat-of-the-pants code that might qualify as parsing, for
> various things related to my math research, but nothing at all
> complicated or formal. And my experience with, say, bison, is that I've
> heard of it. :) But I'm comfortable reading documentation and happy to
> learn new things. And I have plenty of experience getting down into the
> weeds fiddling with things to get them to work just right.
>
> So if you're willing to have a bit of patience and point me in the right
> direction to learn things I need to know, I'm happy to help.
Well, I guess the first litmus test is taking a walk crossreading
lily/parser.yy and getting a feeling for what makes sense to you and
what makes your eyes glaze over.
A recent comparatively straightforward change had been
commit 276d688a358ff49e04b8b18e91ac15d56276cb62
Author: Jean Abou Samra
Date: Sun Dec 18 18:27:24 2022 +0100
Accept bare pitches/durations as music arguments to markup commands
This adds a tiny bit of the smart argument handling music functions have to
markup commands. Namely, if a command expects a Scheme argument (i.e., the
predicate is not markup? or markup-list?), and { } or {
} is
passed, the music interpretation as note event of those constructs is tried
as
well against the predicate. The most obvious use case is
\markup \rhythm { 8. }
Checking it out may be a hint about what a "comfort level" change not
involving an inordinate amount of shoestring and glue would like.
Probably the worst shoestring and glue department is how
function_arglist is destructured.
I may add some work-in-progress stuff to a branch soonish. I currently
have implemented the equivalent of define-music-function for pitches and
am mostly through with duration function (I am stuck on 4 reduce/reduce
conflicts at the moment that are essentially all the same problem).
This would warrant extending to book functions, score functions and a
few others. Most of those are likely trivial to do and don't offer a
lot (other than consistency and syntactic predictability) over
define-scheme-function.
So there are some candidates which are easy to implement in that
context, and some that are really tricky.
--
David Kastrup
Anybody else with an interest in parser wrangling?
I've not been particularly active in the last years, and there has not really been a significant pickup in activity concerning syntax/parser. Now for better or worse, before I picked up tenure there was GLISS, the "Grand Lilypond Input Syntax Something" that sort of tried a top-down prescription of what syntax would be desirable. This suffered from a lack of feedback and input, suggestions and inspiration from the technical/implementation side and led, among other things, to a lot of churn between myself and the maintainer at that time, Graham, that ultimately contributed to him releasing the reins of the project because he figured he wasn't helping. His organisational talents that fleshed out roles and procedures working reasonably well with our scattered resources and interests of developers and documenters and other contributors can still be witnessed in the LilyPond project's somewhat unique organisational approach for getting contributions integrated and, to the degree possible, vetted. But while my desire for work on user-pointing and internal design and architecture at that time sort of unfolded mostly in a vacuum, the years since then have not seen a lot of uptake. For example, git shortlog -n -s --since '10 years ago' lily/parser.yy is sort of one-sided (admittedly, with '1 year ago' this looks different, though removing the -s argument in order to see the details also makes clear that a lot of work was not syntax related, with not much more than one minor and one more elaborate addition). As an example, I am just wrangling with extending user-definable functions in the parser, and end up with things like reduce/reduce conflicts that need to get ironed out. Bison options like -Wcounterexamples by now help with visualising what goes wrong (in my time, I used an Emacs Lisp contraption to come up with conflict examples), but one still needs to come up with plans how to circumnavigate such obstacles and it usually ends up being an exercise of trial and error a lot. There also is a lot of potential for making ping-pong progress. I realize that I am not exactly the most fun person to be working with, but also I tend to get stuck on boring or repetitive tasks to an inordinate degree. Of course it is not an inviting process to tackle those, but someone being slowed down to 20% of their potential will still easily beat someone being slowed down to 0.2% of their potential regardless of how impressive or not the respective potentials may look on paper, or more exactly before doing the gritty work of actually getting down on paper. So how to better involve others? The parser may be one of those areas with an awful amount of shoestring and glue, namely fiddling around until things happen to work. All that fiddling happens in private before commits end up in master, meaning that it has no opportunity to end up contagious the way it happens now. That's not really fabulous regarding the "bus factor" in that area. -- David Kastrup
Re: RFC: stop doing "grand replace" updates to copyright years
Jean Abou Samra writes: > To summarizes, it changes `LICENSE` like this: > > ``` > @@ -1,3 +1,14 @@ > +GNU LilyPond is Copyright (C) 1996-2023 by the LilyPond authors, as > defined below. > + > +LilyPond's Git repository is the authoritative source for copyright > +attribution of each piece of code. It can be found at > + > + https://git.savannah.gnu.org/cgit/lilypond.git > + > +or > + > + https://gitlab.com/lilypond/lilypond > + > GNU LilyPond is free software: you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation, either version 3 of the License, or > ``` > > and copyright headers like this: > > ``` > @@ -1,10 +1,13 @@ > This file is part of LilyPond, the GNU music typesetter. > > - Copyright (C) 2012--2023 David Nalesnik > - Thomas Morley > - Dan Eble > - Jonas Hahnfeld > - Jean Abou Samra > + Please read the file LICENSE for copyright information. > + > + This file was mainly authored by: > + David Nalesnik > + Thomas Morley > + Dan Eble > + Jonas Hahnfeld > + Jean Abou Samra > > LilyPond is free software: you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > ``` > > Thoughts? "Mainly authored" relies on which metric? How are mechanical reformattings not generally affecting the copyright situation catered for? How is a generational update expounding on the original idea but not leaving original code in place catered for? -- David Kastrup
Re: RFC: stop doing "grand replace" updates to copyright years
Wol writes: > On 15/02/2023 15:36, Werner LEMBERG wrote: >> Code contributed to GNU LilyPond will*always* be under the GPL. You >> can't change the license afterwards. > > Sorry. This is legal bullshit. If *I* contribute a file to lilypond, > and *I* stick a *BSD* licence on it, the BSD licence does *NOT* give > *YOU* the right to change the licence to GPL. You are not understanding that a license is associated with a transaction, not with a file text. > Even the GPL itself makes this extremely clear. It explicitly states > that you receive your licence to GPL code - not from the person who > gave you the code - but from the copyright holder themself. Uh, no? From the GPL: 10. Automatic Licensing of Downstream Recipients. Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License. I repeat: "Each time you convey a covered work, the recipient automatically receives a license from the original licensors". There is no word about the license being in some manner connected to the file contents. > If the copyright holder NEVER GRANTED a GPL licence, how the hell are > you supposed to receive a GPL licence? "From the original licensors", not "From the copyright holders". Section 7f: f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors. This makes rather explicit that "licensors" and "authors" is not synonymous. > You are correct that I can't change the licence afterwards. But if *I* > *NEVER* licenced that code under GPL, then that code can NEVER be GPL. You still don't understand. Code can never *be* GPL anyway. It can be _licensed_ under the GPL. How do you imagine dual licensing could even work if code magically "was" GPL or any other license? > So what you're saying is, I can't take someone else's BSD-licenced > code, MAYBE add stuff to it, and add the result to lilypond? Now am I saying anything like that? > Absolutely NO FLOSS licence I can name allows a licensee to change the > licence. (One or two explicitly allow conversion to GPL, but I can't > name them.) There is no "conversion" because code _is_ not GPL or BSD or stuff like that but is _licensed_ under such licences. Relicensing is not "conversion". You are confusing the licenses with the attributions. _Those_ are what BSD-like licenses do not allow changing. > The GPL works, NOT because it changes the licence on everything else, > but because it guarantees that by complying with the GPL, you are also > complying with any other licence that it may be mixed up with. I really recommend that you read up on the material you talk about with such confidence. The GPL FAQ is a good start. <https://www.gnu.org/licenses/gpl-faq.html> > First rule of copyright licencing. You cannot change the licence of > someone else's code unless the original licence gave you permission. Your "first rule of copyright licencing" already confuses what a license is. It is not governing code but its conveyance. > As I said, almost no FLOSS licence gives you that authority. Now you are confusing license and attribition again. > So if the copyright owner put BSD, MIT, Apache, whatever code into > lilypond, then that code REMAINS BSD, MIT, Apache or whatever. Licenses cover conveyance, not code. You could not otherwise dual-license code. > The lilypond BINARY is *effectively* GPL. > I use the word *effectively* because it is under a mix of licences, > but the only licence a distributor can use is the GPL. Because the GPL > guarantees that, by complying with the GPL, you are complying with all > the other relevant licences. > > So the effect of the GPL is that we can safely behave as if lilypond > is completely GPL, while the legal reality is completely different. "legal reality". Sigh. And of course you know much better about the legal reality than the law professors consulted by the FSF. -- David Kastrup
Re: RFC: stop doing "grand replace" updates to copyright years
Wol writes: > On 15/02/2023 17:08, David Kastrup wrote: >> Wols Lists writes: >> >>> On 15/02/2023 02:01, David Kastrup wrote: >>>>> Personally, I'd be happiest if everybody who updated a file was >>>>> responsible for making sure the copyright date was updated >>>>> appropriately, >>> >>>> That is going to work fantastically well, right? Distribute >>>> responsibility until nobody feels responsible for anything and enjoy the >>>> chaos. >>> >>> Put it another way. If they can't be bothered to claim their >>> copyright, that's their lookout. (Or reject submissions if they >>> don't.) >> I haven't ever seen a project that demands authors to declare that >> they >> will defend their copyright in court. That would be a much more onerous >> burden than even a copyright assignment. >> > PLEASE be more careful reading what I wrote. You can take things too > literally, I know. Please take what I write rather more literally > also. > > All I said was "if the copyright owner can't be bothered to update > attribution, that's down to them". Quote marks suggest quoting. But what you wrote was "if they can't be bothered to claim their copyright, that's their lookout. (Or reject submissions if they don't.)" Seems like you don't take literally what you write. > If they want to rigorously keep it up to date, that's fine too. It's > their copyright, their prerogative. And how does updating (or not) a > copyright statement to reflect reality make any statement as to > whether they are going to defend said copyright? > > All I'm saying, it's not MY right to alter YOUR copyright statements, > and nor is it your right to alter mine. We are talking about updating the project license header. Not about falsifying the detailed record. Of course every single line is open to change in the course of project maintenance. Maybe it would avoid this kind of noise if the copyright header just referred to the LilyPond project and gave the year of licensing, deferring to the revision control log for the details of authorship, and to the ChangeLog files for the ancient history before Git. Of course we'll get a shitstorm for such a change, and one should check back with those authors who appear comparatively frequently in the headers. But at least that kind of shitstorm would at least be just once and hopefully this will end the claims that LilyPond project maintenance constitutes a criminal enterprise. > I've been messaged off-list saying this is a contentious subject, and > while I'm clearly trying to do "the right thing" he doesn't agree with > me. What is it in particular you are doing that is the right thing? > I'm not a lawyer, I could be wrong. But my feelings are simple. Your feelings about whose copyright headers? > The *source* is an *aggregation* of individual files. Don't mess with > *other* *peoples* copyrights. Everything I've said boils down to > that. I just find it incredibly hard to justify anything else. Hence > me wording it so strongly. > > If you want to disagree with me, fine. But please read what I wrote, > not what you think I wrote. See above. > I think we both need to back off and cool down. Sorry. -- David Kastrup
Re: RFC: stop doing "grand replace" updates to copyright years
Jean Abou Samra writes: > Le mercredi 15 février 2023 à 18:05 +0100, David Kastrup a écrit : > >> No GNU program requiring a copyright assignment for working on it has >> ceased doing so as far as I know, > > [Off-topic] > > Actually, both GCC and Guile have done so by now. > > [https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html](https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html) > > [https://lists.gnu.org/archive/html/guile-devel/2022-10/msg8.html](https://lists.gnu.org/archive/html/guile-devel/2022-10/msg8.html) > > [/Off-topic] Not really surprised about Guile (I think they also wanted to become entirely non-GNU but I have no idea how that went). Surprised about GCC. Thanks for correcting me on that! -- David Kastrup
Re: RFC: stop doing "grand replace" updates to copyright years
Wols Lists writes: > On 15/02/2023 02:01, David Kastrup wrote: >>> Personally, I'd be happiest if everybody who updated a file was >>> responsible for making sure the copyright date was updated >>> appropriately, > >> That is going to work fantastically well, right? Distribute >> responsibility until nobody feels responsible for anything and enjoy the >> chaos. > > Put it another way. If they can't be bothered to claim their > copyright, that's their lookout. (Or reject submissions if they > don't.) I haven't ever seen a project that demands authors to declare that they will defend their copyright in court. That would be a much more onerous burden than even a copyright assignment. -- David Kastrup
Re: RFC: stop doing "grand replace" updates to copyright years
Wols Lists writes: > On 15/02/2023 06:23, Werner LEMBERG wrote: >> >>>> IMHO it's even simpler - is it fraud? (I don't know the answer, but >>>> it feels like it, and we shouldn't do it without legal advice). >>> >>> The GPL is used for licensing works _as_ _a_ _whole_, so it is >>> definitely not fraud to update the license headers in lockstep. >>> [...] >> Well said, thank you! >> > Sorry, can I re-write that? > > An individual source file is an individual work. Apparently you don't understand what licensing a work means. A license is not something pervading files like copyright does. A license is a particular permission. The GPL is a license for using a complete works, not individual files. If you do not accept the license, your rights to use a work fall back to the default rights granted by copyright laws of your country, and the person who has standing to sue you for breach of copyright is the copyright holder of particular code. > What happens if I decide to add a file under a BSD licence? The > copyright ON THAT FILE is not GNU, You are confusing copyright and license. The copyright holder apparently has decided to license the file to you under the BSD license. That includes your right to release that file as a work licensed under the GPL. What happens if someone decides to break your license terms by using that file on its own under the original license? The one who could sue for breach of copyright/license is the copyright holder. That possibility is comparatively useless because a) it's very unlikely you'll get them interested in the unlicensed use of your copy b) more often than not a copy could have been obtained by alternate paths under a more permissive license c) so you'll have a hard time proving that this particular copy had been obtained from your GPLed work d) If there had been any possibility to obtain a copy through a different path, the copyright holder will have a hard time proving actual damages As a consequence, files obtained via a BSD license will be _effectively_ available under the BSD license since pressing the GPL licensing is not likely to fly. Legally, however, there is a distinction between authorship/copyright of the material and licensing of a particular copy. > it is not GPL, let's assume no-one has modified it. If that file is > 100% my BSD-licenced copyright, you changing the copyright notice > (even if it's just the date!) is fraudulent misrepresentation. No, it isn't, not least of all because text bytes at the start of the file are of no legal consequence as long as they are not declared to be part of some interaction. I can write at the start of a file "shoot yourself" and that is not legally binding. But changing the BSD licensing notice is against the terms of the BSD license. It's one of the few things where BSD without advertising clause actually differs significantly from Public Domain. > You yourself said "The GPL is used for licensing works _as_ _a_ > _whole_", that "whole", legally BEING THE BINARY. Otherwise the GPL > truly would be viral, as detractors like to claim, seizing ownership > of works that their creators explicitly did NOT place under the GPL. Now you are really going off the rails. I recommend that you read the respective FAQs about the GPL. > (And lastly, when you said that "GNU only requires copyright > assignment for EMACS" and something else, I'm very sorry but you > clearly did not read what I wrote. You used present tense, I used past > tense. If GNU used to require assignment, then a policy of updating > the notices every year makes sense. No GNU program requiring a copyright assignment for working on it has ceased doing so as far as I know, and no GNU program not requiring a copyright assignment for working on it has started requiring one (for the record: to integrate AUCTeX into Emacs core as a GNU project, it was decided that copyright assignments would be needed in order not to have a non-copyright-assigned GNU package for the copyright-assigned GNU Emacs. That made it necessary to hunt up all relevant old AUCTeX contributors well into the 20th century and get assignments from them, a real nuisance: so this was a case where becoming a GNU project necessitated assignments after the fact). > But if they DON'T require copyright assignment, and they DON'T own the > copyright, then changing the copyright notice smacks of fraud. The FSF does not change copyright notices of projects it is not in charge of and I already explained why this statement is both wrong and unnecessarily inflammatory. > Simple as. BUT DOES ANYBODY REALLY CARE? Only the armchair lawyers, I > guess :-) I am not sure who you try to denigrate here and for what purpose. -- David Kastrup
Re: RFC: stop doing "grand replace" updates to copyright years
Wol writes: > On 13/02/2023 22:50, Han-Wen Nienhuys wrote: >>> which sounds like exactly the opposite. > >> I read it again, and you are right. The instructions say to update >> each file even if the file itself wasn't changed in that year. I guess >> the instructions codify what I find annoying in this practice: to >> touch files even if they weren't changed in any way. >> > My gut feeling is that this is actually fraud. > > Strong words, I know, but if nothing creative has happened that is > worthy of copyright, then to claim that the copyright has changed is > just plain wrong. For better or worse, the only way with copyright laws based on the Berne convention where this could make a difference is once the author is dead. That's when the copyright clock starts ticking. But it's not the point of time when a work under the GPL is licensed as a whole. For better or worse, the actual copyright situation with regard to who may or may not have standing to enforce copyright when, is much more complicated and mostly reflected by the version control change logs. Before those were reliably available from version control, they were meticulously maintained manually in every GNU project and led to lots of moping from the developers. The licensing headers are really not as much providing any kind of dependable author information as they do provide a reference to the license under which the entire work is provided. > Personally, I'd be happiest if everybody who updated a file was > responsible for making sure the copyright date was updated > appropriately, That is going to work fantastically well, right? Distribute responsibility until nobody feels responsible for anything and enjoy the chaos. -- David Kastrup
Re: RFC: stop doing "grand replace" updates to copyright years
Wol writes: > On 14/02/2023 10:27, Werner LEMBERG wrote: >> >>> I have proposed before to move to a system based on SPDX before for >>> the same reason, it reduces busywork that brings no advantage. And >>> as it's been suggested before in the thread, the bulk advantage of >>> accurate/updated copyright years is likely to be somewhere between >>> small and modest, to be generous. >> Please bear in mind that LilyPond is a GNU project. I'm tracking a >> few other GNU projects (autoconf, automake, bison, coreutils, emacs, >> gettext, gnulib, m4, mc), and they update copyright notices, too. >> > Did GNU not used to insist on copyright assignment? If they own the > copyright they are free to change the dates. If they don't ... Sigh. No, GNU only uses copyright assignments for specific projects where the FSF itself is willing to defend the copyright in court. Most prominent here are GCC and Emacs. >>> Like Han-Wen, my own perspective was also informed by many >>> discussions had at various employers and with various other houses >>> and bodies investing big money in software in a variety of ways. >> IMHO, it's simple: Just follow the GNU guidelines. >> > IMHO it's even simpler - is it fraud? (I don't know the answer, but it > feels like it, and we shouldn't do it without legal advice). Look, if the FSF has one thing it is lawyers, and it takes legal steps and sets legal guidelines certainly consulting with lawyers. So "I don't know the answer but certainly feel qualified to behave like I do" is not helpful. The GPL is used for licensing works _as_ _a_ _whole_, so it is definitely not fraud to update the license headers in lockstep. What it does is making it harder to figure out for anybody trying to use code that actually is older than 90 years after its author's death whether a particular _passage_ might be lifted out and used independently of other code of younger origin without someone or someone's estate having standing to sue for a copyright violation for the unlicensed use. There is no obligation for a project to make it easier to use some parts without license. The GPL is used for licensing works as a whole. Copyright notices are put in for the purpose of stopping the excuse "I thought I could just use this code how I wanted, and how should I have known otherwise?". Copyright enforcement is a murky area without a unified copyright holder, but that situation is pretty common and leads to situations where only few people can be bothered actually pressing the licensing conditions (cf Harald Welte regarding the Linux kernel). That is the same with LilyPond. Mouthing off that the practices vetted extensively by the FSF lawyers are fraudulent is really pointless. -- David Kastrup
Re: RFC: stop doing "grand replace" updates to copyright years
Werner LEMBERG writes: >>> If accepting this proposal just means no more grand-replace, I'm >>> fine with it, but it would seem a bit weird to keep "Copyright >>> 1995-2023" at the top of all files even in 2025. >> >> it is weird, but so is doing the grand update. > > Honestly, I don't see anything weird with doing `make grand-replace`. > Commits affecting these parts of files almost never interfere with > real changes, which means that neither `git bisect` nor `git blame` > are essentially affected. Admittedly, `git log` produces a lot of > output, but it is possible to filter out relevant commits with > > ``` > git log -i --grep="grand.*replace" --invert-grep > ``` > > In total, we have exactly 45 such commits out of more than 32000 > commits done over the last 27 years. An unresolvable merge conflict in a feature branch occurs when there has been a copyright header update both in the feature branch and in the master branch. I am responsible for a number of commits over the years. I remember having to fix copyright header conflicts exactly zero times. `git blame` tracks local changes. If you are looking for the source of some change, the grand replace has no impact on it. I can understand this discussion about whitespace/formatting changes (`git blame -w` helps and can be set as the default behavior). For the grand replace, it seems like a nothingburger to me. -- David Kastrup
[Jose E. Marchesi] [gnu-prog-discuss] GNU GSOC 2023 application
Forwarded from gnu-prog-disc...@gnu.org: --- Begin Message --- Hi hackers. Please see below. If you are interested in participating with your GNU program in GSOC 2023 under the umbrella of GNU, please subscribe to summer-of-c...@gnu.org and send the requested information for ideas. Thanks! From: "Jose E. Marchesi" To: summer-of-c...@gnu.org --text follows this line-- Hello everyone. I have just submitted an application for the GNU Project to participate as a mentoring organization in GSOC 2023. We will know the outcome in late February. In the meanwhile, it is VERY important to collect and publish a list of ideas of the GNU programs interested in participating under the GNU umbrella. To do so, please send them to this list and I will be adding it to our GSOC ideas page. For each idea, please include the following information: - Name of the program (example, GNU poke). - Short description of the program. - URL of the program (example, https://www.gnu.org/s/recutils) - Title for the idea (example, Writing python bindings for libpoke). - Description of the idea. - Skills necessary to do the work. - Address a prospective student should use in order to contact the development community and maintainers of the program. This would be the typical foo-de...@gnu.org or bug-...@gnu.org list. - A list of URLs with reference information useful for the idea. Please do not bother to format the ideas in HTML. We will do it for you. Remember people: the more and more exciting and nice ideas we have in the page, the bigger are the odds we will get accepted this year. Also, the sooner we have the info on place, the more odds we will have as well. So please send the information sonner than later! Do not wait until mid-February to do so. Salud! --- End Message --- -- David Kastrup
Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail
Jonas Hahnfeld via Discussions on LilyPond development writes: > On Sun, 2023-02-05 at 12:54 +, Werner LEMBERG wrote: >> Looking into MacPorts 'lilypond-devel' log files for Yosimite >> ( >> https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/ >> 211914/steps/install-port/logs/stdio) >> and El Capitan >> ( >> https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/ >> 209146/steps/install-port/logs/stdio) >> [...] >> >> @dan: I guess this is a problem or bug with the XCode clang versions >> of these two macOS versions since both older and newer ones compile >> fine. I'm not a C++ expert, but maybe there is a simple fix >> available? > > These are *ancient*, the last version 10.11.6 was released in 2018. > Even if we find one, I think we must not introduce any workaround for > such outdated systems. Did you intent to write "need not" instead of "must not"? In German, the negations of the corresponding words have other meanings than in English. -- David Kastrup
Re: GSoC 2023
Jean Abou Samra writes: > On 30/01/2023 09:55, Werner LEMBERG wrote: >> >> The deadline for registering LilyPond as mentor organization for GSoC >> 2023 is February 7th. Do we want to participate? > > > I won't mentor anyone (I wouldn't feel comfortable doing this for > someone roughly my age), On the Internet, nobody can measure the length of your beard. -- David Kastrup
Re: What is the difference between \paper and \layout blocks?
David Kastrup writes:
> Jean Abou Samra writes:
>
>> Le 14/01/2023 à 22:10, David Kastrup a écrit :
>>> What should it be?
>>
>>
>> I have no idea. My own gut feeling is that output defs need a redesign
>> and reimplementation from scratch anyway. In an ideal world, we wouldn't
>> even have the paper/layout/midi distinction.
>
> I don't see that. layout/midi are different output media. paper has
> some overarching information (like base file names). It also contains
> some information pertinent to typesetting a whole document as opposed to
> single scores, like paper dimensions. Things like staff sizes are a
> whole lot murkier, and developers have been scratching their head about
> making things like layout-set-staff-size work in a sensible manner, if
> at all.
Adding a bit more info: layout blocks inherit from the corresponding
paper block, books and bookparts have their own paper block, bookparts
inherit the paper block of the surrounding book. There is only
provision for single inheritance.
Markups outside of scores are called with a paper block as "layout"
parameter, but a global
\markup \score { \layout { ...
does not accept a paper block in its \layout definition, and a score can
only encompass a \layout syntactic construct.
Books and bookparts cannot contain layout blocks of their own.
Maybe the scaled paper block created by the Paper_book constructor
should be relabeled as a layout block?
This is such a mess.
--
David Kastrup
Re: Explicit default duration?
Dan Eble writes: > On Jan 26, 2023, at 12:22, David Kastrup wrote: >> >>c'' x2 >> > > That looks a lot like "twice" to me. Ugh. Well, it would be a rare syntax discussion that had everybody on the same page... -- David Kastrup
Re: Explicit default duration?
Aaron Hill writes: > On 2023-01-26 9:57 am, David Kastrup wrote: >> Luca Fascione writes: >>> I'd think that if 'x' meant "last pitch" and 'X' meant "last >>> chord", things >>> would be real peachy. >> Not a fan of using case distinction here (doesn't help that the >> German >> accordion accompaniment notation uses c for a c major chord and C for a >> single c root note). >> Maybe xx for chords... Should be fast enough to type and is >> somewhat >> mnemonic. At least more so than y . > > Users probably are used to case-sensitivity with r and R for rests and > multi-measure rests, respectively. Sure, but assuming a German accordion input mode using uppercase for single notes and lowercase for chords, x for note repetition and X for chord repetition would be quite awkward. I'll admit that xx does not look chord-like from its syntax, but we don't have a single character or x: lookalike. Huh. as a chord repeat? Maybe too clever. > I could get behind 'xx' for chords as the naming seems to imply > multiple notes are being reused. However, 'q' for "qords" should > still work even if 'x' were introduced. Ok... -- David Kastrup
Re: Explicit default duration?
Luca Fascione writes: > Being it said that "ibid2" is worthy of some award somewhere, because it's > awesome, > I'd think that if 'x' meant "last pitch" and 'X' meant "last chord", things > would be real peachy. Not a fan of using case distinction here (doesn't help that the German accordion accompaniment notation uses c for a c major chord and C for a single c root note). Maybe xx for chords... Should be fast enough to type and is somewhat mnemonic. At least more so than y . -- David Kastrup
Re: Explicit default duration?
Aaron Hill writes: > On 2023-01-23 3:35 pm, David Kastrup wrote: >> p would require that there actually is a next pitch (or drum type, >> assuming that p gets specialcased like r and R). > > I feel like I am missing context from the original query. '0' seems > to only be necessary if there is another event following as well. > > >> Also it begs the question what to do about c2 ... > > Yeah, does the 'p' pick up the most recently input 'e' or is it > shorthand for the 'c' that occurred before? Perhaps it just is > forbidden in chords, like 'q' is. An idle musing: I think instead of p for last pitch, I think I'd prefer x. Cf c'' p2 c'' x2 For some reason, p looks more like a particular pitch to me than x . Now I am not the greatest fan of q either but that ship has sailed. And I guess there is little utility in c'' ibid2 ... -- David Kastrup
Re: Explicit default duration?
Dan Eble writes: > On Jan 23, 2023, at 18:05, David Kastrup wrote: >> >> Dan Eble writes: >> >>> On Jan 23, 2023, at 10:11, David Kastrup wrote: >>>> >>>> I am not saying that 0 is the best choice here. It merely appears to be >>>> rather cheap. I thought of * and / but the first renders sequences like >>>> c4*2 ambiguous and the second would at least become a mess in chord >>>> mode. >>> >>> Can you clarify how `c4*2` would be ambiguous? (I was about to >>> suggest `r*1` for your original example.) >> >> c4*2 could be read as c4 c4 c2 if all of 4 * 2 are interpreted as >> individual durations. > > I see. I was thinking not of using '*' as a duration, but of omitting > the duration part of r4*1. > > r4 quarter rest > rrest of default duration > r4*2/3 quarter rest compressed to 2/3 of its duration > r*2/3rest of the default duration, compressed to 2/3 of it > > So r*1 would use the unscaled default duration. I'd imagine that syntax to actually be a pretty easy shoo-in. But its utility seems limited and I fear that seeing an abundance of *1 inputs would be more likely to give beginners wrong ideas about what it does than scaled rests already do. -- David Kastrup
Re: Shorthand for \repeat unfold for individual notes
Aaron Hill writes: > On 2023-01-23 3:46 pm, Carl Sorensen wrote: > >> I get the lack of utility of \repeat unfold (14 keystrokes) for >> short music >> expressions (like a single note). But I don't think that ** is >> intuitive >> enough to use it. >> If there were an alternative operator that would not mess up >> lookahead and >> would not suffer with the confusion between * and ** (people already >> think >> * does your proposed **), I could be convinced. > > Well, blame my email program, as it truncated my original post. I had > intended to fully call out that ** is exponentiation in some language, > thus might not be the best symbol. Well, mathematically c**4 in some sense is the same as c c c c . Not saying that I find that compelling but it is some kind of argument. -- David Kastrup
Re: Shorthand for \repeat unfold for individual notes
Jean Abou Samra writes: > On 24/01/2023 00:41, David Kastrup wrote: >> At any rate, postfix expressions require lookahead, and ** requires more >> than one token of lookahead. What constructs would you see as >> candidates before ** ? > > > Without agreeing or disagreeing with the '**' idea, couldn't > the lexer just emit a different token for '**'? I am not too enthused about composite tokens. That makes for awkward stuff in lyrics, for example. At any rate, any postfix sequence requires lookahead. -- David Kastrup
Re: Explicit default duration?
Aaron Hill writes: > On 2023-01-23 3:35 pm, David Kastrup wrote: >> p would require that there actually is a next pitch (or drum type, >> assuming that p gets specialcased like r and R). > > I feel like I am missing context from the original query. '0' seems > to only be necessary if there is another event following as well. > > >> Also it begs the question what to do about c2 ... > > Yeah, does the 'p' pick up the most recently input 'e' or is it > shorthand for the 'c' that occurred before? Perhaps it just is > forbidden in chords, like 'q' is. > > Granted, I have wondered if 'q' could be accepted like a chord > extension syntax: > > " " becomes " " > > If that could be made to be consistent, perhaps 'p' would then need a > good meaning. > > With '0' as a pseudo duration, there is less to mess about with > regarding pitches and special-casing naming. > > > > Out of curiosity, would this work in your proposed syntax? > > "tamb4 r0 0 8 8" for "tamb4 r4 r4 tamb8 tamb8" No, it would be tamb4 r4 tamb4 tamb8 tamb8 . Rests have never had any form of implicit notation. Saving a single letter is just not worth it. -- David Kastrup
Re: Shorthand for \repeat unfold for individual notes
Carl Sorensen writes:
> I'm not in favor.
>
> a8**3 is 5 key strokes.
> a8 8 8 is 6 key strokes.
> In exchange for saving one key stroke, I have a new operator to remember
> (and get confused about) and to maintain changes to the lexer and parser.
>
> I get the lack of utility of \repeat unfold (14 keystrokes) for short music
> expressions (like a single note). But I don't think that ** is intuitive
> enough to use it.
>
> What about
>
> %%
> \version "2.24"
>
> dup =
> #(define-music-function
> (count mus)
> (number? ly:music?)
> #{
> \repeat unfold $count $mus
> #})
>
> {\time 7/8 \dup #3 a8 \dup #4 b16 c4}
> %
>
> If you don't like the name dup, you could use ru (short for repeat
> unfold)
"\\*" works as well, giving
{\time 7/8 \*3 a8 \*4 b16 c4}
--
David Kastrup
Re: Shorthand for \repeat unfold for individual notes
Aaron Hill writes:
> There is already shorthand for tremolo repeats,
Not really. The internal representations are different.
> so I wondered if there could be the same for cases when a single note
> or rest is repeated.
>
> %%
> % Start with music that has repeated notes:
> { \time 7/8 a8 8 8 b16 16 16 16 c4 }
>
> % Manually unfolded repeats work, but take up a lot of input space:
> { \time 7/8 \repeat unfold 3 a8 \repeat unfold 4 b16 c4 }
>
> % This produces the correct length of music without note repetition:
> { \time 7/8 a8*3 b16*4 c4 }
>
> % Possible shorthand for unfolded repeat:
> { \time 7/8 a8**3 b16**4 c4 }
> %%
>
> In a sense, the ** acts like (integral) scaling of a duration but with
> unfolded repetition as the realization.
What Scheme representation would you propose?
At any rate, postfix expressions require lookahead, and ** requires more
than one token of lookahead. What constructs would you see as
candidates before ** ?
--
David Kastrup
Re: Explicit default duration?
Aaron Hill writes:
> On 2023-01-23 9:12 am, Luca Fascione wrote:
>> Of course. Forgive me I got distracted with Mats's message (for which I
>> suspect 'p' could be a viable suggestion? p -> last sound (or last
>> pitch?),
>> q -> last chord)
>> For your case I'm warming up to the 0, actually
>
> I would say there is symmetric value with 'p' as a pseudo pitch, so
> maybe not throw out the idea altogether.
>
> %%
> { a4. b8 c4 r0 2 b } % '0' breaks up the parsing without changing
> duration
> { a4. b8 c4 r p2 b } % 'p' achieves a similar goal but regarding pitch
> %%
>
> If both of these patterns could be accepted, then it would give users
> a choice of how they prefer to input music. I, for one, would find
> myself using 'p' over '0', but others may find the exact opposite
> working for their needs.
p would require that there actually is a next pitch (or drum type,
assuming that p gets specialcased like r and R).
Also it begs the question what to do about c2 ...
Not saying that it's a dealbreaker but it does seem to require a bit of
attention. The positive thing is that there already is a Scheme
representation, and there might be _some_ motivation to remove redundant
durations in \displayLilyMusic again when one can output
{ c'4 c' p2 } instead of the faulty { c'4 c' 2 } . But I am not sure
that removing redundancy would actually be a good thing.
--
David Kastrup
Re: Explicit default duration?
Dan Eble writes: > On Jan 23, 2023, at 10:11, David Kastrup wrote: >> >> I am not saying that 0 is the best choice here. It merely appears to be >> rather cheap. I thought of * and / but the first renders sequences like >> c4*2 ambiguous and the second would at least become a mess in chord >> mode. > > Can you clarify how `c4*2` would be ambiguous? (I was about to > suggest `r*1` for your original example.) c4*2 could be read as c4 c4 c2 if all of 4 * 2 are interpreted as individual durations. -- David Kastrup
Re: Explicit default duration?
Benkő Pál writes:
> Jean Abou Samra ezt írta (időpont: 2023. jan.
> 22., V, 23:45):
>>
>> On 22/01/2023 23:38, David Kastrup wrote:
>> >
>> > There are situations where sticking with the default duration may make
>> > sense when something looking like (or being) an explicit duration may
>> > follow.
>> >
>> > Like when switching pitches (or to rest) but not wanting to change the
>> > default duration.
>> >
>> > Like
>> >
>> > \drums { tamb 4. 8 4 r | 4. 8 4 r }
>> >
>> > in situations where there _isn't_ something like | to put between r and
>> > 4. (here).
>>
>> My knee-jerk reaction is a bit of skepticism on an explicit
>> default duration being more ergonomic than just repeating the
>> previous duration.
>
> My knee-jerk reaction is "how these modern musicians keep forgetting
> those highly unergonomical durations \breve, \longa, \maxima and their
> dotted versions!"
Well, they are a pain in the neck in their own right.
--
David Kastrup
Re: Explicit default duration?
Luca Fascione writes: > Is 'p' an option? There is some mild level of appeal in this choice in that > it's a reversed 'q' which might help memory. The problem with a letter is that you need to separate it with a space from other letters. That makes for a decidedly different look from the usual c4 syntax for notes. -- David Kastrup
Re: Explicit default duration?
Mats Bengtsson writes:
>On 2023-01-23 00:36, David Kastrup wrote:
>
> We have q for "repeat last chord with default duration" and 4 for
> "repeat last pitch with specific duration" but not "repeat last pitch
> with default duration".
>
>To me, the most natural solution would be to extend q to mean last
>pitch/chord (i.e. last "sounding music event") with default duration.
>Over the years, I have several times misremembered the exact meaning of
>q and tried to use it to repeat the last pitch, and instead got a
>repetition of a chord that happened much earlier in the score.
For one thing, I think that ship has sailed in terms of dealing with
existing sources writing, say
{ \partial 8 g8 | 4. g8 q4. g8 | q2 r4. \bar "|." }
which were a large motivation for the current q behavior. The current
behavior also very much facilitates "oom-pah" basses like
{ \clef "bass" c,4 g, q | c, q g, q | }
Also, having to approach the concept of "anything with default duration"
with a variety of different constructs feels like beating around the
bush.
I am not saying that 0 is the best choice here. It merely appears to be
rather cheap. I thought of * and / but the first renders sequences like
c4*2 ambiguous and the second would at least become a mess in chord
mode.
--
David Kastrup
Re: Explicit default duration?
Jean Abou Samra writes:
> On 22/01/2023 23:38, David Kastrup wrote:
>>
>> There are situations where sticking with the default duration may make
>> sense when something looking like (or being) an explicit duration may
>> follow.
>>
>> Like when switching pitches (or to rest) but not wanting to change the
>> default duration.
>>
>> Like
>>
>> \drums { tamb 4. 8 4 r | 4. 8 4 r }
>>
>> in situations where there _isn't_ something like | to put between r and
>> 4. (here).
>>
>> Since it should act as a shorthand, it should be short to enter. I
>> thought of
>>
>> \drums { tamb 4. 8 4 r0 4. 8 4 r0 }
>>
>> That provides no conflict with the grammar (as the syntax is not
>> affected, just the interpretation).
>>
>> 0 has no extra cost in terms of syntax but seems weird. A superficial
>> look at the ASCII table did not suggest an obvious other choice to me.
>
>
>
>
> My knee-jerk reaction is a bit of skepticism on an explicit
> default duration being more ergonomic than just repeating the
> previous duration.
The "previous duration" may not be readily accessible when working with
#{ ... #} or similar.
We have q for "repeat last chord with default duration" and 4 for
"repeat last pitch with specific duration" but not "repeat last pitch
with default duration".
> Did you think about this while entering a score that you would have
> been sensibly easier to write that way?
"Sensibly" is not synonymous with "for lack of alternatives" in my book.
--
David Kastrup
Explicit default duration?
There are situations where sticking with the default duration may make
sense when something looking like (or being) an explicit duration may
follow.
Like when switching pitches (or to rest) but not wanting to change the
default duration.
Like
\drums { tamb 4. 8 4 r | 4. 8 4 r }
in situations where there _isn't_ something like | to put between r and
4. (here).
Since it should act as a shorthand, it should be short to enter. I
thought of
\drums { tamb 4. 8 4 r0 4. 8 4 r0 }
That provides no conflict with the grammar (as the syntax is not
affected, just the interpretation).
0 has no extra cost in terms of syntax but seems weird. A superficial
look at the ASCII table did not suggest an obvious other choice to me.
--
David Kastrup
Re: Updating GNU Guix's package definition for LilyPond
Jean Abou Samra writes: > Hi Jahrme, > > Le 17/01/2023 à 12:14, Jahrme Risner a écrit : >> Hello all, >> >> I recently moved my primary system onto GNU Guix and have been >> getting it set up according. While doing that I noticed that the >> Guix package for LilyPond is still on 2.20.0, seemingly having >> missed the entire 2.22.0 release cycle, > > > > Given that one of LilyPond's creators now works on Guix, I actually find > this a bit surprising... Jan? Well, he'd not likely be in a rush to update, given that LilyPond worked fine for him for decades. Anekdote: two(?) years ago I was in a LilyPond-centric conference in Salzburg and put something like \override Staff.KeySignature.color = #red on a slide. Han-Wen discretely took me aside and told me that I had misspelt what should be \override Staff.KeySignature color = #red That seriously threw me for a loop since that syntax change had been done (backward-compatibly) in 2012 or so, and my whole manner of thinking about that line did not match Han-Wen's. Of course I literally knew where he was coming from, and it was a place he was comfortable with. It felt sort of seeing someone enter a house through a tunnel trapdoor that had not been used as such for a decade because there was a much more convenient entrance by now. -- David Kastrup
Re: What is the difference between \paper and \layout blocks?
Jean Abou Samra writes: > Le 14/01/2023 à 22:10, David Kastrup a écrit : >> What should it be? > > > I have no idea. My own gut feeling is that output defs need a redesign > and reimplementation from scratch anyway. In an ideal world, we wouldn't > even have the paper/layout/midi distinction. I don't see that. layout/midi are different output media. paper has some overarching information (like base file names). It also contains some information pertinent to typesetting a whole document as opposed to single scores, like paper dimensions. Things like staff sizes are a whole lot murkier, and developers have been scratching their head about making things like layout-set-staff-size work in a sensible manner, if at all. -- David Kastrup
What is the difference between \paper and \layout blocks?
What should it be? The presence of a \layout block in a score makes for typeset output. \paper contains things like paper dimensions only necessary for typeset output. Also base file names that are also relevant for MIDI. Global markup currently only gets to see the \paper block. That also concerns things like \score markup that can get information for typesetting from \layout blocks. Layout blocks "inherit" from the paper block: when a variable in a layout block is not set, it is taken from the respective paper block. Currently a "paper-book" where the typesetting is done only stores the relevant paper block. Consequently, any page-level/top-level markup currently gets only the paper block as its "layout" parameter. That is not accepted as layout block in a score markup. Suggestions? -- David Kastrup
Re: Missing items to make Cairo ready
Jean Abou Samra writes: > Le 04/01/2023 à 22:42, David Kastrup a écrit : >> There is a difference between a score that is downloaded and copied and >> transferred thousands of times indefinitely, and a finalized print >> journal that is sent from a publisher to a printer once. > > > > I think there is a misunderstanding. We are talking about the > LilyPond manuals only, not about the size of user scores. Again, the size of a manual that will get copied repeatedly and indefinitely and the size of a document that is transferred once to a printer are different things, and the quoted reply of a Ghostscript developer suggests that they are not willing or able to view the realities of one use case as similarly important or relevant as the other. -- David Kastrup
Re: Missing items to make Cairo ready
Jean Abou Samra writes: > Le 04/01/2023 à 22:22, Werner LEMBERG a écrit : >> Honestly, a fourfold size increase is not something that I would call >> 'acceptable'. > > > > It's a question of absolute values, not relative ones. A fourfold > increase from an acceptable value to an acceptable value is > acceptable. There is a difference between a score that is downloaded and copied and transferred thousands of times indefinitely, and a finalized print journal that is sent from a publisher to a printer once. -- David Kastrup
Re: The hel-arabic.ly file story...
Amir Czwink writes: > Thanks for your responses. > > First and foremost: I'm not trying to accuse or hold someone > accountable. I'm trying to understand (and idealistically improve) the > process. [...] > But I wonder, how the process will work then? Every one simply commits > what he thinks is best and we regularly overwrite each others > contributions? That can't be in the best interest of nobody... Well, any expenditure and continuation of effort is voluntary. So the modus operandi is that everybody tries figuring out based on what is there and on the feedback of others how to best achieve progress in the area of their interest and then propose a contribution that others may vet to various degrees. Depending on how specific such an area of interest may be, the quality and extent of vetting may end up different. A lot of contributions are isolated with regard to how they affect the rest of the project: that may result in its inclusion even if their code quality may seem to be lacking in some respect. However you rate contributions, I don't think that many are characterized by willful sloppiness, namely a lack of quality stemming from a lack of effort. Large cohesive work on the whole code base is more likely to be driven by people drawn in by their fascination/obsession with the code/language rather than a specific musical problem. So the more special music problems have a tendency to have code less in line with the style and quality of the core code. You have to see where you see your place in such a situation. The one thing that makes comparatively little sense is complaining: things here will only get done by people doing them. Nobody is getting paid here, and complaints are rather limited in their capacity to motivate people. So usually your outrage tends to be better spent in improving code/coding rather than asking others to improve it: after all, you tend to be most motivated about the task in the first place. -- David Kastrup
Re: LSR update?
David Kastrup writes: > Thomas Morley writes: > >> Am So., 1. Jan. 2023 um 11:52 Uhr schrieb Jean Abou Samra >> : >>> >>> Le 31/12/2022 à 21:15, Thomas Morley a écrit : >>> > Today I found some time :) >>> > >>> > lilypond *.ly on all lsr-snippets fails because of the following snippets: >>> >custom-tuning-and-midi-rendering.ly >>> >dodecaphonic-staff.ly >>> >dodecaphonic-staff-with-accurate-ledger-lines.ly >>> >microtonal-notation-and-theory-of-harmony.ly >>> >retuning-to-a-regular-temperament.ly >>> > >>> > All of them are using ly:set-default-scale and/or >>> > ly:parser-set-note-names on toplevel niveau. >>> > >>> > How to limit those settings to the current file? >>> >>> >>> I would approach it differently: not "how to fix the snippets?", but >>> "how to fix LilyPond so that these settings apply to the current file?". >>> >> >> Sure, out of my depth, though. >> And any fix in lilypond would be too late for the 2.24. lsr-update. > > Session bleedover does not invalidate the isolated snippets but > invalidates our testing infrastructure. The testing infrastructure is > not inherently tied to the release version. > > Have a fix for set-default-scale in the queue. As a note aside: there are a few Midi data structures that contain a raw, unprotected Pitch. If ly:set-default-scale is called to reset the default scale before the Midi soundsetting pass has been accomplished, those Midi data structure pitches may lose their associated Scale. Which would be comparatively bad news. So "fixing" the snippets by resetting the default scale might actually do more damage than fixing LilyPond's session bleedover (which resets the default scale at a point of time where Midi data should all have been flushed). -- David Kastrup
Re: LSR update?
Thomas Morley writes: > Am So., 1. Jan. 2023 um 11:52 Uhr schrieb Jean Abou Samra > : >> >> Le 31/12/2022 à 21:15, Thomas Morley a écrit : >> > Today I found some time :) >> > >> > lilypond *.ly on all lsr-snippets fails because of the following snippets: >> >custom-tuning-and-midi-rendering.ly >> >dodecaphonic-staff.ly >> >dodecaphonic-staff-with-accurate-ledger-lines.ly >> >microtonal-notation-and-theory-of-harmony.ly >> >retuning-to-a-regular-temperament.ly >> > >> > All of them are using ly:set-default-scale and/or >> > ly:parser-set-note-names on toplevel niveau. >> > >> > How to limit those settings to the current file? >> >> >> I would approach it differently: not "how to fix the snippets?", but >> "how to fix LilyPond so that these settings apply to the current file?". >> > > Sure, out of my depth, though. > And any fix in lilypond would be too late for the 2.24. lsr-update. Session bleedover does not invalidate the isolated snippets but invalidates our testing infrastructure. The testing infrastructure is not inherently tied to the release version. Have a fix for set-default-scale in the queue. The notenames are more tricky: the way it looks to me, they are maintained in the parser (or lexer?). If we don't set up a new parser, it could be that we get bleedover of things like the default duration and the default tremolo duration as well. That would be worth checking. -- David Kastrup
Re: A question about a scheme function with two input notes
Jean Abou Samra writes:
> [This is the continuation of
> https://lists.gnu.org/archive/html/lilypond-user/2022-12/msg00321.html]
By the way, I don't like what would happen with, say
singlebeat =
#(define-music-function (time) (fraction?)
#{ \time #(make-list (car time) 1) #time #})
\displayLilyMusic { \singlebeat 5/8 { c'8 8 8 8 8 } }
For better or worse, there is no visual distinction between music
functions and reserved words.
--
David Kastrup
Re: A question about a scheme function with two input notes
Jean Abou Samra writes:
> [This is the continuation of
> https://lists.gnu.org/archive/html/lilypond-user/2022-12/msg00321.html]
>
>
> Le 30/12/2022 à 15:07, David Kastrup a écrit :
>> You conflate "parsing" and "reading". For #{...#}, there is a
>> rudimentary scan for # and $
>
>
> Yes, I know that.
>
>
>> that tends to deliver false positives (which then just don't get
>> evaluated later on)
>
>
> This sounds worrisome.
Not particularly worrisome.
> Do you have examples of that happening?
"\\%" = "Huh?"
x = "What?"
sam =
#(define-music-function (x) (string?)
#{ \lyricmode { \% #x
} #})
\lyrics { "Hi" \sam "Hello" }
> The Scheme reader will throw an error that is incomprehensible
> for the user in case this happens and # or $ is followed by something
> that is not a valid Scheme expression, so avoiding false positives
> is important for correctness.
x is a valid Scheme expression here but escaped being treated as
closure.
>> and may get confused into
>> overlooking actual positives. \ offers a lot more potential for getting
>> this wrong.
>>> It would also make Guile evaluate one (lambda () ) per use
>>> of \ in #{ #}, which I don't believe is costly.
>> It is. The optimisation of not putting up closures for most constants
>> made a relevant performance difference.
>
>
>
> I did a test with a file constructed using
>
> $ echo '\version "2.25.1"' > perftest.ly
> $ for i in `seq 1`; do echo '##{ #1 #}' >> perftest.ly; done
>
> I pinned my CPUs at 2GHz (to reduce statistical noise) and measured:
>
> $ hyperfine -m 30 'master/build/out/bin/lilypond perftest.ly'
> Benchmark 1: master/build/out/bin/lilypond perftest.ly
> Time (mean ± σ): 1.446 s ± 0.021 s [User: 1.395 s, System:
> 0.107 s]
> Range (min … max): 1.410 s … 1.498 s 30 runs
>
> $ hyperfine -m 30 'build/out/bin/lilypond perftest.ly'
> Benchmark 1: build/out/bin/lilypond perftest.ly
> Time (mean ± σ): 1.609 s ± 0.083 s [User: 1.551 s, System:
> 0.108 s]
> Range (min … max): 1.539 s … 1.917 s 30 runs
>
>
> The second one is with the removal of the (or (symbol? expr) ...) test
> in parser-ly-from-scheme.scm. The difference is about 0.16s for 10,000
> expressions, or 16μs / expression.
Huh? You need to set it to #t rather than remove it.
> The Notation manual has a section on what it calls "substitution
> functions", which is separate from the section on music functions
> in the Extending manual, and I think that is for good reason.
> Those "substitution functions" have the form of a define-music-function
> where the body is just a #{ ... #}. There is little Scheme "programming"
> involved for that apart from cargo-cult copy of the
> define-music-function template and picking type predicates
> from the list in the documentation.
>
> I regularly see people (especially on lilypond-user-fr lately)
> wondering why returning #{ \book { ... } #} from a music function
> does not work, and that sort of thing.
> It's LilyPond's kind of "macro" facility, which is accessible to
> all users including those who know nothing about Scheme, and
> I think there is a point in making it behave more like users
> would expect ("just use variables like you always do, except
> that the variables change every time").
But there is a difference between variables and local bindings. This is
just serving to confuse people by comingling Scheme and LilyPond in an
incomprehensible manner.
--
David Kastrup
Re: Missing items to make Cairo ready
Jean Abou Samra writes: > Le 30/12/2022 à 16:59, Karlin High a écrit : >> What are the chances of having a conversion tool that produces >> LilyPond markup commands for the vectors in formats such as EPS? >> Perhaps as an eps2ly or something. > > > Zero. PostScript is a full-fledged programming language. See the > size of GhostScript, an implementation of PostScript; we're not > going to create our own. So? ps2pdf exists. It's not like it isn't already part of our toolkit, so I don't see the problem with using it for creating a vector format. pdftocairo can create an SVG from that, for example. -- David Kastrup
Re: Oriental microtonal music
Hans Åberg writes: > Graham Breed wrote a file regular.ly <http://regular.ly/> that allows > for retuning into any ET (around C4, not A4), but Adam Good is expert > on Turkish music specifically. > > There are some issues with Turkish, Persian and Arabic music that must > be dealt with when adapting for LilyPond: Notation system limitations, > transposability, and MIDI output. > > Because of those issues, I would prefer to use Helmholtz-Ellis > notation. There, LilyPond does not have the double arrowhead > accidentals. > > Though Persian music is transposed, in Turkish makam and Arabic maqam, > one may rename. In LilyPond, transposability is hard wired, so some > care must be taken here: Turkish music has different notation systems, > but the common AEU (Arel–Ezgi–Uzdilek) is not transposable, as its > sharp ♯ and and doublesharp 턪 represents microtonal accidentals, not > the ordinary ones. AEU also writes the pitch a 4th above the sounding > pitch. > > As for MIDI, the traditional tuning is Pythagorean tuning with > Pythagorean commas for microtonal alterations in Turkish music, though > with departures in actual performance. In Arabic and Persian music, > these have drifted considerably, the double is a possibility. > > LilyPond does not support exact Pythagorean tuning, but it could be > replaced by E₅₃ (53 ET) by the use of regular.ly <http://regular.ly/> > if included in the distribution. An alternative that does not require > this file is E₇₂ (72 ET), which relative E₅₃ and Pythagorean tuning > changes the diatonic scale into E₁₂ (12 ET), but alters the microtonal > neutral seconds only with a few cents. > > I believe that Adam Good used E₇₂ for the rewritten Turkish makam file. > > The original LilyPond makam file had an error making it not transposable: > > E₅₃ has minor second m = 4, major second M = 9 commas (E₅₃ tonesteps), > so that the sharp ♯ = 9 - 4 = 5 commas, and the Pythagorean comma is > approximated by 1 E₅₃ tonestep, also called a comma. Therefore, in > E₅₃, one arrives at the microtonal alteration of one comma by dividing > the E₅₃ M by 9 or the E₅₃ ♯ by 5. > > A type of error one sees though, is that these last rules are not > applied to E₅₃ but to E₁₂: > > In the original LilyPond file, they reasoned to divide the M of E₁₂ > further in form of the LilyPond accidental, which is internally > represented as a rational number where ♯ is 1/2. So the doublesharp 턪, > which has a value 1, is divided by 9, but unfortunately the ♯ of 1/2 > is not then an integral multiple of that. The new one by Adam Good > corrects this issue. > > If the ♯ of E₁₂ is divided to 5 parts, one arrives at E₆₀, which is > done in a suggested Persian file. The Arabic files written so far use > E₂₄, possibly because LilyPond did not have the rational accidentals > originally, but only this 24 ET. I doubt anybody has an idea what you want to to get done by whom for what reason. That makes your extensive writeup (that takes a lot of things for granted that will not be in the experience or knowledge set of whoever could actually be convinced to actually fix or write code) a complete waste of time. This waste of time, in turn, will serve for nothing except to convince you that other developers/users of LilyPond are unable to cater to your use cases. I have no idea how to get you on the same page with anybody. At the same time, if you want something to be done, it is your job to figure out a common base of communication. -- David Kastrup
Re: pygment regex question
Lukas-Fabian Moser writes: > \override NoteHead.color = red > > actually lowers the barrier immensely compared with > > \override NoteHead #'color = #red red and #red are completely different Scheme entities. > - of course that's more than one syntax simplificiation here, but it > shows how much David's improvements have improved accessibility. I was not responsible for symbolic/string color support (or whatever is involved here). > But, as I said before: Making everything seem perfectly simple (no #, > no ', no "") is bound to put the user in a situation sooner or later > where things are not so simple anymore, and we have to explain why > they need to use additional symbols in their specific case. But in any > case, I'm much more inclined to explain about string delimiters "" > than about #'. Which is one thing making the type-light approach of Lua nice for extension language design. Scheme already has too many types. But that ship has sailed... -- David Kastrup
Re: pygment regex question
Jean Abou Samra writes:
>> \version "2.23.10"
>>
>> \removeWithTag dyn \new Staff = upper {
>> \tag dyn <>\mf
>> \ottava -1
>> a4_boringly
>> }
>>
>> But of course there's always the danger of beginners tripping up on
>> this because they do not recognise the situations where #/'/"" are
>> still needed.
>
>
>
> FWIW, the last one
>
> a4_boringly
>
> is something I wouldn't do, since
>
> a_boringly
>
> does not work ("a_boringly" is interpreted as a pitch name).
Not really.
But I'd not use _boringly anyway since it seems counterintuitive that
_cis would not work.
> Personally, I tend to leave out # when possible for numbers,
> and also leave out #' for symbols when possible because it
> is not only shorter, but allows the syntax highlighting program
> to highlight them specially if they're built-ins, be it
> in Frescobaldi or in the documentation via Pygments.
> On the other hand, I usually use " marks (but not # when
> not required) around strings, because I might want to add
> spaces in them, and once again because it makes the syntax
> highlighting more useful.
Scheme has symbols and strings, and how to map LilyPond to either is
sometimes a tricky decision. In contrast, Lua has only interned
strings, so the mapping becomes a no-brainer. Sometimes not having a
choice can be helpful.
> For \new Staff = , I never settled my mind :-) It
> expects a string, but then one could argue that accepting
> a symbol here would more sense.
could be "cisis" while Staff couldn't.
--
David Kastrup
Re: PATCHES - Countdown to November 23
Aaron Hill writes:
> On 2022-11-21 9:26 pm, Werner LEMBERG wrote:
>>>> !1734 Resurrect banana commas - Werner Lemberg
>>>> https://gitlab.com/lilypond/lilypond/-/merge_requests/1734
>>> Heh, "banana". But seriously, many thanks for the quick fix,
>>> Werner!
>> :-) Someone on the list (or in a MR/bug issue) used this word for
>> the
>> shape, IIRC, and I found it catchy.
>
>
> \version "2.22.0"
>
> \layout {
> \override BreathingSign.color = #'(0.83 0.67 0.29)
> \override BreathingSign.text =
> \markup \lower #0.5 \scale #'(-1 . 1)
> \rotate #-30
> }
>
> { b'4 4 \breathe 2 }
>
>
> (Sadly, emoji shapes are not standardized, so the code above would not
> be portable.)
That's a rather long caesura. I remember once being in a theatre
performance with that kind of caesura. Could have been Hamlet or
something, and the various ingenuities of the director took so much time
that he felt it appropriate to cut out a lot of that pesky Shakespeare
text to compensate.
That spread out the entertainment value to a degree where I considered
my time better invested leaving in the intermission.
Spreading the payload thin does not work for me.
Now I've spread the payload of this reply rather thin. A long caesura.
--
David Kastrup
Re: Prefer luatex for documentation
Werner LEMBERG writes: >> I'd say that for a 80-100page document it's maybe somewhere between >> 50% and twice as slow. Still it's a several seconds build that >> becomes more several seconds. I'm not sure it crosses important >> workflow thresholds [1], it certainly didn't in my own use. > > The problem is the startup time of luatex. For processing our more > than 1000 small snippets that are embedded in the final documentation > (as PDF files), this sums up. Why would the snippets cause multiple startups of luatex? -- David Kastrup
Re: Prefer luatex for documentation
Luca Fascione writes: > On Mon, Nov 21, 2022 at 2:06 PM Werner LEMBERG wrote: > >> The thing is: Something might happen if I'm not available, for >> whatever reasons. It definitely *is* a high maintenance cost if a >> single developer is responsible... >> > > But that's true of any one feature: I build you a nice template library to > do in > and you find a bug while I'm . That can always happen, we know > this, we cope with it. > How's the TeX/texinfo build any different? LuaTeX is not in "bugfixes only" mode. The other TeX engines are, if even that. -- David Kastrup
Re: strut problem,Re: strut problem,Re: strut problem,Re: strut problem
Werner LEMBERG writes:
>>>>> Why is the vertical extent of the strut ignored?
>>>>
>>>> Because side positioning is primarily based on (vertical)
>>>> skylines, not extents.
>>>
>>> Thanks. What is the reasoning behind this? For me, this behaviour
>>> is unexpected.
>>
>> By the way, this is one reason why \strut is not such a great thing
>> in my opinion. I suppose that in LaTeX, {\strut abc} and {abc
>> \strut} (or whatever the exact syntax is) are equivalent. In
>> LilyPond, they can't be, since if you want \strut to factor into the
>> skylines, its placement will be visible in the shape of the skylines
>> (and consequently make a difference in the spacing).
>
> You are correct with your LaTeX observation. However, the longer I
> think about struts – even `\vspace` is nothing else than a vertical
> strut! – the more I believe that there is a conceptual problem in
> LilyPond: There is a 'typesetting mode' where vertical struts have an
> effect (like the problem originally reported in 'lilypond-user',
> starting with
> https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00237.html),
> and there are other modes without such an effect.
You did see the code I posted that would do what you asked for?
--
David Kastrup
Re: strut problem
Werner LEMBERG writes:
> Consider this input.
>
> ```
> \version "2.23.81"
>
> #(define-markup-command (strut layout props)
>()
>#:properties ((baseline-skip))
>(ly:make-stencil ""
> empty-interval
> (cons (* -0.3 baseline-skip)
> (* 0.7 baseline-skip
>
> {
> \override TextScript.show-horizontal-skylines = ##t
> e'4^\markup { "a" }
> e'4^\markup \concat { \strut "a" }
> }
> ```
>
> Why is the vertical extent of the strut ignored?
It isn't ignored. It's just not part of the outlines/skylines.
Try
\version "2.23.81"
#(define-markup-command (strut layout props)
()
#:properties ((baseline-skip))
(make-transparent-box-stencil
empty-interval
(cons (* -0.3 baseline-skip)
(* 0.7 baseline-skip
{
\override TextScript.show-horizontal-skylines = ##t
e'4^\markup { "a" }
e'4^\markup \concat { \strut "a" }
}
--
David Kastrup
Re: markup->string
Jean Abou Samra writes: > Le 15/11/2022 à 14:43, David Kastrup a écrit : >> If it's "mundane", why would the conversion result in a complex >> replacement? > > > > Have you looked at the replacement? > > It is > > (lambda* (m #:optional headers) > (if headers > (markup->string m #:props (headers-property-alist-chain headers)) > (markup->string m)) > > which is the only thing convert-ly can programmatically > replace markup->string with to make the change equivalent to > > (markup->string x) -> (markup->string x) [no change] > (markup->string x headers) -> (markup->string x #:props > (headers-property-alist-chain headers)) Conversion rules can look at the number of arguments and only revert to a generic replacement when the number of arguments cannot be determined (like when the arguments are too complex for the patterns, or markup-string is not used as a call but as a function). Even then, the generic call can be given a name like headers-markup->string or markup->string can get a #:rest argument that will get interpreted in the old manner when there are no optional arguments (in order to encourage only the new syntax but maintain backward compatibility) or generally (though this would further proliferation of the old syntax). > The "complexity" we are talking about is the length of the output of > convert-ly relative to the input. There is no complex logic at all. If you are talking about human-readable complexity, for the average user this is eyes-glaze-over material in most contexts (the average user does not even know lambda* and it is not a core Scheme construct). If you are talking about computer-readable complexity, lambda* is a huge beast. If you are talking about conceptual complexity, headers-property-alist-chain depends on internal data structure details for the conversion of headers to a property-alist-chain. Since the interface now does optional argument processing, there is no point in not having markup->string x #:headers headers at the very least in order to obviate the knowledge of internal processing at the call point. And this is the kind of conversion call that convert-ly should aim for. -- David Kastrup
Re: markup->string
Jean Abou Samra writes: > Le 15/11/2022 à 14:17, David Kastrup a écrit : >> Alternatively, providing something approaching the previous behavior >> under a different name, assuming that this functionality has at least >> some motivation or possibility to continue existing. > > > > It's not a behavior change, just a mundane calling convention > change that makes the function more flexible and consistent > with interpret-markup. No "functionality" is being removed. If it's "mundane", why would the conversion result in a complex replacement? -- David Kastrup
Re: markup->string
Jean Abou Samra writes: > Le 15/11/2022 à 00:56, Jean Abou Samra a écrit : >>> Nevertheless the insertion done by convert-ly is not nice, imho. As a >>> mere user I'd think some bug happened. >> In that case, NOT_SMART is the way to go (i.e., not changing > anything but just printing “Not smart enough to convert…”). > > > > https://gitlab.com/lilypond/lilypond/-/merge_requests/1732 Alternatively, providing something approaching the previous behavior under a different name, assuming that this functionality has at least some motivation or possibility to continue existing. -- David Kastrup
Re: procedure to check equality of list-elements
Thomas Morley writes: > Call me surprised. > The guile manual only gives code-examples comparing _two_ values with > eq? and friends. > I didn't know and didn't imagine it would work for more arguments as > you wrote above. The Guile manual may be somewhat fixated on the C interface which only takes two values. There are several Scheme operators that have some automated behavior for a variable number of operands. Other candidates that may be surprising are < <= > >= The C API is strictly two-operands, but from Scheme you can throw a variable number at them. -- David Kastrup
Re: Sphinx
Jean Abou Samra writes: > Le 24/10/2022 à 20:00, David Kastrup a écrit : >> Jean Abou Samra writes: >> >>> Personally, my dream would be to switch to a different documentation >>> tool entirely, like Sphinx, which supports HTML, LaTeX and Texinfo >>> output, with extensive HTML customization possibilities, and would >>> not need so much build system fuss (lilypond-book etc.), >> How do you imagine the LilyPond images to arrive in the documentation >> without the "build system fuss"? The bulk of the lilypond-book fuss is >> about efficiently compiling ten thousands of small LilyPond fragments >> without recompiling duplicates appearing in multiple translations. > > > > Sphinx supports arbitrary roles and directives, which are similar to > Texinfo commands and environments. Texinfo has macros, but they can't > capture the literal input without Texinfo macro expansion (@verbatim is > special and you could not redefine it as a custom macro), and they don't > have a programming language available to them. In Sphinx, this is just > a matter of reading the LilyPond input in a Python extension and inserting > the output at that point, as is already done in > > https://pypi.org/project/sphinxcontrib-lilypond/ > or the alternative > https://github.com/sphinx-notes/lilypond > > Which means that there is no longer a need to parse and pre-process > the source ourselves with regexes in lilypond-book, with the associated > build system fuss. Everything remains in the .rst or .md source files. > There is a built-in mechanism for serialisation of the build environment > and documentation data structures, using the Python pickle module, > so I think you can add the images to that in order to cache them and > worry less about how to store the cache on the disk. (But I'm not > an expert and I didn't study the extensions linked above that > extensively.) > > Plus, dependency management across multiple files is built-in, > so you don't need to define the build process in Makefiles yourself. > (Extensions can hook into that.) I think you'd be seriously seriously surprised at the difference in efficiency when _not_ deduplicating snippets and rolling hundreds of them into a single LilyPond call. The basics of lilypond-book where you can think of how to map them to Spinx are not the ones responsible for doing the really heavy lifting. -- David Kastrup
Re: Is a texi2any upgrade still wanted, and what would it take?
Jean Abou Samra writes: > Personally, my dream would be to switch to a different documentation > tool entirely, like Sphinx, which supports HTML, LaTeX and Texinfo > output, with extensive HTML customization possibilities, and would > not need so much build system fuss (lilypond-book etc.), How do you imagine the LilyPond images to arrive in the documentation without the "build system fuss"? The bulk of the lilypond-book fuss is about efficiently compiling ten thousands of small LilyPond fragments without recompiling duplicates appearing in multiple translations. > and supports internationalization via po files on top of that. But > that is going to be controversial and the amount of work is magnitudes > larger :) The problem is that an advertised feature set is comparatively useless for imagining the amount of work before arriving at a satisfactorily smoothly operating and efficient solution. It is not uncommon to have a proof of concept running within less than a week, with a satisfactory efficient solution adding years of development. -- David Kastrup
Re: Potential LSR licensing violations
Wols Lists writes: > On 20/10/2022 11:34, Jean Abou Samra wrote: >> The LSR distributes a piece of GPLed code under GPL-incompatible >> terms, which is illegal, period. I don't think I am imagining >> a problem here. Being an LSR-editor now, I don't like having >> my responsibility involved in copyright infringement. > > And as the linux kernel found out, David is wrong saying that only the > copyright holder can take enforcement action. > > German law allows people to take enforcement action without the > copyright holder's knowledge or consent. And somebody took active > advantage of that. Come again? Particularly in Germany, the bulk of Linux kernel enforcement actions have been taken by Harald Welte on behalf of his ipfilter/netfilter code in particular. What other examples do you have in mind? -- David Kastrup
Re: Potential LSR licensing violations
Werner LEMBERG writes: >> The LSR is advertised as being released under the public domain. >> [...] >> >> The following exceptions apply: >> >> * It does not apply to input files (contained in the directory >> tree Documentation/snippets/); these are in the public domain. >> [...] >> >> So far, so good. However, take this snippet: >> >> https://lsr.di.unimi.it/LSR/Item?id=102 >> >> It begins with 300 lines of code that used to be in the LilyPond >> repository, released under the GPL, before they were considered >> legacy and moved to a snippet. I am pretty sure this violates the >> GPL. 300 lines looks too much for fair use law to apply, doesn't >> it? > > Assuming that it is ok with , we can put his > outdated, GPLed code into the public domain. "Ask the author" is the correct solution here. > I guess the opposite happens, too: there are probably some snippets > that have been incorporated into LilyPond code over the years. Such > code must be sufficiently rewritten so that the GPL can and be applied. That is nonsensical. PD code can be incorporated as part of a GPLed code base. When push comes to shove, the GPL relies on copyright as the legal means to enforce compliance, and only the copyright holder of some code can sue for compliance. LilyPond is not a copyright-assigned project, so enforcement will always be on a hit-and-miss basis, relying on the author of specific passages to have an interest in pursuing legal measures. > This sounds like a good temporary solution. However, I suggest that > we either get permission by the author to change the license,[*] or > the code gets rewritten eventually so that the 'correct' license can > be applied (again). We don't need permission of the author to "change the license" from PD. We are free to license in whatever manner we like. But the only one who can enforce any license is the original author, and when they release something as PD, chances are that they are very much not interested in pursuing legal steps on our behalf. And we would have to prove that the respective copy was taken from our licensed code base rather than the original distribution of PD code, and that would be tricky without significant modification. And the copyright holder could hardly claim real damages for PD code, so one would have to fall back on statutory damages. Essentially, this is going to be a disaster for enforcement purposes, but permission by the original author is not going to make any difference. For the other direction (GPLed to PD), yes, we should check back with the author. > [*] Here comes the benefit of transferring the copyright to the FSF, > which can handle such things without having to ask the original > author AFAIK. LilyPond, however, inspite of being a GNU project, > doesn't ask contributors for such a copyright transfer. LilyPond is not considered a strategic part of GNU, one where the FSF would consider taking legal measures for enforcing the licensing. -- David Kastrup
Re: source file ... .scm newer than compiled ... .go file
Federico Bruni writes: > Hi all > > I think I've already seen discussions about this. > Can you please remind how to work around this error? > > The 2.23.14 lilypond version built and bundled in Frescobaldi flatpak > hangs forever and cannot compile any simple file, probably because > it's checking this stuff. > > [ org.frescobaldi.Frescobaldi test]$ /app/dev/bin/lilypond test.ly > GNU LilyPond 2.23.14 (running Guile 2.2) > ;;; note: source file /app/share/guile/2.2/ice-9/psyntax-pp.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/ice-9/psyntax-pp.go > ;;; note: source file /app/share/guile/2.2/srfi/srfi-1.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-1.go > ;;; note: source file /app/share/guile/2.2/srfi/srfi-9.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-9.go > ;;; note: source file /app/share/guile/2.2/srfi/srfi-9/gnu.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-9/gnu.go > ;;; note: source file /app/share/guile/2.2/srfi/srfi-11.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-11.go > ;;; note: source file /app/share/guile/2.2/rnrs/bytevectors.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/rnrs/bytevectors.go > ;;; note: source file /app/share/guile/2.2/system/base/compile.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/system/base/compile.go > > [...] Just go to bed and hope that the file is through in the morning. Hopefully this is a one-time thing. -- David Kastrup
Re: Administration of mailing lists
David Kastrup writes: > Jean Abou Samra writes: > >> Thus I wrote to the general GNU list server admins and proposed >> to step up for being an admin on these lists, just like I am >> already an admin on lilypond-user-fr (the French-speaking equivalent >> of lilypond-user, in case you didn't know). >> >> Is that OK with everyone? > > I am still serving as one admin on other lists and there's never been > anything akin to "moderation" involved: you junk the spam and let the > other stuff through, usually with "mark this mail address as ok" to cut > down on future work. > > The "complex" decisions consists mostly of returning some from multiple > pending attempts to post the same content and telling the poster that > one did so and why. > > But that's actually rare, and if it's not excessive, it might be better > not to give the impression of micromanagement and just let things > through. > > That's the impression I also get from current LilyPond list moderators > (thanks David!): you don't really get the impression that there is > anybody doing anything except that the amount of visible spam is > essentially zero and that doesn't happen by itself. I see that I failed to answer the question: I find that "list moderator" on these lists is not as much a position of power as a light sideload of work and responsibility. As such, I'd have no qualms with any volunteer taking it on except for those with an obvious agenda, like wanting to shape the discourse. And I really don't have that expectation from any contributor here. So it's a "sure, go ahead" from me. -- David Kastrup
Re: Administration of mailing lists
Jean Abou Samra writes: > Thus I wrote to the general GNU list server admins and proposed > to step up for being an admin on these lists, just like I am > already an admin on lilypond-user-fr (the French-speaking equivalent > of lilypond-user, in case you didn't know). > > Is that OK with everyone? I am still serving as one admin on other lists and there's never been anything akin to "moderation" involved: you junk the spam and let the other stuff through, usually with "mark this mail address as ok" to cut down on future work. The "complex" decisions consists mostly of returning some from multiple pending attempts to post the same content and telling the poster that one did so and why. But that's actually rare, and if it's not excessive, it might be better not to give the impression of micromanagement and just let things through. That's the impression I also get from current LilyPond list moderators (thanks David!): you don't really get the impression that there is anybody doing anything except that the amount of visible spam is essentially zero and that doesn't happen by itself. -- David Kastrup
Re: To branch or not to branch
Werner LEMBERG writes: >>> I think we should branch now. What do others think? >> >> Needless to say that I agree, but as you witnessed nobody else >> bothers to reply. > > Sorry, I got the impression that we already made a decision to do so. > For the record, I also agree. > >> Discussions on MRs opened during the weekend also showed me that >> we're not even on one page for what should still go in before >> branching, > > As mentioned, I leave this decision to you: Please define a commit > that you want to use for branching. > >> and now it seems you went back to feature development. > > Why is this a problem? Isn't the idea that a release is based on a > 'stable' branch, and that normal development continues on 'master'? For that idea to apply, you first need a stable branch. -- David Kastrup
Re: Markup command \simple
Jean Abou Samra writes: > Le 02/10/2022 à 15:05, David Kastrup a écrit : >> If the function itself isn't used as a placeholder. > > I haven't found any such use. > > I've opened https://gitlab.com/lilypond/lilypond/-/merge_requests/1650 git grep simple-markup returns a whole slew of results, including in `Documentation/*/extending/programming-interface.itely` where the procedure `simple-markup` is getting embedded as a value into a markup expression. A single-step procedure of invalidating documented coding practice instead of a slower deprecation process seems rather impolite. It doesn't help that translations of the docs tend to trail by varying degrees. -- David Kastrup
Re: Markup command \simple
Jean Abou Samra writes: > The markup command \simple is defined as > > > (define-markup-command (simple layout props str) > (string?) > #:category font > "[docstring...]" > (interpret-markup layout props str)) > > > > That sounds like \simple "x" can be replaced with just > "x". I suppose \simple is an artifact of history and > can be removed. Right? If the function itself isn't used as a placeholder. -- David Kastrup
Re: using '[skip ci]'?
Jean Abou Samra writes: > Le 27/09/2022 à 17:39, Werner LEMBERG a écrit : >> I've just submitted >> >>https://gitlab.com/lilypond/lilypond/-/merge_requests/1643 >> >> to improve `makelsr.pl`. Running CI for this MR is a waste of >> resources because this script is not part of the normal build and test >> cycle – we could add `[skip ci]` to avoid that. Shall I do that for >> this commit and similar ones in the future? > > > > Can you make it so that it'll skip CI in the initial MR upload > and in subsequent iterations, but still spawn a pipeline when > merging? > > As long as we aren't short on CI resources, I prefer keeping > the rule that a change is only merged to master after a successful > pipeline, because it's too easy to think "this is trivial" when > it does contain a mistake, and one of the great things about > CI running in the background is that you don't need to make > this decision anymore. One example is a "trivial" merge/rebase of a commit that removes/changes a feature and another commit that introduces a new use of the old feature. The respective changes may well occur in a completely different set of files. -- David Kastrup
Re: Another case of “temporary staff not ending”
Jean Abou Samra writes:
> Le 23/09/2022 à 14:02, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> I believe this exhibits a bug:
>>>
>>> \version "2.23.14"
>>>
>>> {
>>> \new Staff { c'1 }
>>> \new Devnull { s1 }
>>> }
>>>
>>>
>>> I would have expected the staff to stop after one measure.
>>>
>>> Does anyone see a reason for this behavior being correct,
>>> or am I right that it is another bug similar to the “temporary
>>> staff not ending” bug fixed by Dan in 74af697126?
>> It is documented behavior. "Keeping contexts alive" starts with it:
>>
>> [...]
>>
>> You can either enclose your Staff in << ... >> or you can end its visual
>> impact using \stopStaff .
>
>
>
> Thanks, that is helpful. I don't fully understand the quoted
> documentation passage to be honest, but at least I know how to
> deal with it.
Well, in
\new Staff { c4'( << g' \\ e' >> c') }
you would not want the Voice context where the slur starts to be
terminated because it is a) implicit b) dormant from timestep 2/4 up to
4/4 .
So it is being kept alive in spite of being implicit and dormant.
--
David Kastrup
