PATCHES: Countdown for Septemeber 3rd - 06:00 GMT
hello *Countdown – September 3rd – 06:00 GMT* * * * * * * * * 3517http://code.google.com/p/lilypond/issues/detail?id=3517q=label%3APatch-reviewsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup Push Patch: Parse composite music in context modifications in \notemode 3516http://code.google.com/p/lilypond/issues/detail?id=3516q=label%3APatch-reviewsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup Push Patch: Let parser accept symbols after \new, \context, \unset and implicit \set 3514http://code.google.com/p/lilypond/issues/detail?id=3514q=label%3APatch-reviewsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation Mark Polesky Push Clean up CG Major release checklist. 3513http://code.google.com/p/lilypond/issues/detail?id=3513q=label%3APatch-reviewsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Frederic Bron Push Patch: removed unused code: functions that are declared but never defined and stream.hh 3511http://code.google.com/p/lilypond/issues/detail?id=3511q=label%3APatch-reviewsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Frederic Bron Push Patch: removed unused header tie-column-format.hh 3505http://code.google.com/p/lilypond/issues/detail?id=3505q=label%3APatch-reviewsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup Push Patch: Let add-grace-property and remove-grace-property only work in current context 3457http://code.google.com/p/lilypond/issues/detail?id=3457q=label%3APatch-reviewsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Mark Polesky Push Add NullVoice context (using \partcombine with lyrics). 3383http://code.google.com/p/lilypond/issues/detail?id=3383q=label%3APatch-reviewsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Defect Keith Ohara Push old-straight-flag + smaller Stem.thickness gives no output and huge over Regression 3359http://code.google.com/p/lilypond/issues/detail?id=3359q=label%3APatch-reviewsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Crash Keith Ohara Push ties for notes in \changed Staff brings LP to crash Regression 2910http://code.google.com/p/lilypond/issues/detail?id=2910q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Ugly Keith Ohara Countdown problem with 'outside-staff-padding 2141http://code.google.com/p/lilypond/issues/detail?id=2141q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Keith Ohara Countdown accidental spacing - some accidentals are too far from each other 3300http://code.google.com/p/lilypond/issues/detail?id=3300q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Defect Keith Ohara Countdown Error messages became less specific Regression 3523http://code.google.com/p/lilypond/issues/detail?id=3523q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup Countdown Patch: Remove a signed/unsigned comparison compiler warning 3525http://code.google.com/p/lilypond/issues/detail?id=3525q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Patch Janek Warchol review Patch: make sure that AmbitusLine is visible for small ambits 3526http://code.google.com/p/lilypond/issues/detail?id=3526q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Julien Rioux review Patch: ./configure should fail on missing fonts. 3524http://code.google.com/p/lilypond/issues/detail?id=3524q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Mike Solomon review Patch: Allows inner-markup spacing using skylines. 3522http://code.google.com/p/lilypond/issues/detail?id=3522q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Ugly Mike Solomon review \transparent does not create correct skylines in markups 3255http://code.google.com/p/lilypond/issues/detail?id=3255q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Critical Keith Ohara review \with-dimensions doesn't affect the overall size of a TextScript Regression James ___ lilypond-devel
Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)
On 30 août 2013, at 07:49, Keith OHara k-ohara5...@oco.net wrote: On Thu, 29 Aug 2013 21:24:25 -0700, lemzw...@googlemail.com wrote: Conceptually, I prefer (1), but this is based on your descriptions and the previous discussion, not on understanding the code... Then look at (2) and see if you think that would be good enough to clear the last bugs before 2.18. The uses of \transparent, \pad-to-box, etc., are rare. It hurts very little to find ourselves stuck with a second-choice implementation in this case. We won't know what our first-choice implementation is unless we see some application examples in this area. I'd still argue that (2) is the best way to go as it is a one-stop-shopping way to clear all these bugs (and perhaps more) as they arise. To me, the question is Is the implementation of (2) inferior to (1) to the point where we'd like to allow certain bugs to persist? My answer is no - LilyPond has already a practice of creating placeholder stencils whose sole purpose is to reserve space and (2) is in this vein. (2) does for skylines what the empty-stencil does for dimensions. Additionally, (2) clears all the stencil-related skyline bugs on the tracker, whereas (1) does not. So my vote is for (2). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)
On 2013/08/30 07:41:49, mike7 wrote: I'd still argue that (2) is the best way to go as it is a one-stop-shopping way to clear all these bugs (and perhaps more) as they arise. Since we are currently in the process of recovering from the last one-stop-shopping way to clear bugs galore which is where all those regressions are actually from, I suggest that we refrain from embracing your somewhat optimistic estimates until after wrapping up a stable release. And frankly, I completely fail to see how this advertisement as a magic bullet for all the regressions is even remotely rooted in fact. The regressions will not in any way be automagically addressed by such sweeping changes. The changes will offer different ways to address them and you like those better. But that's not the same as actually getting them addressed. https://codereview.appspot.com/9295044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser: more specific error messages; issue 3300 (issue 8506043)
https://codereview.appspot.com/8506043/diff/13001/lily/parser.yy File lily/parser.yy (right): https://codereview.appspot.com/8506043/diff/13001/lily/parser.yy#newcode2995 lily/parser.yy:2995: parser-parser_error (@1, _ (unexpected markup, without any ^ _ or -, and outside of \\lyricmode)); The error message is a bit too cumbersome. Maybe markup outside of text script or \\lyricmode. https://codereview.appspot.com/8506043/diff/13001/lily/parser.yy#newcode3000 lily/parser.yy:3000: parser-parser_error (@1, _ (unexpected string, or unrecognized note-name, outside of \\lyricmode)); Strings can also be in text scripts. https://codereview.appspot.com/8506043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)
On 30 août 2013, at 10:11, d...@gnu.org wrote: On 2013/08/30 07:41:49, mike7 wrote: I'd still argue that (2) is the best way to go as it is a one-stop-shopping way to clear all these bugs (and perhaps more) as they arise. Since we are currently in the process of recovering from the last one-stop-shopping way to clear bugs galore which is where all those regressions are actually from, The skyline code was not written to address bugs. LilyPond's previous spacing algorithms weren't buggy - they were just less snug than they are now. I suggest that we refrain from embracing your somewhat optimistic estimates until after wrapping up a stable release. I don't see the relationship between the two. The skyline code was a major, over-a-thousand line overhaul of spacing. This is much smaller in scale and addresses one specific aspect of the code. I'm not claiming that any solution - Keith or mine - is bug proof, but rather that we should adopt the one that will get the most mileage against eventual spacing bugs with stencils. The general category of problem we are trying to solve is a shape around stencil X is not being represented in the skylines. My solution fixes problems in that general category, whereas Keith's addresses the more specific problem a box around stencil X is not being represented in the skylines. And frankly, I completely fail to see how this advertisement as a magic bullet for all the regressions is even remotely rooted in fact. The regressions will not in any way be automagically addressed by such sweeping changes. The changes will offer different ways to address them and you like those better. But that's not the same as actually getting them addressed. We agree here. In my previous e-mail, I make the case that this is a way to clear all these bugs and above you correctly identify that it offers ways to address them. I don't think it's a magic bullet, but rather a general framework that allows us to address this category of bugs without coming up with specific solutions for each bug. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)
On Thu, 29 Aug 2013 23:57:59 -0700, Mike Solomon m...@mikesolomon.org wrote: On 30 août 2013, at 07:49, Keith OHara k-ohara5...@oco.net wrote: It hurts very little to find ourselves stuck with a second-choice implementation in this case. We won't know what our first-choice implementation is unless we see some application examples in this area. To me, the question is Is the implementation of (2) inferior to (1) to the point where we'd like to allow certain bugs to persist? My answer is no - LilyPond has already a practice of creating placeholder stencils whose sole purpose is to reserve space and (2) is in this vein. (2) does for skylines what the empty-stencil does for dimensions. Additionally, (2) clears all the stencil-related skyline bugs on the tracker, whereas (1) does not. Well, approach (1) with boxes solves the \page-ref and \with-dimensions bugs, and restores the behavior of \transparent to what we had in version 2.16. Approach (2) with stencil-expressions also fixes issue 3255 as requested, but that bug report was written to describe what approach (2) can do. Does any music typesetting application benefit from fixing issue 3255 as requested ? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)
On 2013/08/30 08:55:15, mike7 wrote: On 30 août 2013, at 10:11, mailto:d...@gnu.org wrote: On 2013/08/30 07:41:49, mike7 wrote: I'd still argue that (2) is the best way to go as it is a one-stop-shopping way to clear all these bugs (and perhaps more) as they arise. Since we are currently in the process of recovering from the last one-stop-shopping way to clear bugs galore which is where all those regressions are actually from, The skyline code was not written to address bugs. Neither is this here. We are talking about changing established behavior to something different. And the motivation for that _is_ the responsibility of the skyline code. But if you want a one-stop-shopping way to clear bugs galore from which we are still recovering, take a look at issue 3199. It's responsible for at least issues 3359, 3360, 3385 and was pushed without even waiting for the review to clear. LilyPond's previous spacing algorithms weren't buggy - they were just less snug than they are now. Snug reminds me of issue 2527, another problem solver responsible for issues 3363, 3465, 3497. I suggest that we refrain from embracing your somewhat optimistic estimates until after wrapping up a stable release. I don't see the relationship between the two. Which makes it a good thing that you are not pursuing a career as project manager. At any rate, we are trying to stabilize our code base in a timely manner suitably for a stable release, and the established track record of ingenious solutions solving all problems in one fell swoop does not suggest that this is the way to go. https://codereview.appspot.com/9295044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)
On 30 août 2013, at 11:39, d...@gnu.org wrote: I suggest that we refrain from embracing your somewhat optimistic estimates until after wrapping up a stable release. I don't see the relationship between the two. Which makes it a good thing that you are not pursuing a career as project manager. At any rate, we are trying to stabilize our code base in a timely manner suitably for a stable release, and the established track record of ingenious solutions solving all problems in one fell swoop does not suggest that this is the way to go. The sarcasm of your e-mails has gotten to the point where I need to limit my work on the project as a developer. When I work on a team project, I need to be part of a community with a different style of communication than this. I will still use LilyPond as a tool and and continue to help fix any bugs that have resulted from my work. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make sure that AmbitusLine is visible for small ambits (issue 4609041)
https://codereview.appspot.com/4609041/diff/29002/input/regression/ambitus-gap.ly
File input/regression/ambitus-gap.ly (right):
https://codereview.appspot.com/4609041/diff/29002/input/regression/ambitus-gap.ly#newcode5
input/regression/ambitus-gap.ly:5: note heads are set by the @code{gap}
property. Also, ambitus line
On 2013/08/30 04:57:30, Keith wrote:
By default, @code{gap} is a function that reduces the gap for small
intervals,
so line remains visible.
We cannot say Also, because if I set the gap property to 0.4, then
the line
will *not* be visible in fourth.
Done.
https://codereview.appspot.com/4609041/diff/29002/scm/output-lib.scm
File scm/output-lib.scm (right):
https://codereview.appspot.com/4609041/diff/29002/scm/output-lib.scm#newcode1252
scm/output-lib.scm:1252: (if (and (ly:grob-array? heads)
On 2013/08/30 04:57:30, Keith wrote:
You should have an 'else' case (if test body else) so that if
the test
ever fails you return some value; otherwise the user gets a mysterious
error
message.
Done.
https://codereview.appspot.com/4609041/diff/29002/scm/output-lib.scm#newcode1258
scm/output-lib.scm:1258: (max-gap (ly:grob-property grob 'maximum-gap
2))
On 2013/08/30 04:57:30, Keith wrote:
The defaults seem strange. They should be typical values, otherwise
people get
confused. Is 'max-gap normally 2 ?
Good catch, this was a typo. Done.
https://codereview.appspot.com/4609041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser: more specific error messages; issue 3300 (issue 8506043)
https://codereview.appspot.com/8506043/diff/13001/lily/parser.yy File lily/parser.yy (right): https://codereview.appspot.com/8506043/diff/13001/lily/parser.yy#newcode2995 lily/parser.yy:2995: parser-parser_error (@1, _ (unexpected markup, without any ^ _ or -, and outside of \\lyricmode)); On 2013/08/30 08:52:27, dak wrote: The error message is a bit too cumbersome. Maybe markup outside of text script or \\lyricmode. Yep. That might let the whole message fit on a terminal line. https://codereview.appspot.com/8506043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
