[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Project - Eliminating grob parents and outside-staff-priority
From: |
address@hidden |
Subject: |
Re: Project - Eliminating grob parents and outside-staff-priority |
Date: |
Wed, 26 Sep 2012 22:42:29 +0200 |
On 26 sept. 2012, at 21:51, Han-Wen Nienhuys <address@hidden> wrote:
> On Wed, Sep 26, 2012 at 9:17 PM, address@hidden
> <address@hidden> wrote:
>
>> Another way to think of this is that, in general, we'd try to eliminate
>> grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do
>> traffic-coppery. Or, inversely, we'd say that positioning only happens via
>> traffic-cop grobs and no grob has the right to position itself. But it
>> seems like we need to pick one.
>
> The reason for trafic-coppery is that for many positioning schemes,
> there is no inherent order that can determine how two objects of the
> same type (and hence, with the same set of callbacks) should be
> typeset.
>
> A typical example of this is NoteCollision of N NoteColumns. The
> NoteColumns have to all move in a coordinated way, and the easiest way
> is to have a function (with local variables) that determines what has
> to happen. You might get around it, by having a bunch of properties
> instead, but you'd still have to store those somewhere, ie in the
> NoteCollision grob.
Not necessarily, it'd just make computation time longer. If each note column
had other concurrent note columns in its side-position-elements grob-array and
we kept the same function from note-column.cc but rewrote it such that instead
of translating axes by values it returned the offset value for a given note
column, the function would be called N times for N note columns. It's a
tradeoff between efficiency and consistency - I'm not sure which one is better,
but I'm sure it's possible to eliminate the NoteCollision grob at the cost of
redundancy.
>
>> Agreed, but this is just one instance of translate_axis, which is just one
>> example of a side-effect in lilypond. Is your eventual goal to remove them
>> all?
>>
>>
>> Yes - that'd be great. That'll make explicit dependencies a lot easier to
>> handle - everything can be calculated in terms of callbacks.
>
> I'm all for removing side effects, but you can pursue that separately
> without trying to rewrite the backend.
My goal is not to rewrite the backend. My goal is to come up with a
generalized way to do multiple passes at many places in the compilation
process, and the best way seems to be deleting certain cached properties. I'm
all for other ideas, though.
>
>
>> To keep the main thing the main thing, the goal is to be able to wipe
>> certain caches, restore the original callbacks, and know that all grobs
>> properties that depended on the restored property will also be recalculated.
>> My idea is an idea for simplifying LilyPond so that this work is easier, but
>> there is no point in doing that if it won't help reach that goal. I'm open
>> to any and all suggestions.
>
> Have you thought this through?
>
> In order to do cache invalidation, you will have to construct the
> reverse graph. If A.x depends on B.y, now A points to B. For proper
> cache invalidation, if B.y changes, then A.x becomes invalid. This
> means that A has to store a back-reference to B. Hence all pointers
> have to be stored both ways (including inverting 1-N relations into
> N-1 relations), and the both-way links have to be rewritten correctly
> during line breaking.
I'm sure this is doable - it'd just be a royal pain. It'd meant that
get_property would have to take the "me" grob as an argument and somehow make
the grobs aware of each other.
Cheers,
MS
- Re: Project - Eliminating grob parents and outside-staff-priority, (continued)
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/29
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, Janek WarchoĊ, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority,
address@hidden <=
- Re: Project - Eliminating grob parents and outside-staff-priority, Joe Neeman, 2012/09/26