Re: Adds a glyph for tied lyrics. (issue4808074)
Please use tabs in MF files. Besides that, everythings looks fine. http://codereview.appspot.com/4808074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: where X-extent of noteheads is set?
>
> I've done a very dirty test which showed that a properly set glyph
> bounding box solves this perfectly (see in the attachment how the
> bounding box should change).
> However, there is a problem. Currently bounding box is set by
> procedure draw_outside_ellipse (defined in mf/feta-params.mf) - it is
> not set in the definition of the glyph. How to set glyph bounding box
> to something different than outside_ellipse bounding box?
You could define it in the "final" definitions of glyphs. Here is an
example. Of course, these values have to be define in a clean metafont way.
fet_beginchar ("Brevis notehead", "sM1");
draw_brevis (1, 1);
draw_staff (-2, 2, 0);
set_char_box (.1 staff_space#, 2.1 staff_space#, .5 staff_space#, .5
staff_space#);
fet_endchar;
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
David Kastrup gnu.org> writes: > Looks like we associate differing meanings with one or several of the > words "unless", "somebody" or "objects". > Oops. I'm delaying pushing. The troublesome word was the verb "keep", from "I'd like to keep". Of course you can keep it, on your branch. If the test remains in input/regression, then anyone inspecting the tests will think that \revert of nested properties worked completely in version 2.14 but now fails. Does anyone object to removing the test 'nested-property-revert.ly' from the input/regression? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Circular dependencies for beam-skip.ly
mike apollinemike.com apollinemike.com> writes:
> I'm getting a lot of circular dependencies for
> input/regression/beam-skip.ly from the current master.
> I don't have time to do a full git bisect, but is this
> standard behavior?
>
You should have a word with the gentleman who pushed that test and
caused us all this inconvenience.
The rest position depends on the beam, which depends on the stem-direction
of the rest, since there are only rests under the beam, which depends...
I replaced the test with something else that exposes the same bug, 1706,
but without all the warnings
\new Voice << { c'4 c'8 c' } { s8[ s] s[ s] } >>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
Keith OHara writes: > David Kastrup gnu.org> writes: > >> Keith OHara oco.net> writes: >> > >> > Unless somebody objects, I will remove 'nested-property-revert.ly' from >> > the test suite; The test code still exists in the open issue 1063. >> >> I'd like to keep this test as I am working on the full functionality. >> It will likely get extended in the end to cover more cases, but it is >> useful as a start already. > > Thanks, David. > > Since you are keeping a copy, and there is a copy on 1063, I will remove it > from input/regression right away. > > Don't forget to make an extra copy before you next rebase the branch on which > you are working on 1063; you will probably need to `git add` it back to that > branch. Looks like we associate differing meanings with one or several of the words "unless", "somebody" or "objects". -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
David Kastrup gnu.org> writes: > Keith OHara oco.net> writes: > > > > Unless somebody objects, I will remove 'nested-property-revert.ly' from > > the test suite; The test code still exists in the open issue 1063. > > I'd like to keep this test as I am working on the full functionality. > It will likely get extended in the end to cover more cases, but it is > useful as a start already. > Thanks, David. Since you are keeping a copy, and there is a copy on 1063, I will remove it from input/regression right away. Don't forget to make an extra copy before you next rebase the branch on which you are working on 1063; you will probably need to `git add` it back to that branch. - Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: where X-extent of noteheads is set?
Hi,
i think i know how to fix this
(http://code.google.com/p/lilypond/issues/detail?id=1546 and some
related problems); there are two things to do.
>>> I suppose that noteheads X-extent is wrongly calculated now. Judging
>>> by this
>>> http://lilypond.googlecode.com/issues/attachment?aid=-4756087064344904294&name=test.png&token=22aa1208ff6775e1780efcedc7e7e841&inline=1
>>> , all noteheads are assigned the same X-extent, even though the glyphs
>>> have different widths.
>>
>> No, the problem is that the code doesn't account for differences in
>> font-size between heads; all the hard-coded shifts it calculates
>
> You mean the values in lines 264-291 of note-collision.cc?
>
>> (split equally between heads; heads move away from each other by the
>> same amount) are based on the assumption that meshing notes have the
>> same font-size.
>> Further to this (since I was thinking of collisions between CueVoice
>> and Voice), there are no rules in note-collision.cc which specifically
>> cater for heads with duration logs less than zero (apart from the
>> no-merge rule).
>
> Yes, neither different font-size nor different glyph widths seem to be
> cared for.
This needs to be changed so that shift amount depends on notehead
extent. Anyone willing to help me with this? I'll read the code and
i guess that i won't have much trouble understanding it, but changing
architecture is not what i'm good at.
> 2011/7/18 m...@apollinemike.com :
>>
>>> I don't want to read the value of extent, i want to modify how it's
>>> calculated in case of noteheads.
>>> I suppose that noteheads X-extent is wrongly calculated now. Judging
>>> by this
>>> http://lilypond.googlecode.com/issues/attachment?aid=-4756087064344904294&name=test.png&token=22aa1208ff6775e1780efcedc7e7e841&inline=1
>>> , all noteheads are assigned the same X-extent, even though the glyphs
>>> have different widths.
>>> Or maybe i don't understand how it works...
>>
>> The issue is in the metafont file: see line 160ish in feta-noteheads.mf.
>
> You mean that metafont's char box contains only the notehead, not the lines?
>
> I guess that the problem in general is that sometimes we want to
> include breve's lines in glyph width calculations, and sometimes not.
> Take this example:
>
> \new Voice <<
> { c''1 }
> { \override Staff.NoteHead #'style = #'altdefault g'\breve }
>>>
> (i'm using double-lined breve to magnify the effect)
>
> the whole note and breve are "center-aligned" here - i.e. left-most
> edge of breve glyph is not aligned with left-most edge of whole note.
> I guess it's desired. So, in the case of calculating non-colliding
> note columns we want to ignore the lines. However, in all other cases
> we want to include them - for example in colliding note columns (like
> in 1546), in accidental calculations - see this, it looks quite bad
> now:
>
> \new Voice { \override Staff.NoteHead #'style = #'altdefault
> gis'\breve*1/2 ges' g'! }
>
> The question is - how this should be done?
I've done a very dirty test which showed that a properly set glyph
bounding box solves this perfectly (see in the attachment how the
bounding box should change).
However, there is a problem. Currently bounding box is set by
procedure draw_outside_ellipse (defined in mf/feta-params.mf) - it is
not set in the definition of the glyph. How to set glyph bounding box
to something different than outside_ellipse bounding box?
cheers,
Janek
<><><><>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Adds a glyph for tied lyrics. (issue4808074)
Reviewers: , Message: Better handling of lyric ties: * The space between two tied words is no more fixed. Its value is word-space. The default space is therefore decreased. * New glyph, so that we won't need an external font. * Increased vertical space between words and tie. It is therefore now possible to have commas in tied lyrics without any collision (example: verte,~et). How to build it: rm mf/out/feta* make Regards, Bertrand Description: Adds a glyph for tied lyrics. Please review this at http://codereview.appspot.com/4808074/ Affected files: M Documentation/de/notation/vocal.itely M Documentation/es/notation/vocal.itely M Documentation/fr/notation/vocal.itely M Documentation/notation/vocal.itely M mf/feta-generic.mf M mf/feta-test-generic.mf A mf/feta-ties.mf M scm/define-markup-commands.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
Keith OHara writes: > No need for a new tracked issue. 'nested-property-revert.ly' was the test > for issue 1063. > > It is now clear that issue 1063 was never really fixed. The goal was to > make \revert restore the default value in more situations. > The patch made 'nested-property-revert.ly' work, > but made 'property-nested-revert.ly' fail, > as noted in issue 1771. These similarly-named tests cover the same concept. > > Version 2.14 did not actually get the desired behavior that issue 1063 asked > for, so there is no meaningful regression. > > Unless somebody objects, I will remove 'nested-property-revert.ly' from > the test suite; The test code still exists in the open issue 1063. I'd like to keep this test as I am working on the full functionality. It will likely get extended in the end to cover more cases, but it is useful as a start already. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a starting point to 1301
2011/7/19 Neil Puttock : > 2011/7/18 Janek Warchoł : > >> My friend and I, having some spare time, wanted to fix a bug >> http://code.google.com/p/lilypond/issues/detail?id=1301. It's related >> to planning distribution of music notes and other signs, so we need >> some overview how the whole process works. Comments in the source >> code are rare and in the documentation we couldn't find a word about >> it. Where could we find some info? > > The clef is on a loose column (it floats before the head), so the > first place I'd look would be lily/spacing-loose-columns.cc (and > possibly lily/spacing-determine-loose-columns.cc). > > I'd guess the problem is the way loose columns are spaced between > other columns: in this snippet, the columns for the quaver and tuplet > minim are so close together that the clef's column gets dumped on top > of the quaver (since it's loose, it doesn't influence the spacing). Sorry for not responding earlier... My friend and I didn't have a chance to work on this again yet (it's too difficult for me - i tried reading that code and i'm a bit lost, so i prefer to work on things easier for me), but in order not to waste your answer, maybe let's add it to CG/Programming work/miscellaney ? I attach a patch. thanks, Janek From f889ee5ee4b4277039723a02f549c42fb90f6401 Mon Sep 17 00:00:00 2001 From: Janek Warchol Date: Sat, 6 Aug 2011 23:32:27 +0200 Subject: [PATCH] CG: add info about spacing from e-mail --- Documentation/contributor/programming-work.itexi | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/Documentation/contributor/programming-work.itexi b/Documentation/contributor/programming-work.itexi index 593e456..e64fa16 100644 --- a/Documentation/contributor/programming-work.itexi +++ b/Documentation/contributor/programming-work.itexi @@ -1679,6 +1679,16 @@ We create lots of extra grobs (eg. a BarNumber at every bar line) but most of them are not drawn. See the break-visibility property in item-interface. +Here is another e-mail exchange. Janek Warchoł asked for a starting point +to fixing 1301 (change clef colliding with notes). Neil Puttock replied: + +The clef is on a loose column (it floats before the head), so the +first place I'd look would be lily/spacing-loose-columns.cc (and +possibly lily/spacing-determine-loose-columns.cc). +I'd guess the problem is the way loose columns are spaced between +other columns: in this snippet, the columns for the quaver and tuplet +minim are so close together that the clef's column gets dumped on top +of the quaver (since it's loose, it doesn't influence the spacing). @node Info from Han-Wen email @subsection Info from Han-Wen email -- 1.7.0.4 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lily/auto-beam-engraver: keep a Context_handle to starting Staff (issue4830064)
Passes make and reg tests http://codereview.appspot.com/4830064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
Phil Holmes philholmes.net> writes: > > > "Phil Holmes" philholmes.net> writes: > > > >> One major change from 2.15.7 - in nested-property-revert.ly. I'm > >> assuming this is down to David's reversion of an earlier commit. > I think this needs to be added to the tracker, and would normally count as > critical regression. Phil, No need for a new tracked issue. 'nested-property-revert.ly' was the test for issue 1063. It is now clear that issue 1063 was never really fixed. The goal was to make \revert restore the default value in more situations. The patch made 'nested-property-revert.ly' work, but made 'property-nested-revert.ly' fail, as noted in issue 1771. These similarly-named tests cover the same concept. Version 2.14 did not actually get the desired behavior that issue 1063 asked for, so there is no meaningful regression. Unless somebody objects, I will remove 'nested-property-revert.ly' from the test suite; The test code still exists in the open issue 1063. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes bad slur heights by limiting fit_factor to the interior of slurs. (issue4810072)
Passes make and one reg test difference http://code.google.com/p/lilypond/issues/detail?id=163#c23 see attached there. http://codereview.appspot.com/4810072/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates a glissando stem grob that uses stems' functionality. (issue4777044)
make fails. --snip-- -DHAVE_CONFIG_H -DNDEBUG -I/home/jlowe/lilypond-git/lily/include -I./out -I/home/jlowe/lilypond-git/flower/include -I../flower/./out -I../flower/include -I/home/jlowe/lilypond-git/lily/out -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2 -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wno-pmf-conversions -W -Wall -Wconversion -o out/note-head-line-engraver.o /home/jlowe/lilypond-git/lily/note-head-line-engraver.cc /home/jlowe/lilypond-git/lily/glissando-stem.cc:134: warning: unused parameter 'smob' /home/jlowe/lilypond-git/lily/glissando-stem.cc: In static member function 'static scm_unused_struct* Glissando_stem::calc_head_positions(scm_unused_struct*)': /home/jlowe/lilypond-git/lily/glissando-stem.cc:154: error: 'VALGRIND_PRINTF_BACKTRACE' was not declared in this scope make[1]: *** [out/glissando-stem.o] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory `/home/jlowe/lilypond-git/build/lily' make: *** [all] Error 2 jlowe@jlowe-lilybuntu2:~/lilypond-git/build$ sorry James http://codereview.appspot.com/4777044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 40. (issue4801083)
Pass make and reg tests http://codereview.appspot.com/4801083/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Progress on loose columns. (issue4841052)
On Sat, 06 Aug 2011 01:52:27 -0700, m...@apollinemike.com wrote: Do you know where these reference points are specified? No, but the extents of each glyph are calculated relative to the reference points, so from the extents we can figure how long to make the rods to prevent the glyphs from touching, etc. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On Sat, 06 Aug 2011 00:13:49 -0700, Jan Warchoł wrote: 2011/8/6 Keith OHara : "order in which the project encourages contributors to attack issues". Sounds good to me. Still, decision depends on our views about relative importance of user needs vs. developer needs. Decision of the contributor on what to attack next, right? We could collectively agree how to assign "priorities", right now -- without all agreeing on whether the precise spacing of notes in boring monophonic music is more or less important than making readable interesting piano music with clef changes and staff-crossings :-) On Sat, 06 Aug 2011 00:55:46 -0700, James Lowe wrote: This sounds a bit like "let's drop 'priority' field and use labels only" :) - OK but it still doesn't get away from the 'when do we release the next stable release' question if we only have labels? I don't think Janek was suggesting we drop the field, only that my suggestion sounds more like a label than a rank. When it's time for a release we make sure the Critical issues are solved. Right before a release individual contributors will probably prefer to concentrate on ugliness issues, whether we assign them High or Medium, and go back to maintenance issues after the release. Also let's say I have 20 'ugly output' issues, how do I as a user show my preference for one or more of them so that a dev who has the skill and choice to work on any knows which one will benefit the project from a user's perspective? How do you do it now? Star the issue. Post a well-considered description of what the good output would be, maybe with a reference, so the developer knows how to proceed without making a trip to the library. Complaining about how bad the bug is tends to back-fire, but sometimes we need some explanation why the buggy output is actually wrong. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (final)
On Sat, 06 Aug 2011 03:13:33 -0700, Phil Holmes wrote: From: "Keith OHara" I agree, and want `make bin` to show me warnings. I might have been taking the proposal too literally. I know no reason why it shouldn't. Have you tried putting code that emits errors or warnings into /lily and running make bin? Make does show warnings on the terminal right now. make -s bin lets me find them, which makes me very happy. Only after the proposal is fully implemented, will a successful build stop showing me the warnings. I'd be happy if we leave the redirection-to-file of stderr from gcc and standard tools, as the last piece to implemented in the proposal. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixes issue 40. (issue4801083)
Reviewers: ,
Message:
Here's a fix for Issue 40.
Cheers,
MS
Description:
Fixes issue 40.
Please review this at http://codereview.appspot.com/4801083/
Affected files:
M lily/line-spanner.cc
M scm/define-grobs.scm
Index: lily/line-spanner.cc
diff --git a/lily/line-spanner.cc b/lily/line-spanner.cc
index
b2877211f17d31eac7fb87ead457feadaf892777..ade5b7d4bc1ee6ee287997733eb88c844cd422d5
100644
--- a/lily/line-spanner.cc
+++ b/lily/line-spanner.cc
@@ -24,6 +24,7 @@
#include "item.hh"
#include "lily-proto.hh"
#include "line-interface.hh"
+#include "note-column.hh"
#include "output-def.hh"
#include "pointer-group-interface.hh"
#include "spanner.hh"
@@ -108,9 +109,13 @@ Line_spanner::calc_bound_info (SCM smob, Direction dir)
? columns[0] : columns.back ();
}
+ Real x_coord = robust_relative_extent (bound_grob, commonx,
X_AXIS).linear_combination (attach);
+ Grob *acc = Note_column::accidentals (bound_grob->get_parent
(X_AXIS));
+ if (acc && to_boolean (ly_assoc_get (ly_symbol2scm
("end-on-accidental"), details, SCM_BOOL_F)))
+x_coord = robust_relative_extent (acc, commonx,
X_AXIS).linear_combination (attach);
+
details = scm_acons (ly_symbol2scm ("X"),
- scm_from_double (robust_relative_extent
(bound_grob, commonx, X_AXIS)
-.linear_combination (attach)),
+ scm_from_double (x_coord),
details);
}
Index: scm/define-grobs.scm
diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
index
4545e5bd9f6f7c130267397d3947812e31c82881..b618516173eea8f5ad10f5b9514e8999f0ddfc8d
100644
--- a/scm/define-grobs.scm
+++ b/scm/define-grobs.scm
@@ -929,11 +929,12 @@
(Glissando
. (
(after-line-breaking . ,ly:spanner::kill-zero-spanned-time)
- (bound-details . ((right . ((attach-dir . ,CENTER)
- (padding . 1.5)
+ (bound-details . ((right . ((attach-dir . ,LEFT)
+ (end-on-accidental . #t)
+ (padding . 0.5)
))
- (left . ((attach-dir . ,CENTER)
- (padding . 1.5)
+ (left . ((attach-dir . ,RIGHT)
+ (padding . 0.5)
))
))
(gap . 0.5)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates a glissando stem grob that uses stems' functionality. (issue4777044)
I've merged my glissando stem work with current master. It passes
regtests and can currently handle tremoli and scripts (see the regtest).
However, these scripts just kinda float in the ether - they are prone
to bump into anything outside the staff (for now). If anyone has any
suggestions for how to make:
a'4 \glissando
\xenakisStems { s4-.^"foo" }
a''4
such that the staccato does not bump into foo, I'd be much obliged. It
likely has something to do with outside staff skylines and such, but I'm
not sure yet how to negotiate this with pure heights.
Once this gets pushed, I'll work on beams.
Cheers,
MS
http://codereview.appspot.com/4777044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
- Original Message -
From:
To: ; ;
Cc: ;
Sent: Saturday, August 06, 2011 4:23 PM
Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly
File input/regression/mozart-hrn-3.ly (right):
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode25
input/regression/mozart-hrn-3.ly:25: \fill-line { "This music is part of
the Mutopia project,"
On 2011/08/06 14:57:14, PhilEHolmes wrote:
On 2011/08/02 19:59:39, Neil Puttock wrote:
Can't see a missing line. I was trying to recreate the old
regtest, but with better syntax, so wasn't adding lines
where they didn't exist.
Not a missing line, but a missing \line (the markup command); I suspect
it's a convert-ly problem from a while back (when the markup syntax
changed).
Here's the last page from the 2.4 docs:
http://lilypond.org/doc/v2.4/input/mutopia/W.A.Mozart/out-www/mozart-hrn-3-page4.png
http://codereview.appspot.com/4811066/
Thanks for your time on this one Neil. Final patch (?) uploaded for
review - it uses \line where appropriate, I hope. (BTW - I also got rid of
the code that changed the beams and stems - I think it's better without.)
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
Neil Puttock writes:
> On 6 August 2011 15:31, David Kastrup wrote:
>
>> I have a hard time counting the removal of a band aid for an artificial
>> test case with undefined behavior (try finding a place in the user
>> documentation that declares this kind of code as producing predictable
>> results) as a regression because the original code did not fix the
>> underlying problem, but merely masked it.
>
> So how would you expect the following code to behave? It's the
> snippet from the original bug report, which segfaulted in stem.cc.
>
> \relative c' {
> \time 2/4
> \voiceOne
> s16 [g s g ] s16 [g s g ] |
> s16 [g s g ] \override Stem #'(details beamed-lengths) = #'(15 15)
> s16 [g s g ] |
> s16 [g s g ] s16 [g s g ] |
> s16 [g s g ] \revert Stem #'(details beamed-lengths) s16 [g s g ] |
> s16 [g s g ] s16 [g s g ] |
> }
>
> The regression test is deliberately artificial since it gives a clear
> indication of failure, which this code doesn't (the segfault no longer
> occurs due to checking the nested property is a pair before using
> robust_list_ref). I don't think it's unreasonable to expect this code
> to return 'beamed-lengths to the default value defined in
> define-grobs.scm.
The problem is that you can't reliably distinguish
\override Stem #'(details) = #'(beamed-lengths 15 15)
from
\override Stem #'(details beamed-lengths) = #'(15 15)
Maybe something like
(eq? (assq-ref (cdr alist) (caar alist)) (cddar alist))
could determine whether we are still on the spine leading to the
nested override or beyond it, but I am skeptical, and it still does not
solve the problem that updating a nested property in a parenting context
will require updating of the copies in the current context.
In any case, I am not interested in policies. Mark this whatever you
like, use whatever inconsistent behavior you like. The smaller code is
more useful as a starting point for reasonably sensible and correct
behavior, and I never suggested that it stay in either of the incorrect
states.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes bad slur heights by limiting fit_factor to the interior of slurs. (issue4810072)
On Aug 6, 2011, at 11:09 AM, lemniskata.bernoull...@gmail.com wrote: > Hi Mike, > > i tried writing a review, but i don't understand what's going on here. > Can you add some comments to the code? > > cheers, > Janek > The function fit_factor pushes up the height of a slur if there is an extra-encompass-object in the way. My change makes this function ignore all extra-encompass-objects close to the extremes of a slur, as these objects have a tendency to push a slur up disproportionately high. These objects are still penalized in the scoring, which results in their avoidance if possible. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly
File input/regression/mozart-hrn-3.ly (right):
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode25
input/regression/mozart-hrn-3.ly:25: \fill-line { "This music is part of
the Mutopia project,"
On 2011/08/06 14:57:14, PhilEHolmes wrote:
On 2011/08/02 19:59:39, Neil Puttock wrote:
Can't see a missing line. I was trying to recreate the old
regtest, but with better syntax, so wasn't adding lines
where they didn't exist.
Not a missing line, but a missing \line (the markup command); I suspect
it's a convert-ly problem from a while back (when the markup syntax
changed).
Here's the last page from the 2.4 docs:
http://lilypond.org/doc/v2.4/input/mutopia/W.A.Mozart/out-www/mozart-hrn-3-page4.png
http://codereview.appspot.com/4811066/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
On 6 August 2011 15:31, David Kastrup wrote:
> I have a hard time counting the removal of a band aid for an artificial
> test case with undefined behavior (try finding a place in the user
> documentation that declares this kind of code as producing predictable
> results) as a regression because the original code did not fix the
> underlying problem, but merely masked it.
So how would you expect the following code to behave? It's the
snippet from the original bug report, which segfaulted in stem.cc.
\relative c' {
\time 2/4
\voiceOne
s16 [g s g ] s16 [g s g ] |
s16 [g s g ] \override Stem #'(details beamed-lengths) = #'(15 15)
s16 [g s g ] |
s16 [g s g ] s16 [g s g ] |
s16 [g s g ] \revert Stem #'(details beamed-lengths) s16 [g s g ] |
s16 [g s g ] s16 [g s g ] |
}
The regression test is deliberately artificial since it gives a clear
indication of failure, which this code doesn't (the segfault no longer
occurs due to checking the nested property is a pair before using
robust_list_ref). I don't think it's unreasonable to expect this code
to return 'beamed-lengths to the default value defined in
define-grobs.scm.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
- Original Message -
From:
To: ;
Cc: ;
Sent: Saturday, August 06, 2011 3:57 PM
Subject: Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
Again - not too familiar with the codereview tool, so I hope this makes
sense. New patch set soon.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly
File input/regression/mozart-hrn-3.ly (right):
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode25
input/regression/mozart-hrn-3.ly:25: \fill-line { "This music is part of
the Mutopia project,"
On 2011/08/02 19:59:39, Neil Puttock wrote:
Can't see a missing line. I was trying to recreate the old
regtest, but with better syntax, so wasn't adding lines
where they didn't exist.
Hmm. Wherever it says "Neil Puttock wrote" it means Neil made a comment
here and I responded with the words below. Must work out how the codereview
site works...
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
Again - not too familiar with the codereview tool, so I hope this makes
sense. New patch set soon.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly
File input/regression/mozart-hrn-3.ly (right):
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode25
input/regression/mozart-hrn-3.ly:25: \fill-line { "This music is part of
the Mutopia project,"
On 2011/08/02 19:59:39, Neil Puttock wrote:
Can't see a missing line. I was trying to recreate the old
regtest, but with better syntax, so wasn't adding lines
where they didn't exist.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode28
input/regression/mozart-hrn-3.ly:28: \fill-line { #(ly:export
(string-append "It has been typeset and placed in the public "
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode29
input/regression/mozart-hrn-3.ly:29: "domain by " maintainer "."))
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode31
input/regression/mozart-hrn-3.ly:31: \fill-line { #(ly:export
(string-append "Unrestricted modification and redistribution"
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode32
input/regression/mozart-hrn-3.ly:32: " is permitted and
encouraged---copy this music"
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode33
input/regression/mozart-hrn-3.ly:33: " and share it!"))
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode53
input/regression/mozart-hrn-3.ly:53: system-system-spacing
#'basic-distance = 10 \mm
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode54
input/regression/mozart-hrn-3.ly:54: score-system-spacing
#'basic-distance = 20 \mm
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode61
input/regression/mozart-hrn-3.ly:61: \header { piece = "Allegro" opus =
"" }
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode73
input/regression/mozart-hrn-3.ly:73: \header { piece = "Romanze" opus =
"" }
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode82
input/regression/mozart-hrn-3.ly:82: \layout {}
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn-3.ly#newcode88
input/regression/mozart-hrn-3.ly:88: \header { piece = "Rondo" opus = ""
}
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn3-defs.ily
File input/regression/mozart-hrn3-defs.ily (right):
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn3-defs.ily#newcode16
input/regression/mozart-hrn3-defs.ily:16: \override MultiMeasureRest
#'padding = #0.5
On 2011/08/02 19:59:39, Neil Puttock wrote:
If it doesn't do anything, I'll just take it out.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn3-defs.ily#newcode22
input/regression/mozart-hrn3-defs.ily:22: \override Beam #'thickness =
#0.6
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn3-defs.ily#newcode23
input/regression/mozart-hrn3-defs.ily:23: \override Beam
#'space-function = #(lambda (beam mult) 0.8)
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn3-defs.ily#newcode27
input/regression/mozart-hrn3-defs.ily:27: \override VerticalAxisGroup
#'minimum-Y-extent = #'(-2.5 . 3.5)
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn3-defs.ily#newcode32
input/regression/mozart-hrn3-defs.ily:32: indent = 10. \mm
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn3-defs.ily#newcode33
input/regression/mozart-hrn3-defs.ily:33: line-width = 189. \mm
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn3-rondo.ily
File input/regression/mozart-hrn3-rondo.ily (right):
http://codereview.appspot.com/4811066/diff/1/input/regression/mozart-hrn3-rondo.ily#newcode23
input/regression/mozart-hrn3-rondo.ily:23: rondo =\relative c' {
On 2011/08/02 19:59:39, Neil Puttock wrote:
Done.
http://codereview.appspot.com/4811066/
__
Re: 2.15.8 Regtests
"Phil Holmes" writes: >> "Phil Holmes" writes: >> >>> One major change from 2.15.7 - in nested-property-revert.ly. I'm >>> assuming this is down to David's reversion of an earlier commit. I'm >>> not expert enough to say what should happen here, although it doesn't >>> look right to me. >> >> This "should not" is not achievable with the current data structures >> without causing other regressions even harder to explain (which already >> happened). So I picked the less complex code and behavior as a starting >> point for first fixing the data structures, then the code. >> >> The test case is quite artificial and, in my opinion, not worth fixing >> temporarily at the cost of breaking more straightforward code. > > I think this needs to be added to the tracker, and would normally > count as critical regression. I'm tempted to mark it regression - > high - since it's only there because of another critical that you > fixed (IIRC) and you are working on it. You OK with that? I have a hard time counting the removal of a band aid for an artificial test case with undefined behavior (try finding a place in the user documentation that declares this kind of code as producing predictable results) as a regression because the original code did not fix the underlying problem, but merely masked it. As a rather silly analogy: imagine that I put exit(0) right at the start of the main program. Somebody takes it out eventually, and I demand that every segfault needs now to be labelled as a regression since Lilypond did not segfault with my fix installed. Bluntly: unmatched nested overrides/reverts never ever worked sensibly, and actually their behavior never has been defined in the user documentation either. That we temporarily had a "fix" that was hand-crafted to match the only test-case in our regression tests in order to make just this test produce more intuitive results, does not change that. So I don't see the regression, and frankly, I don't see the high importance as the feature could not be used predictably at any point of time. It is a rather new and, obviously, largely untested feature. If you tread carefully (and this test case doesn't), you are likely to get what you expect. There is a cheap workaround: don't revert a nested property that you did not override in the same manner and order. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
- Original Message -
From: "David Kastrup"
To:
Sent: Saturday, August 06, 2011 3:04 PM
Subject: Re: 2.15.8 Regtests
"Phil Holmes" writes:
One major change from 2.15.7 - in nested-property-revert.ly. I'm
assuming this is down to David's reversion of an earlier commit. I'm
not expert enough to say what should happen here, although it doesn't
look right to me.
It's work in progress, I am afraid. If you take a look at the source
code, you'll see that it is quite dubious:
\version "2.14.0"
\header {
texidoc = "
If a nested property revert follows an override in the same grob for
a different property, the nested property's default setting should not
be evicted from the property alist.
"
}
\relative c' {
c1\startTrillSpan
c1\stopTrillSpan
\override TrillSpanner #'color = #red
\revert TrillSpanner #'(bound-details left text)
c1\startTrillSpan
c1\stopTrillSpan
}
This "should not" is not achievable with the current data structures
without causing other regressions even harder to explain (which already
happened). So I picked the less complex code and behavior as a starting
point for first fixing the data structures, then the code.
The test case is quite artificial and, in my opinion, not worth fixing
temporarily at the cost of breaking more straightforward code.
So this is work in progress. I am on it, but currently I need to find
the source of a segmentation fault. If we are lucky, it is the same
already marked down as critical.
I think this needs to be added to the tracker, and would normally count as
critical regression. I'm tempted to mark it regression - high - since it's
only there because of another critical that you fixed (IIRC) and you are
working on it. You OK with that?
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
"Phil Holmes" writes:
> One major change from 2.15.7 - in nested-property-revert.ly. I'm
> assuming this is down to David's reversion of an earlier commit. I'm
> not expert enough to say what should happen here, although it doesn't
> look right to me.
It's work in progress, I am afraid. If you take a look at the source
code, you'll see that it is quite dubious:
\version "2.14.0"
\header {
texidoc = "
If a nested property revert follows an override in the same grob for
a different property, the nested property's default setting should not
be evicted from the property alist.
"
}
\relative c' {
c1\startTrillSpan
c1\stopTrillSpan
\override TrillSpanner #'color = #red
\revert TrillSpanner #'(bound-details left text)
c1\startTrillSpan
c1\stopTrillSpan
}
This "should not" is not achievable with the current data structures
without causing other regressions even harder to explain (which already
happened). So I picked the less complex code and behavior as a starting
point for first fixing the data structures, then the code.
The test case is quite artificial and, in my opinion, not worth fixing
temporarily at the cost of breaking more straightforward code.
So this is work in progress. I am on it, but currently I need to find
the source of a segmentation fault. If we are lucky, it is the same
already marked down as critical.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.15.8 Regtests
One major change from 2.15.7 - in nested-property-revert.ly. I'm assuming this is down to David's reversion of an earlier commit. I'm not expert enough to say what should happen here, although it doesn't look right to me. -- Phil Holmes Bug Squad <>___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
On 06/08/11 08:47, David Kastrup wrote: > The compromises between the wishes of people and the technical feasible > things and those you want to do are a moving target. And the > responsibility for making technical and logical impossibilities > disappear, to match the program better to expectations and requirements, > is only something the experienced programmer can do. Sometimes the > results please the user more than the programmer. It is hard to > generalize this into policies, since a policy would not change its mind > if enough people bother it. And sometimes, the user needs results that the programmer hates. At the moment, I've got a piece of music I need to clean up because it looks awful. And it looks awful because I've forced it into a straitjacket it doesn't fit properly. BUT. The whole philosophy of lilypond is that beautiful music is easily playable music. *Mostly* that's true. But as a bandsman, I place a *very* high penalty on page breaks. I wish I could force lily to force music on to one, or at most two, pages. But that goes completely against the grain of what most lily people want. Unfortunately, to me, music with page turns can far too easily be unplayable. It's all very well saying "it's easier to read" but that's no consolation when it's doing a fifty yard sprint down the field away from me! :-) I know asking users to categorise importance to them is hard - yes they'll often say any bug is a serious bug - but to me for example printing one last stave on page two instead of cramming it onto page one is a massive failing of lily as a "master engraver". No disrespect to the programmers (heck, I'm trying to become a contributor myself, in part because I want to correct the failings I see), but by default lily does a very poor job of minimising wasted space by default on small scores. To me that's a very serious failing, but most programmers don't see that. Maybe we should have some scoring system whereby things are graded both on importance to user, and ease of fixing, along with program integrity (ie how serious a programmer would rate it - segfault, buggy code, etc). My formatting issues would probably rate about 1 on ease of fix and program integrity, but the higher the average score the more critical the feature because fixing it would have a far bigger impact across the board. Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ugliness in the Learning Manual
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sent: Saturday, August 06, 2011 11:26 AM
Subject: Re: Ugliness in the Learning Manual
"Phil Holmes" writes:
Would the following patch help?
\envdef\cartouche{%
+ \ifvmode\the\everypar\fi % trigger headers
\ifhmode\par\fi % can't be in the midst of a paragraph.
\startsavinginserts
\lskip=\leftskip \rskip=\rightskip
I edited the texinfo.tex file in src/tex and recreated the LM. No
difference.
Thanks. It was worth a try, and I currently don't have the time for a
more thorough analysis.
--
David Kastrup
Actually, I've just been looking at this, and your patch almost solves the
problem - *if I change the correct file*. I already have texinfo installed
on my system, and I noticed that when I run it, part of the output is
(./WarningProb.texi (/usr/share/texmf/tex/texinfo/texinfo.tex
so it's looking at a different texinfo.tex than the one in my lily-git
directory. This applies whether I run in inside the git directory or not.
After a bit of messing about teaching myself how to change permissions so I
could edit that file, I made your change to the texinfo.tex. It was
successful in moving the text of my test file below the header, but not the
box (i.e. it shifted it down about 1 line space).
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ugliness in the Learning Manual
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "James Lowe" ; "Werner LEMBERG" ; Sent: Friday, August 05, 2011 11:54 PM Subject: Re: Ugliness in the Learning Manual On Fri, Aug 05, 2011 at 03:12:23PM +0100, Phil Holmes wrote: )Looks like a bug in texinfo. Can you try to isolate this as much as possible? )What about using the most recent version of texinfo.tex (attached)? That would replace tex/texinfo.tex Nothing in the CG I can see. I think the simplest fix is probably to put a forced new line after the heading. This avoids the problem. I'd rather fix the more fundamental problem. Please try David's patch, and if that doesn't work, then try Werner's new file, and if that doesn't work, try Werner's new file plus David's patch. It'll be a good test of the "build a single manual" command. :) Cheers, - Graham As you see, these don't appear to fix the problem. I think it would be worth applying the forced new line approach - otherwise the first manual that users open looks bad - the sooner it doesn't, the better. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ugliness in the Learning Manual
"Phil Holmes" writes:
>> Would the following patch help?
>> \envdef\cartouche{%
>> + \ifvmode\the\everypar\fi % trigger headers
>> \ifhmode\par\fi % can't be in the midst of a paragraph.
>> \startsavinginserts
>> \lskip=\leftskip \rskip=\rightskip
>>
>
> I edited the texinfo.tex file in src/tex and recreated the LM. No
> difference.
Thanks. It was worth a try, and I currently don't have the time for a
more thorough analysis.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
- Original Message - From: "Jan Warchoł" Going back to your colorful examples, here's what effects i'd expect: +1 on all of those. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no love for LSR (was: Doc: Added \compoundMeter function to NR (issue4837050))
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "Trevor Daniels" ; "James Lowe" ; ; "Lily-Devel List" ; "Valentin Villenave" Sent: Saturday, August 06, 2011 12:13 AM Subject: no love for LSR (was: Doc: Added \compoundMeter function to NR (issue4837050)) On Thu, Aug 04, 2011 at 03:05:42PM +0100, Phil Holmes wrote: I don't run LSR update: I'm an authoriser, but that's all. Yes, it's almost as though there's no amour for LSR. Cheers, - Graham Not at all. It's just not something I do. I like watching cricket on the TV, but have no involvement in the production of the programme. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (final)
- Original Message - From: "Keith OHara" To: Sent: Friday, August 05, 2011 11:07 PM Subject: Re: GOP-PROP 5: build system output (final) Reinhold Kainhofer kainhofer.com> writes: We shouldn't need to type anything to see the warnings/errors of a compile run. I agree, and want `make bin` to show me warnings. I might have been taking the proposal too literally. I know no reason why it shouldn't. Have you tried putting code that emits errors or warnings into /lily and running make bin? I recall doing so and being able to see the errors and warnings, but would be interested in your experience. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (final)
- Original Message - From: "Reinhold Kainhofer" To: Sent: Friday, August 05, 2011 9:09 PM Subject: Re: GOP-PROP 5: build system output (final) Am Freitag, 5. August 2011, 21:22:49 schrieb Keith OHara: Building the program (as opposed to documentation) is now *very* nice, with make -s bin where -s is short for --silent to tell make not to print the commands she runs. We see errors or warnings from the changed files and nothing else. Ah, right, that's nice, but I'm missing the progress ;-) I think it's held up pending discussion - Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (final)
- Original Message - From: "Keith OHara" To: Sent: Friday, August 05, 2011 8:22 PM Subject: Re: GOP-PROP 5: build system output (final) Graham Percival percival-music.ca> writes: ** Proposal details When you run make or make doc, * All output will be saved to various log files, with the exception of output directly from make(1). * By default, no other output will be displayed on the console, with one exception: if a build fails, [...] The user may optionally request additional output to be printed; this is controlled with the VERBOSE=x flag. Building the program (as opposed to documentation) is now *very* nice, with make -s bin where -s is short for --silent to tell make not to print the commands she runs. We see errors or warnings from the changed files and nothing else. The entire source tree generates only seven warnings, all but one of which point to code we could write more clearly. Under this proposal, we should choose an easy-to-type VERBOSE=x option that allows use to see the stderr stream from gcc and yacc and lex. Thanks Keith. Please bear in mind that make bin will only look into the lily directory, so only source files there are rebuilt. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond loglevels & debug output
- Original Message - From: "Reinhold Kainhofer" Of course, this involves env variables, while I would prefer cmd line arguments. The problem is then that you need a (simple) parser to parse the given arguments... Cheers, Reinhold I'm working my way through all the detailed stuff here right now, but, for this: +1 (makes it much easier to launch Lilypond from a "controller" application, which I do). -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ugliness in the Learning Manual
- Original Message -
From: "David Kastrup"
To:
Sent: Friday, August 05, 2011 5:31 PM
Subject: Re: Ugliness in the Learning Manual
"Phil Holmes" writes:
- Original Message -
From: "James Lowe"
To: "Werner LEMBERG" ;
Cc:
Sent: Friday, August 05, 2011 1:42 PM
Subject: RE: Ugliness in the Learning Manual
Hello,
)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Werner LEMBERG
)Sent: 05 August 2011 13:19
)To: m...@philholmes.net
)Cc: lilypond-devel@gnu.org
)Subject: Re: Ugliness in the Learning Manual
)
)
)> Please see the attached image of page 2 of the LM. Anyone know why
)> this collision occurs and how to fix it?
)
)Looks like a bug in texinfo. Can you try to isolate this as much as
possible?
)What about using the most recent version of texinfo.tex (attached)?
)
)
I'm sure Graham will know but it is 'probably ' to do with the
warning/note box construction coming immediately after the Node
without anything in between.
Did you check the CG to see if we mention anything like this - there
are some formatting 'known issues' in that where HTML and PDF don't
always play in the same way.
James
Nothing in the CG I can see. I think the simplest fix is probably to
put a forced new line after the heading. This avoids the problem.
See the attached. I could make a patch with these line breaks
included if you want?
Would the following patch help?
diff --git a/tex/texinfo.tex b/tex/texinfo.tex
index 9140826..b3d1412 100644
--- a/tex/texinfo.tex
+++ b/tex/texinfo.tex
@@ -6038,6 +6038,7 @@ end
\newskip\lskip\newskip\rskip
\envdef\cartouche{%
+ \ifvmode\the\everypar\fi % trigger headers
\ifhmode\par\fi % can't be in the midst of a paragraph.
\startsavinginserts
\lskip=\leftskip \rskip=\rightskip
I edited the texinfo.tex file in src/tex and recreated the LM. No
difference.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
Jan Warchoł writes:
> 2011/8/5 David Kastrup :
>
> I'm not sure if i understand it (is "a" a property or a value?),
Property. I am not yet concerned about values... Anyway, I am not sure
I understand what I write either.
> but it seems to me that \override should indeed not begin with a
> revert.
My current comprehension is that this is likely the intent of the code.
Doesn't work yet, but I'll try figuring out why, and then likely what
change caused this for what reason.
> However, we may need additional command like
> \revertTillDefaultIsReached or sth like that.
>
> Going back to your colorful examples, here's what effects i'd expect:
>
> \relative c' {
> c4
> \once\override Stem #'color = #red
> \override Stem #'color = #blue
> c4 c
> \revert Stem #'color
> c4
> }
>
> black blue blue black
That's a reasonable expectation, but it requires that \once\override
keeps track of just what it is supposed to revert at the end of the time
step. Popping the top of the stack would not work, leaving us with
black, blue, red, black. One possibility would be to store the
\once\override info in a separate location (or with a special mark)
where it does not mix with the \override info.
> \relative c' {
> c4
> \override Stem #'color = #blue
> \once\override Stem #'color = #red
> c4 c
> \revert Stem #'color
> c4
> }
>
> black red blue black
Yup.
> \relative c' {
> c4
> \override Stem #'color = #blue
> \once\override Stem #'color = #red
> \revert Stem #'color
> c4 c
> c4
> }
>
> black black black black.
Actually, I think I'd prefer black, red, black, black. I feel a revert
should not cancel more than one \override, so something should happen at
the second time step. The pure stack approach would leave us with
black, blue, black, black, arguably weird. But pretty easy to explain.
If we aim for black, red, black, black, this would more or less imply
(if things should obey simple rules) that you can _never_ use \revert to
cancel \once\override. However, the syntax already permits
\once\revert, so maintaining what amounts to a separate stack for \once
could work reasonably well and be nice enough to document.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes bad slur heights by limiting fit_factor to the interior of slurs. (issue4810072)
Hi Mike, i tried writing a review, but i don't understand what's going on here. Can you add some comments to the code? cheers, Janek http://codereview.appspot.com/4810072/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
2011/8/5 David Kastrup :
>
> On the hopefully correct assumption that this was intended to go to the
> list and just mistakenly sent in private
Yes, i occasionally misclick the button. Thanks!
> I think that originally \override was a push, \revert was a pop, and
> \once\override was a push/pop pair (that's more or less what is in the
> user docs as well).
>
> Then somebody probably thought that \override\override\revert should be
> a nop since \override has to be used instead of \set anyway (which would
> not push), and turned \override into a pop-push pair (pop never goes
> beyond the current context, so "little harm done"). That explains why
> the first example pairs the pop from the \once\override with the push
> from \override. In the first example, the \override should, when
> cancelling the push from \once\override, not leave the corresponding pop
> lying around to be executed later.
>
> Now take that incoherent mess, and add nested properties into it.
> Apparently the current code has no qualms to start an \override with a
> pop that will cancel an entirely unrelated operation.
>
> Now if we do something like (never mind the value and the syntax)
> \override a.b.c \override a
> should the second \override be able to cancel the first one with its
> implied \revert at its front? How about if we do
> \override a \override a.b.c
> instead? Should the second override be able to cancel the first one?
> Only partially? What if we now do
> \override a \override a.b.c \override a
> How many \revert a should we need to have the stack empty again? If we
> do
> \override a \override a.b.c \revert a.b.c
> what should the state of a.whatever be? Changed against before or not?
> What should the state of a.b.c be? Changed against before (to the value
> set by \override a) or not?
I'm not sure if i understand it (is "a" a property or a value?), but
it seems to me that \override should indeed not begin with a revert.
However, we may need additional command like
\revertTillDefaultIsReached or sth like that.
Going back to your colorful examples, here's what effects i'd expect:
\relative c' {
c4
\once\override Stem #'color = #red
\override Stem #'color = #blue
c4 c
\revert Stem #'color
c4
}
black blue blue black
\relative c' {
c4
\override Stem #'color = #blue
\once\override Stem #'color = #red
c4 c
\revert Stem #'color
c4
}
black red blue black
\relative c' {
c4
\override Stem #'color = #blue
\once\override Stem #'color = #red
\revert Stem #'color
c4 c
c4
}
black black black black.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Progress on loose columns. (issue4841052)
On Aug 5, 2011, at 9:49 PM, Keith OHara wrote: > gmail.com> writes: > >> >> I was assuming that a rod >> attaches to the right of the left `between-columns' and the left of the >> right one? Is this not the case? >> > > I haven't tried the patch yet, but the rods of rods-and-springs measure from > the > reference points of the objects. > The left- and right- sides of columns have protrusions and holes. Usually > the > rod length is based on the distance between reference points where the > skylines > of the columns just touch. > Thanks Keith! Do you know where these reference points are specified? Cheers MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes bad slur heights by limiting fit_factor to the interior of slurs. (issue4810072)
I like this approach. http://codereview.appspot.com/4810072/diff/3002/lily/slur-configuration.cc File lily/slur-configuration.cc (right): http://codereview.appspot.com/4810072/diff/3002/lily/slur-configuration.cc#newcode102 lily/slur-configuration.cc:102: close_to_edge = close_to_edge || -d * (p[X_AXIS] - curve_xext[d]) < close_to_edge_length; This is quite obfuscated. I am too old to remember details like whether LEFT<0 in Lilypond. close_to_edge = p[X_AXIS] < curve_xext[LEFT] + c_t_e_l || p[X_AXIS] > curve_xext[RIGHT] - c_t_e_l; I think you are right to have the ignore region be length in staff-spaces, rather than a fraction of the length of the slur. Did you try both ways? http://codereview.appspot.com/4810072/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 8: issue priorities
Hello, > But any interpretation of "priority" in the sense of "importance" seems > useless. We differ quite a lot in our opinions of importance. I suspect > Janek and I would rank issues in near-opposite order of importance. That > means that any importance-type priority estimated by the contributor who > opens the issue, won't really help other contributors decide what to work on > next. > > Probably, however, we would all sort issues into roughly the same types of > problems: > Regressions, crashes, incorrect output, ugly output, things that get in the > way of contributing, ... > > So, all we really need to do is make useful classifications, and admit that > we won't all agree on their relative priorities. This sounds a bit like "let's drop 'priority' field and use labels only" :) - OK but it still doesn't get away from the 'when do we release the next stable release' question if we only have labels? When we don't have regressions only? regressions + crashes? Are some regressions more 'critical' than others (genuine question) ditto crashes? Also let's say I have 20 'ugly output' issues, how do I as a user show my preference for one or more of them so that a dev who has the skill and choice to work on any knows which one will benefit the project from a user's perspective? After all I see issues bumped 'down' because they seem to have been hanging about for 'ever' and no one shows an interest in it. So issues must also be able to be bumped 'up' right? Therefore Labels in this sense that are just descriptive don't help. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
Jan Warchoł writes: > 2011/8/6 James Lowe : > >> Users and new contributors will interpret priority as importance, >> though, and will naturally want their favorites to be higher on the >> list. That's why I suggested putting issues where we don't know >> exactly what Lilypond should do, as "Postponed". Obviously we can't >> program the behavior until we know what we want it to be, and that >> motivates users (who might know their area of notation better than we >> do) to think through what they want. > > Hmm. Interesting point of view. Not always helpful either. A lover of artwork won't be able to tell an artist how to improve his work. He still can be more, or less satisfied with it. You can tell critics "do it yourself then", and they won't be able to. But it is not their job. I have had in projects of my own long histories of explaining to people why something "obvious" they want to is a logical impossibility, or how the blame lies with bugs and deficiencies of components outside of my control. You can get religious about it, and it becomes annoying at the twentieth repetition from somebody who does not know about the nineteen times before that. And at some point of time, you do some imprudent workaround, or some total magic, or whatever, and people stop bothering you. The compromises between the wishes of people and the technical feasible things and those you want to do are a moving target. And the responsibility for making technical and logical impossibilities disappear, to match the program better to expectations and requirements, is only something the experienced programmer can do. Sometimes the results please the user more than the programmer. It is hard to generalize this into policies, since a policy would not change its mind if enough people bother it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
2011/8/6 James Lowe : > We don't have a GOP for 'isn't there a better way to keep track of issues AND > upload patches' I see though. We have, but it's not yet put on schedule. http://lilypond.org/doc/v2.15/Documentation/contributor/policy-decisions 2011/8/6 Keith OHara : > I suspect Graham meant "order in which to best keep the project moving". > Since the project doesn't control the order in which contributors attack > issues, that would really be "order in which the project encourages > contributors to attack issues". Sounds good to me. Still, decision depends on our views about relative importance of user needs vs. developer needs. Theoretically, satisfying developer needs is more important to "keep the project moving". However, if we follow this attitude to the extreme, there will be less users (and potentially new decelopers) coming. > But any interpretation of "priority" in the sense of "importance" seems > useless. We differ quite a lot in our opinions of importance. I suspect > Janek and I would rank issues in near-opposite order of importance. That > means that any importance-type priority estimated by the contributor who > opens the issue, won't really help other contributors decide what to work on > next. > > Probably, however, we would all sort issues into roughly the same types of > problems: > Regressions, crashes, incorrect output, ugly output, things that get in the > way of contributing, ... > > So, all we really need to do is make useful classifications, and admit that > we won't all agree on their relative priorities. This sounds a bit like "let's drop 'priority' field and use labels only" :) > Users and new contributors will interpret priority as importance, though, > and will naturally want their favorites to be higher on the list. > That's why I suggested putting issues where we don't know exactly what > Lilypond should do, as "Postponed". Obviously we can't program the behavior > until we know what we want it to be, and that motivates users (who might > know their area of notation better than we do) to think through what they > want. Hmm. Interesting point of view. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
