Mike Solomon <m...@mikesolomon.org> writes: > On Dec 11, 2013, at 11:36 AM, David Kastrup <d...@gnu.org> wrote:
[...] > But that’s no good - we have to find a solution. Modularity, while > perhaps a good long term solution, is a long ways away. How are we > going to deal with this in 2014? By making headway and not be defeatist about it? "is a long ways away" is terribly close to "somebody else's problem" and "let's think about this the year after next year". >> And I see no-one in the current developer base who would work in that >> direction. > > One of my major projects - eliminating calls to translate_axis, was > moving exactly towards this (https://codereview.appspot.com/7185044/). It's called "Caches the interior skylines of vertical axis groups and systems." and there is no obvious reason why cached skylines would not be translatable. Of course, there is the non-obvious reason that a translation might lead to a violation of skyline invariants due to numerical effects, but that's nothing that can't be caught in-place. In other words: there are several different issues that are conflated here in a single patch. There is no inherent reason why not being able to use translate_axis will lead to more modular code. It seems actually more likely that having to track offsets separately is going to make stuff more complex. "More modular" does _not_ mean "eliminate functions doing a common task because of restructuring data in a manner incompatible with using a common function on it". Most graphic subsystems deal with this kind of thing by including a "current transform matrix" in their data sets so that transforms do not need to be performed until the final operation (actually, since PostScript also has the concept of a current transform, it's easy to pass this job to the backend). Of course, many skyline operators require a common coordinate system for the involved skylines, so there are points where one needs to normalize. > The less we’re calling translate_axis (the Defense Against the Dark > Arts function of LilyPond) in the backend, the more we can isolate > functionality to certain places and the less surprises there are. I don't see the connection. The net effect for the user, according to the Changes file, appears to be that outside-staff-priority stops working unless special callbacks or special commands (\tupletOutsideStaffPriority) are used, regardless of whether the grobs have the side-position-interface or not. As a result, it is not all that surprising that there were several grobs overlooked. Does this have anything to do with "caching the interior skylines of vertical axis groups and systems"? Not apparently. Does it have anything to do with "Removes the translate_axis call from axis-group-interface outside-staff positioning"? Not obviously. There is no explanation in the review or patches for that. I've taken a look at the current patch: <URL:https://codereview.appspot.com/7185044/#msg53> rather suggests that there is considerable work needed to get this into commit quality. There is also no explanation of the great plan behind this anywhere, and since this is a whole lot of stuff muddled in one review, it appears unlikely that the work will be split into a sequence of commits that give some overall direction (it would be quite untypical for you to split the material in a review, however involved, into separate commits). You say that there is plenty of followup work. > I’ve for the time being dropped it until we can work out these > community problems. The respective comments are in <URL:http://code.google.com/p/lilypond/issues/detail?id=3134#c64> and the following. They have nothing whatsoever to do with "community problems". What they _have_ to do with is release timing. Yes, the time frame I estimated for getting 2.18 was too optimistic. However, if this code would have been pushed at that stage and/or I would have been required to review it until it was of stable release quality, the time for getting every kink ironed out would have been much much larger. You stated that the bug fixes of previous patches were mostly done by Keith since you were removing yourself from development due to bad communication of mine. That does not really fit the time frames: your respective announcement came after most of the fixes. What figured in in your lack of time and/or concentration at that time, as it very well should, is you getting married, and working a whole lot with your ensemble to boot. The actually sad thing about the whole thing is that your withdrawal from active development (based on the feedback on a different issue) gave 2.18 and me as its warden the breathing room that was required for it to get into releasable state. So while you paint it as a loss for LilyPond, the _direct_ consequence of your withdrawal regarding those patches was a net win for getting the release done. The indirect consequences, namely you stopping also fixes necessary for getting to a release and, as you claim, others turning away from LilyPond, were obviously not positive. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel