- Original Message -
From: julien.ri...@gmail.com
To: julien.ri...@gmail.com
Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org
Sent: Tuesday, January 17, 2012 11:13 PM
Subject: Build: Strict error checking from makeinfo and texi2html
(issue2219). (issue 5554043)
Begin LilyPond compile, commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117
Merged staging, now at: b667b7fe1bf651b7373014204edbe0e68f17326e
Success:./autogen.sh --noconfigure
Success:../configure --disable-optimising
Success:
lilypond.patchy.gra...@gmail.com writes:
Begin LilyPond compile, commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117
Merged staging, now at: b667b7fe1bf651b7373014204edbe0e68f17326e
Success:./autogen.sh --noconfigure
Success:../configure
Janek Warchoł janek.lilyp...@gmail.com writes:
2012/1/17 Graham Percival gra...@percival-music.ca:
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
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
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
Graham Percival gra...@percival-music.ca 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:
Graham Percival gra...@percival-music.ca 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:
2012/1/18 David Kastrup d...@gnu.org:
Culprit would be
commit 44f3e55e3c283ccfdcb32af3ba3f45ec8580ca23
Author: Yoshiki Sawada sawada.yosh...@gmail.com
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
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 merge.
You are
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
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
Francisco Vila paconet@gmail.com 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
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
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,
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:
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
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
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
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, I
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 check
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
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 more
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
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
LGTM
http://codereview.appspot.com/046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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:
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
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:
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.
Carl
http://codereview.appspot.com/5553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
32 matches
Mail list logo
