Re: [PATCH] Spelling fixes
Stefan, On 21 January 2012 07:23, Stefan Weil s...@weilnetz.de wrote: Am 21.01.2012 00:10, schrieb Pavel Roskin: On Fri, 20 Jan 2012 17:58:47 +0100 Stefan Weils...@weilnetz.de wrote: Hi, tre my last two patches were sent inline (with git send-email), but I just learned that they should have been appended instead. So here are both patches again. Both fix some spelling issues. By the way, somebody please run codespell on the Lilypond sources: http://git.profusion.mobi/cgit.cgi/lucas/codespell/ Hi Pavel, that's what I did. I started with three patches, but as soon as I know that they are accepted, more will follow. Your two patches have been opened as http://code.google.com/p/lilypond/issues/detail?id=2237 http://code.google.com/p/lilypond/issues/detail?id=2238 The code is uploaded for review and comment to http://codereview.appspot.com/5562043 and http://codereview.appspot.com/5561053 I 'own' these issues but if you get reqests for changes you can just upload the changes to 'codereview' yourself (if you know how to do that) or you can attach any corrected patches to the code.google issues and I can re-submit them. The process is documented here: http://lilypond.org/doc/v2.15/Documentation/contributor/summary-for-experienced-developers (start at 'reviews' in this case) -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Spelling fixes in comments and documentation (issue 5562043)
LGTM, but I can't speak to the translation stuff. Depending on what Francisco says (or has said), you might want to split this into two separate patches: one for non-translation stuff, and one for translations. http://codereview.appspot.com/5562043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix spelling in input/regression/*.ly (issue 5561053)
LGTM, please push directly to staging. As a general rule, any spelling fixes like this can be pushed directly (as long as they don't involve translations). http://codereview.appspot.com/5561053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix spelling in input/regression/*.ly (issue 5561053)
Reviewers: Graham Percival,
Message:
Thanks
author Stefan Weil s...@weilnetz.de
Thu, 19 Jan 2012 21:39:31 + (22:39 +0100)
committer
James Lowe pkx1...@gmail.com
Sat, 21 Jan 2012 13:27:19 + (13:27 +)
commit cf9cf627cf5f7d6b82db3cfb4b1829c7ef4508ae
James
Description:
Fix spelling in input/regression/*.ly
accomodate - accommodate
adn - and
eigth - eighth
excercise - exercise
inbetween - between
occurence - occurrence
refered - referred
supressed - suppressed
Signed-off-by: Stefan Weil s...@weilnetz.de
Please review this at http://codereview.appspot.com/5561053/
Affected files:
M input/regression/backend-excercise.ly
M input/regression/markup-scheme.ly
M input/regression/mozart-hrn3-rondo.ily
M input/regression/multi-measure-rest-text.ly
M input/regression/nested-fill-lines.ly
M input/regression/page-label.ly
M input/regression/rest-polyphonic-2.ly
M input/regression/spacing-short-notes.ly
M input/regression/tie-single.ly
Index: input/regression/backend-excercise.ly
diff --git a/input/regression/backend-excercise.ly
b/input/regression/backend-excercise.ly
index
06120020d9ba0aa5a5193f281b517bd060b18063..ba4af1182a69b668e23e751bd061c7371ebe6bee
100644
--- a/input/regression/backend-excercise.ly
+++ b/input/regression/backend-excercise.ly
@@ -1,5 +1,5 @@
\header {
- texidoc = Excercise all output functions
+ texidoc = Exercise all output functions
}
\version 2.14.0
Index: input/regression/markup-scheme.ly
diff --git a/input/regression/markup-scheme.ly
b/input/regression/markup-scheme.ly
index
fa7168624436bf731d5d7edca49c7a55f647eb4e..5dea41d01c20c06d2816c1d30be9955675ae8986
100644
--- a/input/regression/markup-scheme.ly
+++ b/input/regression/markup-scheme.ly
@@ -10,7 +10,7 @@
%{
-For maintenance reasons, we don't excercise the entire markup command set.
+For maintenance reasons, we don't exercise the entire markup command set.
%}
Index: input/regression/mozart-hrn3-rondo.ily
diff --git a/input/regression/mozart-hrn3-rondo.ily
b/input/regression/mozart-hrn3-rondo.ily
index
aeeb211fee862e0e90bd7dbffe6e72311ae651c6..8e45355a8bf5cabfde700b1deaef13deef0a35e6
100644
--- a/input/regression/mozart-hrn3-rondo.ily
+++ b/input/regression/mozart-hrn3-rondo.ily
@@ -130,7 +130,7 @@ rondo = \relative c' {
fis[ g gis]
a[ bes b]\!
- %% EB does the slur in the Rondo differently from the 1st adn 2nd time.
+ %% EB does the slur in the Rondo differently from the 1st and 2nd time.
%% why. Should check with MS.
\rondotheme
Index: input/regression/multi-measure-rest-text.ly
diff --git a/input/regression/multi-measure-rest-text.ly
b/input/regression/multi-measure-rest-text.ly
index
2e2d4324daa366e141397bb3e352c6d2bb8b4edb..73e1218813a98bceb9acc6d07162b5320d6eb5bb
100644
--- a/input/regression/multi-measure-rest-text.ly
+++ b/input/regression/multi-measure-rest-text.ly
@@ -6,7 +6,7 @@
Texts may be added to the multi-measure rests.
By setting the appropriate @code{spacing-procedure}, we can make
-measures stretch to accomodate wide texts.
+measures stretch to accommodate wide texts.
Index: input/regression/nested-fill-lines.ly
diff --git a/input/regression/nested-fill-lines.ly
b/input/regression/nested-fill-lines.ly
index
f4236ea699fbc369fd11f5007de897d40ba2daa3..011cc904edb693385d874a1a32dd3d20d150192a
100644
--- a/input/regression/nested-fill-lines.ly
+++ b/input/regression/nested-fill-lines.ly
@@ -4,7 +4,7 @@
{
texidoc =
-Nested fill-lines should work properly. In this example, both occurences
+Nested fill-lines should work properly. In this example, both occurrences
of FOO should be centered.
Index: input/regression/page-label.ly
diff --git a/input/regression/page-label.ly b/input/regression/page-label.ly
index
143d685a781bb6cdbd931934cd18b95e0ec00f3e..a36964079c464fca6b8f1ea919a67fa4d7252e18
100644
--- a/input/regression/page-label.ly
+++ b/input/regression/page-label.ly
@@ -2,7 +2,7 @@
\header {
texidoc = Page labels may be placed inside music or at top-level,
-and refered to in markups.
+and referred to in markups.
}
#(set-default-paper-size a6)
Index: input/regression/rest-polyphonic-2.ly
diff --git a/input/regression/rest-polyphonic-2.ly
b/input/regression/rest-polyphonic-2.ly
index
23af88ff41b725d51e5b617d1ef12ae4ab317883..e009dcf9460ee06b252a81ccd5d5ac28333f58da
100644
--- a/input/regression/rest-polyphonic-2.ly
+++ b/input/regression/rest-polyphonic-2.ly
@@ -3,7 +3,7 @@
texidoc = Rests avoid notes. Each rest is moved in the direction
of the stems in its voice. Rests may overlap other rests in voices
with the same stem direction, in which case a warning is given, but
-is supressed if the rest has a pitch.
+is suppressed if the rest has a pitch.
}
Index: input/regression/spacing-short-notes.ly
diff --git a/input/regression/spacing-short-notes.ly
b/input/regression/spacing-short-notes.ly
index
Re: [PATCH] Spelling fixes
Stefan, On 21 January 2012 07:23, Stefan Weil s...@weilnetz.de wrote: Am 21.01.2012 00:10, schrieb Pavel Roskin: On Fri, 20 Jan 2012 17:58:47 +0100 Stefan Weils...@weilnetz.de wrote: Hi, tre my last two patches were sent inline (with git send-email), but I just learned that they should have been appended instead. So here are both patches again. Both fix some spelling issues. By the way, somebody please run codespell on the Lilypond sources: http://git.profusion.mobi/cgit.cgi/lucas/codespell/ Hi Pavel, that's what I did. I started with three patches, but as soon as I know that they are accepted, more will follow. http://code.google.com/p/lilypond/issues/detail?id=2237 (the texidoc corrections) Has been approved and pushed to our staging branch. It will be merged in to the master branch soon. Thanks for the patch. The other I am leaving the other for a more thorough review -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.16 release candidate 3 imminent
All release-Critical issues have patches which are either on a current countdown, have been on a previous countdown, or don't make sense to be on a countdown at all and will thus be pushed in a few hours. Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. There seems to be a desire to wait for 2 weeks instead of 1 week, so that's what I'll announce? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Graham Percival gra...@percival-music.ca writes: All release-Critical issues have patches which are either on a current countdown, have been on a previous countdown, or don't make sense to be on a countdown at all and will thus be pushed in a few hours. Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. There seems to be a desire to wait for 2 weeks instead of 1 week, so that's what I'll announce? I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change that should not occur during a stable release series, and it paves the way for making the music function work continue smoothly enough that backporting further enhancements into a stable 2.16 series would be feasible. For similar reasons, it needs to be in a release candidate before release. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change that should not occur during a stable release series, and it paves the way for making the music function work continue smoothly enough that backporting further enhancements into a stable 2.16 series would be feasible. IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. But I'm not going to kick up a fuss about it. I've marked 2240 as Critical. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change that should not occur during a stable release series, and it paves the way for making the music function work continue smoothly enough that backporting further enhancements into a stable 2.16 series would be feasible. IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. Earlier, we expressed a need to have stable mean *stable*, i.e. no syntax changes necessary for some period of time. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. If we still want to have that policy, I believe that subversion numbers are cheap, but stable version numbers are expensive. I think we'd be best to try to get this into 2.16. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Carl Sorensen c_sorensen at byu.edu writes: On 1/21/12 9:45 AM, Graham Percival graham at percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change IMO, significant API changes should not happen right before a release. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. The implication is that issue 2240 changes the interface (but not the input syntax because there is no convert-ly rule) in a way enables improvements user code (presumably Scheme) that we will want so badly that we cannot wait for 2.18. Does anybody know what 2240 improves ? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sat, Jan 21, 2012 at 05:02:32PM +, Carl Sorensen wrote: On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote: IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. Earlier, we expressed a need to have stable mean *stable*, i.e. no syntax changes necessary for some period of time. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. I disagree. I think that stable should mean *stable*, i.e. no syntax changes necessary for *that series of major version numbers*. I reject the notion that we shouldn't release a new stable version after a few months if there's no regressions in the new version. Other tools can advertise works with lilypond versions 2.14.0 and 2.17.23 if necessary. Look, this reminds me of some essay I skimmed recently by an economist who was worried that if the US paid off its debt in full, the bond market would collapse and that would have negative consequences for the world economy. I see no reason to worry about what might happen if we have too many stable releases unless that actually becomes a possibility. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 10:24 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:02:32PM +, Carl Sorensen wrote: On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote: IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. Earlier, we expressed a need to have stable mean *stable*, i.e. no syntax changes necessary for some period of time. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. I disagree. I think that stable should mean *stable*, i.e. no syntax changes necessary for *that series of major version numbers*. I reject the notion that we shouldn't release a new stable version after a few months if there's no regressions in the new version. Other tools can advertise works with lilypond versions 2.14.0 and 2.17.23 if necessary. OK, I'm fine with that. Look, this reminds me of some essay I skimmed recently by an economist who was worried that if the US paid off its debt in full, the bond market would collapse and that would have negative consequences for the world economy. I see no reason to worry about what might happen if we have too many stable releases unless that actually becomes a possibility. Well, you were the one who mentioned having 2.16 in two weeks and 2.18 in March. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 21, 2012, at 6:14 PM, Keith OHara wrote: Carl Sorensen c_sorensen at byu.edu writes: On 1/21/12 9:45 AM, Graham Percival graham at percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change IMO, significant API changes should not happen right before a release. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. The implication is that issue 2240 changes the interface (but not the input syntax because there is no convert-ly rule) in a way enables improvements user code (presumably Scheme) that we will want so badly that we cannot wait for 2.18. Does anybody know what 2240 improves ? I was asking myself a similar question lately now that I've gotten deeper into the non-parser-related aspects of 2240. After playing around with iterators and such, I'm convinced that all the articulation stuff can be written to be slicker independent of any changes to the parser. Meaning that, without any changes to the representation of event-chords, we could get rid of the script engraver and fingering engraver and just keep the new fingering engraver, doing all necessary massaging at the iterator level. My question is this: what is the basic advantage of having rhythmic events not wrapped in event chords? I understand that it can be used to wedge a distinction between c and c, but how is this distinction useful? Especially given the perspective David addressed earlier that part of LilyPond's code base getting better will be it getting more uniform and boring, how is this move away from uniformity (meaning creating two channels for of handling rhythmic events) beneficial? I think the question boils down to: is there an inherent difference between c and c and, if so, what is it and why is it meaningful? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Carl Sorensen c_soren...@byu.edu writes: On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change that should not occur during a stable release series, and it paves the way for making the music function work continue smoothly enough that backporting further enhancements into a stable 2.16 series would be feasible. IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. Earlier, we expressed a need to have stable mean *stable*, i.e. no syntax changes necessary for some period of time. Strictly speaking, this is not a syntax change. If you write LilyPond, no Scheme, the output should be the same. I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. I certainly would have been more than happy to have that inconsistency abolished. The way to do that would be to _stop_ the tabstaff engravers from listening to string events and instead have them look in the articulations for them. If the string events become unlistened to, the rhythmic music iterator will leave them in the articulations. Alternatively, make a listener/engraver for per-chord string indications (which, like fingerings, can be typeset with less need to keep them close to the notehead). We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. I don't think they will be affected unless they do Scheme juggling. The one thing that _will_ be affected is XML output. If we still want to have that policy, I believe that subversion numbers are cheap, but stable version numbers are expensive. I think we'd be best to try to get this into 2.16. And it definitely needs to be in a prerelease for that. If the prerelease makes it obvious that this won't work, it will have to be backed out, something which I would find rather unhappy (since it would mean that parts of the music function syntax changes that belong together logically would be spread across two stable releases). If you take a look at the stats, you'll find that apart from the implementation of the rhythmic music iterator (which is rather boilerplate), most of the changes are _reductions_ in size. In particular the parser. It will also make the programmer's guide simpler. I am starting on that now. commit 0e9b4d86388b83bfbd217b0d77d6759f2ef81cef Author: David Kastrup d...@gnu.org Date: Thu Dec 1 18:32:15 2011 +0100 Don't wrap EventChord around rhythmic events outside of music lists. 9 files changed, 212 insertions(+), 222 deletions(-) commit 10c40a07236febc9279a5faadbcdc15dc3bb1c82 Author: David Kastrup d...@gnu.org Date: Sat Jan 21 14:24:01 2012 +0100 Let \relative run through articulations for the sake of pitched trills 1 files changed, 1 insertions(+), 0 deletions(-) commit 84144db390bac765fcd0e80403b548ca4e90a59f Author: David Kastrup d...@gnu.org Date: Fri Jan 20 21:38:09 2012 +0100 Define a post-event music type and let post-event? and ly:event? use it. 5 files changed, 37 insertions(+), 68 deletions(-) commit c4760f3c4a5ec896231e285363c8f10e59a07c53 Author: David Kastrup d...@gnu.org Date: Thu Jan 19 18:58:38 2012 +0100 Fixes to Rhythmic-music-iterator 4 files changed, 38 insertions(+), 9 deletions(-) commit efb9bc79e3714ce06ef48b148850de29625ddb18 Author: Mike Solomon m...@apollinemike.com Date: Wed Jan 18 20:12:13 2012 +0100 Implements rhythmic-music-iterator 3 files changed, 109 insertions(+), 0 deletions(-) -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 10:37 AM, David Kastrup d...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes: On Jan 21, 2012, at 6:14 PM, Keith OHara wrote: Carl Sorensen c_sorensen at byu.edu writes: On 1/21/12 9:45 AM, Graham Percival graham at percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change IMO, significant API changes should not happen right before a release. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. The implication is that issue 2240 changes the interface (but not the input syntax because there is no convert-ly rule) in a way enables improvements user code (presumably Scheme) that we will want so badly that we cannot wait for 2.18. Does anybody know what 2240 improves ? I was asking myself a similar question lately now that I've gotten deeper into the non-parser-related aspects of 2240. After playing around with iterators and such, I'm convinced that all the articulation stuff can be written to be slicker independent of any changes to the parser. Meaning that, without any changes to the representation of event-chords, we could get rid of the script engraver and fingering engraver and just keep the new fingering engraver, doing all necessary massaging at the iterator level. That is a backend aspect. 2240 is not concerned with improving the backend: its changes to the backend are just designed to keep LilyPond produce the same graphical output given the same textual input. The advantage is in a much more straightforward relation of input to music expressions. That makes experimenting with and programming LilyPond more simple. One example from the notation manual: For the `\tweak' command to work, it must remain immediately adjacent to the object to which it is to apply after the input file has been converted to a music stream. At times, LilyPond may insert additional items into the music stream during the parsing process. For example, when a note that is not explicitly part of a chord will be placed in a chord by LilyPond, so notes to be modified with `\tweak' must be placed inside a chord construct: \tweak #'color #red c4 \tweak #'color #red c4 Guess what: both work just the same now. \tweak is a music function. Music functions inside of chords were special: they got chord constituents as arguments and were expected to produce them again, as opposed to normal music functions that received notes only wrapped in EventChord. If you were serious about making your music functions maximally useful, you needed to check what you got and behave accordingly. Now music functions can get _multiple_ music arguments. Will only the last be chord constituents when we have a chord music function? What if optional arguments are in between? Actual the optional argument scanning was so complex that it was only implemented for main music functions, not for chord constituent music functions. Because chord constituents are not artificially wrapped in EventChord unless they are actually placed in a chord, the difference is _gone_. _All_ music functions will work predictably inside of chords like outside. They don't see different input. They don't need to produce different output (of course, if they produce something inside of a ... chord that has no place inside of such a chord, LilyPond will complain). If you wrote note^postevent previously, the postevent ended up in articulations of the NoteEvent when written inside of a chord, or as an EventChord companion when not written in a chord. Now it ends up in articulations, period. My question is this: what is the basic advantage of having rhythmic events not wrapped in event chords? I understand that it can be used to wedge a distinction between c and c, but how is this distinction useful? URL:http://code.google.com/p/lilypond/issues/detail?id=1110#c26 Especially given the perspective David addressed earlier that part of LilyPond's code base getting better will be it getting more uniform and boring, how is this move away from uniformity (meaning creating two channels for of handling rhythmic events) beneficial? I think the question boils down to: is there an inherent difference between c and c and, if so, what is it and why is it meaningful? The problem that I have been tackling is more: is there an inherent difference between c-. and c-. and, if not so, why the heck do they look utterly different in the music expression depending on whether inside of or outside? Why does \tweak c require chord brackets to work? Why does \displaySchemeMusic produce oodles of layers for simple input? Issue 2240 makes the relation between input and resulting music expressions much more straightforward. And the everything-is-an EventChord mantra gave you a false sense of
Re: Implements DOM-id property for grobs. (issue 5504106)
Hi Mike, i apologize for the delay; i focused on other things that seemed more urgent to me. On 2012/01/11 12:27:10, mike_apollinemike.com wrote: [explanation of the patch] I'm not sure how/where to include this info in the source: if you can think of a good way to phrase it that would make sense to other people, I'd be happy to include it in the patch. I'm thinking about it (as a matter of fact, the new docstring looks nice!), but i need to understand your code better. Below are my questions. http://codereview.appspot.com/5504106/diff/11013/lily/grob.cc File lily/grob.cc (right): http://codereview.appspot.com/5504106/diff/11013/lily/grob.cc#newcode128 lily/grob.cc:128: retval = *m; so retval is the current stencil, but only when it's not empty? http://codereview.appspot.com/5504106/diff/11013/lily/grob.cc#newcode175 lily/grob.cc:175: if (scm_is_string (id)) I understand that we're doing something if the grob already has an id set. http://codereview.appspot.com/5504106/diff/11013/lily/grob.cc#newcode177 lily/grob.cc:177: SCM expr = scm_list_3 (ly_symbol2scm (id), isn't 'id' a scheme-thingy already? I mean, in line 174, it is declared as SCM, so why convert it with ly_symbol2scm? http://codereview.appspot.com/5504106/diff/11013/lily/grob.cc#newcode178 lily/grob.cc:178: id, why store id two times? http://codereview.appspot.com/5504106/diff/11013/lily/grob.cc#newcode179 lily/grob.cc:179: retval.expr ()); do i understand correcly that retval stands for return value and is some kind of an object? http://codereview.appspot.com/5504106/diff/11013/lily/grob.cc#newcode181 lily/grob.cc:181: retval = Stencil (retval.extent_box (), expr); Do we overwrite the retval that was set earlier (in other if's)? Why? http://codereview.appspot.com/5504106/diff/11013/lily/stencil-interpret.cc File lily/stencil-interpret.cc (right): http://codereview.appspot.com/5504106/diff/11013/lily/stencil-interpret.cc#newcode81 lily/stencil-interpret.cc:81: (*func) (func_arg, scm_list_2 (ly_symbol2scm (start-enclosing-id-node), id)); this line is longer than 80 chars, do we care about it? http://codereview.appspot.com/5504106/diff/11013/lily/stencil-interpret.cc#newcode82 lily/stencil-interpret.cc:82: interpret_stencil_expression (scm_caddr (expr), func, func_arg, o); i understand that we extract actual stencil here and interpret it again, but what these func's do? http://codereview.appspot.com/5504106/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Carl Sorensen c_soren...@byu.edu writes: On 1/21/12 10:37 AM, David Kastrup d...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. If nobody listens to string number events, they will stay articulations except when placed explicitly on chords like c\3 and then you deserve what you don't get. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. That would be the case. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 11:16 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 1/21/12 10:37 AM, David Kastrup d...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. If nobody listens to string number events, they will stay articulations except when placed explicitly on chords like c\3 and then you deserve what you don't get. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. That would be the case. Great! I'll make tabstaff engraver stop listening to string number events once your patch is pushed. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
Hi Julien, could you please explain to me how your patch fixes this issue? I've read it but don't understand why it works :( thanks, Janek http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
I believe the problem had to do with filename extensions; as such, I think the following three places constitute the actual fix for . But he also cleaned up a few other little bits, which seems sensible and ok since it's a pretty small patch. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (right): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode336 python/book_snippets.py:336: self.ext = '.ly' this http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode662 python/book_snippets.py:662: result.append (base + self.ext) this http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode849 python/book_snippets.py:849: self.ext = os.path.splitext (os.path.basename (self.filename))[1] this http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Am 21.01.2012 18:44, schrieb Carl Sorensen: On 1/21/12 10:37 AM, David Kastrupd...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g \3\2\1 once these changes are implemented? The former displays circled string numbers in a normal staff, whereas the latter doesn't. Tablature staffs are identical, of course. Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 21, 2012, at 7:12 PM, David Kastrup wrote: If you wrote note^postevent previously, the postevent ended up in articulations of the NoteEvent when written inside of a chord, or as an EventChord companion when not written in a chord. Now it ends up in articulations, period. I think it this is good - this is what will help scrap the fingering and script engraver. It seems like this is a separate problem from wrapping notes in event chords or not: if all articulations are in an articulations list, then they can all go to the new fingering engraver. My question is this: what is the basic advantage of having rhythmic events not wrapped in event chords? I understand that it can be used to wedge a distinction between c and c, but how is this distinction useful? URL:http://code.google.com/p/lilypond/issues/detail?id=1110#c26 Why couldn't this be solved on the iterator level? The problem that I have been tackling is more: is there an inherent difference between c-. and c-. and, if not so, why the heck do they look utterly different in the music expression depending on whether inside of or outside? I absolutely agree that everything should be in an articulations list, but I think this can be done while preserving event chords. It just means that EventChords will no longer contain articulation events and that all articulation events will be pulled out of NoteEvents or RestEvents and broadcast at the iterator level. And the everything-is-an EventChord mantra gave you a false sense of security: you thought if stuff worked with single notes, chords would be covered as they are the same. Poppycock. When c-. works, that does not mean that c-. will also work. Because suddenly it becomes quite different even though both are in a chord. I'm not quite getting what you're saying here... With the current setup, the music expressions reflect the input, the Stream Events (and thus everything passing through engravers) reflects the old behavior that was previously hand-cranked in the parser. You can now synthesize single NoteEvents and have them work as expected. I think that expected behavior depends on how we define it. If there were synthesized articulation events that fell outside of an EventChord, LilyPond would not know what to do with them. Similarly, if we simply say that a NoteEvent makes no sense outside of an EventChord, then there is no expected functionality for a dangling NoteEvent. I'm not at all saying that this is a bad proposal, but rather that as I'm learning more about how iterators do their thing, I'm realizing that all articulations can be in a list attached to a rhythmic event and that event chords never need to carry articulations. Some of this comes from my continued limitation in understanding what this patch does - I get the general concepts in your e-mails, but it is very difficult to understand how LilyPond works without seeing lily code. So, *** What would be really helpful is an e-mail that has almost no text explanation but that shows before and after examples of how this will change LilyPond. This can be syntax before versus syntax after or music stream before versus music stream after. I know that adds an extra burden to your work, but I'd greatly appreciate it! *** Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Marc Hohl m...@hohlart.de writes: Am 21.01.2012 18:44, schrieb Carl Sorensen: On 1/21/12 10:37 AM, David Kastrupd...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g \3\2\1 once these changes are implemented? The latter would not display anything anywhere. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Am 21.01.2012 19:41, schrieb David Kastrup: Marc Hohlm...@hohlart.de writes: Am 21.01.2012 18:44, schrieb Carl Sorensen: On 1/21/12 10:37 AM, David Kastrupd...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g\3\2\1 once these changes are implemented? The latter would not display anything anywhere. Great! Thanks, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
2012/1/21 gra...@percival-music.ca: I believe the problem had to do with filename extensions; as such, I think the following three places constitute the actual fix for . Do i understand correctly that line 336 http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode336 adds .ly extension to snippet files, and line 661 http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode661 checks for it so that lilypond-book doesn't try to compile non-ly files? If so, would it be worth mentioning in code and/or commit message for code readability's sake? thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes: On Jan 21, 2012, at 7:12 PM, David Kastrup wrote: If you wrote note^postevent previously, the postevent ended up in articulations of the NoteEvent when written inside of a chord, or as an EventChord companion when not written in a chord. Now it ends up in articulations, period. I think it this is good - this is what will help scrap the fingering and script engraver. It seems like this is a separate problem from wrapping notes in event chords or not: if all articulations are in an articulations list, then they can all go to the new fingering engraver. They won't be in an articulation list if they are on a chord. Then they are separate events inside of EventChord. It is conceivable that we let EventChord _also_ take articulations as a property. It is not all that clear to me who will be responsible for interpreting them, but it would likely not be hard to just let the event chord iterator broadcast them without thinking. This would, however, be a more fundamental change. The current syntax changes don't create music events that could not previously also occur (just not everywhere). EvantChord+articulation would be new. My question is this: what is the basic advantage of having rhythmic events not wrapped in event chords? I understand that it can be used to wedge a distinction between c and c, but how is this distinction useful? URL:http://code.google.com/p/lilypond/issues/detail?id=1110#c26 Why couldn't this be solved on the iterator level? There was no distinction between c and c at the iterator level anymore. Either case you had an EventChord around it. The problem that I have been tackling is more: is there an inherent difference between c-. and c-. and, if not so, why the heck do they look utterly different in the music expression depending on whether inside of or outside? I absolutely agree that everything should be in an articulations list, but I think this can be done while preserving event chords. It just means that EventChords will no longer contain articulation events and that all articulation events will be pulled out of NoteEvents or RestEvents and broadcast at the iterator level. There is such a thing as a chord articulation. I'm not at all saying that this is a bad proposal, but rather that as I'm learning more about how iterators do their thing, I'm realizing that all articulations can be in a list attached to a rhythmic event and that event chords never need to carry articulations. What do you do with c e g\p then? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Le 21/01/2012 17:19, Graham Percival disait : All release-Critical issues have patches which are either on a current countdown, have been on a previous countdown, or don't make sense to be on a countdown at all and will thus be pushed in a few hours. Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. There seems to be a desire to wait for 2 weeks instead of 1 week, so that's what I'll announce? Two weeks seems a reasonable time-window for the FTP mary-go-round as well as polishing and merging translations. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
There were actually two issues. The second was discovered after fixing the first. I intend to push as two separate commits explaining each. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode184 python/book_snippets.py:184: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1)) Here was the first problem: line-width is being adjusted. This is written to the .ly file generated by lilypond-book, but it is not clear whether %(paper_string)s above will contain a definition for line-width. And for HTML, it does not. This gave an error while running lilypond, mentioned in the bug report. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode890 python/book_snippets.py:890: return result ...this part. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (right): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode124 python/book_snippets.py:124: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1))''', This fixes the first problem by adjusting line-width directly where it is defined. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode336 python/book_snippets.py:336: self.ext = '.ly' On 2012/01/21 18:32:05, Graham Percival wrote: this Here was the second problem, discovered after fixing the first: Somewhere in the HTML output, a filename and extension is needed. This was not defined for inline lilypond code. It gave a python error. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode506 python/book_snippets.py:506: override['padding_mm'] = self.global_options.padding_mm This is needed for the line-width adjustement thingy with default settings otherwise python errors. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode662 python/book_snippets.py:662: result.append (base + self.ext) On 2012/01/21 18:32:05, Graham Percival wrote: this Just some clean up, simplification, with the same meaning as... http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 11:47 AM, Marc Hohl m...@hohlart.de wrote: I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g\3\2\1 once these changes are implemented? The latter would not display anything anywhere. Great! I'm not sure you actually will find it great (although I think it is more consistent). If we don't want to have string numbers show up in the music, but we need them for the tabstaff, right now we can do c e g\3\2\1 In the future, c e g\3\2\1 won't assign the string numbers to the tabstaff. (And in fact, I can't find this usage documented in the NR). Instead, as would be done regularly in lilypond, we would do \once \override StringNumber #'stencil = ##f c\3 e\2 g\1 This is consistent with how things are handled in lilypond, so I think we ought to move in this direction. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 21/01/2012 11:19 AM, Graham Percival wrote: Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. Once the fix for (lilypond-book fails with html input) is in, I'll fix 2223 (Regtests for lilypond-book are not running). I've already done so locally, and looking at the result of lilypond-book regtests, we already have new regressions: suffix-lyxml: looks suspicious, no image of music tex-twocolumn: fails, lilypond snippet is fullpage-wide. texinfo-language-detection: has a weird @lydoctitle popping up -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sat, Jan 21, 2012 at 02:28:15PM -0500, Julien Rioux wrote: I've already done so locally, and looking at the result of lilypond-book regtests, we already have new regressions: ok, good to know! I'm sure that you've done this already, but make sure that you actually try those version in 2.14.0 or 2.12.3 or whatever -- I wouldn't want to blindly assume that those tests actually worked when they were added to git. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 21, 2012, at 7:58 PM, David Kastrup wrote: I absolutely agree that everything should be in an articulations list, but I think this can be done while preserving event chords. It just means that EventChords will no longer contain articulation events and that all articulation events will be pulled out of NoteEvents or RestEvents and broadcast at the iterator level. There is such a thing as a chord articulation. Why couldn't this distinction be captured via a different event name? ChordArticulationEvent versus ArticulationEvent, for example. What do you do with c e g\p then? \p is an AbsoluteDynamicEvent and is not treated like articulations. What would really help are some before/after examples (ly code and/or music streams and/or brief text like before the patch, you could not do X, after, you can or this patch will allow me to experiment with implementing X) would help a great deal. As if it were going into the Change Log, for example. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
Some questions and concerns.
thanks,
Janek
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl
File scripts/auxiliar/lily-git.tcl (right):
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode222
scripts/auxiliar/lily-git.tcl:222: proc update_lilypond_norebase {} {
this isn't used anywhere, we keep it just in case?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode252
scripts/auxiliar/lily-git.tcl:252: if {$workingBranch != } {
Do i understand correctly that we check workingBranch and switch to
working on it if it's not empty? So, if we don't want to work on
workingBranch, we set it to null and lily-git will remain on OriginHead
(i.e. master)?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode253
scripts/auxiliar/lily-git.tcl:253: add_working_branch
Won't this reset our workingBranch to be a copy of master every time we
update repository?
Wait, i see: it's done only when creating new repository?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode270
scripts/auxiliar/lily-git.tcl:270: git rebase origin/$originHead
shouldn't we update local master too?
If we don't do this, how can we not run into trouble in line 309?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode272
scripts/auxiliar/lily-git.tcl:272: git merge origin/$originHead
Shouldn't we checkout workingBranch first (after checking if it exists)?
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode309
scripts/auxiliar/lily-git.tcl:309: git rebase $originHead
isn't there a risk that master is less up-to-date than working-branch?
(see comment on line 270)
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode560
scripts/auxiliar/lily-git.tcl:560: if [catch {set workingBranch
$env(LILYPOND_BRANCH)}] {
does this mean it there's no external variable to control
workingBranch?
http://codereview.appspot.com/5504092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
Thanks for explanations, Julien! Janek http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode184 python/book_snippets.py:184: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1)) On 2012/01/21 19:14:15, Julien Rioux wrote: Here was the first problem: line-width is being adjusted. This is written to the .ly file generated by lilypond-book, but it is not clear whether %(paper_string)s above will contain a definition for line-width. And for HTML, it does not. This gave an error while running lilypond, mentioned in the bug report. Ah, so the problem was that sometimes line-width wasn't defined and thus trying to adjust it failed? http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
Thanks for explanations, Julien! Janek http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode184 python/book_snippets.py:184: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1)) On 2012/01/21 19:14:15, Julien Rioux wrote: Here was the first problem: line-width is being adjusted. This is written to the .ly file generated by lilypond-book, but it is not clear whether %(paper_string)s above will contain a definition for line-width. And for HTML, it does not. This gave an error while running lilypond, mentioned in the bug report. Ah, so the problem was that sometimes line-width wasn't defined and thus trying to adjust it failed? http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
On Sat, Jan 21, 2012 at 4:18 PM, janek.lilyp...@gmail.com wrote: On 2012/01/21 19:14:15, Julien Rioux wrote: Here was the first problem: line-width is being adjusted. This is written to the .ly file generated by lilypond-book, but it is not clear whether %(paper_string)s above will contain a definition for line-width. And for HTML, it does not. This gave an error while running lilypond, mentioned in the bug report. Ah, so the problem was that sometimes line-width wasn't defined and thus trying to adjust it failed? http://codereview.appspot.com/5553056/ Yes. From the initial bug report for issue the failed output shows: Running lilypond... GNU LilyPond 2.15.25 Processing `snippet-map-1372012142.ly' Parsing... Processing `html-inline-no-options.html' Parsing... html-inline-no-options.html:16:16: error: GUILE signaled an error for the expression beginning here line-width = # (- line-width (* mm 3.00) (* mm 1)) Unbound variable: line-width We see that line-width was used before it was defined. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Makes sure dynamics don't budge for tuplet brackets. (issue 5555046)
So the problem was that by default tupletBracket doesn't have
outside-staff-priority (because we want it to be placed on staff lines
sometimes), and the code failed to check for that?
But i don't see how this patch solved the same problem with
outside-staff-priority set to something:
{ % this produced wrong output in 2.15.26, but now is ok:
\override TupletBracket #'outside-staff-priority = #3
\times 2/3 {c''4\ff c'' c''}
}
could you explain?
http://codereview.appspot.com/046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Makes sure dynamics don't budge for tuplet brackets. (issue 5555046)
On Jan 21, 2012, at 11:02 PM, janek.lilyp...@gmail.com wrote:
So the problem was that by default tupletBracket doesn't have
outside-staff-priority (because we want it to be placed on staff lines
sometimes), and the code failed to check for that?
But i don't see how this patch solved the same problem with
outside-staff-priority set to something:
{ % this produced wrong output in 2.15.26, but now is ok:
\override TupletBracket #'outside-staff-priority = #3
\times 2/3 {c''4\ff c'' c''}
}
could you explain?
The idea is that if outside-staff-priority is set for either the tuplet-bracket
or the dynamics, their vertical spacing with respect to each other should be
out of the hands of tuplet-bracket.cc and in the hands of the
axis-group-interface.cc .
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
Hello On 21 January 2012 21:12, janek.lilyp...@gmail.com wrote: Some questions and concerns. While I don't understand any of this really, isn't lily-git.tcl supposed to be for git-idiots (like me) who don't even want to think about branches? :) Just wondering if Janek is 'overthinking' this - apologies if not. Also @carl, could we make lilygit-tcl (not this patch) with a text area I can *paste* into (and/or ctrl-v) as I cannot do that with the current iteration, I can only type into it. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 21, 2012, at 10:15 PM, David Kastrup wrote:
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 7:58 PM, David Kastrup wrote:
that all articulation events will be pulled out of NoteEvents or
RestEvents and broadcast at the iterator level.
There is such a thing as a chord articulation.
Why couldn't this distinction be captured via a different event name?
ChordArticulationEvent versus ArticulationEvent, for example.
Where would be the point?
To not make the distinction in the parser. I think that changing the parser
should be a last resort if we can't figure out a way to represent information
through different event classes.
What would really help are some before/after examples (ly code and/or
music streams and/or brief text like before the patch, you could not
do X, after, you can or this patch will allow me to experiment with
implementing X) would help a great deal. As if it were going into
the Change Log, for example.
It's a bit hard since the whole design (perfected by the
rhythmic-music-event) was intended to make no user-visible difference.
The music expression has just become predictable. You get an EventChord
iff ... has been in the input. You get articulations on NoteEvent
for pitch-postevent regardless whether or not this is part of a chord.
Why can't we treat c as shorthand for c? Having a compulsory wrapping around
singletons is just as predictable as no wrapping at all.
As for articulations being on a NoteEvent whether or not this is part of a
chord, I agree that this is a very good idea, but I think this can be
accomplished by wrapping everything in an event chord and farming out the work
to iterators.
If you use \displayMusic on something that you might want to put into a
chord, you don't get wrong input. Tacking around a construct does
not change the structure of its inside. It is not necessary to tack
around a construct to make a \tweak work (which is a user-visible
change).
Why couldn't tweak make this distinction in the music function itself?
The music function could check if its input is an EventChord and, if so, feed
it the first entry in the 'elements list of the EventChord. This seems like a
less intrusive change than changing the parser.
You can use #{ #} for constructing material that ends up _inside_ of a
chord. Something like
\displayLilyMusic \displayLilyMusic ##{ c-. #}
does not go up in flames but just does what one would expect.
This is indeed an interesting case. Again, though, I would expect this to
fail, precisely because #{#} manipulates the material. If we define c as
shorthand for c, then this would be like doing \displayLilyMusic
\displayLilyMusic c , which I would also expect to fail.
I'm playing devil's advocate because it is an important change and I want to
make sure that its benefit outweighs the cost of adding exceptions into the
code base that facilitate the in/out of EventChord distinctions.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music font
Et un coup de pied dans la fourmilière ! On 9 January 2012 22:02, Emilio Grazzi i...@emiliograzzi.com wrote: Hi you all, i'm a (typo)graphic designer from Italy and i'm about to finish my dissertation about typography inside musical notation. I would like to apply my result inside lilypond like it was for the gonville font ( http://www.chiark.greenend.org.uk/~sgtatham/gonville/ ). The problem is that i'm not skilled in python, i use to create and modify each glyph with tools such fontlab, it drops out .otf fonts... But I see there's some .svg and .woff files inside the font folder (through contents/Resources/share/lilypond/current/fonts/). Do I need my font even in those file format in order to run it with lilypond? what can I use to have all those output from my otf file? I am not a developer, just a simple user. But I must say I am a bit disappointed no developer (except Janek) replied to your e-mail. Some of these developers are known to grump at the lack of investment (mainly from users) to help improving LilyPond. And when a typographic designer come with a music font and ask for help in order to run it with LilyPond, these same developers simply ignore it! Emilio, I guess you can ask for advise directly at Simon Tatham (the author of Gonville), I cc him in this reply. I would be pleased to hear about how you manage with this. Cheers, Xavier -- Xavier Scheuer x.sche...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
convert-ly: Better formatted error messages (issue 803). (issue 5564043)
Reviewers: , Message: Simpler formatting of convert-ly error messages, with improved partitioning of translatable parts. Description: convert-ly: Better formatted error messages (issue 803). Please review this at http://codereview.appspot.com/5564043/ Affected files: M python/convertrules.py ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
convert-ly: Handle malformed \version string (issue 2044). (issue 5563047)
Reviewers: ,
Message:
Simple patch to issue a warning when the \version string is malformed.
Description:
convert-ly: Handle malformed \version string (issue 2044).
Please review this at http://codereview.appspot.com/5563047/
Affected files:
M scripts/convert-ly.py
Index: scripts/convert-ly.py
diff --git a/scripts/convert-ly.py b/scripts/convert-ly.py
index
9bf72876bf58327ebd67ffaede6dcd57906e399c..73073a33ba78f7a291ba1514ce42680b09965d52
100644
--- a/scripts/convert-ly.py
+++ b/scripts/convert-ly.py
@@ -39,6 +39,8 @@ import convertrules
lilypond_version_re_str = 'version *\([0-9.]+)'
lilypond_version_re = re.compile (lilypond_version_re_str)
+lilypond_version_strict_re_str = 'version
*\([0-9]+[.][0-9]+[.][0-9]+)'
+lilypond_version_strict_re = re.compile (lilypond_version_strict_re_str)
help_summary = (
_ ('''Update LilyPond input to newer version. By default, update from the
@@ -206,11 +208,13 @@ string.
def guess_lilypond_version (input):
-m = lilypond_version_re.search (input)
+m = lilypond_version_strict_re.search (input)
if m:
return m.group (1)
-else:
-return ''
+m = lilypond_version_re.search (input)
+if m:
+ly.warning (_ (Malformed version string:) + m.group (1))
+return ''
class FatalConversionError (Exception):
pass
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music font
On Sun, Jan 22, 2012 at 12:05:46AM +0100, Xavier Scheuer wrote: I am not a developer, just a simple user. But I must say I am a bit disappointed no developer (except Janek) replied to your e-mail. And I'm a bit disappointed that you keep on whining about developers not doing what you want them to do. I am not your slave. The fact that I have volunteered thousands of hours working on lilypond does not make me your slave. I did not crawl out of my mother's womb knowing about lilypond internals, or even about programming at all. Any knowledge I have was from hard work: reading source code, reading public emails on the list archives, and learning about programming in general. I am a bit dissapointed that *you* have not done that. You want something done? Do it yourself. That's what open source means -- you have the legal right to do it yourself. It does not mean that other people are obligated to do it for you. You have la liberté, not royauté. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly: Handle malformed \version string (issue 2044). (issue 5563047)
LGTM, please push directly to staging http://codereview.appspot.com/5563047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly: Handle malformed \version string (issue 2044). (issue 5563047)
On Sat, Jan 21, 2012 at 6:36 PM, gra...@percival-music.ca wrote: LGTM, please push directly to staging http://codereview.appspot.com/5563047/ I noticed that there is already an InvalidVersion exception, so I am going to use that and push the result. Thanks, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
LGTM in general. Some comments though. Plus: The example in the comment above will now compile, but it will be missing the additional padding... Another thing about the hard-coded .ly extension: I would leave the extension extraction in the file snippet class, so that the base class sets a default of .ly, but for file snippets the extension will be extracted from the file name. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode184 python/book_snippets.py:184: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1)) On 2012/01/21 21:18:00, janek wrote: Ah, so the problem was that sometimes line-width wasn't defined and thus trying to adjust it failed? Yes, the problem is that I don't know of any way to get the default line-width, because there are cases where line-width is not explicitly defined in the snippets. In those cases we also need to subtract the padding... http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode806 python/book_snippets.py:806: self.ext = os.path.splitext (os.path.basename (self.filename))[1] Why are you removing a generic statement and hardcoding .ly above? This will break e.g. if you try to include a .ily file as a snippet! http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode890 python/book_snippets.py:890: return result On 2012/01/21 19:14:15, Julien Rioux wrote: ...this part. Yeah, appending the original extension makes more sense (and also works when you have a compressed .xml file where you explicitly specify --compress). http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (right): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode124 python/book_snippets.py:124: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1))''', On 2012/01/21 19:14:15, Julien Rioux wrote: This fixes the first problem by adjusting line-width directly where it is defined. Aren't there cases when neither LINE_WIDTH nor QUOTE is used? In that case we don't subtract the padding... http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
Thanks for reviewing it. Regards, Julien http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode806 python/book_snippets.py:806: self.ext = os.path.splitext (os.path.basename (self.filename))[1] On 2012/01/21 23:54:36, Reinhold wrote: Why are you removing a generic statement and hardcoding .ly above? This will break e.g. if you try to include a .ily file as a snippet! It does not break. I tested it. This self.ext is used only in output, in links to the source file. The '.ly' is hardcoded elsewhere already, so that when you include a .ily, lilypond-book actually writes a lily-.ly file for it, and this is what we link to. On the other hand leaving the current code in leads to broken links to a lily-.ily file. http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (right): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode124 python/book_snippets.py:124: line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1))''', On 2012/01/21 23:54:36, Reinhold wrote: On 2012/01/21 19:14:15, Julien Rioux wrote: This fixes the first problem by adjusting line-width directly where it is defined. Aren't there cases when neither LINE_WIDTH nor QUOTE is used? Yes, that's the case for html-inline-no-option.html In that case we don't subtract the padding... Why would a padding be relevant when there is no specified line width? http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
2012/1/21 Graham Percival gra...@percival-music.ca: All release-Critical issues have patches which are either on a current countdown, have been on a previous countdown, or don't make sense to be on a countdown at all and will thus be pushed in a few hours. Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. Sounds great even despite the fact that Julien discovered new regressions. There seems to be a desire to wait for 2 weeks instead of 1 week, so that's what I'll announce? +1 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
2012/1/21 James pkx1...@gmail.com: Hello On 21 January 2012 21:12, janek.lilyp...@gmail.com wrote: Some questions and concerns. While I don't understand any of this really, isn't lily-git.tcl supposed to be for git-idiots (like me) who don't even want to think about branches? :) That's exactly why they should work themselves, not needing you to fix them when they fail :) Being fool-proof requires extra tricks sometimes, hidden under the hood. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 1/21/12 5:36 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: 2012/1/21 James pkx1...@gmail.com: Hello On 21 January 2012 21:12, janek.lilyp...@gmail.com wrote: Some questions and concerns. While I don't understand any of this really, isn't lily-git.tcl supposed to be for git-idiots (like me) who don't even want to think about branches? :) That's exactly why they should work themselves, not needing you to fix them when they fail :) Being fool-proof requires extra tricks sometimes, hidden under the hood. And I believe the current patch *is* foolproof. Have you found an error? If so, can you demonstrate what you have done to reproduce the error? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Makes sure dynamics don't budge for tuplet brackets. (issue 5555046)
2012/1/21 m...@apollinemike.com m...@apollinemike.com:
On Jan 21, 2012, at 11:02 PM, janek.lilyp...@gmail.com wrote:
{ % this produced wrong output in 2.15.26, but now is ok:
\override TupletBracket #'outside-staff-priority = #3
\times 2/3 {c''4\ff c'' c''}
}
The idea is that if outside-staff-priority is set for either the
tuplet-bracket or the dynamics, their vertical spacing with respect to each
other should be out of the hands of tuplet-bracket.cc and in the hands of the
axis-group-interface.cc .
Sounds nice, but i don't see how it actually happens. There's nothing
like axis-group-interface in the code that follows :(
thanks,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
Nice review.
I will make changes in response to your comments.
Thanks,
Carl
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl
File scripts/auxiliar/lily-git.tcl (right):
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode222
scripts/auxiliar/lily-git.tcl:222: proc update_lilypond_norebase {} {
On 2012/01/21 21:12:58, janek wrote:
this isn't used anywhere, we keep it just in case?
Looks like it can go. Thanks for the catch.
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode252
scripts/auxiliar/lily-git.tcl:252: if {$workingBranch != } {
On 2012/01/21 21:12:58, janek wrote:
Do i understand correctly that we check workingBranch and switch to
working on
it if it's not empty? So, if we don't want to work on workingBranch,
we set it
to null and lily-git will remain on OriginHead (i.e. master)?
No. workingBranch should never be null. If it is, we'll get lots of
git errors. So if workingBranch is null, we don't do any checking out.
No. $workingBranch should never be null. If you try to ch
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode253
scripts/auxiliar/lily-git.tcl:253: add_working_branch
On 2012/01/21 21:12:58, janek wrote:
Won't this reset our workingBranch to be a copy of master every time
we update
repository?
Wait, i see: it's done only when creating new repository?
Precisely.
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode270
scripts/auxiliar/lily-git.tcl:270: git rebase origin/$originHead
On 2012/01/21 21:12:58, janek wrote:
shouldn't we update local master too?
If we don't do this, how can we not run into trouble in line 309?
Ahh. I see what you mean. Before we were only rebasing master to
origin/master. Then we changed to rebasing workingBranch to
origin/master.
We should be rebasing master to origin/master, and then workingBranch to
master.
Thanks for the catch.
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode560
scripts/auxiliar/lily-git.tcl:560: if [catch {set workingBranch
$env(LILYPOND_BRANCH)}] {
On 2012/01/21 21:12:58, janek wrote:
does this mean it there's no external variable to control
workingBranch?
Yes. Strictly speaking it means If there is an error in setting the
value of the local variable workingBranch to the environment variable
LILYPOND_BRANCH.
http://codereview.appspot.com/5504092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Abandoned patches countdown to Tuesday, January 24, 2012
The patches listed below have had no updates since before December, and in a couple of cases, the last update was me asking if the patch was still being developed. Would the owners please review their patches, and mark them abandoned if applicable, closing any Rietveld item as necessary, or update the tracker item with a brief note about current status. I propose to mark any remaining items from this list as abandoned on Tuesday, January 24. *ID**Type* *Priority* *Owner* *Summary* *Modified* 1742Enhancement janek.lilypond print transposed guitar chords on piano sheets 2011-09-06 1833Enhancement n.puttock Deprecate \fermataMarkup for full-bar rests. 2011-09-08 1786Enhancement bordage.bertrandNew engraver for braces 2011-09-12 1784 Enhancement Medium mtsolo Adds epsilon to Bezier range calculations 2011-09-14 1128Defect Medium Text pedal mark not closed at music end 2011-09-14 1780Enhancement ianhulin44 Scheme format functions with no destination parameter cause deprecation warnings in Guile V2 2011-09-25 1727 Enhancement Medium mtsolo Adds glissando stems to lilypond 2011-10-04 1956Enhancement mtsolo Patch: Creates a LeftBarStub that stops lyrics from bumping into the SystemStartBar. 2011-10-12 1850Enhancement reinhold.kainhofer FiguredBass: Rewrite of the engraver to fix vertical position 2011-10-14 155 Ugly joeneeman \parenthesize does not take accidentals into account 2011-11-04 1922Enhancement mtsolo Adds StemTremolo to the note column's element list. 2011-11-04 Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
