Hi, you might have been wondering what I've been up to in the last month or so. I have by now accumulated several rewrites of the "dispatcher"/"listener"-related internals of engravers/performers/translators and got them working. Unfortunately, by the time I finish one rewrite, I have learnt enough to figure out why the approach in general is more complex to maintain than desirable and how the work might be better organized.
Also the first rewrite was sort of embarrassing in that I got every wrinkle out until the last point remaining were Scheme engravers. And those would not have fit into this approach well at all. But they are too important for that. As things currently stand, I suspect that the current mechanism for creating Scheme engravers with their own variables (namely providing a function creating an engraver description) does not have likable performance characteristics and, more importantly, does not really work reasonably at all with regard to registering Scheme engravers like C++ engravers so that they can be called by name and documented in the same manner. I'll probably come up with something GOOPS-related eventually and the closure mechanism for creating Scheme engravers will be deprecated. At any rate, I am starting over _again_ but I think that I am now at the stage where my plan of execution is nicely streamlined and "Listeners" from both C++ and Scheme level (as well as their creation from the bowels of the respective engraver types) are quite straightforward to deploy and debug and don't rely on all the C level macro hackery. It _is_ sort of a nuisance to have several iterations of working branches that have each taken quite a bit of work to run fine but that end up catering for what amounts to ultimately being the wrong kind of data structure for long-time code maintenance. Reminds me of the old joke about an experimental physicist asking the university dean for funding of an accelerator, and the dean goes "why can't you be like the mathematicians? All they need is pencil, paper, and a wastebasket. And the philosophers don't even need a wastebasket..." So in short, I've been tending the most important resource a good programmer should have in his possession: the wastebasket. And I expect people to ultimately be glad about all the code I have thrown away once I get to throwing away the current code we work with. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
