"m...@mikesolomon.org" <m...@mikesolomon.org> writes: > On 26 sept. 2012, at 13:39, David Kastrup <d...@gnu.org> wrote: > >> It sounds to me like it would make more sense that we improve our >> cache invalidation strategy where it goes wrong > > There is currently no cache invalidation strategy.
Sounds like we found the place where it goes wrong. >> rather than shifting the >> problem around in increasingly complex manners. > > There is currently no way in LilyPond to trace what properties depend > on what properties. So if we want to invalidate the cache of property > X, it is very difficult to invalidate the caches of properties that > depend on it. This is made considerably easier if side-positioning is > streamlined. When a grob X's side position changes for a given axis, > iterate over its side-position elements and recalculate their offsets. > That's one of the main reasons I want to make this change. What we need to arrive at is a situation where somebody without a clue starting to write stuff will more likely than not get a whole lot of things working right without realizing it, rather than getting a whole lot of things working wrong without realizing it. Which apparently is what is happening to Marc right now. He is working on a simple problem, and it fails for complex reasons. And that means the current design of our backend is bad. Conceptually simple problems need to map to conceptually simple solutions. If they don't, our APIs suck. > I think the change decreases complexity as it makes LilyPond more > predictable and boring - objects side position based off of other > objects and that's it. No need for side-position, parents and > outside-staff-priority. parents are used for a _lot_ of positioning, and for example the determination of a common grob parent is an _efficient_ operation. So it might make sense to solve the problem you are thinking of via artificial/grouping parents. I can't vouch for it, obviously, as the backend is mostly opaque to me right now. But it is a possibility. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel