On 26 sept. 2012, at 21:51, Han-Wen Nienhuys <hanw...@gmail.com> wrote:
> On Wed, Sep 26, 2012 at 9:17 PM, m...@mikesolomon.org > <m...@mikesolomon.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
