date:20111110

Graham Percival  writes:

> On Thu, Nov 10, 2011 at 11:56:30PM +0100, David Kastrup wrote:
>> Let's take the "David, I tested dev/staging at commit 43214314xx,
>> and it's fine" mail scenario.
>
> David, I ran Patchy, and it built commit
> cd229915fc873fdb6fd0125827452cb0ba0067a7 and it's fine.
>
> Patchy has printed out the
> -
> push merge:
> (do this manually for debugging/testing)
> git push origin HEAD:master
> -
>
> message, but will let you do the actual pushing if you agree that
> cd229915fc873fdb6fd0125827452cb0ba0067a7 was the right thing to
> test.

Yes, this was right to test, and if HEAD at the time Patchy suggested
pushing it was cd229915fc873fdb6fd0125827452cb0ba0067a7, it would have
done right.  I am pushing it myself presently.  We now know that Patchy
will not do anything imprudent if master has not moved independently.

The next scenario we can test if _only_ master has moved (in which case
it might be possible to fastforward dev/staging and test it, even though
pushing the result would be a noop).  I have a patch here that is fine
enough, but have to fend for breakfast soon.  Probably back in 1h20.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCH: Countdown to 20111113

2011-11-10 Thread Colin Campbell


For 20:00 MST Sunday November 13

Issue 2034 : 
Patch: grob.cc: rewrite O(n^2) algorithm in Grob::common_refpoint 
algorithm to O(n) - R 5371050 


Issue 1875 : 
tests for flower appear to miss instantiations of classes - R 5375051 



Issue 11 : 
beamlet on wrong side of tuplet sixteenth - R 4941041 




Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: what should patchy do for staging?

On Thu, Nov 10, 2011 at 11:56:30PM +0100, David Kastrup wrote:
> Let's take the "David, I tested dev/staging at commit 43214314xx,
> and it's fine" mail scenario.

David, I ran Patchy, and it built commit
cd229915fc873fdb6fd0125827452cb0ba0067a7 and it's fine.

Patchy has printed out the
-
push merge:
(do this manually for debugging/testing)
git push origin HEAD:master
-

message, but will let you do the actual pushing if you agree that
cd229915fc873fdb6fd0125827452cb0ba0067a7 was the right thing to
test.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: what should patchy do for staging?

David Kastrup  writes:

> Let's take the "David, I tested dev/staging at commit 43214314xx,
> and it's fine" mail scenario.
>
> What I would do then is
> git push origin 43214314xx:refs/heads/dev/staging
>
> and see whether it fails.  _That_ is something you can equally well.
> The difference may just be that I check and mail you back telling you
> "Uh, Graham? dev/staging has no commit 43214314xx.  What have you
> been testing?" because either you or your tools tried to do more work
> than they should, and arrived at something they _could_, but likely
> _should not_ push.

P.S.: of course, I have mostly myself to blame, because any such "more
work than they should" is likely lifted straight out of a mail with
instructions from me.  I either had not realized they were going to
become part of an automated process, or I had not realized that it was a
bad idea to make this kind of rebase part of an automated process.
Because it required decisions better made manually, and if someone made
those decisions and checked the results into dev/staging, the automated
process would be perfectly able to resume.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: what should patchy do for staging?

Graham Percival  writes:

> On Wed, Nov 09, 2011 at 05:33:53PM +0100, David Kastrup wrote:
>> Try the following, and please make it fail if any command returns a
>> non-zero exit status.  I don't know Python at all.
>
> thanks, pushed under your name.  I then added the "fail with
> non-zero" thing.
>
> I ran it briefly on my laptop and it seemed plausible.  I'll try a
> longer thing on my desktop now, but I'm not going to push it if it
> works because I'm worried about your "care will be needed".

Let's take the "David, I tested dev/staging at commit 43214314xx,
and it's fine" mail scenario.

What I would do then is
git push origin 43214314xx:refs/heads/dev/staging

and see whether it fails.  _That_ is something you can equally well.
The difference may just be that I check and mail you back telling you
"Uh, Graham? dev/staging has no commit 43214314xx.  What have you
been testing?" because either you or your tools tried to do more work
than they should, and arrived at something they _could_, but likely
_should not_ push.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: what should patchy do for staging?

