Re: What's the deal with the module system?

[David Kastrup]

David Kastrup <address@hidden> writes:

> Neil Puttock <address@hidden> writes:
>
>> 2009/11/24 David Kastrup <address@hidden>:
>>
>>> 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