Graham Percival writes:
> Let’s decide what we want to see when we do:
>
> make
> make doc
+1
> A variable, QUIET_BUILD, can be set and this will reduce the
> clutter but not eliminate it.
-0.5
Almost right. However, try not to invent something new. Please just
use the autoconf/au
I will be away for a long weekend, back Monday, late late Monday, UTC.
http://codereview.appspot.com/4662074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 7/7/11 6:58 PM, "Wols Lists" wrote:
> On 08/07/11 00:23, Carl Sorensen wrote:
>> On 7/7/11 12:26 PM, "Neil Puttock" wrote:
>>
>>> On 7 July 2011 19:09, Wols Lists wrote:
>>>
Which I probably didn't understand :-) BUT from what I remember did you
think that feeding a chord of,
On 08/07/11 00:23, Carl Sorensen wrote:
> On 7/7/11 12:26 PM, "Neil Puttock" wrote:
>
>> On 7 July 2011 19:09, Wols Lists wrote:
>>
>>> Which I probably didn't understand :-) BUT from what I remember did you
>>> think that feeding a chord of, say, C into the formatter should chuck
>>> out A as i
On 7/7/11 12:26 PM, "Neil Puttock" wrote:
> On 7 July 2011 19:09, Wols Lists wrote:
>
>> Which I probably didn't understand :-) BUT from what I remember did you
>> think that feeding a chord of, say, C into the formatter should chuck
>> out A as its result? Which is NOT what this does - it has
Am Donnerstag, 7. Juli 2011, 21:21:16 schrieben Sie:
> Hi Reinhold,
>
> This LGTM, but do you know why removing this code doesn't break the
> regtest added for issue 221 (lyric-combine-switch-voice.ly)?
AFAIU, the main change of Han-Wen's patch
(6a3360c40308285434e06a1de031efb073c015fa) was to l
On 2011/07/07 16:12:08, Neil Puttock wrote:
LGTM, though the regtest is still a bit messy.
What do you consider messy about the regtest?
scm/define-grob-interfaces.scm:128: "A note-head that can become part
of a
ligature."
note head
Done
Thanks,
Carl
http://codereview.appspot.com/4
On 2011/07/07 19:36:27, Graham Percival wrote:
LGTM, please push.
(under my seal as Documentation Meister)
Pushed as 4d828c178c06d87332301030cc02dde9a9403538
Closing Rietveld issue. Thanks.
http://codereview.appspot.com/4668058/
___
lilypond-dev
2011/7/7 Graham Percival :
>
> A variable, QUIET_BUILD, can be set and this will reduce the
> clutter but not eliminate it. (see
> http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables
> ) This variable currently does things like adding a -q flag to the
> TEXI2PDF call ("qui
On Thu, Jul 07, 2011 at 02:26:16PM +0100, Phil Holmes wrote:
> - Original Message - From: "Matthias Kilian"
>
> >Wouldn't it be better to either collect both stdout and stderr in
> >the same log file or to use three log files .err.log, .out.log and
> >.log, where the latter contains the co
On Thu, Jul 07, 2011 at 05:42:46PM +0100, Phil Holmes wrote:
> In my version of LilyDev, it appears that ImageMagick is installed,
> since Synaptic offers either to remove it or to reinstall it. But
> typing imagemagick from the command line doesn't find it. Could
> someone tell me how to run it,
On 5 July 2011 04:48, wrote:
> LGTM
Thanks, Carl.
Pushed: d5766025a1573c709dfa3c9663c1c6b903abec24
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Reinhold,
This LGTM, but do you know why removing this code doesn't break the
regtest added for issue 221 (lyric-combine-switch-voice.ly)?
Cheers,
Neil
http://codereview.appspot.com/4672041/diff/2001/input/regression/lyric-combine-derived-voice.ly
File input/regression/lyric-combine-derived
http://codereview.appspot.com/4643067/diff/15002/input/regression/phrasing-slur-multiple.ly
File input/regression/phrasing-slur-multiple.ly (right):
http://codereview.appspot.com/4643067/diff/15002/input/regression/phrasing-slur-multiple.ly#newcode12
input/regression/phrasing-slur-multiple.ly:12
LGTM, please push.
(under my seal as Documentation Meister)
http://codereview.appspot.com/4668058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 07/07/11 18:08, n.putt...@gmail.com wrote:
> Hi Anthony,
>
> When we discussed this last year, I argued that it shouldn't be part of
> the Chord_name_engraver. I still think this approach is misguided since
> we already have a convenient way of generating chord name markup via the
> formatter
On 7 July 2011 19:09, Wols Lists wrote:
> Which I probably didn't understand :-) BUT from what I remember did you
> think that feeding a chord of, say, C into the formatter should chuck
> out A as its result? Which is NOT what this does - it has to chuck out
> both C *and* A. Bear in mind - that
In my version of LilyDev, it appears that ImageMagick is installed, since
Synaptic offers either to remove it or to reinstall it. But typing
imagemagick from the command line doesn't find it. Could someone tell me
how to run it, please?
--
Phil Holmes
Bug Squad
__
On Wed, Jul 6, 2011 at 4:19 AM, wrote:
> Reviewers: ,
>
> Message:
> I tried this with my local branch and I noticed no slow-down (I'm sure
> there is one, but it certainly is not prohibitive). It gets rid of any
> potential segfaults from bad property sets in the layout block.
Can you do a rea
Hi Anthony,
When we discussed this last year, I argued that it shouldn't be part of
the Chord_name_engraver. I still think this approach is misguided since
we already have a convenient way of generating chord name markup via the
formatter function.
If you check the archives, you'll see a proof-
LGTM, though the regtest is still a bit messy.
http://codereview.appspot.com/4667055/diff/14001/scm/define-grob-interfaces.scm
File scm/define-grob-interfaces.scm (right):
http://codereview.appspot.com/4667055/diff/14001/scm/define-grob-interfaces.scm#newcode128
scm/define-grob-interfaces.scm:1
On 7 July 2011 12:02, wrote:
>
> http://codereview.appspot.com/4654090/diff/1/lily/context.cc
> File lily/context.cc (right):
>
> http://codereview.appspot.com/4654090/diff/1/lily/context.cc#newcode496
> lily/context.cc:496: properties_dict ()->set (sym, val);
> else if (do_internal_type_checking
Am Donnerstag, 7. Juli 2011, 18:15:54 schrieben Sie:
> On 6 July 2011 16:07, wrote:
> > I now debugged that problem and the issue is that ALL events created by
> > \breakDynamicSpan are sent to the engraver before any dynamic event is
> > sent. In particular, for c1\<\breakDynamicSpan the order o
On 6 July 2011 16:07, wrote:
> I now debugged that problem and the issue is that ALL events created by
> \breakDynamicSpan are sent to the engraver before any dynamic event is
> sent. In particular, for c1\<\breakDynamicSpan the order of events heard
> by the dynamic span engraver is:
> 1) break
Reviewers: Graham Percival,
Message:
Draft 2
http://codereview.appspot.com/4668058/diff/1/Documentation/web/manuals.itexi
File Documentation/web/manuals.itexi (right):
http://codereview.appspot.com/4668058/diff/1/Documentation/web/manuals.itexi#newcode129
Documentation/web/manuals.itexi:129: (
On 7/7/11 7:30 AM, "m...@apollinemike.com" wrote:
>> Mmmm...
>>
>> Do we have generic procedures for "combine markup" and "stack markup"?
>> If not, there'll be a flurry of frog emails as I try and write them :-)
>> (note to self - ly:stencil-combine-at-edge)
>>
>
> line and column
> (see l
On Thu, Jul 07, 2011 at 02:59:37PM +0200, Matthias Kilian wrote:
> Wouldn't it be better to either collect both stdout and stderr in
> the same log file or to use three log files .err.log, .out.log and
> .log, where the latter contains the combined streams? Otherwise you are
> loosing the context b
- Original Message -
From: "Matthias Kilian"
To: "Graham Percival"
Cc:
Sent: Thursday, July 07, 2011 1:59 PM
Subject: Re: GOP-PROP 5: build system output
On Thu, Jul 07, 2011 at 01:16:21PM +0100, Graham Percival wrote:
* Wherever possible, stderr output should go to *.err.log a
>> * Wherever possible, stderr output should go to *.err.log and
>> stdout output to *.log
>
> Wouldn't it be better to either collect both stdout and stderr in
> the same log file or to use three log files .err.log, .out.log and
> .log, where the latter contains the combined streams?
> Mmmm...
>
> Do we have generic procedures for "combine markup" and "stack markup"?
> If not, there'll be a flurry of frog emails as I try and write them :-)
> (note to self - ly:stencil-combine-at-edge)
>
line and column
(see line 1074 and line 1426 of scm/define-markup-commands.scm)
> Becaus
On 07/07/11 03:21, carl.d.soren...@gmail.com wrote:
> Looks nice!
>
> I have a few suggestions.
>
> As far as running things through the formatter goes, the current
> formatter in git master is *not* the one that we are trying to get
> approved. So it shouldn't be run on current files.
Ummm. In
On Thu, Jul 07, 2011 at 01:16:21PM +0100, Graham Percival wrote:
> * Wherever possible, stderr output should go to *.err.log and
> stdout output to *.log
Wouldn't it be better to either collect both stdout and stderr in
the same log file or to use three log files .err.log, .out.log and
.
On Jul 7, 2011, at 1:54 PM, Phil Holmes wrote:
> "Phil Holmes" wrote in message
> news:iv1veg$kvm$1...@dough.gmane.org...
>> Official tracker looks OK - good to see the changes to accidental (no
>> natural after sharp->flat and vice versa).
>>
>> Pixel comparator generally OK - one significant
http://lilypond.org/~graham/gop/gop_5.html
(proposal written by Phil Holmes. I have a few qualms, which I
will send when I have a bit more time)
** Proposal summary
Let’s decide what we want to see when we do:
make
make doc
** Rationale
Before any of the current work on reducin
"Phil Holmes" wrote in message
news:iv1veg$kvm$1...@dough.gmane.org...
Official tracker looks OK - good to see the changes to accidental (no
natural after sharp->flat and vice versa).
Pixel comparator generally OK - one significant change with glissandi that
looks wrong to my eyes. See attache
On Thu, Jul 07, 2011 at 12:47:23PM +0200, Jan Nieuwenhuizen wrote:
> Then that's probably largely my fault. Sorry. So somehow we
> unconsciously arrived at some status quo, but how can that be
> taken for a guideline or policy?
The policy element here is "we do not need to follow emacs
blindly".
Am Donnerstag, 7. Juli 2011, 12:47:23 schrieb Jan Nieuwenhuizen:
> Graham Percival writes:
> > I was interpreting "GNU code" to mean "code which strictly follows the
> > GNU guidelines".
>
> I do not see the difference: we try to do that, of course.
Okay, true. We are strictly following the GNU g
http://codereview.appspot.com/4654090/diff/1/lily/context.cc
File lily/context.cc (right):
http://codereview.appspot.com/4654090/diff/1/lily/context.cc#newcode496
lily/context.cc:496: properties_dict ()->set (sym, val);
else if (do_internal_type_checking_global) {
assert(...);
}
Otherwise do_
Graham Percival writes:
> I was interpreting "GNU code" to mean "code which strictly follows the
> GNU guidelines".
I do not see the difference: we try to do that, of course.
> LilyPond code has not done this for years
Then that's probably largely my fault. Sorry. So somehow we
unconsciously
http://codereview.appspot.com/4636082/diff/4002/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):
http://codereview.appspot.com/4636082/diff/4002/Documentation/web/community.itexi#newcode311
Documentation/web/community.itexi:311: Specify which release of LilyPond
http://codereview.appspot.com/4668058/diff/1/Documentation/web/manuals.itexi
File Documentation/web/manuals.itexi (right):
http://codereview.appspot.com/4668058/diff/1/Documentation/web/manuals.itexi#newcode129
Documentation/web/manuals.itexi:129: (LSR). User-created snippets that
show a part
On Thu, Jul 07, 2011 at 12:28:00AM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > But we're not talking about GNU code. We're talking about
> > lilypond code,
>
> When did Lilypond stop to be a GNU project?
*sigh*
I was interpreting "GNU code" to mean "code which strictly follows
On 07/07/11 08:59, Janek Warchoł wrote:
> 2011/7/7 Wols Lists :
>> On 06/07/11 20:31, lemniskata.bernoull...@gmail.com wrote:
>
>> And it's the one supplied with lilypond - I assumed it formatted the
>> code as per lilypond guidelines ...
>
> It isn't, mostly because there were no precisely defi
On 2011/06/26 10:03:16, mike_apollinemike.com wrote:
On Jun 26, 2011, at 11:26 AM, mailto:m...@apollinemike.com wrote:
> On Jun 25, 2011, at 6:38 PM, mailto:percival.music...@gmail.com
wrote:
>
>> On 2011/06/25 07:15:39, J_lowe wrote:
>>> I get an error/seg fault when I try to make:
>>
>> I
2011/7/7 Wols Lists :
> On 06/07/11 20:31, lemniskata.bernoull...@gmail.com wrote:
>> New patch set uploaded.
>> Hmm, Wol, did you use some code formatting tool on a whole file? I see a
>> lot of style changes, and not all of them are for the good.
>>
>> http://codereview.appspot.com/4626094/
>>
>
On Tue 05 Jul 2011, 23:22 David Nalesnik wrote:
> Hi, Colin --
>
> On 7/5/11, Colin Campbell wrote:
> >
> > This will probably require an issue, David, but could you send the code
> > you used to produce the 2.12.3 version, please? I can't reproduce the
> > previous stable example, in order to c
On Jul 7, 2011, at 4:53 AM, Colin Campbell wrote:
> Issue 1734: Lilypond crashes on "fingeringOrientations = #'right" if set in
> \layout { \ context { \Score ... } }
> Reitveld Issue 4650070: Adds a warning for non-list fingeringOrientations
> settings.
>
Hey all,
I'd like to
47 matches
Mail list logo