On Wed, Nov 09, 2011 at 05:33:53PM +0100, David Kastrup wrote:
> Try the following, and please make it fail if any command returns a
> non-zero exit status.  I don't know Python at all.

thanks, pushed under your name.  I then added the "fail with
non-zero" thing.

I ran it briefly on my laptop and it seemed plausible.  I'll try a
longer thing on my desktop now, but I'm not going to push it if it
works because I'm worried about your "care will be needed".

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators

Francisco Vila  writes:

> 2011/11/10 David Kastrup :
>> The normal workflow would be to merge _from_ master into translation,
>> but _into_ staging from translation.
>
> Right; this could cause undesired material from master to be put into
> staging through translation.

There is no undesired material from master in staging.  Everything that
is in master needs to end up in staging eventually since we don't ever
rewind master.

> And it is going to form a three thread braid. Is it okay?

Yup.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: grob.cc: rewrite O(n^2) algorithm in Grob::common_refpoint algorithm to O(n) (issue 5371050)

2011-11-10 Thread pkx166h


Passes make and no reg test diffs

James

http://codereview.appspot.com/5371050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Keep yaffut from attempting to demangle. (issue 5375051)

2011-11-10 Thread pkx166h


Passes make and no reg test diffs

james

http://codereview.appspot.com/5375051/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2011-11-10 Thread pkx166h


passes make and reg tests all posted here:

http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-10-Nov-2011-td4962666.html

James

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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: grob.cc: rewrite O(n^2) algorithm in Grob::common_refpoint algorithm to O(n) (issue 5371050)

2011-11-10 Thread joeneeman


Ok, lgtm

http://codereview.appspot.com/5371050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2011-11-10 Thread m...@apollinemike.com

On Nov 10, 2011, at 10:38 AM, k-ohara5...@oco.net wrote:

> On 2011/11/10 14:51:22, MikeSol wrote:
> 
>>> If we know the space allocated to a staff during horizontal spacing
>> (the
>>> ly:axis-group-interface::height, I think) and the goal (for issue
>> 1955) is to
>>> build a wall to block anything on the staff, then why build each wall
>> to a
>>> custom, usually shorter, height.
> 
>> Because the wall needs to extend places where span bars don't, namely
>> above and below the staff.
> 
> To fix issue 1955, they do need that, but I thought every wall on a
> given staff could be the same height, specifically the height
> tentatively allocated to the staff and its contents during horizontal
> spacing.
> 
> I was talking about custom heights for every bar along the Staff, rather
> than customizing different heights for different staves.
> 

Ah, gotchya.
I think the problem that this'd cause is that the overestimation may block 
lyrics/dynamics/what-have-you from sliding to the left as much as they could.
I can certainly give this a shot, though.

>> And, as we've said before, there can be
>> holes in the wall.  One strategy is to create multiple span bars for
> one
>> column depending on where these holes are (this would make overrides
>> more difficult, but there are ways to get around it that could work
> not
>> unlike glissando-index).
> 
> Well, if we \once\override Score.SpanBar that should affect the whole
> column; while \override Staff.SpanBar{Stub} could affect just one staff.
> 

SpanBarStubs only exist in contexts that SpanBars traverse but do not have bar 
lines (see my e-mail on the subject from this morning - it was in a different 
thread).  So, this wouldn't work unless they were redesigned to be a 
representation of the span bar in all contexts.  The problem I see with going 
down this road is that it wouldn't solve the problem of bar line overhang when 
span bars are not present.

>> However, this does not fix the fundamental
>> problem of how to deal with grobs that span bars would never hit (i.e.
>> accidentals) but that shouldn't hang over barlines, time signatures,
>> clefs, etc.
> 
> 
> You do not need to address multiple issues at one.
> 

And I would even go so far as to say that one shouldn't address multiple issues 
at once unless absolutely necessary.

But here, I think that we can find one elegant solution that solves everything 
instead of several separate solutions that cause code and logic duplication.

> If SpanBars have space reserved where and only where they print, issue
> 910 would be solved.
> 
> If BarLines and KeySignatures later receive extra-spacing-height to
> prevent accidentals from hanging over, issue 1955 would be solved.
> 
> Separation has the advantage that, should there be an exception to the
> rules exemplified by either of these issues, a user can override one
> rule and keep the other.
> 

