patches to apply

Hi,

Can somebody please push these to patches? They were accepted in a 
countdown over a week ago (I think it was 20111023) but they initially 
caused some conflicts when the time came to push them.

Thanks,
Cheers,
Julien

_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Work on 1890: Fix several compiler warnings on amd64 platform (changing variable types) (issue 5039043)

Looks fine to me.
The type ssize_t is unusual, but it was already in the code before this
patch.

http://codereview.appspot.com/5039043/diff/3001/flower/polynomial.cc
File flower/polynomial.cc (right):

http://codereview.appspot.com/5039043/diff/3001/flower/polynomial.cc#newcode332
flower/polynomial.cc:332: Polynomial::degree ()const
This one would be better as a cast to int, because it is an interface
function, and allowing for polynomials of degree greater than 2Billion
is just too weird.

http://codereview.appspot.com/5039043/

Re: Fixes slope errors from incorrect X extents in Beam::print. (issue 5293060)

This looks more reasonable.
I read through a few times until I had it figured out.
I left comments where I really needed either code comments or better
variable names.

Do you know the performance cost of turning on peters-prolongation?

http://codereview.appspot.com/5293060/diff/19014/Documentation/changes.tely
File Documentation/changes.tely (right):

http://codereview.appspot.com/5293060/diff/19014/Documentation/changes.tely#newcode68
Documentation/changes.tely:68: \once \override Beam #'positions =
#beam::strict-prolongation
strict-prolongation is the one that returns y-positions at the ends of
the beam such that beams align-across-breaks

http://codereview.appspot.com/5293060/diff/19014/Documentation/changes.tely#newcode70
Documentation/changes.tely:70: \once \override Beam #'positions =
#beam::peters-prolongation
Despite the advertising, peters-prolungation does not lengthen beams,
nor anything else for that matter.  It returns y-positions for the ends
of the beam such that beams have similar-slope-across-breaks

http://codereview.appspot.com/5293060/diff/19014/input/regression/beam-broken-classic.ly
File input/regression/beam-broken-classic.ly (right):

http://codereview.appspot.com/5293060/diff/19014/input/regression/beam-broken-classic.ly#newcode4
input/regression/beam-broken-classic.ly:4: texidoc="Some classic
examples of broken beams, all taken from
How do we know if the test passes or not ? Suppose some future patch

Re: Who is really alive in the bug squad today?

On Mon, Oct 31, 2011 at 06:20:31PM +0000, Peekay Ex wrote:
> However the Contributor Guide has

I think you're looking at the 2.14 CG ?  or maybe from 2.13 ?

That section in git looks different.  You should remove Dmytro,
and check with Brett.

- Graham

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

On 2011/11/01 08:25:48, mike_apollinemike.com wrote:
> Given that the 0.6 skyline horizontal padding is,
> according to the comment above it, only intended to block ledger lines
from
> overlapping a bar line, I think that this blocking effect it has on
horizontal
> spacing is an unintended side effect.  So, unless anyone has arguments
for why
> the old behavior should be kept, I think this is an acceptable (and
even
> desirable) consequence of this patch.

I have no clue about this issue at all, but reading this comment
triggered my keyword-based interferometer.

A principal reason for skyline horizontal padding was to avoid long
stemmed notes from adjacent staffgroups from interlocking.

While interlocking is usually desired between voices and reasonably
appropriate inside of a pianostaff staffgroup with default clefs (!!!!),
it is usually wrong between independent instruments and totally wrong
between broken lines.

http://codereview.appspot.com/5323062/

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

On Nov 1, 2011, at 9:44 AM, dak <at> gnu.org wrote:

> On 2011/11/01 08:25:48, mike_apollinemike.com wrote:
>> Given that the 0.6 skyline horizontal padding is,
>> according to the comment above it, only intended to block ledger lines
> from
>> overlapping a bar line, I think that this blocking effect it has on
> horizontal
>> spacing is an unintended side effect.  So, unless anyone has arguments
> for why
>> the old behavior should be kept, I think this is an acceptable (and
> even
>> desirable) consequence of this patch.
> 
> I have no clue about this issue at all, but reading this comment
> triggered my keyword-based interferometer.
> 
> A principal reason for skyline horizontal padding was to avoid long
> stemmed notes from adjacent staffgroups from interlocking.
> 
> While interlocking is usually desired between voices and reasonably
> appropriate inside of a pianostaff staffgroup with default clefs (!!!!),
> it is usually wrong between independent instruments and totally wrong
> between broken lines.

