[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: What's the deal with the module system?
Date: Wed, 25 Nov 2009 11:19:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Neil Puttock <address@hidden> writes:

> 2009/11/24 David Kastrup <address@hidden>:
>> After applying <URL:> 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 from around
its first check-in, then read the whole thread to its end which is
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:>.

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]