LGTM.
Carl
http://codereview.appspot.com/5553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
Thanks, Julien!
Carl
http://codereview.appspot.com/5557056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
If you run it through fixcc.py we won't get the trailing whitespace
warning.
http://codereview.appspot.com/046/diff/1/lily/tuplet-bracket.cc
File lily/tuplet-bracket.cc (right):
http://codereview.appspot.com/046/diff/1/lily/tuplet-bracket.cc#newcode660
lily/tuplet-bracket.cc:660:
Reviewers: Reinhold,
Message:
Please review.
Description:
lilypond-book:
Fix links in texinfo output (issue 2224).
Also, specify filename and ext for all snippets.
Please review this at http://codereview.appspot.com/5557056/
Affected files:
M python/book_snippets.py
M python/book_texinfo.
Reviewers: Reinhold,
Message:
Please review.
Description:
lilypond-book:
Group line-width settings together (issue ).
Also, specify filename and ext for all snippets.
Please review this at http://codereview.appspot.com/5553056/
Affected files:
M python/book_snippets.py
Index: python/b
On 2012/01/18 15:13:47, Neil Puttock wrote:
http://codereview.appspot.com/5540058/diff/3003/Documentation/changes.tely
Done
http://codereview.appspot.com/5540058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/lis
LGTM
http://codereview.appspot.com/046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Le 17/01/2012 21:31, Graham Percival disait :
On Tue, Jan 17, 2012 at 08:24:35PM +, janek.lilyp...@gmail.com wrote:
could we change this (and other similar) prefix so that it doesn't
contain a slash? I mean, change dev/ to dev- or something like that.
The slash confused me a lot, because it
The tuplet-iterator.cc has a process method that uses similar logic as
that above: it does parts of what the report_music function does,
because as you correctly state, the function does very little.
LGTM - if you can, please adopt this patch so that you can coordinate
getting it and others conne
On 2012/01/18 15:55:35, dak wrote:
On 2012/01/18 15:28:42, http://mike_apollinemike.com wrote:
> I don't think there's a risk that one engraver in a context will get
a
different
> version of an event than another engraver in a context. This would
require
the
> NoteEvent to be reported mor
On 2012/01/18 15:28:42, mike_apollinemike.com wrote:
I don't think there's a risk that one engraver in a context will get a
different
version of an event than another engraver in a context. This would
require the
NoteEvent to be reported more than once.
It would merely require using the s
http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc#newcode284
lily/stem.cc:284: string style = robust_symbol2string
(heads[0]->get_property ("style"), "default");
A bit fussy. You can safely chec
On Jan 18, 2012, at 3:53 PM, d...@gnu.org wrote:
> Where would be the point? If I plan to touch up the stream event before
> broadcasting it, I can't use the everything-included report_event
> anyway. If I plan to touch up the music event in a manner equivalent to
> deleting the articulations,
On 2012/01/18 14:53:28, dak wrote:
Then
rhythmic_iterator could just override it. Better yet, EventChord
could just
override it, and we would not need the rhythmic iterator at all.
Well, it is not really "better yet" since the current case is the simple
and straightforward one, so it should
http://codereview.appspot.com/5540058/diff/3003/Documentation/changes.tely
File Documentation/changes.tely (right):
http://codereview.appspot.com/5540058/diff/3003/Documentation/changes.tely#newcode67
Documentation/changes.tely:67: \override Flag #'color = #red g8
Please put the note on a new li
On 2012/01/18 14:36:57, MikeSol wrote:
On 2012/01/18 14:27:53, dak wrote:
> Are iterators allowed to change their input?
I'm not sure if they're allowed by design, but I know they're allowed
to
proliferate input that wasn't there before.
I don't know what you mean by "proliferate input" as
On 2012/01/18 14:27:53, dak wrote:
http://codereview.appspot.com/5554048/diff/5001/lily/rhythmic-music-iterator.cc
File lily/rhythmic-music-iterator.cc (right):
http://codereview.appspot.com/5554048/diff/5001/lily/rhythmic-music-iterator.cc#newcode42
lily/rhythmic-music-iterator.cc:42: get_m
http://codereview.appspot.com/5554048/diff/5001/lily/rhythmic-music-iterator.cc
File lily/rhythmic-music-iterator.cc (right):
http://codereview.appspot.com/5554048/diff/5001/lily/rhythmic-music-iterator.cc#newcode42
lily/rhythmic-music-iterator.cc:42: get_music ()->set_property
("articulations",
Reviewers: dak,
http://codereview.appspot.com/5554048/diff/2001/lily/rhythmic-music-iterator.cc
File lily/rhythmic-music-iterator.cc (right):
http://codereview.appspot.com/5554048/diff/2001/lily/rhythmic-music-iterator.cc#newcode41
lily/rhythmic-music-iterator.cc:41: report_event (get_music ())
Have you run make doc with these changes?
--
Phil Holmes
I did but forgot make check, so that will delay the review some more
until errors are fixed there.
Thanks,
Julien
http://codereview.appspot.com/5554043/
___
lilypond-devel mailing list
li
http://codereview.appspot.com/5554048/diff/2001/lily/rhythmic-music-iterator.cc
File lily/rhythmic-music-iterator.cc (right):
http://codereview.appspot.com/5554048/diff/2001/lily/rhythmic-music-iterator.cc#newcode41
lily/rhythmic-music-iterator.cc:41: report_event (get_music ());
I suppose that
LGTM
http://codereview.appspot.com/5543064/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/5540058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Francisco Vila writes:
>>> It would seem that rerunning scripts/auxiliar/update-with-convert-ly.sh
>>> after merging the translation might have fixed that problem this time.
>>>
>>> I am not sure it would work in all such cases.
>>>
>>> I don't have a better suggestion than doing a test run befor
Reviewers: MikeSol,
Message:
On 2012/01/17 17:42:38, MikeSol wrote:
I would advise not handling it this way - the function to_event is
supposed to
take music and return an event. In this patch, it is taking music,
returning an
event, and maybe broadcasting music and/or sending it to a conte
I still think this patch goes outside the model of the way these things
are usually designed in LilyPond. I'm not saying that LilyPond's design
paradigm is objectively good or bad (I truly have no idea, as I know
nothing about any other piece of software), but I think it's best to
follow it whene
>> It would seem that rerunning scripts/auxiliar/update-with-convert-ly.sh
>> after merging the translation might have fixed that problem this time.
>>
>> I am not sure it would work in all such cases.
>>
>> I don't have a better suggestion than doing a test run before pushing a
>> translation merg
2012/1/18 David Kastrup :
> Culprit would be
> commit 44f3e55e3c283ccfdcb32af3ba3f45ec8580ca23
> Author: Yoshiki Sawada
> Date: Sun Jan 15 09:00:54 2012 +0900
>
> Doc-ja: Adding and updating NR
>
> Doc-ja: Adding and updating NR.
>
>
> merged in from the translation branch.
>
> This is som
Graham Percival writes:
> On Wed, Jan 18, 2012 at 02:20:09AM -0800,
> lilypond.patchy.gra...@gmail.com wrote:
>> *** FAILED BUILD ***
>>
>> nice make doc -j3 CPU_COUNT=3
>>
>> Previous good commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117
>>
>> Current broken commit: b667b7fe
Graham Percival writes:
> On Wed, Jan 18, 2012 at 02:20:09AM -0800,
> lilypond.patchy.gra...@gmail.com wrote:
>> *** FAILED BUILD ***
>>
>> nice make doc -j3 CPU_COUNT=3
>>
>> Previous good commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117
>>
>> Current broken commit: b667b7fe
On 2012/01/17 21:31:01, janek wrote:
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297
Do
On Wed, Jan 18, 2012 at 02:20:09AM -0800, lilypond.patchy.gra...@gmail.com
wrote:
> *** FAILED BUILD ***
>
> nice make doc -j3 CPU_COUNT=3
>
> Previous good commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117
>
> Current broken commit: b667b7fe1bf651b7373014204edbe0e68f17326e
Janek Warchoł writes:
> 2012/1/17 Graham Percival :
>>> http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297
>>> Documentation/contributor/source-code.itexi:297: git branch dev/cg
>>> I think it would be good to be verbose, because it will give pe
lilypond.patchy.gra...@gmail.com writes:
> Begin LilyPond compile, commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117
>
> Merged staging, now at: b667b7fe1bf651b7373014204edbe0e68f17326e
>
> Success:./autogen.sh --noconfigure
>
> Success:../configure
Begin LilyPond compile, commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117
Merged staging, now at: b667b7fe1bf651b7373014204edbe0e68f17326e
Success:./autogen.sh --noconfigure
Success:../configure --disable-optimising
Success:
- Original Message -
From:
To:
Cc: ;
Sent: Tuesday, January 17, 2012 11:13 PM
Subject: Build: Strict error checking from makeinfo and texi2html
(issue2219). (issue 5554043)
Reviewers: ,
Description:
Build: Strict error checking from makeinfo and texi2html (issue 2219).
Run makei
36 matches
Mail list logo
