[Top][All Lists]

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

Re: Keep yaffut from attempting to demangle. (issue 5375051)

From: David Kastrup
Subject: Re: Keep yaffut from attempting to demangle. (issue 5375051)
Date: Fri, 11 Nov 2011 18:15:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Graham Percival <address@hidden> writes:

> On Fri, Nov 11, 2011 at 02:42:55PM +0100, Jan Nieuwenhuizen wrote:
>> David Kastrup writes:
>> > The patch in its current state does not affect a working test suite, and
>> > it lets "make check" finish with slightly less readable output when
>> > cxxabi.h breaks g++ 4.6.  So it is _strictly_ an improvement.
>> Then commit it already!
> Classy.
> (the below is NOT directed at David, who is an absolutely
> fantastic developer)

He still tested the change backward and forward before committing it,
both with conditions breaking cxxabi and without.  Since just flower is
concerned, testing this is fast.

Remember that the previous state was that checking failed at the linking
stage when using options useful for debugging were used with g++ 4.6.

I actually pushed before Jan wrote this because I was annoyed as heck at
the amount of time I invested into this, was very positive that it would
work (I doubt anybody gave this 5% of the thought and testing I did),
and would probably have committed homicide when getting one more comment
in the review about this totally unnecessary issue, and how I should
spend another few $100 worth of developer time in order not to take any
polish from this misbegotten hobby horse not belonging in Lilypond.

> Might I remind you that almost everybody wants to have stable release
> more often?  And that the biggest cause of not having stable releases
> are regressions?  And that the best time to fix regressions are
> *before* they happen?  And that code reviews have been found to be the
> best single factor for catching bugs?  And that nobody (apart from
> maybe you) actually knows what yaffut is doing or how it works?

If nobody knows that it does, then there is nobody else going to give a
useful review.  Case closed.

Mind you, it is not like I was enthused at the flippantness of that
followup comment, but I had taken action before that anyway.

> David is good.  Really good.  But he's also human.  Maybe he added
> an extra semicolon somewhere that makes the code look ok, but blow
> up in certain circumstances.  (I've spent at least 20 hours of my
> life on semicolon bugs)
> Maybe his changes work great on his machine, but they'll fail when
> using a different version of gcc.  Maybe he just has some variable
> names that are unclear, or maybe a one-line comment would clarify
> something... I mean, after staring at his change to yaffut.hh for
> a while, I gather that it's constructing a name for a type... but
> if I'd seen
>   // construct a name for a type of variable
> at the top of the demangle() function, I wouldn't have to spend a
> minute or two puzzling through stuff like
>   std::string name (ptr ? ptr : "", ptr ? strlen (ptr) : 0);

Sorry, but all the _uncommented_ _crap_ in yaffut.hh was there to start
with.  I introduced not a single line doing anything that was not
already there in more complex surroundings.

> Of course the lack of a comment like that isn't David's fault;
> it's the fault of whoever wrote that code in the first place.  But
> this would be a good opportunity to clarify that, for future
> programmers.

How many man-hours from Lilypond developers are you planning in
maintaining yaffut.hh, for a test suite that calls exactly 15 functions
and checks that they return the expected values?

One can do that in half an hour.  Probably a third of the time needed to
get yaffut.hh compile without warnings, and 5% of the time I already
invested in debugging this contraption and coming up with an
autoconf-based approach making Jan happy.

This is _totally_ stupid.  Any sane programmer would replace this
nonsense by a call of 15 functions and checking the returned results.

Don't further feed that time sink.

> Unfortunately, most people expect (or at least want) lilypond to
> be stable, and we have no budget for hiring experienced
> developers.

Do you have a budget for chasing them off?

> The 48-hour "patch countdown" is designed to give people a chance to
> address both problems -- does the code work, and is it *obvious* how
> the code works.  Granted, we rarely take advantage of the review
> period to actually discuss what the code is doing and request more
> comments... but this *does* happen occasionally, and I definitely
> think it's worth keeping the *opportunity* for idiots like me to ask
> for help in understanding the code.

I am covered in red tape.  I have been doing major brain surgery on
Lilypond in the recent weeks, and gotten almost no comment whatsoever in
the reviews.  Not very encouraging, but at least I know that I am making
Lilypond a place with a reasonably comfortable programming model, even
if nobody else does.

And now I get an explosion of self-important chastisement on the
silliest and most brainless issue of all, stopping an independent check
routine from crashing, something that is not part of Lilypond and broken
to start with, and invest a wagonload of work so that the output, which
nobody will ever look at, remains a bit prettier given the right

Give it a rest.  I pushed this thing because this issue is dead and does
not deserve to cause me further annoyance.  If you want to keep harping
on it, pay me for the time I spent for no sane reason on it, just to
keep people happy.

David Kastrup

reply via email to

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