Re: Quit [now definitely O/T]

[Joe Neeman]

On Thu, 2009-11-12 at 14:28 -0700, Carl Sorensen wrote:
> Chris, 
> 
> Thanks for your contributions.  I'm sorry for whatever part I've played
> in discouraging you.
> 
> 
> On 11/12/09 11:04 AM, "Chris Snyder" <address@hidden> wrote:
> 
> > 
> > Over the past year, I've submitted patches on occasion for possible
> > inclusion in the trunk. On one occasion (accidentals in chords not
> > spaced properly), I spent quite a bit of time implementing a solution
> > proposed by one core developer, which took quite a bit of time
> > (including a steep learning curve, which I'll discuss below), only to
> > have another core developer reject it out of hand as being the wrong
> > approach. The rejection left a bad taste in my mouth - it was fairly
> > terse, and didn't acknowledge the wasted effort I had expended. Not
> > surprisingly, I haven't found the motivation to touch that code again.
> 
> I assume you're talking about the issue 415 stuff, found here:
> 
> <http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/14926/>
> 
> If so, I read it slightly different than you do.
> 
> I read it as Joe giving you some guidance, and Han-Wen saying that he didn't
> particularly like Joe's idea, but then Joe and Han-Wen went back and forth a
> few times, and the final message I heard from Han-Wen was "sounds good to
> me." (see the message at 29 Mar 17:17)  In other words, I think that a
> proposed solution that met Han-Wen's sensibilities had been arrived at.

It's been a while, but I think the conclusion was that my _second_
proposal for a solution was ok, but it would require Chris to throw away
all the work he had done on my _first_ proposal.

> > 
> > Over the past couple of days, I've been working on fixing a couple of
> > bugs that were caused by an earlier bug fix I submitted (that was
> > accepted). Joe Neeman has given me very constructive comments and asked
> > for reasonable improvements. At times, however, I've been struck by the
> > level of perfection required for patches such as mine, which seem to be
> > much higher than the current code. For instance, I was asked to correct
> > some indentation - never mind the fact that the code right around my
> > patch was indented incorrectly (I thought about fixing the whole file,
> > but didn't want to add noise to the patch set).
> 
> If we had a working code janitor who was fixing things up, we could just let
> spacing go.  But we don't.

I also think that we should hold documentation in new patches to a
higher standard than the current code, particularly when it comes to
corner cases (and there are a lot). There are a lot of dusty corners of
the code with complicated boolean expressions and it's sometimes hard to
tell what's going on. If we avoid creating _more_ of these situations
then it will help a lot later on. Hence my insistence on comments for
Chris' last patch.

> > As I mentioned above (and others have mentioned), the learning curve for
> > developing is quite steep. I applaud the effort by Graham et al to
> > improve the documentation, especially the Contributor's Guide, which has
> > been a big help even in its incomplete form. However, a lot of the code
> > is difficult to follow - when is stop_translation_timestep called in
> > engravers, for instance? It took me a while to understand that it will
> > be called even due to rhythms in other voices besides the one the
> > engraver is interested in.
> 
> I didn't even know that.  I hope we can get this documented.  Would you be
> willing to take a stab at how events are passed to engravers (or how various
> routines inside an engraver are called from outside the engraver)?

It would also be nice to have a summary of the order in which things
happen for engravers. For example, when are the announced grobs
processed and what happens if you create a grob after grobs have already
been announced? Currently, I only have a very vague picture of how the
whole engraving step works so you aren't alone in your confusion.

Cheers,
Joe