lilypond-devel
[Top][All Lists]
Advanced

[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: Tue, 24 Nov 2009 00:27:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Nicolas Sceaux <address@hidden> writes:

> Le 23 nov. 2009 à 19:03, David Kastrup a écrit :
>
>> Han-Wen Nienhuys <address@hidden> writes:
>> 
>>> On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup <address@hidden> wrote:
>>> 
>>>>>  lilypond a.ly b.ly
>>>>> 
>>>>> we want to reuse the built-in definitions, without changes effected
>>>>> in a.ly leaking into the processing of b.ly
>>>> 
>>>> Wouldn't just putting the built-in definition at public scope
>>>> accomplish that?
>>> 
>>> I don't know.  Why don't you try it, and send us a patch if it passes
>>> the regression tests?
>> 
>> That would not be my first thought when meddling with code I know
>> nothing about, and where I assume that somebody had created it because
>> of some inherent necessity.  And not every dead end needs to be entered
>> repeatedly.  It is a waste of time.
>
> A waste of time for you.

And everybody else trying to work with this code.

> I think it's a waste of time *for me* to explain you things when I
> read a subject line like "WTF with..." and no thank you in the end.

I think you are well aware that your personal dislike of me, which
certainly is quite justified, skews your perception and your
representation.  "What is the deal with" is an open question, certainly
not the same as "WTF with".  And this request which you complain about
here _did_ end with "Thanks," as I bothered to check right now.

There is really no need to invent or exaggerate things in order to
convince others of my obnoxiousness: I think it is apparent enough
without external help.

> The reason why I've used this define-public-toplevel macro has something
> to do with the modules being not the same when a .ly file is included into
> another.  So that hack was a way to define all markup commands in the same
> module.  I didn't find at that time an easier way to define a function in
> a given module (not the current one) than to define this macro.
>
> BTW, the guile module is not bypassed: module-define!, module-export!
> and module-ref are all guile module primitives.
>
> When you modify that code, try something like:
>
> file1.ly:
>   \include "file2.ly"
>   \markup \foo
>
> file2.ly:
>    #(define-markup-command (foo ...) ...)
>
> and compile file1.ly
>
> Also try to compile file3.ly:
>
> file3.ly:
>   myInclude =
>   #(define-music-function (parser location file) (string?)
>      #{ \include $file #}
>      (make-music 'void #t))
>
>   \myInclude "file2.ly"
>   \markup \foo
>
> Please send *complete* patches for review at retvield.

Thank you: this information about the intent and mechanism of this code
is certainly helpful.  I recommend that you place something like this
along with the code itself.

I don't see myself fighting Subversion and Rietveld myself in the near
future, but am confident that somebody with a better control of the
required tools will pick up patches posted here that are well enough
documented and of enough interest.

I certainly will try to see whether I can figure out a way to use the
module system in a manner requiring less code duplication and separate
defining commands.

Thanks for the test examples and the explanation.

-- 
David Kastrup





reply via email to

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