[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Markup module patch (Issue 2026)
From: |
Ian Hulin |
Subject: |
Re: Markup module patch (Issue 2026) |
Date: |
Fri, 16 Dec 2011 23:26:31 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 |
On 16/12/11 18:07, David Kastrup wrote:
> Ian Hulin <address@hidden> writes:
>
>> Because this means serious fiddling with the maoing markup code.
>> I really hope you didn't write it because I agree with David,
>> it's a fetid pile of Dingo's kidneys to maintain, and I fear
>> it'll take me a lo-o-o-ong time and much cursing and swearing to
>> change it.
>
> I actually extended it somewhat at one time. I have stated on this
> list that I hate working with C++ and am working hard to make it
> possible to avoid that. As a result, you'll see that the vast
> majority of my work is on the C++ code base. In a similar vein,
> you will find my handwriting in the markup code. But I did not
> start it.
>
No finger-pointing intended. I'm just frustrated that this rather
brittle subsystem is holding up progress on what I really want to work
on (i.e. fixing issue 2026 so I can crack on with completing 1686.
> If #{ \markup ... #} were evaluated at compile time, I would
> likely already have set out to obliterate the markup macro
> altogether and we would not be slashing with knives at each other
> for the sake of not needing to touch this code implementing its own
> language and system between LilyPond and Guile ever again.
>
Seconded, but knives? I do hope it hasn't got *that* unfriendly.
It's more like a game of "hot-potato voleyball". I'm trying to get
away with changing as little of the markup code internals as I can.
>> It'll mean trying to find a way of getting
>> compile-markup-expression to look in a list both in the current
>> module, and then falling back to the (lily) module (where all the
>> base code markup commands from define-markup-commands.scm will
>> be) before failing the validation.
>
> Can you explain what modules have to do with it? You make it sound
> as if every source file needed to end up in its own module except
> when taking special measures. That sounds quite inconvenient for
> working with projects distributed among multiple Lilypond files.
>
Lilypond scoping is implemented using the Guile module system. Each
new Lilypond scope is declared as an anonymous Guile module, and we
use special code provided by Guile V2 (module-export-all!) which we
emulate for Guile V1.8 by declaring it in lily.scm (the Guile team
actually supplied us with the code as we were doing it before in a
rather under-the-counter unsupported manner). This is done in code by
routine ly_make_module in ly-module.cc using a undocumented Guile
routine make-module.
- Re: Markup module patch (Issue 2026), (continued)
Re: Markup module patch (Issue 2026), David Kastrup, 2011/12/13
- Re: Markup module patch (Issue 2026), Ian Hulin, 2011/12/13
- Re: Markup module patch (Issue 2026), David Kastrup, 2011/12/14
- Re: Markup module patch (Issue 2026), Han-Wen Nienhuys, 2011/12/15
- Re: Markup module patch (Issue 2026), Ian Hulin, 2011/12/16
- Re: Markup module patch (Issue 2026), address@hidden, 2011/12/16
- Re: Markup module patch (Issue 2026), David Kastrup, 2011/12/16
- Re: Markup module patch (Issue 2026), David Kastrup, 2011/12/16
- Re: Markup module patch (Issue 2026),
Ian Hulin <=
Re: Markup module patch (Issue 2026), Han-Wen Nienhuys, 2011/12/18
Re: Markup module patch (Issue 2026), David Kastrup, 2011/12/19
Re: Markup module patch (Issue 2026), Han-Wen Nienhuys, 2011/12/14