Mike Solomon <address@hidden> writes:
On Dec 11, 2013, at 11:36 AM, David Kastrup <address@hidden> 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.
The title for this is pretty terrible, I agree. It was in sketch phase a few months ago before I stopped working on it. 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.
In most of LilyPond, grob properties are calculated via callbacks, which themselves trigger the calculations of other properties they need a cascading sort of way. This means that we can swap out the default function Script.Y-offset with another callback or a number.
When translate_axis is used in the code, it means that while looking up a property of grob A, the offsets of B, C, and D will be set internally. This means that if a user sets the Y-offset of grob B to 2 and it is actually 4 because translate_axis has been called somewhere deep in the code, it is counterintuitive how this happened and how to change it. Furthermore, if the user overrides the callback that triggered translate axis, customary grob movements won’t happen anymore and the user won’t know why. In this way, translate_axis impedes modularity: it makes us less able to plug in different callback functions for different grobs and get expected results.
My goal is to put all offset calculations in the callback function so that if I set TextScript.Y-offset to #0.1, I am positive that its Y offset with respect to its parent will be #0.1. This is currently not the case.
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 a lot of work ahead of it, and if I get back to it, I’ll be splitting it up into smaller commits. There is also no explanation of the great plan behind this anywhere,
The great plan is: - Remove as many calls to translate_axis as possible.
- Create pure versions of the offset callbacks, which now calculate actual offsets without translate_axis tacked on.
- Now that these pure versions are used, pure estimates of staff height will be more accurate because they’ll finally take into consideration outside-staff grobs.
- That means that spacing stubs for cross staff grobs that need to user pure staff height calculations will be closer to the actual spacing.
- This means that scores with lots of cross-staff grobs will have better vertical spacing. Currently, vertical spacing of these scores is too airy because there is no good way to estimate outside-staff grobs, so LilyPond overestimates.
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.
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.
Argued, which is why I waited.
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.
The announcement came well after I had decreased work on LilyPond and after several attempts to get back in the game. This dates back at least a year and a half, at a time that other developers were leaving for similar reasons.
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.
Both of these things took up time, but they’re not the main reason. During this time, I increased my work on other projects where communication is graceful. And in some of these projects there are _major_ ideological differences between people, including me. But they are always handled cordially and gracefully, which makes it fun, which keeps me and others involved.
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.
I had signaled a while ago on the list the list (almost 10 months ago) that I wouldn’t push this work until 2.19 came out. What I paint for a loss for LilyPond is a decline in commit diversity over the past 3 years. Not the departure of any one individual, but rather a general trend that I do not see in other projects that have fluid, graceful communication between developers. 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.
I think what Trevor said is absolutely right - communication needs to be mutually respectful. There are several elements to respect, and one major one is listening to people. I’ve noticed that often times, flare ups with you and others revolve around a sentiment you have that you are not being listened to. I would certainly feel disrespected if I felt not listened to. Everyone, including me, listens to you and respects you a lot. You may not feel that way, but I’m positive it is true and I think _everyone_ on this list would say the same thing. There is no need to engage in acerbic communication out of a fear of not being listened to. For example, the long review you just sent out about my sketches for translate_axis is courteous, well written and very appreciated. I am looking forward to responding to it and working to make the patch better thanks to it.
Cheers, MS
|