David Kastrup <[email protected]> writes: > 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. > > Fixed the memory leaks. Something new every day. Why tell me all the > time that the purpose of the code was scoping, then? > > Since the code registers properties and functions permanently, sure it > will work as a memory leak between multiple sessions. I was worrying > about the action of the code. > > It is easy enough to turn off this registration for user level code. > That might already do the job. > >> 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): > > I did not use --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. > > I have my doubts -j2 is concerned with the patch other than accidently. > > Our results are so different that I have my suspicion this might also > depend on the guile version used. 1.8.7 here.
Further data: g++ 4.4.1. I used --without-optimise now, recompiled and am now running make check. No problems so far, but indeed memory usage is excessive (850MB of virtual memory so far after 45min of compiling the regression tests). I'll see what switching off the registration of functions might achieve. 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. Or, for the matter, if somebody on the mailing list had bothered to tell me instead of basically saying "figure this out yourself, this will be fun". Since I can't reproduce the apparent memory corruption problem that Neil reports, without any code comments or information I have no clue whatsoever about what I should do for finding out why my code fails for _others_. Reverse-engineering the purpose of undocumented code when I can't even reproduce the symptoms that it was apparently intended to cure is really not the level of expertise reasonable to expect from aspiring Lilypond developers if you want to expand their circle. Does anybody have suggestions how I am supposed to continue from here? Both with regard to working with the code, as well as working with developers? What am I (or other prospective developers) supposed to ask for, and from whom, in order to continue working on the Scheme code base? Let us put myself aside right now. Let's assume that a perfectly amicable, capable Scheme developer decides to work on and with the Lilypond codebase. How would this person then get to know what the code does, why it does that, which symptoms it adresses, how they can be reproduced, why it is a bad idea to remove the code, and what was the idea behind its design? By the way: anybody have a suggestion about why, even after make clean and the like, my regression tests always bomb out with riting `/usr/local/tmp/lilypond/input/regression/out-test/AAA-intro-regression.texi'... /usr/local/tmp/lilypond/scripts/build/out/extract_texi_filenames -I ./out-test -o /usr/local/tmp/lilypond/./out-test/xref-maps out-test/collated-files.texi extract_texi_filenames.py: Processing out-test/collated-files.texi writing: /usr/local/tmp/lilypond/./out-test/xref-maps/collated-files.xref-map SRC_DIR=. PERL_UNICODE=SD texi2html --I=. --I=./out-test -I /usr/local/tmp/lilypond/Documentation --I=/usr/local/tmp/lilypond/./out-test/xref-maps --init-file=/usr/local/tmp/lilypond/Documentation/lilypond-texi2html.init --output=out-test/collated-files.html out-test/collated-files.texi 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 ultimately? Is there nothing that can be fixed in the source tree to address this? Thanks -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
