Neil Puttock <[email protected]> writes: > 2009/11/24 David Kastrup <[email protected]>: > >> After applying <URL:http://codereview.appspot.com/160048> first, >> indeed the following diff that throws out all the toplevel scoping >> constructs and separate definitions of define-markup-command and >> define-markup-list-command passes the regressions tests. Furthermore, >> tests show that the namespace of markups defined in one input file does >> not extend into the next input file. > > As far as I can see, all you've done is effectively revert Nicolas's > code which fixed the memory leaks, so I can't see why it would work.
Too bad nobody told me "check the git log of markup-init.ly from around its first check-in, then read the whole thread to its end which is <URL:http://lists.gnu.org/archive/html/lilypond-devel/2006-12/msg00329.html>. While nobody bothers mentioning that this final suggestion about the error message that your own compilation does not show, but that of others do, has been cast into code, it should be obvious that this is what you are dealing with". Kind of obvious, isn't it? In the light of this archive mail proposing the fix for the scoping issue being from Han-Wen, I have a hard time feeling enthused about his advice I don't know. Why don't you try it, and send us a patch if it passes the regression tests? in <URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/25672>. If people can't be expected to know their code and analysis from three years ago, there must be comments, or the whole thing will explode around the head of the next person who touches it. Including the original author that apparently does not remember what he did something for. Now Han-Wen could say "Nicolas actually wrote this code" and Nicolas could say "I did not really know what I was doing, just following Han-Wen's advice". But then the patch should not have passed code review. The kind of code review that causes days of explanations from me for trivial patches. > I've just applied your patch, and as expected, I get the following > errors with nearly every file (using a binary compiled with > --disable-optimising): > > programming error: Parsed object should be dead: static > scm_unused_struct* Prob::mark_smob(scm_unused_struct*) > continuing, cross fingers > programming error: Parsed object should be dead: static > scm_unused_struct* Context_def::mark_smob(scm_unused_struct*) > continuing, cross fingers > > Furthermore, make check segfaults if I use -j2. Well, as I said, I don't. I'll try seeing whether I can come up with a good deal for letting markup signatures go out of scope together with their markups themselves. Even while I can't reproduce the problem, maybe this will improve the situation for somebody else. I have my doubts that Lilypond can develop into a sustainable project from the current state of core mind and code. Projects like the frogs are nice for recruiting people, but if they are locked out of engagedly working with parts of the core for technical and social reasons, this is ultimately going nowhere new. New people can't pick up the slack if they are not shown the ropes. Those that do the heavy lifting, not the whips. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
