LGTM, I think this can be pushed directly to staging.
https://codereview.appspot.com/6996052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2012/12/21 07:03:45, Graham Percival wrote:
There might be some weirdness between having foo.itexi, @foo, and
foo.html
output. But as long as the 2-minute "make website" doesn't die, it's
probably
ok.
I tweaked this patch to cater for that. See if this is better.
https://codereview.a
On 22 déc. 2012, at 23:14, k-ohara5...@oco.net wrote:
>
> https://codereview.appspot.com/4917046/diff/34001/lily/grob.cc
> File lily/grob.cc (right):
>
> https://codereview.appspot.com/4917046/diff/34001/lily/grob.cc#newcode647
> lily/grob.cc:647: g1->programming_error ("could not place this g
https://codereview.appspot.com/4917046/diff/34001/lily/grob.cc
File lily/grob.cc (right):
https://codereview.appspot.com/4917046/diff/34001/lily/grob.cc#newcode647
lily/grob.cc:647: g1->programming_error ("could not place this grob in
its axis group");
It sounds like you're mixing together "axis
On Sat, 22 Dec 2012 00:46:21 -0800, wrote:
In this particular case, however, the problem is adding an axis group to
an axis group. _Any_ old axis group to _any_ old axis group.
No no. The reported problem
\new StaffGroup \RemoveEmptyStaves <>
causes a StaffGrouper to be added to the Vert
Reviewers: ,
Message:
Please review
Please review this at https://codereview.appspot.com/6996052/
Affected files:
M Documentation/web/manuals.itexi
Index: Documentation/web/manuals.itexi
diff --git a/Documentation/web/manuals.itexi
b/Documentation/web/manuals.itexi
index
fd194de3a8955
On 22 déc. 2012, at 07:43, k-ohara5...@oco.net wrote:
>
> https://codereview.appspot.com/6827072/diff/34001/lily/axis-group-interface.cc
> File lily/axis-group-interface.cc (right):
>
> https://codereview.appspot.com/6827072/diff/34001/lily/axis-group-interface.cc#newcode62
> lily/axis-group-in
On 22 déc. 2012, at 09:46, d...@gnu.org wrote:
> On 2012/12/22 08:29:59, mike7 wrote:
>> Where in the new code are things being allocated and thrown away
> temporarily on
>> the heap?
>
> What do you think extract_grob_set does?
Got it.
>
>> If there is a more efficient way to implement this p
On 2012/12/22 08:29:59, mike7 wrote:
Where in the new code are things being allocated and thrown away
temporarily on
the heap?
What do you think extract_grob_set does?
If there is a more efficient way to implement this patch, let me know.
It
seems, though, that the only way to prevent gr
On 22 déc. 2012, at 09:25, d...@gnu.org wrote:
> On 2012/12/22 06:41:06, mike7 wrote:
>> On 21 déc. 2012, at 10:09, mailto:d...@gnu.org wrote:
>
>> > On 2012/12/21 07:59:02, MikeSol wrote:
>> >> Hey all,
>> >
>> >> I'm ok w/ this on the countdown but can someone check out David's
>> > suspicion
On 2012/12/22 06:41:06, mike7 wrote:
On 21 déc. 2012, at 10:09, mailto:d...@gnu.org wrote:
> On 2012/12/21 07:59:02, MikeSol wrote:
>> Hey all,
>
>> I'm ok w/ this on the countdown but can someone check out David's
> suspicion that
>> this slows stuff down by O(n^3)? I definitely won't push t
11 matches
Mail list logo
