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: 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: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)
Untangling the stencil regressions. The commit that made skylines from stencils (issue 2148) omitted space-reservations for stencils that: + are not drawn (\transparent) + have unknown contents until after layout (\page-ref and similar) or + had their space reservation modified (\pad-around and similar). It makes sense to put information to restore these space-reservations in the stencil-expression, because that is where the skyline-building code looks for them. We could encode the information in the stencil expression as: 1) a 'with-dimensions primitive with box-dimensions, to be read by the skyline code to restore the former behavior (this patch) 2) a 'transparent primitive with a stencil subexpression, to be read by the skyline code but not printed (http://codereview.appspot.com/13416044/) Both work for me. Supposing for the moment that plan (2) meets resistance, does this code for plan (1) look good? 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)
Conceptually, I prefer (1), but this is based on your descriptions and the previous discussion, not on understanding the code... 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 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. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
