Re: Fixes footnote automatic numbering. (issue 4877041)
On Oct 4, 2011, at 8:48 AM, pkx1...@gmail.com wrote: > Passes make but fails make check. Cannot see where I just get > > --snip-- > > job 0 terminated with signal: 11 > fatal error: Children (0) exited with errors. > command failed: /home/jlowe/lilypond-git/build/out/bin/lilypond -I > /home/jlowe/lilypond-git/input/regression/ -I ./out-test -I > /home/jlowe/lilypond-git/input -I /home/jlowe/lilypond-git/Documentation > -I /home/jlowe/lily ... > > etc. > > --snip-- > I just got the same thing - sorry about that. Working on a fix. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes footnote automatic numbering. (issue 4877041)
Passes make but fails make check. Cannot see where I just get --snip-- job 0 terminated with signal: 11 fatal error: Children (0) exited with errors. command failed: /home/jlowe/lilypond-git/build/out/bin/lilypond -I /home/jlowe/lilypond-git/input/regression/ -I ./out-test -I /home/jlowe/lilypond-git/input -I /home/jlowe/lilypond-git/Documentation -I /home/jlowe/lily ... etc. --snip-- http://codereview.appspot.com/4877041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Grob::vertical_less and DOWN/UP
Hey all, Currently, I've written the function Grob::vertical_less such that it returns true for a grob that is higher than another grob. This is because the ordering of a vertical alignment's element list goes from top to bottom, so the vertical axis groups with lower indices in the list are higher on the page. I'm using this as well in my footnote patch. This is theoretically no big deal, as it corresponds to our intuition about how scores are organized (if someone asked me "What's the first instrument in an orchestral score?" my instinctive response would be flute, not contrabass). However, it goes against the way that DOWN/UP works in LilyPond, where down is "less" than up. Thus, Grob::vertical_less yields a result that may be confusing for some. I think that it'd be good to scrub this inconsistency from the code base such that "lower on the page" always means "numerically lower" (so the contrabass, for example, would be the 0th vertical axis group in an elements list). Thoughts? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for fix of issue 307 (issue 4813048)
passes make and make check http://codereview.appspot.com/4813048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes footnote automatic numbering. (issue 4877041)
Hey Reinhold et al, This newest patch set should do the trick for automatic numbering. Cheers, MS http://codereview.appspot.com/4877041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for fix of issue 307 (issue 4813048)
On Oct 3, 2011, at 8:24 AM, k-ohara5...@oco.net wrote: > Mike, > Maybe your flower/out didn't get rebuilt after config > --disable-optimising. I had to rm flower/out/* > > > http://codereview.appspot.com/4813048/diff/29001/lily/slur-scoring.cc > File lily/slur-scoring.cc (right): > > http://codereview.appspot.com/4813048/diff/29001/lily/slur-scoring.cc#newcode274 > lily/slur-scoring.cc:274: Real y_place = linear_interpolate > (extra_encompass_infos_[i].extents_[X_AXIS].center (), > input/regression/tablature-tie-spanner.ly > has the "Assertion `!is_empty ()' failed" in center() > Fixed in the most recent patchset. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes closeness-factor from the Slur details list. (issue 4825051)
Mike this patch no longer applies to current tree. I get failed hunks. http://codereview.appspot.com/4825051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
I've taken care of the issues Bertrand points out in #46. There are still some issues outstanding. The code in output-lib.scm is probably not the best way of doing this. Also, the Kievan bar line does not appear correctly. http://codereview.appspot.com/4951062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for broken beams with consistent slopes (issue 4961041)
On Oct 3, 2011, at 6:53 AM, hanw...@gmail.com wrote: > i know it's annoying, but could you separate out the cosmetics (adding _ > ) to members from the rest of this change? The cosmetic changes make it > difficult to see the essence of what you are trying to do. > > > http://codereview.appspot.com/4961041/diff/39001/lily/include/beam-scoring-problem.hh > File lily/include/beam-scoring-problem.hh (right): > > http://codereview.appspot.com/4961041/diff/39001/lily/include/beam-scoring-problem.hh#newcode151 > lily/include/beam-scoring-problem.hh:151: vector stem_ypositions_; > organize so it's clear to what members the comment pertains. > > http://codereview.appspot.com/4961041/ Doable. I'll push the cosmetic to master after running regtests on it and then try to sort out the patch either tonight or tomorrow morning. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for broken beams with consistent slopes (issue 4961041)
On Oct 3, 2011, at 6:53 AM, hanw...@gmail.com wrote: > i know it's annoying, but could you separate out the cosmetics (adding _ > ) to members from the rest of this change? The cosmetic changes make it > difficult to see the essence of what you are trying to do. > > > http://codereview.appspot.com/4961041/diff/39001/lily/include/beam-scoring-problem.hh > File lily/include/beam-scoring-problem.hh (right): > > http://codereview.appspot.com/4961041/diff/39001/lily/include/beam-scoring-problem.hh#newcode151 > lily/include/beam-scoring-problem.hh:151: vector stem_ypositions_; > organize so it's clear to what members the comment pertains. > > http://codereview.appspot.com/4961041/ It's good, as it eliminates the programming error and makes the line-break slicker (IMHO). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Abandoned patch countdown 20111003
Graham Percival writes: > On Mon, Oct 03, 2011 at 10:16:01AM +0200, David Kastrup wrote: >> "m...@apollinemike.com" writes: >> >> > If you could leave this up for another week, that'll give me time to >> > collect the bounty on it. >> >> Since a reward loses its meaning if you need to invest weeks of >> bartering, running after people, sending out payment reminders and so >> on, my take on this is that we should either turn this into an official >> thing where an independent party does the vetting and likely gets the >> money in advance in escrow, or scrap it altogether. >> >> As a system of honor, it does not work and thus is rather a disincentive >> for contributors than otherwise. > > Agreed, but it'll be a few weeks before we discuss this in GOP. > I'm not willing to hold back the patch management work to address > this now. Perhaps it would help to have an issue tag "Unpaid" that keeps an issue open. Having the issue remaining open, in contrast to leaving a patch uncommitted, at least does not _damage_ other Lilypond users as opposed to patches without bounty that go in without delay. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc#newcode855
lily/stem.cc:855: if (attach && !scm_is_eq (style, ly_symbol2scm
("mensural"))
On 2011/10/03 08:52:27, Bertrand Bordage wrote:
By default, the stem is right-aligned...
Right-aligned for up-stems, left-aligned for down-stems, so that most
fonts can conveniently use the outer edges of the stencil as the
attachment point, using the character width.
If your font attaches stems differently, charwx is provided to specify
the difference.
Here you seem to change the rules (costing users time for four
additional property-lookups per stem) without updating mf/README with
your change to the rules.
http://codereview.appspot.com/4639065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Abandoned patch countdown 20111003
On Mon, Oct 03, 2011 at 10:16:01AM +0200, David Kastrup wrote: > "m...@apollinemike.com" writes: > > > If you could leave this up for another week, that'll give me time to > > collect the bounty on it. > > Since a reward loses its meaning if you need to invest weeks of > bartering, running after people, sending out payment reminders and so > on, my take on this is that we should either turn this into an official > thing where an independent party does the vetting and likely gets the > money in advance in escrow, or scrap it altogether. > > As a system of honor, it does not work and thus is rather a disincentive > for contributors than otherwise. Agreed, but it'll be a few weeks before we discuss this in GOP. I'm not willing to hold back the patch management work to address this now. Sorry, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves some parmesan noteheads. (issue 4639065)
Thanks Keith, I'll quickly fix that in a new issue.
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc#newcode853
lily/stem.cc:853: extract_grob_set (me, "note-heads", heads);
... OK.
http://codereview.appspot.com/4639065/diff/42001/lily/stem.cc#newcode855
lily/stem.cc:855: if (attach && !scm_is_eq (style, ly_symbol2scm
("mensural"))
Of course, but we only choose the position of the attachment. By
default, the stem is right-aligned...
http://codereview.appspot.com/4639065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Abandoned patch countdown 20111003
"m...@apollinemike.com" writes: > Issue 737: Enhancement: support for footnotes and/or endnotes. > > > If you could leave this up for another week, that'll give me time to > collect the bounty on it. I don't find that keeping a patch back helps. I tried work for hire (sending the respective patches in private after agreeing on a price and keeping back the code from upstream in the hope of payment) as well as committing to the code base. Neither worked as to yet. Also there is a tendency to keep asking for more than in the original specs, vastly inflating the effort. Notwithstanding, I have about $500 outstanding and nothing paid. On the plus side, I promptly paid for a set of accordion font glyphs for which I had offered a bounty, so the bounty system sometimes does work. Since a reward loses its meaning if you need to invest weeks of bartering, running after people, sending out payment reminders and so on, my take on this is that we should either turn this into an official thing where an independent party does the vetting and likely gets the money in advance in escrow, or scrap it altogether. As a system of honor, it does not work and thus is rather a disincentive for contributors than otherwise. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes closeness-factor from the Slur details list. (issue 4825051)
added as http://code.google.com/p/lilypond/issues/detail?id=1953 http://codereview.appspot.com/4825051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for fix of issue 307 (issue 4813048)
Passes make and make check http://codereview.appspot.com/4813048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for broken beams with consistent slopes (issue 4961041)
Passes make. I get a few reg tests pop up; see attached at http://code.google.com/p/lilypond/issues/detail?id=1952#c1 but also 'spanner-break-overshoot.log' gives me: --snip-- @@ -4,8 +4,6 @@ Preprocessing graphical objects... Calculating line breaks... Drawing systems... -programming error: Disagree on common x. Skipping collisions in beam scoring. -continuing, cross fingers Writing header field `texidoc' to `/home/jlowe/lilypond-git/build/out/lybook-testdb/2f/lily-050456a8.texidoc'... Writing /home/jlowe/lilypond-git/build/out/lybook-testdb/2f/lily-050456a8-1.signature Writing /home/jlowe/lilypond-git/build/out/lybook-testdb/2f/lily-050456a8-2.signature --snip-- is this bad? http://codereview.appspot.com/4961041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dots in chords can not be moved Issue 1266 (issue 5174043)
Passes Make and there are reg tests that show up but I can see no significant changes at first glance. See: http://code.google.com/p/lilypond/issues/detail?id=1266#c7 http://codereview.appspot.com/5174043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
