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" <csny...@adoromusicpub.com> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