I'll do my best to separate these out - as I said above, I don't want to do it 
if it is going to compromise the universality of the solution and/or if it'll 
require reverting one solution to implement a later one.  But, I'll mull over 
it and see if I can cook something up on my 11 hour plane ride today 
(ugh).

> 
>> So, using your metaphor of building a wall, I think that the idea of a
>> custom wall is more tractable - it both allows for holes
>> (span-bar-allow-span-bar.ly) and allows for the blocking power of the
>> wall to kick in where it is not visibly present (i.e. the scenario
> with
>> accidentals described above).
> 
> 
> http://codereview.appspot.com/5323062/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2011-11-10 Thread k-ohara5a5a


On 2011/11/10 14:51:22, MikeSol wrote:


If we know the space allocated to a staff during horizontal spacing

(the

ly:axis-group-interface::height, I think) and the goal (for issue

1955) is to

build a wall to block anything on the staff, then why build each wall

to a

custom, usually shorter, height.



Because the wall needs to extend places where span bars don't, namely
above and below the staff.


To fix issue 1955, they do need that, but I thought every wall on a
given staff could be the same height, specifically the height
tentatively allocated to the staff and its contents during horizontal
spacing.

I was talking about custom heights for every bar along the Staff, rather
than customizing different heights for different staves.


And, as we've said before, there can be
holes in the wall.  One strategy is to create multiple span bars for

one

column depending on where these holes are (this would make overrides
more difficult, but there are ways to get around it that could work

not

unlike glissando-index).


Well, if we \once\override Score.SpanBar that should affect the whole
column; while \override Staff.SpanBar{Stub} could affect just one staff.


However, this does not fix the fundamental
problem of how to deal with grobs that span bars would never hit (i.e.
accidentals) but that shouldn't hang over barlines, time signatures,
clefs, etc.



You do not need to address multiple issues at one.

If SpanBars have space reserved where and only where they print, issue
910 would be solved.

If BarLines and KeySignatures later receive extra-spacing-height to
prevent accidentals from hanging over, issue 1955 would be solved.

Separation has the advantage that, should there be an exception to the
rules exemplified by either of these issues, a user can override one
rule and keep the other.



So, using your metaphor of building a wall, I think that the idea of a
custom wall is more tractable - it both allows for holes
(span-bar-allow-span-bar.ly) and allows for the blocking power of the
wall to kick in where it is not visibly present (i.e. the scenario

with

accidentals described above).



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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators

2011/11/10 David Kastrup :
> The normal workflow would be to merge _from_ master into translation,
> but _into_ staging from translation.

Right; this could cause undesired material from master to be put into
staging through translation. And it is going to form a three thread
braid. Is it okay?


-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: grob.cc: rewrite O(n^2) algorithm in Grob::common_refpoint algorithm to O(n) (issue 5371050)

2011-11-10 Thread dak


Reviewers: joeneeman, md5i,


http://codereview.appspot.com/5371050/diff/1/lily/grob.cc
File lily/grob.cc (right):

http://codereview.appspot.com/5371050/diff/1/lily/grob.cc#newcode536
lily/grob.cc:536: c = c->dim_cache_[a].parent_;
On 2011/11/10 16:41:54, joeneeman wrote:

After this loop, balance will be 0, right?


Only if it was't negative before.

So the next loop won't do anything...


Depending on the sign of balance, either one or both loops will do
nothing.  The compiler is smart enough to know that after exiting the
first loop body it will not need to recheck the balance, so there is
little point in uglifying the code.