Hey David,

The skyline-padding in question only applies to NonMusicalPaperColumns, so it wouldn't have a holistic
effect on staff groups.

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

On Nov 1, 2011, at 12:52 AM, Keith OHara wrote:

>> This fixes the SpanBar regression ID'd by Phil. 
> 
> Well, not exactly.  The failing regression test said:
> texidoc = "SpanBars participate in the horizontal collision system;
> the accidentals should not collide with the bar lines."
> 
> This patch implements issue 1955, keeping accidentals, fingerings, etc.,
> from folding above/below bar lines at all.  Thus this patch moves the 
> accidental away from the extended bar line, whether there is a span bar 
> or not (e.g., whether in a PianoStaff or ChoirStaff).
> 
> So if we take this patch, we should probably change the regression test,
> as well, because the SpanBars will not actually be participating in the 
> horizontal collision system.
> (e.g., if somebody does \remove "Bar_engraver", the accidental collides
> with the span bar again.)
> 

Ah, I see - yes, you're right - will change in a new patch in a couple days.

The problem with SpanBars having Y-extents is that they can never have pure Y extents, as it is not possible
to figure out how high they'll be before line breaks.
One solution would be to create a BarStub grob that works like SpanBarStub but in Staves.  Give it all the same
properties as the BarLine save the stencil.  Then, have the extra-spacing-height callback apply to
BarStub and not BarLine.

But this seems a bit excessive - where are concrete cases that involve people removing the
Bar_line_engraver and, in these cases, can they accomplish the same thing by setting #'transparent = ##t ?

RFC: \hideNote

I noticed that we already have \hideNotes and \unHideNotes, but that
is rather clumsy when you only want to hide a single note.  So I wrote
a patch to add \hideNote, and as a newbie to Lilypond development I
wanted to check that this was a sensible idea.  The patch is here,
although I haven't tested it properly yet because I'm still getting to
grips with the regression test suite:

  https://github.com/aspiers/lilypond/commit/125c734efa2815e358815cdd912acad81940c776

It adds one sentence to the documentation which would need
translating.

Re: [translations] Re: CG 5.8.3: updating committish of lsr snippets

Il 31/10/2011 21:05, Francisco Vila ha scritto:
>> you haven't applied it yet, right?
> Now it is; please pull, test it and tell me.

Ok, thanks.
Well, I had tested it before and I knew what it would have happened.

'make check-translation' is a mess now.

If you run this command you'll see what I mean:

cd Documentation
make ISOLANG=it NO_COLOR=1 check-translation | less

Is it normal?
I guess it's not. There's a lot of garbage.
I've tried the check-translation of spanish and in most (all?) of cases 
the only change for each file in snippets/ is the committish.

BTW, it would be much better if check-translation could check only the 
modifications in the texidoc="" and doctitle="" parts of the snippets 
(the parts that must be translated).
Is it possible? (question for Python developers)

Re: Fixes slope errors from incorrect X extents in Beam::print. (issue 5293060)

Thanks Keith!
I've incorporated most of your comments into the code and otherwise have a couple questions below.

No change in the regtests & a new patch set up.

Cheers,
MS

On Nov 1, 2011, at 5:19 AM, k-ohara5a5a <at> oco.net wrote:

> This looks more reasonable.
> I read through a few times until I had it figured out.
> I left comments where I really needed either code comments or better
> variable names.
> 
> Do you know the performance cost of turning on peters-prolongation?
> 

There's no extra cost for unbroken beams and a cost of anywhere between 2 & 3 times longer for broken beams, as
it runs two extra quants - one full and one that skips all the inits (this is why the figure is between 2 & 3, as
I'm not sure how long the inits take with respect to the quanting).

> 
> http://codereview.appspot.com/5293060/diff/19014/Documentation/changes.tely
> File Documentation/changes.tely (right):
> 
> http://codereview.appspot.com/5293060/diff/19014/Documentation/changes.tely#newcode68
> Documentation/changes.tely:68: \once \override Beam #'positions =
> #beam::strict-prolongation
> strict-prolongation is the one that returns y-positions at the ends of