Graham Percival <gra...@percival-music.ca> 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 circumstances. 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel