On Sat, 14 Jul 2012 19:14:41 -0700, wrote:
Do we have evidence of people using 2/ 3 anywhere?
I don't know of any scores with spaces alongside the / .
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/li
http://codereview.appspot.com/6399046/diff/1/configure.in
File configure.in (right):
http://codereview.appspot.com/6399046/diff/1/configure.in#newcode66
configure.in:66: _NCSB_SOURCE_FILES_=""
On 2012/07/15 00:37:15, John Mandereau wrote:
On 2012/07/15 00:21:16, Graham Percival wrote:
> what's
http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi
File Documentation/common-macros.itexi (right):
http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi#newcode16
Documentation/common-macros.itexi:16: % code stolen from Heiko
Oberdiek's `ifpdf
Reviewers: Graham Percival,
Message:
On 2012/07/15 01:45:06, Graham Percival wrote:
I can't see any diff on rietveld, but presumably there's so much being
changed
that a diff wouldn't be helpful anyway.
If a "make doc" looks good to you, and you're willing to handle any
potential
fall-out
Reviewers: Keith,
Message:
On 2012/07/14 21:29:42, Keith wrote:
It is too unfriendly to say "unexpected '/'" to someone who wrote
{\times 2/ 3 {
b2 b b }}. We need at least a conversion rule like "(\d)\s*/\s*(\d)"
=> "\1/\2"
In the existing code base, that would reach the following:
input/
On Fri, Jul 13, 2012 at 09:23:00AM +0100, Phil Holmes wrote:
> My suggestion - unless there are _real_ problems with my patch (and
> there aren't) let's start focussing on other shitty bits of
> documentation now that I've fixed this shitty element of the NR.
...
ok. By my "working rule" (he who
On Sat, Jul 14, 2012 at 02:49:21PM +0100, Trevor Daniels wrote:
>
> Jean-Charles Malahieude wrote Saturday, July 14, 2012 1:29 PM
>
> > I think that most of these bad presentations are due to the fact that
> > proofreading is done with the HTML version. We should then advocate
> > that the "fi
LGTM
http://codereview.appspot.com/6344092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I can't see any diff on rietveld, but presumably there's so much being
changed that a diff wouldn't be helpful anyway.
If a "make doc" looks good to you, and you're willing to handle any
potential fall-out from breakage at this point in the release cycle,
then as far as I'm concerned you can push
On Sun, Jul 15, 2012 at 12:37:15AM +, john.mander...@gmail.com wrote:
> configure.in:66: _NCSB_SOURCE_FILES_=""
> On 2012/07/15 00:21:16, Graham Percival wrote:
> >what's the convention for leading _ in names? I havent' encountered
> this
> >before.
>
> It was just my lack of imagination for
Reviewers: Graham Percival,
Message:
Hi Graham,
Thanks for the quick review, I'll upload another patch when I get
another review or at the earliest this week-end.
Please also note my comments on the bug tracker w.r.t. distribution of
lilypond.map and documentation.
http://codereview.appspot.c
wow, awesome work!
http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi
File Documentation/common-macros.itexi (right):
http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi#newcode16
Documentation/common-macros.itexi:16: % code stolen from Hei
Patch pushed.
On Tue, 10 Jul 2012 22:40:49 -0700, Frédéric Bron wrote:
patch proposed.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
It is too unfriendly to say "unexpected '/'" to someone who wrote
{\times 2/ 3 { b2 b b }}. We need at least a conversion rule like
"(\d)\s*/\s*(\d)" => "\1/\2"
http://codereview.appspot.com/6399045/
___
lilypond-devel mailing list
lilypond-devel@gnu.
LGTM.
Scheme-only patches are nice, because we don't have to book Linux to try
them out.
I would not hesitate to put this in before 2.16, because it is adds
capability without changing anything existing.
http://codereview.appspot.com/6344092/diff/12002/Documentation/snippets/new/cross-staff-st
http://codereview.appspot.com/5626052/diff/85004/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/5626052/diff/85004/lily/skyline.cc#newcode292
lily/skyline.cc:292: Real p1 = left->end_ * left->slope_ +
left->y_intercept_;
On 2012/07/14 14:01:08, joeneeman wrote:
use
Please review final updates.
http://codereview.appspot.com/6344092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham,
Please see http://code.google.com/p/lilypond/issues/detail?id=2585
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Just looked at skyline-related stuff for now...
http://codereview.appspot.com/5626052/diff/85004/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/5626052/diff/85004/lily/skyline.cc#newcode292
lily/skyline.cc:292: Real p1 = left->end_ * left->slope_ +
left->y_intercept
Jean-Charles Malahieude wrote Saturday, July 14, 2012 1:29 PM
> I think that most of these bad presentations are due to the fact that
> proofreading is done with the HTML version. We should then advocate
> that the "final draft" before pushing a patch that touches any part of
> the documentat
Le 13/07/2012 10:23, Phil Holmes disait :
- Original Message - From: "Graham Percival"
Anyway, my current understanding is that there are three realistic
options:
1)
--- linewidth --
fromsome kind of
emergency-stretch-tweak
--- linewidth --
2)
manua
Hi,
this is really cool!
A few general remarks:
- is there a command to turn it off?
- there already is a command \parenthesize. Your function seems to be
smarter (at least in some cases); would it be to combine them? Having
two similar functions is confusing.
- i get a segmentation fault when
Hi,
Keith, somehow i had overlooked this part of your email:
On Wed, Jun 27, 2012 at 7:33 AM, Keith OHara wrote:
> For any changed test then, it is probably worth reading the header, to
> see if a subtle change that looks harmless happens to be the point of
> the test (and would presumably cause
- Original Message -
From:
To: ;
Cc: ;
Sent: Saturday, July 14, 2012 2:39 AM
Subject: Re: Adds support for cross-staff-stems (issue 6344092)
http://codereview.appspot.com/6344092/diff/7001/input/regression/cross-staff-stems.ly
File input/regression/cross-staff-stems.ly (right):
ht
- Original Message -
From: "Thomas Morley"
To: "Phil Holmes"
Cc: ;
Sent: Friday, July 13, 2012 11:13 PM
Subject: Re: parenthesizeStencil and bracketifyStencil (issue 6397043)
2012/7/13 Phil Holmes :
(...)
So - if your changes will break the snippet, but will only work in in
future
Janek Warchoł writes:
> On Sat, Jul 14, 2012 at 11:30 AM, David Kastrup wrote:
>> "Trevor Daniels" writes:
>>> I suggest that you keep any such decision to yourself until
>>> just before the next stable is built, or defer making it until
>>> then. Otherwise interest in fixed such bugs will wan
On Sat, Jul 14, 2012 at 11:30 AM, David Kastrup wrote:
> "Trevor Daniels" writes:
>> I suggest that you keep any such decision to yourself until
>> just before the next stable is built, or defer making it until
>> then. Otherwise interest in fixed such bugs will wane.
>
> And in the interest of
Janek Warchoł writes:
> On Sat, Jul 14, 2012 at 4:56 AM, Graham Percival
> wrote:
>> David,
>>
>> I realize that you are angry, but please stop using words like
>> "monkey"
>
> I'm responsible for "monkey". You asked to stop using it, but i
> continued to do so (not because of malice - i just d
Graham Percival writes:
> On Fri, Jul 13, 2012 at 06:23:57PM +0100, Phil Holmes wrote:
>> - Original Message - From: "Trevor Daniels"
>>
>>
>> >a) a release-meister with responsibility to take all decisions.
>> >That's what Han-Wen used to do, I believe. It worked
>> >quite well, altho
"Trevor Daniels" writes:
> David Kastrup wrote Saturday, July 14, 2012 9:30 AM
>
>> After the first release, the focus of branch maintenance will go from
>> _defining/shaping_ a stable release to _maintaining_ it. That
>> seriously changes the importance of avoiding new regressions even of
>> mi
David Kastrup wrote Saturday, July 14, 2012 9:30 AM
> Graham Percival writes:
>
>> Let’s appoint David Kastrup as the “benevolent dictator” of the
>> stable/2.16 git branch.
I'm happy to go along with this. It's hardly a policy, but it
will definitely move things along!
> Well, it definit
Am 13.07.2012 10:08, schrieb ArnoldTheresius:
Well, I found it so ugly the Segno in the staff does not cooperate with the
\repeat volta command.
I installed on my WIN7 offline computer the lilydef VM, got a tarball from
GIT (HTML user interface), and tested my ideas to change it.
In contact wit
Graham Percival writes:
> I will officially introduce this next Tuesday, but since it's now
> a hot topic, let's have an extra round of discussion and fixing
> before then.
>
> http://lilypond.org/~graham/gop/gop_3.html
>
>
> *** Summary
>
> Let’s appoint David Kastrup as the “benevolent dictator
On Sat, Jul 14, 2012 at 6:31 AM, Graham Percival
wrote:
> On Wed, Jul 11, 2012 at 05:48:48PM +0200, Janek Warchoł wrote:
>> On Tue, Jun 26, 2012 at 10:55 PM, Graham Percival
>> wrote:
>> > To avoid slowing down programming to a crawl, I figure that we’ll
>> > identify some subset of these regtest
On Sat, Jul 14, 2012 at 6:15 AM, Graham Percival
wrote:
> Let’s appoint David Kastrup as the “benevolent dictator” of the
> stable/2.16 git branch.
+1
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/
http://codereview.appspot.com/6303065/diff/9001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/6303065/diff/9001/lily/stem.cc#newcode710
lily/stem.cc:710: if (calc_beam && !beam && !unsmob_stencil
(me->get_property ("stencil")))
On 2012/06/11 16:33:27, Keith wrote:
If you
http://codereview.appspot.com/6211047/diff/20001/lily/bar-line.cc
File lily/bar-line.cc (right):
http://codereview.appspot.com/6211047/diff/20001/lily/bar-line.cc#newcode151
lily/bar-line.cc:151: Real const gap_to_find = (1.0 + 3 * staffline) /
staff_space;
It seems you want
Real const gap_to_fi
Janek Warchoł writes:
> Hi Harm,
>
> On Fri, Jul 13, 2012 at 11:38 PM, Thomas Morley
> wrote:
>> Hi Janek,
>>
>> UFF!!
>>
>> Thanks a lot.
>> Your hint about the wrong server was it. I overlooked it in the log
>> and I've absolutely no idea how it could happen that the server was
>> changed.
>
>
On Sat, Jul 14, 2012 at 4:56 AM, Graham Percival
wrote:
> David,
>
> I realize that you are angry, but please stop using words like
> "monkey"
I'm responsible for "monkey". You asked to stop using it, but i
continued to do so (not because of malice - i just didn't find good
replacement).
I apolo
Hi Harm,
On Fri, Jul 13, 2012 at 11:38 PM, Thomas Morley
wrote:
> Hi Janek,
>
> UFF!!
>
> Thanks a lot.
> Your hint about the wrong server was it. I overlooked it in the log
> and I've absolutely no idea how it could happen that the server was
> changed.
Glad i helped!
> BTW,
> git config -e
>
40 matches
Mail list logo