http://codereview.appspot.com/5371050/diff/1/lily/grob.cc#newcode542
lily/grob.cc:542: while (c != d) {
On 2011/11/10 16:41:54, joeneeman wrote:

The old version would return 0 if there was no common refpoint (which

is

possible if the grob hierarchy hasn't been fully built yet). I'd

suggest a

"while (c && c != d)" to keep the old behavior.


I suggest we leave everything as it is.  If there is no common refpoint,
both c and d will become 0 at the same time, and the loop will exit
without any extra conditions.

The code passed the regtests first time through (after I changed
 to a normal cast.  Surprised that g++ 4.6 does not know
it).

I like it in this style and symmetry which captures the underlying idea
pretty nicely.

Description:
grob.cc: rewrite O(n^2) algorithm in Grob::common_refpoint algorithm to
O(n)

Please review this at http://codereview.appspot.com/5371050/

Affected files:
  M lily/grob.cc


Index: lily/grob.cc
diff --git a/lily/grob.cc b/lily/grob.cc
index  
7f90971803c90c599e1489e875d92add202df864..253736dcadd87aae844250396bec539b489de2c1  
100644

--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -513,15 +513,38 @@ Grob::less (Grob *g1, Grob *g2)
 Grob *
 Grob::common_refpoint (Grob const *s, Axis a) const
 {
-  /* I don't like the quadratic aspect of this code, but I see no
- other way.  The largest chain of parents might be 10 high or so,
- so it shouldn't be a real issue.  */
-  for (Grob const *c = this; c; c = c->dim_cache_[a].parent_)
-for (Grob const *d = s; d; d = d->dim_cache_[a].parent_)
-  if (d == c)
-return (Grob *) d;

-  return 0;
+  /* Catching the trivial cases is likely costlier than just running
+ through: one can't avoid going to the respective chain ends
+ anyway.  We might save the second run through when the chain ends
+ differ, but keeping track of the ends makes the loop more costly.
+  */
+
+  int balance = 0;
+  Grob const *c;
+  Grob const *d;
+
+  for (c = this; c; ++balance)
+c = c->dim_cache_[a].parent_;
+
+  for (d = s; d; --balance)
+d = d->dim_cache_[a].parent_;
+
+  /* Cut down ancestry to same size */
+
+  for (c = this; balance > 0; --balance)
+c = c->dim_cache_[a].parent_;
+
+  for (d = s; balance < 0; ++balance)
+d = d->dim_cache_[a].parent_;
+
+  /* Now find point where our lineages converge */
+  while (c != d) {
+c = c->dim_cache_[a].parent_;
+d = d->dim_cache_[a].parent_;
+  }
+
+  return (Grob *) c;
 }

 void



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: grob.cc: rewrite O(n^2) algorithm in Grob::common_refpoint algorithm to O(n) (issue 5371050)

2011-11-10 Thread md5i . mail



http://codereview.appspot.com/5371050/diff/1/lily/grob.cc
File lily/grob.cc (right):

http://codereview.appspot.com/5371050/diff/1/lily/grob.cc#newcode536
lily/grob.cc:536: c = c->dim_cache_[a].parent_;
On 2011/11/10 16:41:54, joeneeman wrote:

After this loop, balance will be 0, right? So the next loop won't do

anything...
It seems to me that this is true ... unless balance was negative before
the loop.  That's what the next loop is handling, I believe.

http://codereview.appspot.com/5371050/diff/1/lily/grob.cc#newcode542
lily/grob.cc:542: while (c != d) {
On 2011/11/10 16:41:54, joeneeman wrote:

The old version would return 0 if there was no common refpoint (which

is

possible if the grob hierarchy hasn't been fully built yet). I'd

suggest a

"while (c && c != d)" to keep the old behavior.

The balancing code above ensures that the d and c chains are the same
length.  Therefore if there is no common refpoint, the loop will exit
when c and d are both 0, which will maintain the old behavior.

http://codereview.appspot.com/5371050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

grob.cc: rewrite O(n^2) algorithm in Grob::common_refpoint algorithm to O(n) (issue 5371050)

2011-11-10 Thread joeneeman



http://codereview.appspot.com/5371050/diff/1/lily/grob.cc
File lily/grob.cc (right):

http://codereview.appspot.com/5371050/diff/1/lily/grob.cc#newcode536
lily/grob.cc:536: c = c->dim_cache_[a].parent_;
After this loop, balance will be 0, right? So the next loop won't do
anything...

http://codereview.appspot.com/5371050/diff/1/lily/grob.cc#newcode542
lily/grob.cc:542: while (c != d) {
{ on new line

http://codereview.appspot.com/5371050/diff/1/lily/grob.cc#newcode542
lily/grob.cc:542: while (c != d) {
The old version would return 0 if there was no common refpoint (which is
possible if the grob hierarchy hasn't been fully built yet). I'd suggest
a "while (c && c != d)" to keep the old behavior.

http://codereview.appspot.com/5371050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators

Graham Percival  writes:

> On Thu, Nov 10, 2011 at 01:26:25PM +0100, Francisco Vila wrote:
>> 2011/11/10 Graham Percival :
>> >> Before adding "(obviously not enough)" to "I've done my best" I must
>> >> repeat, the commit was tested and the docs compiled. The issue is
>> >> distribution related.  With your help, I'll find a way to fix
>> >> distribution problems without running GUB (I've tried that before; if
>> >> running GUB is mandatory for me, I will think on that nevertheless.)
>> >
>> > Yes.
>> 
>> Yes what.
>
> Yes, you are correct: the issue is distribution related.
>
>> > - made the translators only "combine" their work with dev/staging
>> 
>> "combine" as in $ git combine ?
>
> sigh.  is there any word that git *doesn't* use?!
>
> I meant "combine" as in "either merge, or rebase, or merge
> -ff-only, or pull -r, or git gather --sparkly-unicorn-princess, or
> whatever is the best way to get commits from lilypond/translation
> to dev/staging".
>
> Consult David about what command you should run.

The normal workflow would be to merge _from_ master into translation,
but _into_ staging from translation.

The problem is that so far our success rate for getting merges from
staging into master in a reasonable state has not exactly been fabulous
(in other words, zero).  That's why I would like not to have any
automatic merges except fastforwards.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators

On Thu, Nov 10, 2011 at 01:26:25PM +0100, Francisco Vila wrote:
> 2011/11/10 Graham Percival :
> >> Before adding "(obviously not enough)" to "I've done my best" I must
> >> repeat, the commit was tested and the docs compiled. The issue is
> >> distribution related.  With your help, I'll find a way to fix
> >> distribution problems without running GUB (I've tried that before; if
> >> running GUB is mandatory for me, I will think on that nevertheless.)
> >
> > Yes.
> 
> Yes what.

Yes, you are correct: the issue is distribution related.

> > - made the translators only "combine" their work with dev/staging
> 
> "combine" as in $ git combine ?

sigh.  is there any word that git *doesn't* use?!

I meant "combine" as in "either merge, or rebase, or merge
-ff-only, or pull -r, or git gather --sparkly-unicorn-princess, or
whatever is the best way to get commits from lilypond/translation
to dev/staging".

Consult David about what command you should run.


- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)

2011-11-10 Thread Mike Solomon

On Nov 9, 2011, at 11:19 PM, k-ohara5...@oco.net wrote:

> On 2011/08/30 16:28:28, mikesol_ufl.edu wrote:
>> On Aug 30, 2011, at 5:53 PM, mailto:joenee...@gmail.com wrote:
> 
>> > Correct me if I'm wrong, but this is my understanding: wherever
> there's
>> > a SpanBar, you're creating SpanBarStubs between every relevant pair
> of
>> > staves. These don't actually get printed; they're just there for the
>> > pure-height (because the SpanBar height is pretty much the whole
> system,
>> > so it doesn't tell you where the gaps are).
>> >
> 
>> Yes.
> 
>> > If that's correct, I have two broad comments: it's worth commenting
>> > somewhere (span-bar-stub-engraver.cc, maybe) that the purpose of
>> > SpanBarStub is for pure-height only.
> 
>> Will do.
> 
> 
> Haven't done yet.

Done now.

> 
>> > But more importantly, isn't SpanBar
>> > now obsoleted by SpanBarStub? That is, you can just remove the
> SpanBar
>> > altogether and print the SpanBarStubs.
>> >
> 
>> Mmm...you're not unright, but I'd prefer to do that in another patch
> if that's
>> OK.  It'd require a lot of deleting and moving around, and I'd first
> like to
>> make sure that these stubs are the code base and bug free for a while
> before I
>> deprecate an entire grob (and figure out how to deal with the syntax
> changes
>> that come with said deprecation).
> 
> 
> Well, the SpanBarStub extent is not the full length to bridge between
> BarLines, it is only the height of the Lyrics, and only those Lyrics in
> the neighboring measures.

Yup.

> 
> SpanBarStub needs to change size, or get a bar-extent different from its
> Y-extent, before it can take over the job of printing SpanBars.
> 

You're right - I think that was a bad idea, which is why I haven't followed up 
on it.

> I'm worried the code will be quite difficult to understand for quite a
> while unless Mike retreats.
> 

I would rather create a killer flow chart that explains in as much detail as 
possible how all of this works than give up on code that I believe is correct 
given the way that this problem needs to be formulated.  If someone said to me, 
for example, "Mike, music doesn't actually work like that - sharps should be 
allowed to pass over time signatures and clefs (pertaining to the example I 
sent out before), then I'd say "my bad, my research was incorrect, let's revert 
the patch."  As I've said before, after reverting the patch, there are other 
ways to tackle the problem that this patch was originally designed to fix.

Remembering back to the beam collision days (ah, the good old days...), we saw 
several critical issues arise from that, but at no point did people question 
the validity of getting rid of beam collisions.  I think this is because, 
visually, everyone can say "ouch" just by looking at them.  However, as I've 
studied the present issue more, I've realized that collisions between 
accidentals and the airspace above or below non-musical grobs is just as much 
of a 'collision' in traditional typesetting and needs a similar approach.  
Beams collect all of the colliding grobs in an array and then deal with them 
during their positioning callbacks.  BarLines and other non musical grobs also 
need an array of pertinent grobs (in this case, "neighbors") that they can use 
during their callbacks.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2011-11-10 Thread mtsolo

As always, many thanks for your comments!

http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc
File lily/pure-from-neighbor-engraver.cc (right):

http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc#newcode72
lily/pure-from-neighbor-engraver.cc:72: //first, clump pure_relevants
into vectors of grobs that have the same column.
On 2011/11/10 07:04:56, Keith wrote:

comment update

Done.

http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc#newcode93
lily/pure-from-neighbor-engraver.cc:93: to the pure grobs on either
side.
On 2011/11/10 07:04:56, Keith wrote:

comment update

Done.

http://codereview.appspot.com/5323062/diff/53017/lily/span-bar-stub-engraver.cc
File lily/span-bar-stub-engraver.cc (right):

http://codereview.appspot.com/5323062/diff/53017/lily/span-bar-stub-engraver.cc#newcode55
lily/span-bar-stub-engraver.cc:55: // note that this can get out of hand
if there are lots of vertical axis groups...
On 2011/11/10 07:04:56, Keith wrote:

You are telling me to worry but not telling me what to worry about.

There is

one Span_bar_stub_engraver per Staff, and for each of these you add

one grob for

each spanbar. The total number is typically the same as the number of

BarLines,

so I do not see what gets "out of hand".

You're right - removed.

http://codereview.appspot.com/5323062/diff/53017/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/5323062/diff/53017/scm/define-grobs.scm#newcode201
scm/define-grobs.scm:201: (extra-spacing-height .
,pure-from-neighbor-interface::extra-spacing-height)
On 2011/11/10 07:04:56, Keith wrote:

Now this includes all Items within one bar (usually) on each side.

But extra-spacing-height is used when the tentative staff-spacing is

estimated

using boxes around everything in the entire length of each staff, the

so-called

full-score-pure-minimum-translations. They are minimum in the sense

compressed springs, but not really very minimum because the bounding

boxes are

so conservative.

If we know the space allocated to a staff during horizontal spacing

(the

ly:axis-group-interface::height, I think) and the goal (for issue

1955) is to

build a wall to block anything on the staff, then why build each wall

to a

custom, usually shorter, height.

Because the wall needs to extend places where span bars don't, namely
above and below the staff. And, as we've said before, there can be
holes in the wall. One strategy is to create multiple span bars for one
column depending on where these holes are (this would make overrides
more difficult, but there are ways to get around it that could work not
unlike glissando-index). However, this does not fix the fundamental
problem of how to deal with grobs that span bars would never hit (i.e.
accidentals) but that shouldn't hang over barlines, time signatures,
clefs, etc.

So, using your metaphor of building a wall, I think that the idea of a
custom wall is more tractable - it both allows for holes
(span-bar-allow-span-bar.ly) and allows for the blocking power of the
wall to kick in where it is not visibly present (i.e. the scenario with
accidentals described above).

The quick fix is obviously to revert the patch, but I think we are close
with this, and as I've said several times before, if a rule in
typesetting is that no objects to the right of object X should ever pass
over or under object X, it makes sense that object X's height, in some
way, be estimated from the neighbors that it is supposed to block.

http://codereview.appspot.com/5323062/diff/53017/scm/define-grobs.scm#newcode1859
scm/define-grobs.scm:1859: (SpanBarStub
On 2011/11/10 07:04:56, Keith wrote:

I can see these have effect in Lyrics, but not in regular Staves.

Weren't they

intended to perform the horizontal spacing functions of SpanBar ?

They do not

affect the skylines of the NonMusicalPaperColumn.

Here, I add some padding so we can see the PaperColumn outlines, and

remove the

BarLines from the PaperColumn outline so we can see more easily. I

see the

vestigial SpanBars at the top of the page (I widened them to

distinguish them)

but no SpanBarStub, and nothing even trying to take up space now that

the

BarLine is out of the picture.

\layout { \context { \Score
\override NonMusicalPaperColumn #'stencil =

#ly:separation-item::print

\override PaperColumn #'stencil = #ly:separation-item::print
\override NonMusicalPaperColumn #'skyline-vertical-padding = #0.5
\override BarLine #'extra-spacing-width = #'(+inf.0 . -inf.0)
\override SpanBar #'extra-spacing-width = #'(-1.0 . 1.0)
}} #(ly:set-option 'debug-skylines)
\new GrandStaff <<
\new Staff { dis'''1 | dis'''4 r2. | c''1 }
\new Staff { e'1 | e'1 | fis'''4 r2. } >>

The Span_bar_stub engraver exists only in the Lyrics context.

It is intended to perform the horizontal spacing functions of SpanBar in
vertical axis groups that

Re: can't release 2.15.17 due to translators

2011/11/10 Graham Percival :
>> Before adding "(obviously not enough)" to "I've done my best" I must
>> repeat, the commit was tested and the docs compiled. The issue is
>> distribution related.  With your help, I'll find a way to fix
>> distribution problems without running GUB (I've tried that before; if
>> running GUB is mandatory for me, I will think on that nevertheless.)
>
> Yes.

Yes what.

>  It's basically a "make distcheck" thing, but I think that
> GUB adds some other layer to that testing.  (in other words, I'm
> not guaranteeing that there's any "distcheck" target in the
> lilypond build system)
>
> It would be nice if somebody:
> - looked at GUB to figure out what test(s) it's doing
> - made sure thoses tests are avaible in normal lilypond build
>  system
> - added those tests to patchy
> - made the translators only "combine" their work with dev/staging

"combine" as in $ git combine ?

I'm merging lilypond/translation into dev/staging from now on and
leave master untouched forever.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators

On Thu, Nov 10, 2011 at 09:44:06AM +0100, Francisco Vila wrote:
> 2011/11/10 David Kastrup :
> > We really need to stop the untested commits to master.
> 
> Before adding "(obviously not enough)" to "I've done my best" I must
> repeat, the commit was tested and the docs compiled. The issue is
> distribution related.  With your help, I'll find a way to fix
> distribution problems without running GUB (I've tried that before; if
> running GUB is mandatory for me, I will think on that nevertheless.)

Yes.  It's basically a "make distcheck" thing, but I think that
GUB adds some other layer to that testing.  (in other words, I'm
not guaranteeing that there's any "distcheck" target in the
lilypond build system)

It would be nice if somebody:
- looked at GUB to figure out what test(s) it's doing
- made sure thoses tests are avaible in normal lilypond build
  system
- added those tests to patchy
- made the translators only "combine" their work with dev/staging

I am *absolutely* not getting involved in this.  I've told you
what I know about GUB; if you want more info, go look at the
source.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: mem leak problem

On Wed, Nov 09, 2011 at 06:04:58PM -0800, m...@apollinemike.com wrote:
> Is there a profiling tool i can use to show memory leaks,
> especially on that can compare between two runs of a program
> (for example, one that's on current master and one that's with
> my patch)?

search the archives for valgrind.  Reinhold had a great email
about its use somewhere between 2 and 8 weeks ago.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators

On Thu, Nov 10, 2011 at 10:20:37AM +0100, David Kastrup wrote:
> Graham Percival  writes:
> 
> > as soon as something is in master, I can move it to
> > release/unstable and build a release.
> 
> I rebased dev/staging on top of an emergency fix (no idea whether this
> will do the trick).

I'll try it.

> Feel free to git merge --ff-only only this fix or all of dev/staging.
> Either way, dev/staging does not need another rebasing to move to master
> eventually.

ok, done.  I didn't bother checking if dev/staging actually
compiles or not.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2018 in lilypond: Patch: parser.yy: allow postevents in function arguments in general

Peekay Ex  writes:

> David,
>
> On Thu, Nov 10, 2011 at 10:01 AM,   wrote:
>>
>> Comment #10 on issue 2018 by d...@gnu.org: Patch: parser.yy: allow
>> postevents in function arguments in general
>> http://code.google.com/p/lilypond/issues/detail?id=2018
>>
>> Somebody updated master differently than with the current dev/staging, so
>> rebased and pushed to dev/staging as
>> 10ab28fa0152e333861ce614376db5f0baa867c3
>
> I ran patchy this morning (around 7ish BST) and left it running, I
> pushed the results about 2 hours later and then pulled, it didn't seem
> to me that there had been anything pushed to dev/staging in the
> interim.

Well, that would be pretty much 10am CET.  Anyway, I pushed an emergency
fix for the GUB build to the front of dev/staging (rebasing it in the
process), but your commit to master was based on the non-rebased
version.  I just assumed when doing my "emergency fix" that nothing was
happening to master except based on my fixed dev/staging, but that was
obviously mistaken.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2018 in lilypond: Patch: parser.yy: allow postevents in function arguments in general

2011-11-10 Thread Peekay Ex

David,

On Thu, Nov 10, 2011 at 10:01 AM,   wrote:
>
> Comment #10 on issue 2018 by d...@gnu.org: Patch: parser.yy: allow
> postevents in function arguments in general
> http://code.google.com/p/lilypond/issues/detail?id=2018
>
> Somebody updated master differently than with the current dev/staging, so
> rebased and pushed to dev/staging as
> 10ab28fa0152e333861ce614376db5f0baa867c3

I ran patchy this morning (around 7ish BST) and left it running, I
pushed the results about 2 hours later and then pulled, it didn't seem
to me that there had been anything pushed to dev/staging in the
interim.


-- 
--
James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

newlines at end of file

2011-11-10 Thread Werner LEMBERG


Folks,


please adjust your favourite editor to automatically insert a newline
at the end of file at saving time in case it is missing.  It's a
nuisance to see having `diff' emit

  \ No newline at end of fine

I've recently fixed that for a bunch of files, but right now I'm
seeing it again (in Mike's new file `column-description.cc')...


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators

Graham Percival  writes:

> On Wed, Nov 09, 2011 at 10:18:08PM +0100, David Kastrup wrote:
>> Graham Percival  writes:
>> 
>> > can somebody fix this?  and depending on dak, either push directly
>> > to master (which means he has to play yet more games with
>> > dev/staging),
>> 
>> dev/staging is in a reasonably calm state right now and would be easy to
>> rebase.  But what's the advantage?
>
> as soon as something is in master, I can move it to
> release/unstable and build a release.

I rebased dev/staging on top of an emergency fix (no idea whether this
will do the trick).

Feel free to git merge --ff-only only this fix or all of dev/staging.
Either way, dev/staging does not need another rebasing to move to master
eventually.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators

2011/11/10 David Kastrup :
>> My deepest apologies, I cannot correct it until this evening (worktime
>> 08:00-18:00).
>>
>> file name should not have any trailing *S*
>>
>> Documentation/fr/texidocs/alternative-breve-note.texidoc
>
> We really need to stop the untested commits to master.

I really agree, but please take into account that I've done my best to
ensure that the whole thing and its documentation does compile.

Before adding "(obviously not enough)" to "I've done my best" I must
repeat, the commit was tested and the docs compiled. The issue is
distribution related.  With your help, I'll find a way to fix
distribution problems without running GUB (I've tried that before; if
running GUB is mandatory for me, I will think on that nevertheless.)

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators

Lilyfan  writes:

>> Message du 09/11/11 21:00
>> De : "Graham Percival"
>> A : lilypond-devel@gnu.org
>> Copie à :
>> Objet : can't release 2.15.17 due to translators
>>
>> can somebody fix this? and depending on dak, either push directly
>> to master (which means he has to play yet more games with
>> dev/staging), or push to dev/staging and then wait for James to do
>> his stuff and then I'll try making 2.15.17 again then.
>>
>>
>> file from VC not distributed:
>> lilypond-2.15.17/Documentation/fr/texidocs/alternative-breve-note.texidocs
>
>
> My deepest apologies, I cannot correct it until this evening (worktime
> 08:00-18:00).
>
> file name should not have any trailing *S*
>
> Documentation/fr/texidocs/alternative-breve-note.texidoc

We really need to stop the untested commits to master.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: can't release 2.15.17 due to translators