* David Kastrup wrote on Mon, Aug 16, 2010 at 04:16:49AM CEST:
> The problem, as pointed out already, is that the commit affects the bulk
> of the indentation in the respective functions, while changing only few
> lines of substance.
>
> And that means that it conflicts with any other ongoing work
On Mon, Aug 16, 2010 at 05:00:37AM +0200, David Kastrup wrote:
>
> In the patch
>
> Doc: CG: begin cleaning up Releases chapter.
>
> I read a number of changes like
>
> +...@item
> * write preface section for manual.
Yes.
> It would seem to me that adding the @item lines should be accomp
In the patch
Author: Graham Percival 2010-08-15 19:14:33
Committer: Graham Percival 2010-08-15 19:14:33
Parent: cfe29e5a0720f8e5ca7e220c77e9cf8ab2d08306 (Doc: CG: add warning about
test-output-distance.)
Branches: master, remotes/origin/master
Follows: release/2.13.30-1
Precedes:
Doc:
Carl Sorensen writes:
> On 8/15/10 9:40 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> On 8/15/10 7:39 AM, "David Kastrup" wrote:
>>>
Carl Sorensen writes:
>
> I think so. The full review process for removing old stuff is
> generally very short and sweet (po
LGTM.
Thanks
http://codereview.appspot.com/1991043/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
Further info: This code has been in the file since
114c05e7b0e992de7dbdd0958d23eb8d2ab1eaae
(the file name at that time was scm/new-markup.scm).
I think that the alternate syntax has never been used in the main source
tree;
it could have been used (but it's doubtful) in an individual use
On 8/15/10 9:40 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 8/15/10 7:39 AM, "David Kastrup" wrote:
>>
>>> Carl Sorensen writes:
I think so. The full review process for removing old stuff is
generally very short and sweet (post the patch, somebody important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
Has anyone noticed this problem on the second and following pages of PDF
output, I've reproduced this with 2.13.17 and with 2.13.29. I'd like
to know if anyone else has noticed this.
The shortInstrumentNames you should see are:
Picc 1
Picc
>> Should it be wrapped in a full review process?
>
> I think so. The full review process for removing old stuff is
> generally very short and sweet (post the patch, somebody important
> says OK), so I don't think it hurts a bit to do it.
Well, IMHO, for trivial things: Just do it!
Werner
Le 15/08/2010 17:20, Francisco Vila disait :
2010/8/13 Graham Percival:
Translators: at the moment, I'm cautiously predicting that 2.14.0 will
be 4 to 8 weeks away. You will have at least 2 weeks (14 days) notice
before 2.14.0 -- each release candidate is such a warning. Francisco,
you're in c
http://codereview.appspot.com/1991043>
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Carl Sorensen writes:
> On 8/15/10 9:14 AM, "David Kastrup" wrote:
>
>>
>> The development work should go up to Rietveld, the cleanup should go up
>> to Rietveld. git-cl can associate only one review per branch. So I
>> need to fork out the cleanup from the middle of the branch. Possibly by
Carl Sorensen writes:
> On 8/15/10 7:39 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>>
>>> I think so. The full review process for removing old stuff is
>>> generally very short and sweet (post the patch, somebody important
>>> says OK), so I don't think it hurts a bit to do it.
>>
The aliasing functionality is unused in the current source code, not
documented at user level, and not sure to be fully working (there are no
regtests to check). Documenting it complicates the documentation
without an immediately visible user benefit.
The patch likely does not apply to a pristin
On 8/15/10 9:14 AM, "David Kastrup" wrote:
>
> The development work should go up to Rietveld, the cleanup should go up
> to Rietveld. git-cl can associate only one review per branch. So I
> need to fork out the cleanup from the middle of the branch. Possibly by
> rebasing it to the tip of th
David Kastrup writes:
> Carl Sorensen writes:
>
>> On 8/15/10 7:39 AM, "David Kastrup" wrote:
>>
>>> Carl Sorensen writes:
>>>
On 8/15/10 6:48 AM, "David Kastrup" wrote:
IMO, getting rid of bit-rotted code is always a good idea.
> Should it
> be wrapped in
2010/8/13 Graham Percival :
> Translators: at the moment, I'm cautiously predicting that 2.14.0 will
> be 4 to 8 weeks away. You will have at least 2 weeks (14 days) notice
> before 2.14.0 -- each release candidate is such a warning. Francisco,
> you're in charge of sending this to the translator
Carl Sorensen writes:
> On 8/15/10 7:39 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> On 8/15/10 6:48 AM, "David Kastrup" wrote:
>>>
>>>
>>> IMO, getting rid of bit-rotted code is always a good idea.
>>>
Should it
be wrapped in a full review process?
>>>
>>> I thi
On Sun, Aug 15, 2010 at 3:47 PM, David Kastrup wrote:
> Graham Percival writes:
>
>> On Sun, Aug 15, 2010 at 3:18 PM, David Kastrup wrote:
>>> There is sufficient disagreement that I consider it useful to get a
>>> more qualified point of view.
>>
>> That would hurt if I didn't agree with you co
Graham Percival writes:
> On Sun, Aug 15, 2010 at 3:18 PM, David Kastrup wrote:
>> Carl Sorensen writes:
>>
>>> Well, FWIW, Graham agrees with you and not with me, so you could
>>> follow Graham's advice instead of mine.
>>
>> There is sufficient disagreement that I consider it useful to get a
On Sun, Aug 15, 2010 at 3:18 PM, David Kastrup wrote:
> Carl Sorensen writes:
>
>> Well, FWIW, Graham agrees with you and not with me, so you could
>> follow Graham's advice instead of mine.
>
> There is sufficient disagreement that I consider it useful to get a more
> qualified point of view.
T
On Sun, Aug 15, 2010 at 3:15 PM, David Kastrup wrote:
> Graham Percival writes:
>
>> That's a huge black mark against our development process.
>
> Not the process per se, but try doing this on Rietveld. Those are lots
> of changes in small files. For every single change, you need to tell
> the
On 8/15/10 8:15 AM, "David Kastrup" wrote:
> Graham Percival writes:
>
>>
>> we don't *have* a "full review process" in any meaningful sense of the
>> term. Especially not for "cleaning up" things.
>>
>> As evidence, consider:
>> http://codereview.appspot.com/1724041/show
>>
>> - big ini
Carl Sorensen writes:
> On 8/15/10 8:06 AM, "David Kastrup" wrote:
>
>> Whatever. I'll jump through the hoops for now. I am not confident
>> that I will consider doing cleanup worth the trouble in future. If
>> you have to invest those resources, it distracts from what you
>> actually wanted
Graham Percival writes:
>
> we don't *have* a "full review process" in any meaningful sense of the
> term. Especially not for "cleaning up" things.
>
> As evidence, consider:
> http://codereview.appspot.com/1724041/show
>
> - big initial patch
> - lots of comments about splitting up the patch i
On 8/15/10 8:06 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 8/15/10 7:39 AM, "David Kastrup" wrote:
>>
>>> Carl Sorensen writes:
>>>
On 8/15/10 6:48 AM, "David Kastrup" wrote:
IMO, getting rid of bit-rotted code is always a good idea.
> Should
Carl Sorensen writes:
> On 8/15/10 7:39 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> On 8/15/10 6:48 AM, "David Kastrup" wrote:
>>>
>>>
>>> IMO, getting rid of bit-rotted code is always a good idea.
>>>
Should it
be wrapped in a full review process?
>>>
>>> I thi
On Sun, Aug 15, 2010 at 2:39 PM, David Kastrup wrote:
> Carl Sorensen writes:
>
>>> What is the general stance towards cleanup (of unused dormant stuff
>>> never documented for general use) like that as long as it is contained
>>> in separate commits and not intermingled with other changes?
?>>
>
On 8/15/10 7:39 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 8/15/10 6:48 AM, "David Kastrup" wrote:
>>
>>
>> IMO, getting rid of bit-rotted code is always a good idea.
>>
>>> Should it
>>> be wrapped in a full review process?
>>
>> I think so. The full review process for re
Carl Sorensen writes:
> On 8/15/10 6:48 AM, "David Kastrup" wrote:
>
>> Hi, I'm just trying to improve the documentation of
>> define-markup-command and define-markup-command-list. Those commands
>> have some functionality for defining aliases to existing commands. For
>> one thing, I have my
On 8/15/10 6:48 AM, "David Kastrup" wrote:
>
>
> Hi, I'm just trying to improve the documentation of
> define-markup-command and define-markup-command-list. Those commands
> have some functionality for defining aliases to existing commands. For
> one thing, I have my doubts that this works pr
Hi, I'm just trying to improve the documentation of
define-markup-command and define-markup-command-list. Those commands
have some functionality for defining aliases to existing commands. For
one thing, I have my doubts that this works properly, for another, it
complicates implementation and doc
On 14 August 2010 10:35, Phil Holmes wrote:
>
> I've not been able to access the LSR since Friday. Is it down?
It seems, indeed.
And according to downforeveryoneorjustme.com it is down for everyone.
http://downforeveryoneorjustme.com/http://lsr.dsi.unimi.it/
Cheers,
Xavier
PS: Cc to Sebastian
Trevor Daniels wrote:
>
> The mingw binary of 2.13.30 gives the following error
> under Vista on my system:
>
> Running lilypond-book
> Traceback (most recent call last):
> File "c:/program files/lilypond/usr/bin/lilypond-book.py", line
> 86, in ?
> import book_base as BookBase
> File
On 8/15/10 2:39 AM, "David Kastrup" wrote:
> carl.d.soren...@gmail.com writes:
>
>> On 2010/08/14 19:47:59, Neil Puttock wrote:
>>> Since these are bound with defaults above, you don't need to use
>> chain-assoc-get
>>
>>> (radius size)
>>
>> Done. I forgot about how nifty the new interface i
Patrick McCarty wrote Sunday, August 15, 2010 7:27 AM
On Sat, Aug 14, 2010 at 5:23 PM, Patrick McCarty
wrote:
On Sat, Aug 14, 2010 at 4:10 PM, Trevor Daniels
wrote:
The mingw binary of 2.13.30 gives the following error
under Vista on my system:
Running lilypond-book
Traceback (most recent c
carl.d.soren...@gmail.com writes:
> On 2010/08/14 19:47:59, Neil Puttock wrote:
>> Since these are bound with defaults above, you don't need to use
> chain-assoc-get
>
>> (radius size)
>
> Done. I forgot about how nifty the new interface is that David made
> possible.
Actually, the niftiness is
37 matches
Mail list logo
