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.
>>
>> 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
>
> I can't reproduce this with guile-1.8.7 and g++-4.4.1 from Ubuntu 9.10.
>
> The memory leak might possible be dealt with by putting the following
> code into markup-init.ly:

I have uploaded a patch of that kind to Rietveld at
<URL:http://codereview.appspot.com/160048>.  Since our software versions
appear to be the same and I fail to reproduce the error messages you get
in spite of recompiling with ./configure --disable-optimising, it would
also be helpful if you gave me a recipe on just what I should call from
the command line in order to arrive at similar results.

For the record: I get pretty much the same run time and memory usage on
"make test" with none of my patch set applied, and with the latest
version.  The memory usage in either case grows larger than I think
appropriate (slow start, but goes up to 400MB at the end), so quite
apart from this particular patch set, I consider it likely that there is
some memory leak that keeps information across the various tests of
"make test".

Thanks

-- 
David Kastrup