2012/7/25 David Kastrup :
> Lilyfan writes:
>>> Message du 25/07/12 00:08
>>> De : "Trevor Daniels"
>>> A : "Graham Percival" , "John Mandereau"
>>> Copie à : "lilypond-devel"
>>> Objet : Re: Using MSH Paris Nord server
>>> Graham Percival wrote Tuesday, July 24, 2012 10:55 PM
>>>
>>> > grenouille
2012/7/23 John Mandereau :
> Il giorno lun, 23/07/2012 alle 19.25 +0200, David Kastrup ha scritto:
>> Maybe running gerrit on it would be an option?
>
> This sounds an excellent idea.
Wait, there has already been much discussion about patch review tools,
much of it happened when I was completely a
John Mandereau writes:
> 2012/7/23 John Mandereau :
>> Il giorno lun, 23/07/2012 alle 19.25 +0200, David Kastrup ha scritto:
>>> Maybe running gerrit on it would be an option?
>>
>> This sounds an excellent idea.
>
> Wait, there has already been much discussion about patch review tools,
> much of
Graham Percival writes:
> On Sun, Jul 29, 2012 at 10:15:10PM +0200, David Kastrup wrote:
>
>> It turns out that this definition works with
>> both "make test" as well as "make doc" without requiring any change in the
>> LilyPond code base.
>
> That's certainly promising.
>
>> Discuss. This
-- Forwarded message --
From: John Mandereau
Date: 2012/7/30
Subject: Re: Using MSH Paris Nord server
To: David Kastrup
2012/7/30 David Kastrup :
> Here is what I see as the required steps:
>
> a) get a gerrit server set up
> b) make test-patches.py deal with either Rietveld or
I wonder why Patchy has unconditionnally run configure with
--disable-optimising since last December or so.
I guess there used to be issues with optimisation for some GCC
versions. Could optimisations be enabled again now? Or better, could
we allow developers who run Patchy tune configure flags?
John Mandereau writes:
> I wonder why Patchy has unconditionnally run configure with
> --disable-optimising since last December or so.
Because without that, compilations get run with -DNDEBUG and assertions
are not tested. Also some other tests (like that for parsed objects
that should be dead)
Sorry for duplicating a message again David, I'm bugged by an email
client I don't use often.
-- Forwarded message --
From: John Mandereau
Date: 2012/7/30
Subject: Re: Patchy's configure flags
To: David Kastrup
2012/7/30 David Kastrup :
> The problem is not actually the optimi
On Mon, Jul 30, 2012 at 01:12:44PM +0200, David Kastrup wrote:
> Graham Percival writes:
> > Could I have some examples? I just don't get this "word"
> > business. Is there any syntax which was previously
> > (theoretically) supported, which this patch breaks?
>
> Here is one thing that can be
On Mon, Jul 30, 2012 at 08:50:01AM +0200, Frédéric Bron wrote:
> Who can review my patch?
> http://codereview.appspot.com/6434048
I see that John has just added it to the tracker:
http://code.google.com/p/lilypond/issues/detail?id=2704
so it will now make its way onto our countdown.
- Graham
___
LGTM, and I think it can be pushed to staging right now.
http://codereview.appspot.com/6434048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival writes:
> On Mon, Jul 30, 2012 at 01:12:44PM +0200, David Kastrup wrote:
>> Graham Percival writes:
>> > Could I have some examples? I just don't get this "word"
>> > business. Is there any syntax which was previously
>> > (theoretically) supported, which this patch breaks?
>>
2012/7/30 Frédéric Bron :
>> I wanted to run regression tests and compare before and after a change.
>> However, I obtained the error given below after make -j8 CPU_COUNT=8 check
>>
>> I suspect this is because I am compiling with gcc/g++ 4.7.0 (coming
>> with Fedora 17) and its release notes say:
gra...@percival-music.ca writes:
> LGTM, and I think it can be pushed to staging right now.
Without even asking test-patchy?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-deve
On Mon, Jul 30, 2012 at 03:48:48PM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > Does this affect
> >
> > {
> > \tempo 4. = 120
> > c2 d
> > %\tempo "Adagio" 4. = 43.5
> > \tempo "Adagio" 4. = 43
> > e4. d8 c2
> > }
> >
> > ?
>
> No.
(aside: do we want to disallow all d
On Mon, Jul 30, 2012 at 03:50:18PM +0200, David Kastrup wrote:
> gra...@percival-music.ca writes:
>
> > LGTM, and I think it can be pushed to staging right now.
>
> Without even asking test-patchy?
Sorry, of course we should ask test-patchy. I meant after that --
i.e. in this case I think we ca
Graham Percival writes:
> On Mon, Jul 30, 2012 at 03:48:48PM +0200, David Kastrup wrote:
>> Graham Percival writes:
>>
>> > Does this affect
>> >
>> > {
>> > \tempo 4. = 120
>> > c2 d
>> > %\tempo "Adagio" 4. = 43.5
>> > \tempo "Adagio" 4. = 43
>> > e4. d8 c2
>> > }
>> >
>> > ?
>>
>
On 28/07/2012 07:32, David Kastrup wrote:
> Reinhold Kainhofer writes:
>
>> The text spanner implemented in scheme (which is also used as a basis
>> for David's measure counter engraver) seems to work fine in the regtest,
>> but apparently it is not quote-proof.
>>
>> In particular, if you try cal
On Mon, Jul 30, 2012 at 01:48:15PM +0200, John Mandereau wrote:
> From: John Mandereau
> 2012/7/30 David Kastrup :
> > Here is what I see as the required steps:
-snip steps-
> > At this point of time, it becomes feasible to sensibly test one setup
> > against the other for a typical developer.
Ye
On Mon, Jul 30, 2012 at 02:57:06PM +0100, Graham Percival wrote:
>
> ok, but are we stepping in the right direction here? I mean, if
> \relative c' {
> \tempo "Allegro" 4. = 60
> }
> works but
> \midi {
> \tempo "Allegro" 4. = 60
> }
> fails, I wouldn't blame anybody for being sur
http://codereview.appspot.com/6456047/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (left):
http://codereview.appspot.com/6456047/diff/1/Documentation/notation/input.itely#oldcode645
Documentation/notation/input.itely:645: @code{\header} title block and
@code{
LGTM
http://codereview.appspot.com/6428075/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, much easier to read now!
http://codereview.appspot.com/6448063/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 30/07/2012 16:21, Graham Percival wrote:
> oh, logins just occurred to me. Can gerrit let people log in with
> their google accounts (IIRC there's an api for that), or would we
> all need to make new accounts on the gerrit server?
IIRC, gerrit works with any openID service...
A while ago I se
Reinhold Kainhofer writes:
> On 28/07/2012 07:32, David Kastrup wrote:
>> Reinhold Kainhofer writes:
>>
>>> The text spanner implemented in scheme (which is also used as a basis
>>> for David's measure counter engraver) seems to work fine in the regtest,
>>> but apparently it is not quote-proof.
LGTM, and I really like the comments in the regtests. In a few
instances they were slightly unclear, though.
http://codereview.appspot.com/6445053/diff/2001/input/regression/header-book-multiple.ly
File input/regression/header-book-multiple.ly (right):
http://codereview.appspot.com/6445053/dif
Reinhold Kainhofer writes:
> On 30/07/2012 16:21, Graham Percival wrote:
>> oh, logins just occurred to me. Can gerrit let people log in with
>> their google accounts (IIRC there's an api for that), or would we
>> all need to make new accounts on the gerrit server?
>
>
> IIRC, gerrit works with
Reviewers: Graham Percival,
Message:
On 2012/07/30 14:35:05, Graham Percival wrote:
LGTM, and I really like the comments in the regtests.
Not me who can claim credit.
In a few instances they
were slightly unclear, though.
I did not even bother looking at them. You'll probably tear your ha
2012/7/30 Graham Percival :
> I'm not convinced that this is an advantage. I'd rather have one
> central place to look for patches and their status (currently
> google code, filtered by "has:Patch" and sorted based on patch
> status[1]). If "not bug fixes" patches aren't listed in the same
> plac
John Mandereau writes:
> 2012/7/30 Graham Percival :
>> I'm not convinced that this is an advantage. I'd rather have one
>> central place to look for patches and their status (currently
>> google code, filtered by "has:Patch" and sorted based on patch
>> status[1]). If "not bug fixes" patches a
LGTM, seems to work correctly on all my (reg)tests.
I actually like David's idea of changing the header field values to
include correctness information. Still I like comments inside sample
code to make the reasons for a particular block clearer.
http://codereview.appspot.com/6445053/
_
On Mon, Jul 30, 2012 at 02:43:46PM +, d...@gnu.org wrote:
> "Incorrect title (from book)"
> "Correct title (from bookpart)"
> and similar. That way, it is easier to see whether the results are as
> expected.
sure, that sounds good.
- Graham
___
li
On Fri, Jul 27, 2012 at 12:56:12PM -0300, Han-Wen Nienhuys wrote:
> On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
> wrote:
> > Let’s decide whether to try to stabilize the syntax or not. What
> > type of project do we want LilyPond to be? What kinds of
> > guarantees (or at least firm intention
Please review.
http://codereview.appspot.com/6457049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Little nitpicks based on my C++ experience in other projects, with no
knowledge whatsoever of lilypond internals.
http://codereview.appspot.com/6457049/diff/4001/lily/instrument-name-engraver.cc
File lily/instrument-name-engraver.cc (right):
http://codereview.appspot.com/6457049/diff/4001/lily/
Graham Percival writes:
> In general, yes. But some aspects of our syntax haven't been
> around for a long time -- footnotes, woodwind fingering, compound
> meters, etc. Do we have the best syntax for those? I mean,
> maybe David can figure out a way to allow us to write
> \compoundMeter (3+
There seems to be fairly broad support for _some_ form of
standardization. Here's an update of the proposal along those
lines, along with brief responses to common concerns, in order to
let people just joining the discussion to skip the past 50 emails.
Better formatting here:
http://lilypond.org/
On 2012/07/30 14:28:35, Graham Percival wrote:
... concerned that we discuss bookTitleMarkup and
scoreTitleMarkup.
These are discussed in Custom layout for title blocks
a little further down. But I see they are not indexed,
and a back reference there to this section is not well
worded. I'll
LGTM - I'll push to staging if there are no objections in 24h.
http://codereview.appspot.com/6434048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
- Original Message -
From:
To: ; ;
Cc: ;
Sent: Monday, July 30, 2012 6:54 PM
Subject: Re: Set indent based on instrument name (issue 6457049)
Little nitpicks based on my C++ experience in other projects, with no
knowledge whatsoever of lilypond internals.
http://codereview.appspot
22:17:41 (UTC) Begin LilyPond compile, previous commit at
1c980a9906a7ea01b9f99487e75580f7232f2491
22:17:44 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491
22:17:46Success:./autogen.sh --noconfigure
22:18:21Success:..
22:17:41 (UTC) Begin LilyPond compile, previous commit at
1c980a9906a7ea01b9f99487e75580f7232f2491
22:17:44 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491
22:17:46Success:./autogen.sh --noconfigure
22:18:21Success:..
22:17:41 (UTC) Begin LilyPond compile, previous commit at
1c980a9906a7ea01b9f99487e75580f7232f2491
22:17:44 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491
22:17:46Success:./autogen.sh --noconfigure
22:18:21Success:..
22:17:41 (UTC) Begin LilyPond compile, previous commit at
1c980a9906a7ea01b9f99487e75580f7232f2491
22:17:44 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491
22:17:46Success:./autogen.sh --noconfigure
22:18:21Success:..
On Mon, Jul 30, 2012 at 10:14:37PM +0100, Phil Holmes wrote:
> - Original Message - From:
>> lily/output-def.cc:38: Real long_name_len = 0.0;
>> could these be class member variables instead of global variables?
>
> I don't believe so. I'd be happy to be corrected by someone who
> unders
On Mon, Jul 30, 2012 at 11:44:28PM +0100, Bernard Hurley wrote:
> On Mon, Jul 30, 2012 at 10:14:37PM +0100, Phil Holmes wrote:
> > - Original Message - From:
> >> lily/output-def.cc:38: Real long_name_len = 0.0;
> >> could these be class member variables instead of global variables?
> >
>
04:35:09 (UTC) Begin LilyPond compile, previous commit at
1c980a9906a7ea01b9f99487e75580f7232f2491
04:35:11 Merged staging, now at:1c980a9906a7ea01b9f99487e75580f7232f2491
04:35:13Success:./autogen.sh --noconfigure
04:35:38Success:..
47 matches
Mail list logo