[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make define-builtin-markup{, -list}-command #:category #:properties

From: David Kastrup
Subject: Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)
Date: Thu, 03 Dec 2009 22:39:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Graham Percival <address@hidden> writes:

> On Thu, Dec 03, 2009 at 09:57:39PM +0100, David Kastrup wrote:
>> Are you suggesting that this incident should show that newcomers are
>> to jump through even higher hoops while the regulars continue to work
>> efficiently?
> No.  It shows that regular committers *should* jump through the same
> hoops, and when they don't, Bad Things Happen (tm).  I mean, Carl is
> probably #5 on the "most knowledgeable people about lilypond
> architecture in the world"; he even *he* can royally screw up with a
> "simple" patch, then surely a new contributor is even more likely to
> write bad code.
> That's why we should have patch reviews and testing.

I keep asking for the testing, with little success so far.  I still
don't know whether the changes from a week ago solve the memory
leak/corruption problem reported with a previous version.

I might have mentioned that I have not been able to verify the original
report, since it worked and I got no recipe to make it fail in the
reported way.

Nicolas has put up a review just today for which I am grateful, but it
focuses on programming style questions.

It would be a bit of a nuisance to invest a lot of time into polishing
the style of obliterating when I have no idea whether the
basic approach will work at all.  I have no working test to check.  At
least Neil had such a test, but I am missing the information needed for
reproducing it.

If I am barking up the wrong tree, making the tree prettier is not going
to be a worthwhile exercise.

A "yes, this fixed the memory problem" would be a great help.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]