Reinhold Kainhofer <[email protected]> writes: > Am Mittwoch, 25. November 2009 10:02:55 schrieb David Kastrup: >> It would have helped if the code I threw out had contained any >> comments as to what problem it tried to fix, and what symptoms were >> involved. > > Yes, that's also my main problem: The code does not contain any > comments, so it's really hard to understand how something > works.
I can deal with "how something works" most of the time, where concise, reasonably well-purposed code is involved. I've done this even with disassembled code from hand-written assembly language. One of the best-designed programs I explored was a Reversi program in Z80 machine language. Totally consistent index register use, coherent data structures, Alpha-Beta pruning implemented straight from the book, scoring lookup tables in a good layout. Every piece of code had a clear intent and function. I can read a story and plot written in a programming language. But I can't reinvest the time others placed into designing workarounds, making design decisions and the like. Computer programs are not the place for "Deus ex machina" plot twists and mystery novels. Programs need to be written like good children books, not making life more trivial than it is, not hiding it, but also not making it more complicate. And where this is not possible because of external influences (like bugs in guile), code comments must be there. And if that is not the case, something is rotten. And yes, rotten things make me ill-tempered, and ill-tempered people are a nuisance. Other people silently go away. But that does not help. The likelihood to find nice, friendly persons that know to ask the right questions in the right way about undocumented incomprehensible code written for opaque purposes and have the expertise and experience to both deal with code that is not as it should be as well as with the developers responsible for it, or at least knowledgable about it, is not high. So it is a waste of scarce human resources to even shoo apparent assholes like myself away. > That's one of the reasons why I haven't gotten deeper into lilypond > development, simply because it's way too much work to try to > understand the internal details... I can work myself into internal details. But not into those details that aren't actually to be found. >> By the way: anybody have a suggestion about why, even after make clean >> and the like, my regression tests always bomb out with >> > [...] >> WARNING: Unable to load the map file >> Undefined subroutine &main:: called at >> /usr/local/tmp/lilypond/Documentation/lilypond-texi2html.init line 750. >> make[2]: *** [out-test/collated-files.html] Error 25 >> rm /usr/local/tmp/lilypond/./out-test/xref-maps/collated-files.xref-map >> make[2]: Leaving directory `/usr/local/tmp/lilypond/input/regression' >> make[1]: *** [local-test] Error 2 >> make[1]: Leaving directory `/usr/local/tmp/lilypond/input/regression' >> make: *** [test] Error 2 > > Do you have texi2html CVS installed? The CVS version is under heavy > development, so it currently only works with texi2html 1.82. (some > internal functions were renamed, upon which our .init script relies. Sounds like a dependency impacting developers rather severely. I don't have Python experience so can't get into it. Maybe it would make sense to place a copy of texi2html into the Lilypond source tree as long as Lilypond can't avoid meddling with internals of texi2html? Otherwise arbitrary breakage with versions out of the control of Lilypond will remain to be expected. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
