PATCH: Countdown on hold to Tuesday
As the patches presently up for review were all updated today, and none are critical, it seems we have none to put on countdown. 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
Re: Returns an empty interval for stencilless Stem height (issue 6303065)
On 2012/06/11 03:44:32, Keith wrote:
http://codereview.appspot.com/6303065/diff/4001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/6303065/diff/4001/lily/stem.cc#newcode703
lily/stem.cc:703: if (calc_beam && !unsmob_stencil (me->get_property
("stencil")))
beam-stem-stemlet.ly shows that LilyPond produces no stencil for the
invisible
stems on beamed rests, yet she depends on stem extents for tuplet
brackets.
Maybe
if (calc_beam && !beam && !stenxil) ?
This shows a case where stem height cannot be determined by stem stencil
presence. The first version of the patch works under the assumption
that information about height cannot be gleaned from the stencil and
must be made explicit through overrides. I think that, even though this
requires redundancy (specifying no stencil and an empty height), if
LilyPond treats cases where there is no stencil and a non-empty height
(like beam-stem-stemlet.ly), then the method in the first patch set is
better.
http://codereview.appspot.com/6303065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Returns an empty interval for stencilless Stem height (issue 6303065)
http://codereview.appspot.com/6303065/diff/4001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/6303065/diff/4001/lily/stem.cc#newcode703
lily/stem.cc:703: if (calc_beam && !unsmob_stencil (me->get_property
("stencil")))
beam-stem-stemlet.ly shows that LilyPond produces no stencil for the
invisible stems on beamed rests, yet she depends on stem extents for
tuplet brackets. Maybe
if (calc_beam && !beam && !stenxil) ?
http://codereview.appspot.com/6303065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for beaming in Kievan notation (issue 6305080)
looks good to me. http://codereview.appspot.com/6305080/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix for beaming in Kievan notation (issue 6305080)
Reviewers: ,
Message:
A first attempt at fixing issue 2492.
This fixes the note heads for beamed kievan notes, also getting rid of
the warning messages.
Description:
Fix for beaming in Kievan notation
Implementing correct beaming functionality in Kievan notation
Fix for Issue 2492
Please review this at http://codereview.appspot.com/6305080/
Affected files:
M lily/note-head.cc
M ly/engraver-init.ly
Index: lily/note-head.cc
diff --git a/lily/note-head.cc b/lily/note-head.cc
index
fb93e40eeb82f02574c2fa670183d19054214fd6..287b10dc043a42ce8ebe613422a8c51fe916874b
100644
--- a/lily/note-head.cc
+++ b/lily/note-head.cc
@@ -80,6 +80,15 @@ internal_print (Grob *me, string *font_char)
}
}
+ if (style == "kievan"
+ && 3 == robust_scm2int (me->get_property ("duration-log"), 2))
+{
+ Grob *stem = unsmob_grob (me->get_object ("stem"));
+ Grob *beam = unsmob_grob (stem->get_object ("beam"));
+ if (beam)
+out = fm->find_by_name (idx_either + "2kievan");
+}
+
idx_either += suffix;
if (out.is_empty ())
{
Index: ly/engraver-init.ly
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index
9bb731883cba5d9754fdc7c2030508b49bde06f4..b4a7008b8d4c1f7338557f4f0b0448285bb0b417
100644
--- a/ly/engraver-init.ly
+++ b/ly/engraver-init.ly
@@ -1146,8 +1146,6 @@ accommodated for typesetting a piece in Kievan style."
%% There are beams in Kievan notation, but they are invoked manually
autoBeaming = ##f
- \override Beam #'beam-thickness = #0.32
- \override Beam #'length-fraction = #0.62
}
\context {
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sets TabVoice Stem height to ##f (issue 6303065)
On 2012/06/10 18:22:50, MikeSol wrote: Another way of going about this would be changing the Stem::height function so that it returned an empty interval for stencil-less stems. I'd consider that eminently reasonable. It makes much more sense to me than having to wipe out some non-sensical resulting height explicitly. http://codereview.appspot.com/6303065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Sets TabVoice Stem height to ##f (issue 6303065)
Reviewers: ,
Message:
Another way of going about this would be changing the Stem::height
function so that it returned an empty interval for stencil-less stems.
Then the overrides wouldn't be necessary. It's a design question more
than anything else.
Description:
Sets TabVoice Stem height to ##f
Please review this at http://codereview.appspot.com/6303065/
Affected files:
M lily/grob.cc
M ly/engraver-init.ly
M ly/property-init.ly
Index: lily/grob.cc
diff --git a/lily/grob.cc b/lily/grob.cc
index
cc39c979f0e9cf146b40975b01f82ed9441d08bc..828ae7f07b40687457f8031475f0a42d9992dc67
100644
--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -466,7 +466,10 @@ Grob::extent (Grob *refp, Axis a) const
((Grob *)this)->dim_cache_[a].extent_ = new Interval (real_ext);
}
- real_ext.translate (offset);
+ // We never want nan, so we avoid shifting infinite values.
+ for (LEFT_and_RIGHT (d))
+if (!isinf (real_ext[d]))
+ real_ext[d] += offset;
return real_ext;
}
Index: ly/engraver-init.ly
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index
9bb731883cba5d9754fdc7c2030508b49bde06f4..2c28af1f23f0472b34887bed7e3cbf3fa577d330
100644
--- a/ly/engraver-init.ly
+++ b/ly/engraver-init.ly
@@ -825,6 +825,9 @@ context."
%% after all, the stubs of the stems may still be visible, so ...
\override Stem #'stencil = ##f
\override Flag #'stencil = ##f
+ %% and they certainly don't have heights...
+ \override Stem #'Y-extent = ##f
+ \override Flag #'Y-extent = ##f
%% automatic beams should be suppressed for similar reasons ...
autoBeaming = ##f
%% remove beams, dots and rests ...
Index: ly/property-init.ly
diff --git a/ly/property-init.ly b/ly/property-init.ly
index
c0b352254ad0f195cb20d99465180ca5c706440a..edd117518a458c76460a277b48982c24cd048f2d
100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -451,6 +451,8 @@ tabFullNotation = {
\revert TabVoice.Stem #'details
\revert TabVoice.Stem #'stencil
\revert TabVoice.Flag #'stencil
+ \revert TabVoice.Stem #'Y-extent
+ \revert TabVoice.Flag #'Y-extent
\override TabVoice.Stem #'stencil =
#tabvoice::draw-double-stem-for-half-notes
\override TabVoice.Stem #'X-extent =
#tabvoice::make-double-stem-width-for-half-notes
\set TabVoice.autoBeaming = ##t
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Footnotes correctly printed on grobs at first timestep. (issue 6306064)
http://codereview.appspot.com/6306064/diff/7001/lily/system.cc File lily/system.cc (right): http://codereview.appspot.com/6306064/diff/7001/lily/system.cc#newcode285 lily/system.cc:285: TODO Ugh. At least the comment now mentions that something is likely rotten elsewhere. Thanks! http://codereview.appspot.com/6306064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
New Esperanto PO file for 'lilypond' (version 2.15.37.1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the Esperanto team of translators. The file is available at: http://translationproject.org/latest/lilypond/eo.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Footnotes correctly printed on grobs at first timestep. (issue 6306064)
On 2012/06/10 16:22:25, MikeSol wrote: It's worth mentioning in the change log and perhaps a convert-ly NOT_SMART rule. The change log describes changes relative to the last stable release. A release which did not even have footnotes. If we wanted to put something in the change log, mentioning the existence of footnotes in the first place would be a good candidate. I am not sure that the level of the footnote engraver is not something so fuzzy that it makes little sense to even devise convert-ly rules. At best, one could try changing overrides for Staff.FootnoteItem appropriately in files that don't tamper with Footnote_engraver, but that's all very hickety-wobbledy. http://codereview.appspot.com/6306064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Footnotes correctly printed on grobs at first timestep. (issue 6306064)
http://codereview.appspot.com/6306064/diff/1/input/regression/footnote-break-visibility.ly File input/regression/footnote-break-visibility.ly (right): http://codereview.appspot.com/6306064/diff/1/input/regression/footnote-break-visibility.ly#newcode21 input/regression/footnote-break-visibility.ly:21: \once \override Score . FootnoteItem #'break-visibility = ##(#f #f #t) This looks like an unrelated fix that should just get pushed to staging independently. I am surprised that it did not show in the regtest comparison. http://codereview.appspot.com/6306064/diff/1/lily/system.cc File lily/system.cc (right): http://codereview.appspot.com/6306064/diff/1/lily/system.cc#newcode257 lily/system.cc:257: end_of_line_visible = item->break_status_dir () == LEFT; While I readily admit that this is breaking with the traditions set forth in the existing code, could you add a comment about what you are doing here? http://codereview.appspot.com/6306064/diff/1/lily/system.cc#newcode280 lily/system.cc:280: if (find (out.begin (), out.end (), at_bat) != out.end ()) And here? Thanks. http://codereview.appspot.com/6306064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Footnotes correctly printed on grobs at first timestep. (issue 6306064)
On 2012/06/10 16:09:03, dak wrote: On 2012/06/10 15:58:25, MikeSol wrote: > This fixes Issue 2574 but also deals with the footnote-break-visibility regtest, > which currently does not register the property change (this may have something > to do with the footnote engraver being on the Score level). I'll readily admit that the footnote engraver being at Score level may be a source for new problems. However, automatic footnotes get a number for each time they hit an engraver, and footnotes may occur at pretty much any level. So I don't really see a way around having the engraver registered at Score level by default. Moving it to lower levels may be a user-level option, but it comes at the cost of some elements no longer being available for footnoting. So it would be good if we could get the Score-level footnote engraver working well. It's worth mentioning in the change log and perhaps a convert-ly NOT_SMART rule. A once-over of the footnote regtests wouldn't hurt either if you have a bit of time just to make sure they're doing what they claim to be doing. http://codereview.appspot.com/6306064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Footnotes correctly printed on grobs at first timestep. (issue 6306064)
On 2012/06/10 15:58:25, MikeSol wrote: This fixes Issue 2574 but also deals with the footnote-break-visibility regtest, which currently does not register the property change (this may have something to do with the footnote engraver being on the Score level). I'll readily admit that the footnote engraver being at Score level may be a source for new problems. However, automatic footnotes get a number for each time they hit an engraver, and footnotes may occur at pretty much any level. So I don't really see a way around having the engraver registered at Score level by default. Moving it to lower levels may be a user-level option, but it comes at the cost of some elements no longer being available for footnoting. So it would be good if we could get the Score-level footnote engraver working well. http://codereview.appspot.com/6306064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Footnotes correctly printed on grobs at first timestep. (issue 6306064)
Reviewers: ,
Message:
This fixes Issue 2574 but also deals with the footnote-break-visibility
regtest, which currently does not register the property change (this may
have something to do with the footnote engraver being on the Score
level).
Cheers,
MS
Description:
Footnotes correctly printed on grobs at first timestep.
Please review this at http://codereview.appspot.com/6306064/
Affected files:
M input/regression/footnote-break-visibility.ly
M lily/system.cc
Index: input/regression/footnote-break-visibility.ly
diff --git a/input/regression/footnote-break-visibility.ly
b/input/regression/footnote-break-visibility.ly
index
0f88e2df276599a66ff346c58cdd521e31e1dec6..4626553982a90a4808ac1b7807ae09fb0c9525e3
100644
--- a/input/regression/footnote-break-visibility.ly
+++ b/input/regression/footnote-break-visibility.ly
@@ -18,7 +18,7 @@ This behavior can be overridden.
\time 3/4
\break \pageBreak
c2.
-\once \override Staff . FootnoteItem #'break-visibility = ##(#f #f #t)
+\once \override Score . FootnoteItem #'break-visibility = ##(#f #f #t)
\footnote "foo" #'(0 . 2) #'TimeSignature "bar" \default
\time 4/4
\break \pageBreak
Index: lily/system.cc
diff --git a/lily/system.cc b/lily/system.cc
index
fdcc2b133d1b056f78482087218aac7abbc559ff..5d4cae8a57b8f86333bc49da7e267d2f7e8a81b6
100644
--- a/lily/system.cc
+++ b/lily/system.cc
@@ -254,6 +254,8 @@ System::get_footnote_grobs_in_range (vsize start, vsize
end)
if (Item *item = dynamic_cast(at_bat))
{
+ end_of_line_visible = item->break_status_dir () == LEFT;
+
if (!Item::break_visible (item))
continue;
// safeguard to bring down the column rank so that end of line
footnotes show up on the correct line
@@ -275,6 +277,8 @@ System::get_footnote_grobs_in_range (vsize start, vsize
end)
continue;
if (!at_bat->is_live ())
continue;
+ if (find (out.begin (), out.end (), at_bat) != out.end ())
+continue;
out.push_back (at_bat);
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC comparison
On Sun, Jun 10, 2012 at 11:01:16AM +0200, David Kastrup wrote: > > 1.) Replace lex-bison based parser with handwritten parser in gcalctool ... > I have the suspicion that the student will learn more than the > project. The official response would probably be "that's a feature, not a bug". > Now it's not as bad as the first look: certainly more than half of the > projects are not of this "I could pull out my hairs" variety. And those > projects were likely accepted under the general GNOME umbrella rather > than individually, so they don't really have more elated status than our > GSoC pitch. Being part of an existing umbrella is vital. Doesn't GSoC get over a thousand applications? Think of the role that luck plays in hiring somebody for a low-level job. Imagine somebody shifting through 200 resumes, trying to find half a dozen to interview. I figure a human spent 5 minutes looking at the lilypond application before rejecting it. If I were doing it, I'd probably make my first pass rejections within 2 minutes for each application. *shrug* it's a lottery, not a competition. If you can't stand the heat... - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GSoC comparison
Wow. I looked at http://worldofgnome.org/29-new-things-this-google-summer-of-code-will-bring-to-gnome/>: 29 GSoC projects? Point 1: 1.) Replace lex-bison based parser with handwritten parser in gcalctool The aim of this application is to change current lex-bison based parser with the handwritten parser. As, handwritten parser are much faster and can be ported to other languages without much trouble, this will help in both, making gcalctool fast as well as portable. "As, handwritten parser are much faster". Than an LALR(1) table-based automaton with an O(1) algorithm. For use in a desktop calculator. I have the suspicion that the student will learn more than the project. 4.) Completion of the Gnome Sudoku Vala Port The Gnome Sudoku game, currently written in python, is not up to the standards set out. My project will complete the Vala port, and make sure its easy and worth to play. Well, we have our own porting-idea-of-the-month contest going on in the user list. I don't even say that porting does not help an application _if_ the port is done by people experienced with the original code base. It is an opportunity for redesigning in the light of experience. And one has better motivation for _finishing_ an overhaul when one is porting from X to Y rather than porting from X to X. I've been in a commercial project where the build system was ported from Make to Maven in order to make things work well. One could have improved the results for the workgroup further by taking the results and porting them to Make. But of course, there would have been no resources or justifiable incentive for porting from Make to Make. 6.) GNOME Clock Work with the GNOME Design Team and Seif Lotfy on GNOME Clock, in order to provide the GNOME community with a clock application. GNOME Clock will allow users to quickly and easily determine the time of day anywhere in the world, helping them keep in touch with family, friends and co-workers. GNOME Clock will also allow users to set alarms so that when time X rolls around they know they need to do Y. A stopwatch/timer will also be included so that users can time themselves and/or others as needed. Now it's not as bad as the first look: certainly more than half of the projects are not of this "I could pull out my hairs" variety. And those projects were likely accepted under the general GNOME umbrella rather than individually, so they don't really have more elated status than our GSoC pitch. But it does leave me with some head-scratching. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
08:09:01 (UTC) Begin LilyPond compile, previous commit at af4e93cc3084a0b274044921805477189c6eb1e2 08:09:06 *** FAILED STEP *** merge from staging Command 'git fetch' returned non-zero exit status 128 Permission denied (publickey). fatal: The remote end hung up unexpectedly ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
