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