Document symbol list changes. (issue 6813079)
LGTM. http://codereview.appspot.com/6813079/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Document symbol list changes. (issue 6813079)
LGTM Trevor http://codereview.appspot.com/6813079/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various clean-ups in stems and beams. (issue 6584045)
http://codereview.appspot.com/6584045/diff/1/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/6584045/diff/1/lily/beam.cc#newcode197
lily/beam.cc:197: Grob *me = unsmob_grob (smob);
Looking at the combination of this and is_kievan, it would appear that
the expected response when calling Beam::calc-is-kievan (why no question
mark in the name?) with a non-Grob is a segmentation fault.
That's sub-fabulous.
http://codereview.appspot.com/6584045/diff/1/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/6584045/diff/1/lily/stem.cc#newcode815
lily/stem.cc:815: Grob *beam = unsmob_grob (me-get_object (beam));
Again: it would appear that calling this with a non-grob is intended to
crash LilyPond. Is there a particular reason you write your callbacks
without typechecking their arguments?
We have things like LY_ASSERT_TYPE for a reason.
http://codereview.appspot.com/6584045/diff/1/lily/stem.cc#newcode833
lily/stem.cc:833: Grob *beam = unsmob_grob (me-get_object (beam));
See above.
http://codereview.appspot.com/6584045/diff/1/scm/output-lib.scm
File scm/output-lib.scm (right):
http://codereview.appspot.com/6584045/diff/1/scm/output-lib.scm#newcode70
scm/output-lib.scm:70: (next-stem (cadr stems-grobs))
The above line may set stems-grobs to '(), in which case this line will
bomb out with a Scheme error. Where is the point?
http://codereview.appspot.com/6584045/diff/1/scm/output-lib.scm#newcode85
scm/output-lib.scm:85: (left-height (if (= direction DOWN)
Is direction sure to be non-null?
http://codereview.appspot.com/6584045/diff/12001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/6584045/diff/12001/lily/stem.cc#newcode812
lily/stem.cc:812: Real beg = robust_scm2double (me-get_pure_property
(stem-begin-position, 0, INT_MAX), 0.0);
Using robust_scm2double does not help when me is 0. This still needs
LY_ASSERT_TYPE or similar.
http://codereview.appspot.com/6584045/diff/12001/ly/engraver-init.ly
File ly/engraver-init.ly (right):
http://codereview.appspot.com/6584045/diff/12001/ly/engraver-init.ly#newcode1145
ly/engraver-init.ly:1145: \override Stem.stencil = #'()
Overriding a stencil with an empty list seems strange: is there a
difference in meaning to overriding it with #f?
http://codereview.appspot.com/6584045/diff/12001/ly/property-init.ly
File ly/property-init.ly (right):
http://codereview.appspot.com/6584045/diff/12001/ly/property-init.ly#newcode315
ly/property-init.ly:315: kievanOff = {
Could be just
kievanOff = \undo \kievanOn
Less efficient (if we ever find it makes a difference, \undo could be
done in C++ mostly), but less prone to oversights as well.
http://codereview.appspot.com/6584045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various clean-ups in stems and beams. (issue 6584045)
On 3 nov. 2012, at 12:26, d...@gnu.org wrote: http://codereview.appspot.com/6584045/diff/1/lily/beam.cc File lily/beam.cc (right): http://codereview.appspot.com/6584045/diff/1/lily/beam.cc#newcode197 lily/beam.cc:197: Grob *me = unsmob_grob (smob); Looking at the combination of this and is_kievan, it would appear that the expected response when calling Beam::calc-is-kievan (why no question mark in the name?) with a non-Grob is a segmentation fault. That's sub-fabulous. Quick response - if you're looking at changes in beam.cc, you are reviewing an old patch set from a month ago or so. It seems that some of your comments are in this and some are in the new one. I'll figure out which ones still apply, but just giving you and other reviewers the heads up. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various clean-ups in stems and beams. (issue 6584045)
On 2012/11/03 11:37:08, mike7 wrote: On 3 nov. 2012, at 12:26, mailto:d...@gnu.org wrote: http://codereview.appspot.com/6584045/diff/1/lily/beam.cc File lily/beam.cc (right): http://codereview.appspot.com/6584045/diff/1/lily/beam.cc#newcode197 lily/beam.cc:197: Grob *me = unsmob_grob (smob); Looking at the combination of this and is_kievan, it would appear that the expected response when calling Beam::calc-is-kievan (why no question mark in the name?) with a non-Grob is a segmentation fault. That's sub-fabulous. Quick response - if you're looking at changes in beam.cc, you are reviewing an old patch set from a month ago or so. The problem with incremental changes like this is that the humongous total change set is hard to review, and the incremental change is considered outdated. If we were reviewing this as a commit series of git, every commit in the series of only loosely related changes would be expected to be sane. With Rietveld, one can't really distinguish between history of changes and sequence of commits. So I apologize for having looked at this in parts, but it would appear that the LY_ASSERT_TYPE thing applies equally well to the latest change. http://codereview.appspot.com/6584045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new markup-comand `draw-dashed-line´ was: lilypond-user Digest, Vol 119, Issue 90
Hi Harm, On Thu, Nov 1, 2012 at 9:57 AM, Thomas Morley thomasmorle...@googlemail.com wrote: Hi David (N), attached my first try. If the markup-property full-length is set #t, some calculations ensure that no space occurs at line-end/begin. Some dashes will only be partly visible, but I think its ok. In addition I wrote a top-level-testing-function to minimize typing. Some comments are added. But I have no clue why I need 13 as a factor in a specific calculation. I'm not sure. Could it have something to do with 'blot-diameter of the rounded edges? What do you think? I like the option to have the dashed-line stencil function available for the user to plug in whatever values and get those exact results (full-length = #f). As far as the adjusted line goes, however, I'm thinking that the segments at beginning and end could be complete, not partly visible in some cases. I see that you modify on and off in one circumstance; why not do this whenever full-length is set to #t? The interface could take the settings of on and off as a wish list, and shorten and lengthen them to fit the actual situation. I suppose in this circumstance phase would be set to 0. You could assemble the dashed line from round-filled-boxes as dashed bar lines are (as you mentioned earlier), but would there be any need for that if all dashes and spaces are consistently sized? I'll keep thinking about this, but I hope my comments here are helpful... Best, David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Releases 2.17.6 and 2.16.1
Hi,
I have just been merging translation into stable (after checking
compilation, tests, and documentation). I am not totally happy with
2.16.1: we still have non-convergence on the line-count stuff (which I
will leave in its current state), and it is conceivable that there is
some regression concerning #{ \include ... #}. In particular with
regard to the latter, I am tempted to either cherry-pick some stuff that
has seen no serious exposure (issue 2939
http://code.google.com/p/lilypond/issues/detail?id=2939 is still in
countdown), or alternatively revert some performance-related patches of
mine that have been picked post-2.16.0. I'll have to do some testing to
figure out the exact scope of the problem and then make a decision.
On front of the unstable release, we are having several reviews in
countdown with 2.17.6 syntax, and I think we should roll out 2.17.6 as
soon as possible to avoid things getting too complicated on the
convert-ly front.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Releases 2.17.6 and 2.16.1
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Saturday, November 03, 2012 4:07 PM
Subject: Releases 2.17.6 and 2.16.1
Hi,
I have just been merging translation into stable (after checking
compilation, tests, and documentation). I am not totally happy with
2.16.1: we still have non-convergence on the line-count stuff (which I
will leave in its current state), and it is conceivable that there is
some regression concerning #{ \include ... #}. In particular with
regard to the latter, I am tempted to either cherry-pick some stuff that
has seen no serious exposure (issue 2939
http://code.google.com/p/lilypond/issues/detail?id=2939 is still in
countdown), or alternatively revert some performance-related patches of
mine that have been picked post-2.16.0. I'll have to do some testing to
figure out the exact scope of the problem and then make a decision.
On front of the unstable release, we are having several reviews in
countdown with 2.17.6 syntax, and I think we should roll out 2.17.6 as
soon as possible to avoid things getting too complicated on the
convert-ly front.
--
David Kastrup
I finished building 2.17.6 about 30 minutes ago. Gub failed again, but I
know how to fix this manually and have done so, so it's ready for upload. I
will do the upload when we're not using my internet connection for anything
else... (This evening or tonight). So 2.17.6 should be visible during
tomorrow.
For anyone interested in why Gub was failing, it seems it's to do with using
a commitish as a signature of showing whether make test, etc., should be
re-run. Unfortunately the function that checked the cached signature was
looking in the wrong place. I've just pushed a commit to gperciva/gub that
will likely fix this - although this is somewhat by inspection so if
anyone knows more of the internals of gub and can comment, I'd be happy.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond.pot polluted
Hi John and all, I just noticed that, because the out of tree build, lilypond.pot gets polluted by personal path, what does not happen with an in tree build. e.g. we get, when out of tree : #: parser.yy:174 parser.yy:188 /home/jcharles/GIT/Mentor/lily/parser.yy:174 #: /home/jcharles/GIT/Mentor/lily/parser.yy:188 msgid Too much lookahead msgstr #: parser.yy:466 parser.yy:736 parser.yy:803 #: /home/jcharles/GIT/Mentor/lily/parser.yy:466 #: /home/jcharles/GIT/Mentor/lily/parser.yy:736 #: /home/jcharles/GIT/Mentor/lily/parser.yy:803 msgid bad expression type msgstr instead of just : #: parser.yy:174 parser.yy:188 msgid Too much lookahead msgstr #: parser.yy:466 parser.yy:736 parser.yy:803 msgid bad expression type msgstr As a matter of fact, only lily/lexer.ll and lily/parser.yy are concerned with the duplication. I suspect it comes from ALL_PO_SOURCES which gets defined in stepmake/stepmake/po-targets.make, but am not sure how to fix it. Once again, this does not occur when NOT building out of tree (you know I prefer a local clone). Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various clean-ups in stems and beams. (issue 6584045)
On 3 nov. 2012, at 12:26, d...@gnu.org wrote: http://codereview.appspot.com/6584045/diff/12001/lily/stem.cc#newcode812 lily/stem.cc:812: Real beg = robust_scm2double (me-get_pure_property (stem-begin-position, 0, INT_MAX), 0.0); Using robust_scm2double does not help when me is 0. This still needs LY_ASSERT_TYPE or similar. Hey David, I finally had a chance to read these over - many thanks! For LY_ASSERT_TYPE, I agree with you that this should be used all over the place. Unfortunately, it is not. If you read the code base, you will see that almost every single callback leaves grobs untested, which would cause segfaults for null pointers. I think the best idea would be to open up a separate tracker issue that talks about this problem. Given how often the first argument of scheme callbacks is a grob, it may be worth it to create macros MAKE_SCHEME_GROB_CALLBACK, MAKE_SCHEME_ITEM_CALLBACK, and MAKE_SCHEME_SPANNER_CALLBACK. The macros would roll in a LY_ASSERT_TYPE, thus avoiding writing it out in every function. I'll make sure to fix everything in your other comments, but stuff pertaining to LY_ASSERT_TYPE should wait until we figure out a policy on how this should be handled across all callbacks. While we wait for that to get sorted out, we could create a moratorium on pushing any patches that create new callbacks, although I think that'd be a bit excessive. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various clean-ups in stems and beams. (issue 6584045)
On 3 nov. 2012, at 12:26, d...@gnu.org wrote: http://codereview.appspot.com/6584045/diff/1/scm/output-lib.scm#newcode85 scm/output-lib.scm:85: (left-height (if (= direction DOWN) Is direction sure to be non-null? Thanks again for the review. Aleksandr can respond to this better than I can. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add alias in Spanish for espanol note names language (issue 6811060)
janek.lilyp...@gmail.com: Ah, so \language español will do the same as \language espanol? That's nice. http://codereview.appspot.com/__6811060/ As far as I see, there is no language french or français. Would it be an idea to add french, francais and français as aliases to italiano (like español above)? According to my knowledge in French, the note names are the same and bémol/dièse also fits with the Italian abbreviations -b/-d. The French documentation already uses italiano as example: http://lilypond.org/doc/v2.16/Documentation/notation/writing-pitches.fr.html#note-names-in-other-languages Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Releases 2.17.6 and 2.16.1
On Sat, Nov 03, 2012 at 04:29:53PM -, Phil Holmes wrote: I finished building 2.17.6 about 30 minutes ago. Gub failed again, but I know how to fix this manually and have done so, so it's ready for upload. I suggest a moratorium on releases until GUB works. Too many things can go wrong when manual steps are required. I've just pushed a commit to gperciva/gub that will likely fix this - although this is somewhat by inspection so if anyone knows more of the internals of gub and can comment, I'd be happy. This looks questionable to me: -NATIVE_BUILD_COMMITTISH=$(shell cat $(LILYPOND_REPO_BRANCH_DIR)/refs/heads/$(LILYPOND_DIRRED_BRANCH)) +NATIVE_BUILD_COMMITTISH=$(shell cat $(LILYPOND_REPO_DIR)/git/refs/heads/$(LILYPOND_DIRRED_BRANCH)) Isn't _BRANCH_DIR vs. _DIR how we distinguish between master and release/unstable and stable/2.16 ? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows optional octavation for clefs (issue 6813044)
On Fri, Nov 2, 2012 at 10:20 PM, Marc Hohl m...@hohlart.de wrote: Am 02.11.2012 09:58, schrieb janek.lilyp...@gmail.com: http://codereview.appspot.com/6813044/diff/6001/lily/clef-engraver.cc#newcode125 lily/clef-engraver.cc:125: if (ly_is_procedure (formatter)) it seems that octavation won't work at all if clefOctavationFormatter is not a procedure. Do we want this? Yes. clefOctavationFormatter is set in ly/engraver-init.ly, so by default, it is a procedure. If the user clears the default setting or defines something else instead, then he has to carry the consequences ;-) Maybe there should be a warning? http://codereview.appspot.com/6813044/diff/6001/scm/define-context-properties.scm#newcode200 scm/define-context-properties.scm:200: (cueClefOctavationFormatter ,procedure? A procedure that takes the maybe it would be a good idea to merge this with clefOctavationFormatter? Or is it not possible? In ly/engraver-init.ly, clefOctavationFormatter and cueClefOctavationFormatter are initialized to use the same function, but I think the user should be able to define/choose different functions for each clef type. ah, ok. Missed that. http://codereview.appspot.com/6813044/diff/6001/scm/parser-clef.scm#newcode149 scm/parser-clef.scm:149: ;; not 'default to calm display-lily-tests.scm i don't understand this comment... As could be seen on http://code.google.com/p/lilypond/issues/detail?id=2933#c4 http://code.google.com/p/lilypond/issues/detail?id=2933#c12 http://code.google.com/p/lilypond/issues/detail?id=2933#c15 display-lily-tests.scm complains about a new property set to 'default. David proposed to either change display-lily-tests.scm or to avoid setting an unused property (which it is, in this case) with a strong preference to the latter case. So that's what I did. ok. It may be a good idea to reword the comment a bit, but it's not very important. http://codereview.appspot.com/6813044/diff/6001/scm/parser-clef.scm#newcode170 scm/parser-clef.scm:170: (define-public (make-cue-clef-set clef-name) Again, this piece of code looks the same as make-clef-set. Could it be merged? Well, in the original code there were two functions, so I just extended them. I don't see a *simple* way of merging the two functions into one. ok, let's leave it alone for now. LGTM thanks! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add alias in Spanish for espanol note names language (issue 6811060)
janek.lilyp...@gmail.com: Ah, so \language español will do the same as \language espanol? That's nice. http://codereview.appspot.com/__6811060/ As far as I see, there is no language french or français. Would it be an idea to add french, francais and français as aliases to italiano (like español above)? According to my knowledge in French, the note names are the same and bémol/dièse also fits with the Italian abbreviations -b/-d. The French documentation already uses italiano as example: http://lilypond.org/doc/v2.16/Documentation/notation/writing-pitches.fr.html#note-names-in-other-languages Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add alias in Spanish for espanol note names language (issue 6811060)
Joram Berger joram.no...@gmx.de writes: janek.lilyp...@gmail.com: Ah, so \language español will do the same as \language espanol? That's nice. http://codereview.appspot.com/__6811060/ As far as I see, there is no language french or français. Would it be an idea to add french, francais and français as aliases to italiano (like español above)? According to my knowledge in French, the note names are the same and bémol/dièse also fits with the Italian abbreviations -b/-d. I think they may be using ut instead of do. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add alias in Spanish for espanol note names language (issue 6811060)
Joram Berger wrote As far as I see, there is no language french or français. Would it be an idea to add french, francais and français as aliases to italiano (like español above)? do you really want to add /francais/? Eluze -- View this message in context: http://lilypond.1069038.n5.nabble.com/Add-alias-in-Spanish-for-espanol-note-names-language-issue-6811060-tp135697p135774.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add alias in Spanish for espanol note names language (issue 6811060)
Eluze elu...@gmail.com writes: Joram Berger wrote As far as I see, there is no language french or français. Would it be an idea to add french, francais and français as aliases to italiano (like español above)? do you really want to add /francais/? It's not likely more scary to the French than espanol is to the Spanish. Basically there are two options making sense to me: native language name in utf-8, or English language name (french, spanish). But misspelled native language name seems unattractive as primary interface. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
