Eliminates side poisition calculations for system-start-text grobs. (issue 7574048)
Whoah, Mike! I've understood your patch in first reading! Nice commit message. The spacing of system-star-text-interface implementing grobs used side typo (system-start-text) Also, we change the name of the list of elements used for alignment, as elements should only be used for axis groups. maybe enclose "elements" (from the second line) in quotes? From what i understand, this sentence says that 'elements' is a special identifier that should only be used for axis groups. anyway, LGTM :) thanks! Janek https://codereview.appspot.com/7574048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Release process for 2.18 cancelled
In the last week it has become abundantly clear that the last-minute attempt for reaching the conditions suitable for making a stable release occured too late to arrive at a releasable state. The work I scheduled for myself for arriving at such a state consisted in dealing with several regressions and documentation inconsistencies due to changes from myself in the 2.17 release cycle. This would have been somewhat realistic as a side load to manage in my upcoming vacation. It turns out that the pent-up pressure to get forward-looking changes into the master branch that have transitory user interfaces or extensive changes of internals not exposed to sufficient testing is already too high to permit a prerelease phase focused on arriving at stable release quality. Forcing development into prerelease mode nevertheless would require an amount of involvement that would be incompatible with the amount of time I can invest during my vacation, and it would interfere with the vacation (four work days per year are not really much in the first place) both in terms of getting some sort of relaxation as well as in being able to be focused enough on climbing not to endanger my climbing partners' and my own health. So a release process of 2.18 managed by me is off. In the current situation, I don't consider it realistic that we will be able to make a stable release with sufficient reliability in the next four months at least, likely longer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release process for 2.18 cancelled
David, On Mon, Mar 18, 2013 at 9:52 AM, David Kastrup wrote: > > In the last week it has become abundantly clear that the last-minute > attempt for reaching the conditions suitable for making a stable release > occured too late to arrive at a releasable state. > [] > So a release process of 2.18 managed by me is off. In the current > situation, I don't consider it realistic that we will be able to make a > stable release with sufficient reliability in the next four months at > least, likely longer. I trust your judgement and i support your decision. best wishes, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 03/17/2013 06:47 PM, thomasmorle...@googlemail.com wrote: > And while above the staff dynamic brackets have the hook down. As I said before, I'd have argued for that feature even in the absence of a Ferneyhough example, as it makes musical/notational sense. But I think the example settles it. :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release process for 2.18 cancelled
David Kastrup Monday, March 18, 2013 8:52 AM > > It turns out that the pent-up pressure to get forward-looking changes > into the master branch that have transitory user interfaces or extensive > changes of internals not exposed to sufficient testing is already too > high to permit a prerelease phase focused on arriving at stable release > quality. > > So a release process of 2.18 managed by me is off. In the current > situation, I don't consider it realistic that we will be able to make a > stable release with sufficient reliability in the next four months at > least, likely longer. It's a pity, but I think you're right. But during that four months or longer we need to be vigilant to prevent any potentially disruptive changes entering master. Encouraging or requiring developers to use branches for anything other than tidying up or bugfixes from now onwards seems desirable to me. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: don't abort aligning when grob's parent is a PaperColumn (issue 7564044)
I can't easily test this, but on the basis of the reg tests - LGTM https://codereview.appspot.com/7564044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release process for 2.18 cancelled
"Trevor Daniels" writes: > David Kastrup Monday, March 18, 2013 8:52 AM >> >> It turns out that the pent-up pressure to get forward-looking changes >> into the master branch that have transitory user interfaces or extensive >> changes of internals not exposed to sufficient testing is already too >> high to permit a prerelease phase focused on arriving at stable release >> quality. >> >> So a release process of 2.18 managed by me is off. In the current >> situation, I don't consider it realistic that we will be able to make a >> stable release with sufficient reliability in the next four months at >> least, likely longer. > > It's a pity, but I think you're right. But during that four months or > longer we need to be vigilant to prevent any potentially disruptive > changes entering master. Encouraging or requiring developers to use > branches for anything other than tidying up or bugfixes from now > onwards seems desirable to me. Well, that's presuming a process between consenting adults, but I am afraid that's something we have to do without: it is obvious that we have severe disagreement of what is and what is not going to lead to a stable release. So we need a process that is going to work out even with severely divergent opinion about what can be made stable in due time and what not. The way to do that is to bind people to their predictions of what can and cannot be achieved in a certain amount of time by agreeing on a timeline in advance and putting in deadlines for certain kinds of changes. I am notoriously bad at organizing such processes, but I am even worse at convincing people that I have a clue what I am talking about. So if we can't arrive at a process where people are prepared to swallow what I (or any other single person) have to say, we have to revert to a process letting everyone eat his own words. That means agreeing on a policy in advance rather than making decisions on the fly, based on the best currently available information. Personally, I very much prefer the latter approach, but since we cannot agree on an interpretation of the currently available information and since the currently active set of developers is too small for arriving at a reasonably representative decision for dictatorship (or whatever one would want to call placing the responsibility for making some calls into a single hand), it's the best we can do. So probably after my climbing trip I'll prepare something akin to Graham's GOP proposals that will spell out time frames that most developers will feel comfortable agreeing with. Now. It's not my style of working, but it is obvious that my style of working does not work in this case. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release process for 2.18 cancelled
David Kastrup wrote Monday, March 18, 2013 11:14 AM > "Trevor Daniels" writes: > >> David Kastrup Monday, March 18, 2013 8:52 AM >>> >>> It turns out that the pent-up pressure to get forward-looking changes >>> into the master branch that have transitory user interfaces or extensive >>> changes of internals not exposed to sufficient testing is already too >>> high to permit a prerelease phase focused on arriving at stable release >>> quality. >>> >>> So a release process of 2.18 managed by me is off. In the current >>> situation, I don't consider it realistic that we will be able to make a >>> stable release with sufficient reliability in the next four months at >>> least, likely longer. >> >> It's a pity, but I think you're right. But during that four months or >> longer we need to be vigilant to prevent any potentially disruptive >> changes entering master. Encouraging or requiring developers to use >> branches for anything other than tidying up or bugfixes from now >> onwards seems desirable to me. > > The way to do that is to bind people to their predictions of what can > and cannot be achieved in a certain amount of time by agreeing on a > timeline in advance and putting in deadlines for certain kinds of > changes. This looks a promising approach. Suppose we ask developers to set out what new features they would like to complete in time for a 2.18 release, together with their estimate of the date by which they would be implemented. Not bug-free, but steered through review and pushed in a working state. The date would be firm, with the implication that if it were not met the feature would automatically slip into 2.19. We could then review the list, vote as a community on the features to be implemented in 2.18, and set a time for the release (obviously some weeks after the last feature date.) Any feature not in the agreed list would not be accepted for 2.18, and clearly a long estimated implementation date for any feature might be enough to rule it out. > That means agreeing on a policy in advance rather than making decisions > on the fly, based on the best currently available information. Would the above be a start on a policy? At least it would guarantee 2.18 would eventually be released. We'd need to define 'feature', of course. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: don't abort aligning when grob's parent is a PaperColumn (issue 7564044)
On 2013/03/18 10:36:35, Trevor Daniels wrote: I can't easily test this, but on the basis of the reg tests - LGTM Do you mean that i should improve the test file which is attached to tracker issue? Janek https://codereview.appspot.com/7564044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release process for 2.18 cancelled
"Trevor Daniels" writes: > David Kastrup wrote Monday, March 18, 2013 11:14 AM > >> The way to do that is to bind people to their predictions of what can >> and cannot be achieved in a certain amount of time by agreeing on a >> timeline in advance and putting in deadlines for certain kinds of >> changes. > > This looks a promising approach. Suppose we ask developers to set out > what new features they would like to complete in time for a 2.18 > release, together with their estimate of the date by which they would > be implemented. Not bug-free, but steered through review and pushed > in a working state. The date would be firm, with the implication that > if it were not met the feature would automatically slip into 2.19. > > We could then review the list, vote as a community on the features to > be implemented in 2.18, and set a time for the release (obviously some > weeks after the last feature date.) Any feature not in the agreed > list would not be accepted for 2.18, and clearly a long estimated > implementation date for any feature might be enough to rule it out. > >> That means agreeing on a policy in advance rather than making decisions >> on the fly, based on the best currently available information. > > Would the above be a start on a policy? Not really. > At least it would guarantee 2.18 would eventually be released. We'd > need to define 'feature', of course. The current standoff is not about which feature should be desirable or not, but rather what kind of change should be permitted into a stable release. A "feature" consists of functionality, programming APIs and user interfaces. Without well-fitting user interfaces, the functionality will not see a reasonable amount of testing and it will not be possible to make a good-faith effort to making that feature remain accessible in the same manner for more than one release. So it is pointless on focusing on a particular set of features for the release planning. In particular since this will severely disadvantage those programmers with conservative estimates about their work. Instead we need to set deadlines for the state any functionality may be in for the sake of being admitted into master. The first lockdown date will likely be for features of the "dump code now, think about user interface later" variety. They will need to be in a well-confined state where it is possible to just revert them in the stable branch if it turns out that the "think about user interface later" angle will not be satisfactorily addressed until the release. Similarly there will be a deadline for changes of the "this does not affect the actual current feature set, has large repercussions on code stability, but might come in handy some time in future" kind. We'll set up deadlines for various kinds of changes, and when they are voted to belong in a particular category, that means that after they passed the deadline, they will not pass into master. It does not preclude them being worked on in a separate feature branch. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
report a programming error when trying to align on empty parent (issue 7533046)
Reviewers: dak, MikeSol, J_lowe,
Message:
This is the part of Issue 3239 that introduced additional programming
errors. I hope that the explanation is clear.
Of course there is one fundamental question: maybe we shouldn't complain
about grobs with empty extents, and just silently assume that an empty
extent is equivalent to (0 . 0)?
In other words, maybe this fragment of code should never report any
programming errors?
Description:
report a programming error when trying to align on empty parent
To align grobs, we look at their extents (which are basically
grob dimensions in respective axes) and offset them according
to these extents. If a grob's extent is empty (undefined),
we cannot calculate the offset required to achieve desired
alignment of this grob, so we report a "programming error:
cannot align on self: empty element".
It is acceptable to align a grob which dimension is 0 (for
example its stencil is just a point), but in that case its
extent should be a zero interval, not an undefined value
(i.e. (0 . 0), not #f).
If we want to align a grob on its parent, the required offset
is calculated based on extents of both the grob and the
parent, so the parent's extent shouldn't be empty as well.
This patch makes LilyPond report a programming error if
parent's extent is empty (until now such situations were just
silently ignored).
Please review this at https://codereview.appspot.com/7533046/
Affected files:
M lily/self-alignment-interface.cc
Index: lily/self-alignment-interface.cc
diff --git a/lily/self-alignment-interface.cc
b/lily/self-alignment-interface.cc
index
59adfc3e6ca04d878349f6e3425843c703694c45..1ce24d77e387189b0d5b11c328f7edc1a53e623a
100644
--- a/lily/self-alignment-interface.cc
+++ b/lily/self-alignment-interface.cc
@@ -152,7 +152,9 @@ Self_alignment_interface::aligned_on_parent (Grob *me,
Axis a)
else
x -= ext.linear_combination (align);
- if (!he.is_empty ())
+ if (he.is_empty ())
+programming_error ("cannot align on parent: empty element");
+ else
x += he.linear_combination (align);
return scm_from_double (x);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: don't abort aligning when grob's parent is a PaperColumn (issue 7564044)
On 2013/03/18 13:05:15, janek wrote: On 2013/03/18 10:36:35, Trevor Daniels wrote: > I can't easily test this, but on the basis of the > reg tests - LGTM Do you mean that i should improve the test file which is attached to tracker issue? Janek No, the test file looks fine. It's just that I'm not in a position to compile LilyPond at the moment. Trevor https://codereview.appspot.com/7564044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
a short explanation
Hi, recently i've mixed several things together and made some mess. I apologize fo that. Below i explain the situation so that you won't be lost: Issue 3239 http://code.google.com/p/lilypond/issues/detail?id=3239 https://codereview.appspot.com/7768043 Previous versions of this patch contained some changes that should've been discussed separately - they are now separate issues. At this moment this patch is just a reorganization of self-alignment-interface: it shouldn't change anything in LilyPond output and user interfaces, nor introduce any regtest changes. Issue 3254 http://code.google.com/p/lilypond/issues/detail?id=3254 https://codereview.appspot.com/7564044 This is a solution to a problem discussed in "alignment of unattached lyrics - opinions needed". I expect to send an improved version of this patch later today. Issue 3259 http://code.google.com/p/lilypond/issues/detail?id=3259 https://codereview.appspot.com/7533046 This change makes LilyPond report programming errors in some situations that were previously ignored. I believe they shouldn't be ignored, but *i need your feedback on this*. thanks, janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
https://codereview.appspot.com/7424049/diff/41001/input/regression/repeat-slur.ly
File input/regression/repeat-slur.ly (right):
https://codereview.appspot.com/7424049/diff/41001/input/regression/repeat-slur.ly#newcode10
input/regression/repeat-slur.ly:10: "
This should be rather @code{\\breakSlur}, @code{\\startBrokenSlur} and
@code{\\stopBrokenSlur}.
And what exactly does \breakSlur? It's missing in the regtest.
Finally, you should mention phrasing slurs also.
https://codereview.appspot.com/7424049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Add warning about using \relative with tagged music (3253) (issue 7798045)
https://codereview.appspot.com/7798045/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
https://codereview.appspot.com/7798045/diff/1/Documentation/notation/input.itely#newcode2247
Documentation/notation/input.itely:2247: @end example
That's \relative without reference pitch... This particular form would
not actually be used, instead music would be defined as
music =
\relative c' { ...
So I don't think these examples really make things more clear. There
also is no "correct" and "incorrect" usage.
It is just that it rarely makes sense to apply \relative to music
treated with \keepWithTag/\removeWithTag since then different sequences
will be run through \relative.
However, if you just cut away material at the end of a sequence, or just
cut away articulations, this is not actually a problem.
So the rule more or less is
"Calling \relative on a sequence gained with \keepWithTag/\removeWithTag
will consider only the pitches actually remaining in the sequence,
possibly changing the octave relations."
https://codereview.appspot.com/7798045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: alignment of unattached lyrics - opinions needed
Hi, On Sat, Mar 16, 2013 at 9:36 AM, David Kastrup wrote: > Aligning lyrics at a point of time to notecolumns at the same point of time > should not require associating voices. On Sun, Mar 17, 2013 at 6:55 PM, Janek Warchoł wrote: > On Sun, Mar 17, 2013 at 2:38 PM, Trevor Daniels wrote: >> The thing we are lacking is the ability to self-align them on that point >> with either center or left alignment, or better, any real alignment. > > A basic solution to this problem was already present in patchset 1 of > https://codereview.appspot.com/7768043/ > What i don't know is how to grab the respective notecolumn (i've tried > get_column () but it didn't work for me). > So, here's where i need help: *how to get a NoteColumn when i have a > pointer to a PaperColumn?* ok, now i'm officially dumb as a brick. The solution was under my nose all the time! Patchset 2 in https://codereview.appspot.com/7564044/ extracts NoteHeads happening at the same musical moment and uses them for alignment. Pretty awesome :) Please review - it's a small & easy to understand change (hopefully i did good job with comments) and i'd like to know if i can proceed with reorganizing self-alignment-interface. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
The most recent patch set copies direction from SlurEvents and PhrasingSlurEvents, but this doesn't seem to work as intended (it fails silently). Everything else is operational. https://codereview.appspot.com/7424049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Eliminates side poisition calculations for system-start-text grobs. (issue 7574048)
This will be nice. Notice that the Stanza number in 'input/regression/hara-kiri-stanza-number.ly' lost its alignment. https://codereview.appspot.com/7574048/diff/1/scm/define-grob-interfaces.scm File scm/define-grob-interfaces.scm (right): https://codereview.appspot.com/7574048/diff/1/scm/define-grob-interfaces.scm#newcode251 scm/define-grob-interfaces.scm:251: "A stanza number, to be put in from of a lyrics line." Needs something. https://codereview.appspot.com/7574048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
