lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Quit [now definitely O/T]


From: Chris Snyder
Subject: Re: Quit [now definitely O/T]
Date: Thu, 12 Nov 2009 17:32:26 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Hi Carl,

Thanks for the response. I had one of those "should I want to take that message back?" moments after sending my previous message - I regret the confrontational tone I took at times.

Carl Sorensen wrote:
Thanks for your contributions.  I'm sorry for whatever part I've played
in discouraging you.

Thanks. I've appreciated your patience the few times we've interacted, and I agree with Graham (at the risk of turning this into a "praise Carl" thread) that you do excellent work with shepherding new developers.

I assume you're talking about the issue 415 stuff,
...
So please, pick up your code again, and try to get the patch for 415 into
shape so that it can be applied.  Joe will help you, I'm sure.  And Han-Wen
isn't trying to keep you out; he's just trying to keep the code up to
standard.  We really do *like* patches, even if sometimes it doesn't seem
so.

Looking back at the thread, it does look to me now that I took Han-Wen's response too personally and I ended up tuning out a lot of the rest of the conversation. I revisited the branch I was working on, and - not surprisingly after eight months - it could not be cleanly rebased. I'll try to take a look at it, but it will take me a while to get back up to speed on it.

I think my experience does illustrate the care necessary in shepherding new developers. I think the LilyPond developer community would do well to treat newbies with kid gloves - contributing to a project for the first time can be intimidating. The Frogs program is a good step, but it's not very well publicized.

If we had a perfect code-formatting tool, we could just run the files
through the tool.  But we don't.

I vaguely remember some discussion on this at one point, but I can't find anything in the mailing list archives. I'd like to do some investigating as to what tools are available - it would save a lot of headache.

I realize that it seems like jumping through mindless and unnecessary hoops.
I've been there (had patches rejected because of bad indentation) and I
remember the pain it was to completely reindent the file (as part of that
process I learned to use the automatic indentation in vim).  But my code is
easier to read (which is *really* important for Scheme code IMO), so it's
worth the hassle.

I'm not going to argue against the benefits of readable code - I agree wholeheartedly (as my wife, who has done some first-draft engraving for me, can attest, I'm a stickler for formatting). It is difficult, however, to write code in a different style than the code right before and after the area I'm working on - especially since I was previously unfamiliar with the GNU style.

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)?

Perhaps this could be part of a developer tutorial that details creating a new engraver from scratch? I'm envisioning a LM-equivalent for the CG with the same relationship that the LM has to the NR (the full names of which must not be named).

"Thanks for your willingness to help. Unfortunately,
we don't have a lot of documentation for that right now. And I can't think
of a good discussion that took place on lilypond-devel, but you might find
something if you search the archives.  The recommended way to figure out how
LilyPond works is to read the source.  As you do, you may find some more
specific questions to ask. Please feel free to come back with any further
questions."

Unfortunately, this is often abbreviated as "Our entry point is in main() (lily/main.cc)..." - I'm thankful that verbiage has not been carried over to the new site.

I hope this hasn't come across as defensive.  I'm sincerely trying to help.

Thanks. I appreciate your willingness to put up with me.

-Chris




reply via email to

[Prev in Thread] Current Thread [Next in Thread]