CG: incomplete docs for procedure for issue resolution after pushing to staging
Whilst the procedure of marking an issue as fixed, with an additional Fixed_mm_MM_ss label, is briefly mentioned at the end of the "Issue classification section" in the Contributor's Guide: http://lilypond.org/doc/v2.17/Documentation/contributor/issue-classification it is slightly misleading, and also omits important details: - Fixed_mm_MM_ss suggests fixed width, e.g. Fixed_02_17_01, but this is not the case. It would be better to call it Fixed_X_Y_Z. - What's the correct value of X, Y, and Z? (Answer is presumably that they come from MAJOR_VERSION, MINOR_VERSION, and PATCH_LEVEL in $LILYPOND_GIT/VERSION) - Are developers supposed to mark the issue as fixed immediately after pushing the corresponding patch series to staging, or should they first wait for the tests to automatically advance master? Additionally, the above information still needs to be explicitly referenced from the two[1] places where pushing to staging is documented: http://lilypond.org/doc/v2.17/Documentation/contributor/git-for-the-impatient http://lilypond.org/doc/v2.17/Documentation/contributor/pushing-to-staging I think it would be better to reference via links back to the 'Issue classification' section, rather than have the same information duplicated three times. Thanks, Adam [1] Speaking of duplication, why do we document the procedure for pushing to staging twice? The version in 'Git for the impatient' is hardly any shorter than the full version in 'Pushing to staging', and violating the DRY rule increases the maintenance burden and also risks information becoming out of date in one of the two places. Should impatient git users even be allowed to push to staging? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
online copy of contributor's guide out of date or broken?
http://lilypond.org/doc/v2.17/Documentation/contributor/patch-handling does not match with the CG source: http://git.savannah.gnu.org/cgit/lilypond.git/tree/Documentation/contributor/issues.itexi#n824 The source code has four @subheadings, but none of them are visible online. Additionally the "For people doing maintenance tasks" paragraph is @ignored in the source, but appears online. What's going on here? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Wanting to be involved in lilypond project
On Thu, Jan 17, 2013 at 7:04 AM, Fan Ziye wrote: > Dear Mike, > > Thank you for your rapid reply! It’s very useful for me. I will continue > reading the CG and then go to the issue list. http://lilypond.org/help-us.html is also worth reading for starting points. Thanks very much for the offer of help! Adam ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
confessional (was Re: Configuring git-cl)
On Sun, Jan 13, 2013 at 11:57 PM, Adam Spiers wrote: > On Sun, Jan 13, 2013 at 11:09 PM, Adam Spiers > wrote: >> On Sun, Jan 13, 2013 at 10:55 PM, Adam Spiers >> wrote: >>> Resurrecting an old thread, because I had the same questions due to >>> the gaps in the contributor's guide ... >> >> *sigh* >> >> Just discovered that I already asked this about 13 months ago: >> >> http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/41877/focus=41878 >> >> Apparently gmane's memory is *way* better than mine. >> >>> I'll see if I can make a patch to the CG based on these findings. Does >>> anyone else have any further light to shed? >> >> This time around, I missed this sentence: >> >> If you do not understand any question, just answer with a newline (CR). >> >> So I think it would be better to make this more explicit. > > I have created a patch, issue and Rietveld review for this: > > https://code.google.com/p/lilypond/issues/detail?id=3111 On David's request, I pushed this; unfortunately I accidentally pushed to master rather than staging. I immediately followed it by a push to staging, so at least the two are in sync, but I fear this *may* confuse any automated test infrastructure which is normally responsible for advancing master (I don't know how it's implemented so can't be sure). Many apologies for any inconvenience caused, and please let me know if there is anything I should do to rectify the situation. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grace notes break preceding ties in MIDI
On Sun, Jan 13, 2013 at 05:37:17PM +, Adam Spiers wrote: > On Sun, Jan 13, 2013 at 5:35 PM, James wrote: > > On 13 January 2013 17:27, Adam Spiers wrote: > >> On Sun, Jan 13, 2013 at 4:40 PM, Adam Spiers > >> wrote: > >> > On Sat, Jan 12, 2013 at 12:52 PM, Adam Spiers > >> > wrote: > >> >> On Tue, Jan 8, 2013 at 5:59 PM, Adam Spiers > >> >> wrote: > >> >>> On Tue, Jan 8, 2013 at 5:41 PM, Eluze wrote: > >> >>>> I've added an issue to the tracker: > >> >>>> > >> >>>> https://code.google.com/p/lilypond/issues/detail?id=3091&thanks=3091&ts=1357666391 > > [snipped] > > >> I have published my fix here and will submit to Rietveld soon: > >> > >> https://github.com/aspiers/lilypond/commits/tie-grace-fix > > > > Don't forget to open a tracker issue (use git-cl - which will open a tracker > > and Rietveld at the same time) as this is what is used for automated Patch > > testing. > > Already done by Eluze - see above. OK, this fix is now in Rietveld: https://codereview.appspot.com/7108043/ As you can see, I added a regression test-case, but I couldn't figure out how to prove via "make check" etc. that the code actually altered the MIDI output (even though manual testing shows that it clearly does). I followed the CG steps involving "make test-baseline", "make check" etc. but these two files ended up having identical content: ./build/input/regression/out-test-baseline/midi-grace-after-tie.log ./build/input/regression/out-test/midi-grace-after-tie.log i.e. they both wrote to ./build/out/lybook-testdb/83/lily-b715ac6a.midi so a comparison of the new .midi file with a baseline version seems impossible. Am I missing something, or are .midi regressions not implemented? Thanks, Adam ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Configuring git-cl
On Sun, Jan 13, 2013 at 11:09 PM, Adam Spiers wrote: > On Sun, Jan 13, 2013 at 10:55 PM, Adam Spiers > wrote: >> Resurrecting an old thread, because I had the same questions due to >> the gaps in the contributor's guide ... > > *sigh* > > Just discovered that I already asked this about 13 months ago: > > http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/41877/focus=41878 > > Apparently gmane's memory is *way* better than mine. > >> I'll see if I can make a patch to the CG based on these findings. Does >> anyone else have any further light to shed? > > This time around, I missed this sentence: > > If you do not understand any question, just answer with a newline (CR). > > So I think it would be better to make this more explicit. I have created a patch, issue and Rietveld review for this: https://code.google.com/p/lilypond/issues/detail?id=3111 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Configuring git-cl
On Sun, Jan 13, 2013 at 10:55 PM, Adam Spiers wrote: > Resurrecting an old thread, because I had the same questions due to > the gaps in the contributor's guide ... *sigh* Just discovered that I already asked this about 13 months ago: http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/41877/focus=41878 Apparently gmane's memory is *way* better than mine. > I'll see if I can make a patch to the CG based on these findings. Does > anyone else have any further light to shed? This time around, I missed this sentence: If you do not understand any question, just answer with a newline (CR). So I think it would be better to make this more explicit. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Configuring git-cl
Resurrecting an old thread, because I had the same questions due to
the gaps in the contributor's guide ...
On Tue, May 15, 2012 at 3:51 PM, Łukasz Czerwiński wrote:
> On 15 May 2012 16:35, Graham Percival wrote:
> > On Tue, May 15, 2012 at 02:19:34PM +0200, Joseph Rushton Wakeling wrote:
> > > * Tree Status URL (I put the URL of the LP git repo);
> >
> > IIRC the git-cl on my github account adds a URL which allows us to
> > search for lilypond patches (which would further reduce the chance
> > of lost patches). IIRC this happened a few months ago, but I
> > can't remember how to do the actual searching, nor whether this is
> > included by default or not.
>
> As far as I understand, you mean this:
>
> http://codereview-hr.appspot.com/repos - find "Lilypond" and click the link
> "search". That's what Janek has changed some time ago with my little help.
That page shows:
*trunk* Trunk
http://git.savannah.gnu.org/gitweb/?p=lilypond.git/trunk/ (search)
and the "search" link goes to:
https://codereview-hr.appspot.com/search?base=http://git.savannah.gnu.org/gitweb/?p=lilypond.git/trunk/
Both links are broken. Presumably they worked at some point, and then
something changed. Maybe Janek or Graham can shed light on this?
Anyhow, the first is trivially fixable by removing the trailing
"trunk/", but I have no idea what the value of the "base" parameter is
supposed to be in the second one. Removing it altogether gives a
search form:
https://codereview-hr.appspot.com/search
but I can't figure out how to persuade it to list all lilypond-related
reviews. In any case, the URL given during interactive configuration
of git-cl to the "Tree Status URL" question gets used by the following
code in git-cl:
def GetTreeStatus():
"""Fetches the tree status and returns either 'open', 'closed',
'unknown' or 'unset'."""
url = settings.GetTreeStatusUrl(error_ok=True)
if url:
status = urllib2.urlopen(url).read().lower()
if status.find('closed') != -1 or status == '0':
return 'closed'
elif status.find('open') != -1 or status == '1':
return 'open'
return 'unknown'
return 'unset'
So I get the impression that it has nothing to do with that search
form. It is required to make the "git cl tree" sub-command work:
$ git cl tree
You must configure your tree status URL by running "git cl config".
Since the URL is not parametrised in any way, whatever the tree status
indicates must apply to the whole tree. I'm guessing that Rietveld
has some mechanism for globally flagging a source tree as "closed"
e.g. for occasions where you want to freeze normal development and
focus on something else (I'm not sure what though ...) I tried all
kinds of googling to figure out what this mechanism might be and where
to find it, but had no luck :-/
> > > * ViewVC URL (I hit newline; I've no idea what this is).
This one is used exclusively by "git cl dcommit":
if cl.has_RietveldIssue and output.find("Committed r") != -1:
print "Closing issue (you may be prompted for your codereview password)..."
viewvc_url = settings.GetViewVCUrl()
if viewvc_url:
revision = re.compile(".*?\nCommitted r(\d+)",
re.DOTALL).match(output).group(1)
cl.description = (cl.description +
"\n\nCommitted: " + viewvc_url + revision)
cl.CloseRietveldIssue()
cl.SetRietveldIssue(0)
Given that we don't use svn or git-svn, I think it's irrelevant, and
the CG should instruct developers to leave it blank.
I'll see if I can make a patch to the CG based on these findings. Does
anyone else have any further light to shed?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grace notes break preceding ties in MIDI
On Sun, Jan 13, 2013 at 5:35 PM, James wrote: > On 13 January 2013 17:27, Adam Spiers wrote: >> On Sun, Jan 13, 2013 at 4:40 PM, Adam Spiers >> wrote: >> > On Sat, Jan 12, 2013 at 12:52 PM, Adam Spiers >> > wrote: >> >> On Tue, Jan 8, 2013 at 5:59 PM, Adam Spiers >> >> wrote: >> >>> On Tue, Jan 8, 2013 at 5:41 PM, Eluze wrote: >> >>>> I've added an issue to the tracker: >> >>>> >> >>>> https://code.google.com/p/lilypond/issues/detail?id=3091&thanks=3091&ts=1357666391 [snipped] >> I have published my fix here and will submit to Rietveld soon: >> >> https://github.com/aspiers/lilypond/commits/tie-grace-fix > > Don't forget to open a tracker issue (use git-cl - which will open a tracker > and Rietveld at the same time) as this is what is used for automated Patch > testing. Already done by Eluze - see above. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grace notes break preceding ties in MIDI
On Sun, Jan 13, 2013 at 4:40 PM, Adam Spiers wrote: > On Sat, Jan 12, 2013 at 12:52 PM, Adam Spiers > wrote: >> On Tue, Jan 8, 2013 at 5:59 PM, Adam Spiers >> wrote: >>> On Tue, Jan 8, 2013 at 5:41 PM, Eluze wrote: >>>> I've added an issue to the tracker: >>>> https://code.google.com/p/lilypond/issues/detail?id=3091&thanks=3091&ts=1357666391 [snipped] > I have finally pinned this down! And I'm close to a fix. The culprit > is in Midi_walker::process(): > > if (note->audio_->length_mom_.to_bool ()) > do_start_note (note); > > This to_bool () check is too simplistic. Here is the explanation ... [snipped] > I believe a reasonable approach would be to use a different check: > > if (note->audio_->length_mom_.main_part_ || > note->audio_->length_mom_.grace_part_.sign () == 1) > do_start_note (note); > > It may even warrant a new Audio_note::is_positive_duration() method > which could be used here. > > Thoughts? > > However, this suggested workaround is not sufficient by itself - there > is a related issue with the ordering of NoteOff events which I'm > working on now. Addressing the related issue led me to a better, single fix for both. The real problem is that \grace causes the immediately preceding Audio_note (or Audio_notes if the \grace follows a chord) to be shortened, but it fails to check whether the Audio_note is part of a tie. I have published my fix here and will submit to Rietveld soon: https://github.com/aspiers/lilypond/commits/tie-grace-fix ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grace notes break preceding ties in MIDI
On Sat, Jan 12, 2013 at 12:52 PM, Adam Spiers
wrote:
> [thread moved from lilypond-user]
>
> On Tue, Jan 8, 2013 at 5:59 PM, Adam Spiers
> wrote:
>> On Tue, Jan 8, 2013 at 5:41 PM, Eluze wrote:
>>> I've added an issue to the tracker:
>>> https://code.google.com/p/lilypond/issues/detail?id=3091&thanks=3091&ts=1357666391
>>
>> Thanks!
>>
>>> I'm not aware of a workaround - I could imagine using 2 voices, one without
>>> the grace the other with just the grace and a muted note - but this seems
>>> pretty awkward!
>>
>> Is it perhaps the fault of the
>>
>> if (now_mom ().grace_part_)
>>
>> section in Note_performer::process_music() in lily/note-performer.cc?
>> Does it somehow reintroduce the previous note when shortening it to
>> make room for the grace note, even though the previous note was tied
>> to the one before?
>
> Is there a performer tutorial similar to the engraver tutorial?
>
> http://lilypond.org/doc/v2.16/Documentation/contributor/engraver-tutorial
>
> I've started trying to fix the above bug, but my knowledge of
> LilyPond's C++ performer code (let alone any other code) is poor, and
> getting to grips with the various data structures is slow work. I'm
> running it through gdb which helps, but any other pointers would be
> really useful. Thanks!
I have finally pinned this down! And I'm close to a fix. The culprit
is in Midi_walker::process():
if (note->audio_->length_mom_.to_bool ())
do_start_note (note);
This to_bool () check is too simplistic. Here is the explanation ...
If you have a tie followed by a grace:
a1~a4 \grace b8
then Tie_performer::acknowledge_audio_element() will invoke
Audio_note::tie_to() which will lengthen the duration of the
Audio_note corresponding to the a1 by 1/4, and then set the length of
the Audio_note corresponding corresponding to the a4 to zero.
Later, when Note_performer::process_music() encounters the b8 grace
note, it will shorten the grace_part_ of the now-zero-length
Audio_note for a4 by 1/8, reducing it to -1/8. If you were to invoke
to_string() on the Audio_note at this point, you'd get "0G-1/8".
Now we see why the to_bool() check above is too simplistic. It's
implemented as:
bool
Moment::to_bool () const
{
return main_part_ || grace_part_;
}
but because the grace_part_ is no longer zero, do_start_note will be
invoked for the tied note!
I believe a reasonable approach would be to use a different check:
if (note->audio_->length_mom_.main_part_ ||
note->audio_->length_mom_.grace_part_.sign () == 1)
do_start_note (note);
It may even warrant a new Audio_note::is_positive_duration() method
which could be used here.
Thoughts?
However, this suggested workaround is not sufficient by itself - there
is a related issue with the ordering of NoteOff events which I'm
working on now.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grace notes break preceding ties in MIDI
[thread moved from lilypond-user] On Tue, Jan 8, 2013 at 5:59 PM, Adam Spiers wrote: > On Tue, Jan 8, 2013 at 5:41 PM, Eluze wrote: >> I've added an issue to the tracker: >> https://code.google.com/p/lilypond/issues/detail?id=3091&thanks=3091&ts=1357666391 > > Thanks! > >> I'm not aware of a workaround - I could imagine using 2 voices, one without >> the grace the other with just the grace and a muted note - but this seems >> pretty awkward! > > Is it perhaps the fault of the > > if (now_mom ().grace_part_) > > section in Note_performer::process_music() in lily/note-performer.cc? > Does it somehow reintroduce the previous note when shortening it to > make room for the grace note, even though the previous note was tied > to the one before? Is there a performer tutorial similar to the engraver tutorial? http://lilypond.org/doc/v2.16/Documentation/contributor/engraver-tutorial I've started trying to fix the above bug, but my knowledge of LilyPond's C++ performer code (let alone any other code) is poor, and getting to grips with the various data structures is slow work. I'm running it through gdb which helps, but any other pointers would be really useful. Thanks! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
On Thu, Apr 19, 2012 at 12:30 PM, Graham Percival wrote: > Trying to anticipate future problems, I recalled guile > indentation: > http://codereview.appspot.com/4896043/ > My impression is that it would only take an hour or two to fix > this, and then we could standardize all the scheme indentation. > This isn't a theoretical concern; Adam Spiers' first patch > required hours of extra work because of misunderstandings about > our desired indentation. This strikes me as a fairly juicy piece > of low-hanging fruit. I would be happy to tackle this and *hope* to have a spare few hours at some point in the next month, although it all depends on how things pan out when I get back from California on Wednesday - if someone beats me to it then that's fine. Just to clarify, the remaining work is to follow Neil's suggestions, merge the patch set, close the review, and then run the tool on all .scm files and submit as a separate review? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
potential soak-test / showcase
This would be fun to code ;-) http://lostinthecloudblog.com/2010/03/13/john-stump-composer-of-faeries-aire-and-death-waltz/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rebasing inside staging
On Wed, Nov 30, 2011 at 7:28 AM, Keith OHara wrote:
> Adam Spiers adamspiers.org> writes:
>> Fixed patch series is now in staging.
>
> I am now seeing trouble with 'chord-name-exceptions.ly' and similar.
> The slash missing in the markup for the \chordmode { c:7sus4 }.
That's one of the intended changes in behaviour.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rebasing inside staging
On Tue, Nov 29, 2011 at 11:10 AM, Adam Spiers wrote: > I'm building a fixed version > of the patch series as I type this, and will push as soon as I'm > convinced it's good, in order to minimise the risk of someone else > accidentally pushing the old series back in. Fixed patch series is now in staging. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rebasing inside staging
ARGH. My bad :-( Really sorry guys. It's very simple what happened, and in fact you already know most of it: - There was a long period of time in between the completion of the review and pushing to staging, due to my misunderstanding of the development process (which I will partially blame on the CG being incomplete ;-) - When I finally came to rebase my patches onto staging in order to be able to push them, there was a one-line merge conflict due David's patch providing the new $() syntax. - I read up on the change, and decided that I could resolve the conflict simply by taking his version and changing \super to \normal-size-super. As I was already way over time budget on this whole series and the push was already late, I made a judgement call that this was all simple enough that I could get away without waiting another hour or two for a full build and run of the regression tests. However while using kdiff3 to resolve the conflict, somehow (I'm guessing too many late night hacking sessions) I managed to totally screw it up. I could have sworn I eyeballed the rebased patch after and thought it looked fine, but obviously it wasn't. - A few hours later I saw a mail from James saying that staging was not compiling, and I wondered if it might have been my fault, so I launched a build and saw the failure: /home/adam/.GIT/3rd-party/lilypond/build/out/share/lilypond/current/scm/lily.scm:847:21: Unbound variable: x00f8 but I never touched lily.scm and this didn't look like it could be related to my changes, so I assumed someone else had broken it. I definitely agree with Graham that there's no reason to panic about this, since it arose due to a combination of unusual circumstances, and if any single one of those was different, it would not have happened. There's certainly no reason to increase the red tape - in fact one could argue that it was red tape which caused the latency between review and push to staging in the first place. I suggest the following morals to the story: - I underestimate my own capacity for making mistakes. - Untested work will empirically demonstrate Murphy's Law. - A slow build/test cycle encourages developers (or me, at least) to be sloppy. I'm not sure I have a good solution for that though, other than perhaps substantially simplifying and optimizing the build system. - Cumbersome project tools encourage developers (or me, at least) to be sloppy. If I hadn't gone so far over time budget due to the inadequacies of Rietveld and its lack of integration with the Google Code issue tracker, I most likely would not have been tempted to cut corners in testing. - It's really important that critical sections of the CG are complete and up to date. - The build error could have been better at pointing out the real culprit file (GOP 5?) On Tue, Nov 29, 2011 at 3:09 AM, David Kastrup wrote: > I backed out all of the jazz chord changes. Since they were last in > staging, this did not actually require a rebase. This should likely be > pretty painless. It does have the disadvantage that anybody who already > fetched them can accidentally push them back in without the git server > complaining about this not being a fast forward. Yup - I agree this is the best approach. I'm building a fixed version of the patch series as I type this, and will push as soon as I'm convinced it's good, in order to minimise the risk of someone else accidentally pushing the old series back in. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Usability improvements to {doc,cg}-section.sh and corresponding section of CG. (issue 5342043)
Reviewers: carl.d.sorensen_gmail.com,
Message:
Pushed to staging as f955789f
Description:
Usability improvements to {doc,cg}-section.sh and corresponding section
of CG.
- Now honor LILYPOND_GIT, LILYPOND_BUILD_DIR, and LILYPOND_TEMPDOCS
environment variables (all optional).
- Provide usage help text if '-h' or '--help' or incorrect arguments
are passed.
- Output more helpful messages upon completion.
Please review this at http://codereview.appspot.com/5342043/
Affected files:
M Documentation/contributor/doc-work.itexi
M scripts/auxiliar/cg-section.sh
M scripts/auxiliar/doc-section.sh
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' (issue 5361042)
Pushed to staging as 46081ce4 http://codereview.appspot.com/5361042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve HTML output of regression tests (issue 5342042)
Pushed to staging as 1294535b http://codereview.appspot.com/5342042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
Pushed to staging as f955789f..0fa48c98 http://codereview.appspot.com/5343050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
On Sun, Nov 27, 2011 at 1:21 AM, wrote: > As far as I can see, this patch is approved for pushing, but hasn't been > pushed yet. > > Are you going to push it, Adam, or should I push the one that I have? I will do it now. I guess I have to rebase each branch off staging and then push, right? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
stupid question about patching push / countdowns
Hi all, Sorry - it only recently dawned on me that I'm probably responsible for pushing my patches which I think have now already been reviewed and approved. I've read the CG and tried to understand the exact process, but as previously noted on this list, the CG is not entirely complete and up-to-date so I thought I should check here first. Am I right in guessing that the Patch-push label indicates that the review process is complete and that the patch should be pushed by the developer / patch helper / frog-meister as appropriate? In which case I should push to the dev/staging branch myself? I'm also a bit unclear on how the countdown process works and what it achieves. I see that issues sometimes have the "Patch-countdown" label replaced with the "Patch-push" label - what does that signify? The following sections need to be updated: http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches http://lilypond.org/doc/v2.15/Documentation/contributor/issue-classification http://lilypond.org/doc/v2.15/Documentation/contributor/patch-handling I could perhaps find time for this if I knew answers to the above. Thanks! Adam ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Tue, Nov 8, 2011 at 1:10 AM, Colin Campbell wrote: > On 11-11-07 12:08 PM, adam.spi...@gmail.com wrote: >> >> Please close this issue as it's now superceded by >> http://codereview.appspot.com/5343050/ - thanks! >> >> http://codereview.appspot.com/5320074/ > > Adam, you are the creator of the Rietveld issue, so you need to log on and > edit the issue. You should see a "closed" button and be sure to update the > issue. I share your frustration with the pair of band-aids we are using, Nope, Carl created 5320074. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
On Mon, Nov 7, 2011 at 10:11 PM, David Kastrup wrote: > In this case, the damage is already done, so there seems little point in > investing the effort for trying to get back again. Especially considering my first patch submission did *not* have gratuitous whitespace changes, and I only put them in after I was asked to during a review. It's probably cost me more time than it has anyone else. Let's not waste any more time on the matter now. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
On Mon, Nov 7, 2011 at 9:13 PM, Graham Percival wrote: > On Mon, Nov 07, 2011 at 08:13:46PM +, carl.d.soren...@gmail.com wrote: >> I am not in favor of the tab-to-space change in >> scm/chord-ignatzek-names.scm, since we don't yet have agreement on >> removing tabs from .scm files, AFAICS. > > True, but I assume that other parts of the patch set depend on > this, and high-quality work, so I vote for turning a blind eye to > this change and accepting the patch set. Thanks - I tried removing it and rebasing, but it was more work than I have time for. I'm already about 1000% over budget on all this. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
On Mon, Nov 7, 2011 at 7:34 PM, Neil Puttock wrote: > On 7 November 2011 19:32, Graham Percival wrote: > >> Failing either of these, I guess we're into git bisect time, which >> of course sucks for doc-building if you're not Phil or James. I >> know that Phil can build the docs, but hopefully James' computer >> will fail in this same way? > > I've just finished building the docs without incident. I ran it again without -j2 and it completed fine. *shrug* ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve HTML output of regression tests (issue 5342042)
New patch set uploaded. http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py File scripts/build/output-distance.py (right): http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode8 scripts/build/output-distance.py:8: from cgi import escape On 2011/11/07 15:53:49, Julien Rioux wrote: Since the style within lilypond's python sources is to import the module into the namespace, it would be nice to keep to that style, e.g. "import cgi" here, and then... Done. http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode462 scripts/build/output-distance.py:462: str = '%s' % escape(str) On 2011/11/07 15:53:49, Julien Rioux wrote: ...use "cgi.escape (str)" here. The space before the parenthesis is also to keep the consistent style. Done. http://codereview.appspot.com/5342042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' (issue 5361042)
New version attached. http://codereview.appspot.com/5361042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
Please close this issue as it's now superceded by http://codereview.appspot.com/5343050/ - thanks! http://codereview.appspot.com/5320074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
make doc failure on fresh build tree
The below error was caused by 'make -j2 doc' on a fresh build tree - any ideas? /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation -o /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps out-www/extending.texi The style file: /home/adam/music/software/lilypond.git/Documentation/lily-bib.bst Database file #1: /home/adam/music/software/lilypond.git/Documentation/essay/engravingbib.bib /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation -o /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps out-www/snippets.texi extract_texi_filenames.py: Processing out-www/extending.texi extract_texi_filenames.py: Processing out-www/snippets.texi Traceback (most recent call last): File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 304, in Traceback (most recent call last): File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 304, in (lang_suffix, sections) = extract_sections (filename) File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 142, in extract_sections f = open (filename, 'r') IOError: [Errno 2] No such file or directory: 'out-www/extending.texi' (lang_suffix, sections) = extract_sections (filename) File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 142, in extract_sections f = open (filename, 'r') IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi' make[2]: *** [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/extending.xref-map] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/snippets.xref-map] Error 1 make[2]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build' make: *** [doc-stage-1] Error 2 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 7, 2011 at 2:13 PM, Graham Percival wrote: > On Mon, Nov 07, 2011 at 12:44:42PM +, Carl Sorensen wrote: >> I'll get the update posted today. For this patch, I'm serving as >> adam's frog meister since last Thursday. > > Adam is a very experienced developer, and he already knows how to > use git-cl. He's even patched it! He's not a frog, so he doesn't > need a frog meister. > > Waiting for you to upload stuff adds a completely unnecessary > delay and annoyance to the process. With anybody else, your > assistance would be extremely valuable and appreciated, but in > this case I don't see it adding any value. Yeah, thanks a lot Carl for your help so far but it probably is simpler at this stage if I just do a git cl upload into a fresh ticket. Hopefully this time everyone will have run out of ideas for how to improve the patch series and it can be pushed to staging soon :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 7, 2011 at 2:11 PM, Graham Percival wrote: > On Mon, Nov 07, 2011 at 12:34:15PM +0000, Adam Spiers wrote: >> On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival >> wrote: >> > I doubt it. Just upload a new issue. >> >> So then we would have *three* Rietveld issues tracking the >> same thing. > > The google code issue is our pointer. Rietveld is our memory. We > have one object in memory (the rietveld issue you're going to > upload), and two objects which have been de-referenced (Janek's > and Carl's uploads). > Our machine has infinite memory (because it's run on google > servers, and they have more bandwidth than god, and also more > processing power than the NSA [1]). Garbage collection happens > whenever Carl and Janek get around to it. > > Stop wasting time -- both mine and yours -- trying to handle the > memory manually. Unless you're writing kernel or DSP code, > programmers outgrew that in the 90s. Sure, but it's the de-referencing which worries me for two reasons: 1. These older review issues contain potentially useful history about the review process, so allowing them to be garbage collected doesn't sound safe to me. 2. It's not always clear that they have been de-referenced, which can easily cause confusion. Case in point - I accidentally updated an old issue within the last 24 hours because I forgot a new one had superceded it. And I was directly involved with the creation of both! This could have been avoided by closing the old issue except for Rietveld's inflexible ACL model. I suppose a workaround could be to put a comment at the bottom "THIS ISSUE IS NOW RETIRED, SEE ISSUE 12345". I'll do that from now on. > We're not going to lose the de-referenced pointers, so it's not a > memory leak. Your analogy was working quite nicely until this point, but I don't know what you mean by "de-referenced pointers". I'm guessing you meant "de-referenced objects", but then what would the garbage collection you refer to actually do? > capiche? Almost. It's still an over-complex system though. Ultimately I think it boils down to (a) Rietveld having a lowest common denominator approach to revision control systems rather than properly supporting git/mercurial, and (b) having two sub-par systems (Rietveld and Google Code) when one comprehensive integrated system would be much better (not sure that such a beast exists yet, but github looks pretty damn good these days, maybe also Gerrit). > [1] this is almost certainly false, but it's such a nice pithy > quote that I couldn't resist inventing it. :-) Actually I suspect it's true. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival wrote: > On Mon, Nov 07, 2011 at 11:56:42AM +, adam.spi...@gmail.com wrote: >> Thanks Carl, I've made these changes, and I've also made a corresponding >> patch for changes.tely, but I don't think I have permission to upload >> new patch sets for either to this issue since it says "Can't Edit" at >> the top-left - can you give me permission? > > I doubt it. Just upload a new issue. So then we would have *three* Rietveld issues tracking the same thing. >> (If not, this is yet another >> reason Rietveld sucks. It all seems way too locked down to me.) > > It's not build for collaborate patch editing. The idea is that > you have a patch, you upload it. Make a few small modifications, > go ahead and upload it to the same rietveld number... but anything > major and you should just make a new rietveld number. Numbers are > cheap, after all. > > Note that problems like this are fairly rare. If we had an active > "frog meister", he'd be taking care rieveld for any inexperienced > contributors. And experienced developers like you would be > directed to git-cl, so nobody would have uploaded any patches for > you anyway. Understood, but I still think this workflow is fundamentally flawed. However I'm aware this is not the time nor place to discuss this further. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
Thanks Carl, I've made these changes, and I've also made a corresponding patch for changes.tely, but I don't think I have permission to upload new patch sets for either to this issue since it says "Can't Edit" at the top-left - can you give me permission? (If not, this is yet another reason Rietveld sucks. It all seems way too locked down to me.) In lieu of a patch set, the amended patch series is available here (freshly rebased on master): https://github.com/aspiers/lilypond/commits/jazz http://codereview.appspot.com/5320074/diff/14001/input/regression/chord-additional-pitch-prefix.ly File input/regression/chord-additional-pitch-prefix.ly (right): http://codereview.appspot.com/5320074/diff/14001/input/regression/chord-additional-pitch-prefix.ly#newcode1 input/regression/chord-additional-pitch-prefix.ly:1: \version "2.15.16" On 2011/11/05 14:33:32, Carl wrote: Will need to be adjusted when it's ready to commit. Right now, it should be 2.15.17. Version of new snippets is always one greater than the current release version. Done. http://codereview.appspot.com/5320074/diff/14001/scm/define-context-properties.scm File scm/define-context-properties.scm (right): http://codereview.appspot.com/5320074/diff/14001/scm/define-context-properties.scm#newcode380 scm/define-context-properties.scm:380: (minorChordModifier ,markup? "How should minor chords be formatted On 2011/11/05 14:33:32, Carl wrote: I'd prefer "Markup displayed following the root for a minor chord." Done. http://codereview.appspot.com/5320074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
On 2011/11/07 00:15:48, Graham Percival wrote: On Sun, Nov 06, 2011 at 03:52:15PM +, mailto:adam.spi...@gmail.com wrote: > I've done a corresponding patch for changes.tely but I don't have > permissions to upload it to this issue that's because Janek uploaded the original issue. Could you just make a new one? just ignore the old codereview issue. Uploading a new patch with git-cl, and associate it with issue tracker 1503 or 1572. - Graham Whoops, I forgot that Carl already created a separate issue for the new version of this patch series: http://codereview.appspot.com/5320074 So this one (4981052) should be ignored entirely now, and closed/deleted when Janek gets back. http://codereview.appspot.com/4981052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve HTML output of regression tests (issue 5342042)
On 2011/11/07 09:15:04, dak wrote: Uh, yes? See line 1313: the argument list consists of an arbitrary number of _pairs_. Right - it's comparing (baseline, check) pairs. I didn't introduce the modulo, I just made it explicit which is more legible than relying on Python's interpretation of 0 as False and 1 as True. http://codereview.appspot.com/5342042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
FSF copyright assignment
Given that LilyPond is part of the GNU project, presumably all contributors have to sign a form assigning copyright of all contributions to the FSF? http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html I couldn't find any reference to this in the CG though. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Request to mailing list lilypond-devel rejected
On Sun, Nov 6, 2011 at 11:16 PM, David Kastrup wrote: > Adam Spiers writes: >> I just got a bunch of rejections like the one below. I guess they >> were because when I click 'Publish+Mail Draft Comments' in Rietveld, >> it sends the mail to lilypond-devel using my google account e-mail >> address, which is not the address I am subscribed to this list with. >> Unfortunately the rejections don't include the body of the rejected >> mail, so that text is lost forever now. Hmph. Not sure what to do, >> except suggest that the Contributor's Guide mentions that you need to >> be subscribed to lilypond-devel via your google account e-mail for >> that to work. > > Subscribe via that account and set the options for that account to > "nomail". Then you receive mails as previously, but the posting will > work fine via the review tool. Great idea - thanks! > I think that somewhere in the full mail headers, instructions how to get > list help are hidden. Can all be done from here: https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: Request to mailing list lilypond-devel rejected
I just got a bunch of rejections like the one below. I guess they were because when I click 'Publish+Mail Draft Comments' in Rietveld, it sends the mail to lilypond-devel using my google account e-mail address, which is not the address I am subscribed to this list with. Unfortunately the rejections don't include the body of the rejected mail, so that text is lost forever now. Hmph. Not sure what to do, except suggest that the Contributor's Guide mentions that you need to be subscribed to lilypond-devel via your google account e-mail for that to work. -- Forwarded message -- From: Date: Sun, Nov 6, 2011 at 10:33 PM Subject: Request to mailing list lilypond-devel rejected To: adam.spi...@gmail.com Your request to the lilypond-devel mailing list Posting of your message titled "Re: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' (issue 5361042)" has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: "Non-members are not allowed to post messages to this list. Since you are not subscribed to this list, please use the Gmane interface at http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.devel for posting messages. Thank you, The LilyPond mailing list administrators " Any questions or comments should be directed to the list administrator at: lilypond-devel-ow...@gnu.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
I've done a corresponding patch for changes.tely but I don't have permissions to upload it to this issue so you'll have to get it from here: https://github.com/aspiers/lilypond/commit/3f02826bf5e8854f7da06b2f822d3a65cf63e487 http://codereview.appspot.com/4981052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
git-cl gives up too easily on failed google credentials
I uploaded two more patches last night using git-cl, but due to my use of google's 2-step authentication, both times I screwed up before realising that I needed to create an application-specific password. I created the issues manually, which may have resulted in labelling issues. This also highlighted two issues with git-cl: 1. You only get one shot at authenticating with google for issue creation at code.google.com. Could be easily fixed by wrapping the (interactive) authentication process in a 'while ! authenticated' loop. 2. You can only create a new issue there if you upload something to Rietveld first as part of the same invocation. There's an option: -n, --no-code-issue do not upload to code.google.com so I guess there needs to be a complementary option: -N, --no-review-issue do not upload to Rietveld I could have tried to fix these but (a) I should have already gone to bed and (b) I didn't know how to test them with creating an unholy mess in Rietveld or code.google.com. Hmm, I suppose adding -N for 2. would have allowed testing of a fix for 1. ... One more question: where are issues with git-cl tracked? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quick way to recreate docs
On Fri, Nov 4, 2011 at 4:53 PM, Phil Holmes wrote: > We decided that the "make" syntax served equally well, so I dropped it. I thought the make syntax didn't build the included images? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quick way to recreate docs
On Fri, Aug 5, 2011 at 11:39 PM, Graham Percival wrote: > Doesn't look too bad. If there was no (hidden) mechanism in the > build system to do this, I'd be happy to adopt the script. I only just found this thread, after a significant effort trying to solve the same problem. Did anyone push this script, or was there a consensus about whether it should be pushed? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git cl config question
On Fri, Nov 04, 2011 at 03:41:55PM +, Graham Percival wrote: > On Fri, Nov 04, 2011 at 03:35:53PM +0000, Adam Spiers wrote: > > On Fri, Nov 4, 2011 at 3:18 PM, Graham Percival > > wrote: > > > On Fri, Nov 04, 2011 at 03:08:40PM +, Adam Spiers wrote: > > >> OK, thanks. Next question - any ideas what's going on here? > > >> > > >> $ git cl upload origin/dev/staging > > >> scripts/build/output-distance.py | 65 > > >> ++--- > > >> 1 files changed, 52 insertions(+), 13 deletions(-) > > >> Waiting for Emacs... > > >> No output from ['hg', 'parent', '-q'] > > > > No, the emacs thing is a red herring - that works fine. The problem > > is what happens after the editor quits. > > > > EDITOR=vim git cl upload > > > > yielded exactly the same results. > > hmm. Looking at the 'hg', my next guess is that git-cl is calling > mercurial for some reasno. Sure, that much was clear :-) > git-cl is built on top of rietveld's "upload.py" script. Rietveld > was built around svn. Google added mercurial shortly afterwards, > but didn't add git until a few years later. So git support is > kind-of bolted on with duct tape. Perhaps the upload.py portion > of git-cl is deciding that you're working with mercurial, and then > not finding a .hg or .bzr or whatever directory mercurial uses? You were right. upload.py has: def GuessVCSName(): """Helper to guess the version control system. This examines the current directory, guesses which VersionControlSystem we're using, and returns an string indicating which VCS is detected. First thing it tries is to run `hg root'. In my case that was erroneously succeeding, because for some reason I had an old ~/.hg directory which should never have been there. git cl upload now works great, and I've successfully created my first Rietveld issue and corresponding Google code issue, as you'll see in another mail arriving imminently. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git cl config question
On Fri, Nov 4, 2011 at 3:18 PM, Graham Percival wrote: > On Fri, Nov 04, 2011 at 03:08:40PM +0000, Adam Spiers wrote: >> OK, thanks. Next question - any ideas what's going on here? >> >> $ git cl upload origin/dev/staging >> scripts/build/output-distance.py | 65 >> ++--- >> 1 files changed, 52 insertions(+), 13 deletions(-) >> Waiting for Emacs... >> No output from ['hg', 'parent', '-q'] > > You've got $VISUAL set to emacs, which apparently isn't playing > nice with the git-cl script? Just for the lulz, try doing > VISUAL=nano git cl upload > and see what happens. No, the emacs thing is a red herring - that works fine. The problem is what happens after the editor quits. EDITOR=vim git cl upload yielded exactly the same results. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
On Fri, Nov 4, 2011 at 3:13 PM, Graham Percival wrote: > On Fri, Nov 04, 2011 at 02:52:32PM +0000, Adam Spiers wrote: >> Hey, give yourselves some credit - at least you're not using CVS; >> *that's* what I would label as dark ages :-) git is still relatively >> new for many many people. Also, being short on experience doesn't >> make it impossible, it just means it will take a bit longer to get >> there. > > Yes and no. Suppose you're a windows users. Suppose you notice a > few typos in the lilypond documentation. Suppose you want to be > helpful and actually fix it instead of just filing a bug report to > bring out attention to the typos. > > The *shortest / easiest* method we have for those people is: > - install virtualbox > - download lilydev > - use a simplified graphical lily-git.tcl to get our source > - edit files in gedit > - compile the docs inside the virtual machine > - commit and create patch using the simplified graphical lily-git.tcl > - send patch by email > > When most people look at those steps -- which again, is the > easiest method we have, after continually looking and revamping > this process over the past three years -- they either give up > part-way, or just never start. If the task appears to be too > hard, it's not a question of time+effort; most people (sensibly) > just give up. Understood, but I can't really imagine how you could make the initial set up of a build environment for this size of codebase any less of a hurdle. lilydev is a great thing, and even with using it (I didn't), setting up a build environment was a total walk in the park compared to something like digikam. >> Sure, it can be improved, but I don't think it's >> worth beating ourselves up about it either. > > I'm not beating myself up -- but when I see people spending > literally dozens of hours on tasks that could be automated with > 1-3 hours of programming, I hardly think that optimism is the > appropriate response. :( Given that we have this great opportunity to make things way better without too much effort, it seems an entirely appropriate response to me! Surely you wouldn't prefer the automation to be very difficult, or even worse, impossible? >> I don't know Patchy, but I agree it certainly sounds like a lot of >> this work could be automated. >> >> http://en.wikipedia.org/wiki/Continuous_integration > > Incidently, the latest round of panic is because I switched to > ubuntu oneiric 11.10 instead of staying on 10.04 LTS. I wanted > the gcc 4.6 toolchain for my Vivi work, but that's caused a huge > ripple of disruption in lilypond. How come? Lilypond compiles fine with gcc 4.6.1 on Fedora 15. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git cl config question
On Fri, Nov 4, 2011 at 3:05 PM, Graham Percival wrote: > On Fri, Nov 04, 2011 at 02:56:19PM +0000, Adam Spiers wrote: >> What should I provide as the Tree status and ViewVC URLs to git cl >> config? The CG says "If you do not understand any question, just >> answer with a newline (CR)" but presumably if I leave these blank then >> I'll miss out on some functionality? > > No clue. I've always omitted them, and I haven't noticed any > missing functionality -- but then again, I'm not at all demanding > in my git usage. OK, thanks. Next question - any ideas what's going on here? $ git cl upload origin/dev/staging scripts/build/output-distance.py | 65 ++--- 1 files changed, 52 insertions(+), 13 deletions(-) Waiting for Emacs... No output from ['hg', 'parent', '-q'] Also, please let me know if I'm incorrectly assuming I should be using dev/staging as the reference branch rather than master. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
git cl config question
What should I provide as the Tree status and ViewVC URLs to git cl
config? The CG says "If you do not understand any question, just
answer with a newline (CR)" but presumably if I leave these blank then
I'll miss out on some functionality?
$ git cl config
Rietveld server (host[:port]) [codereview.appspot.com]:
CC list ("x" to clear) [lilypond-devel@gnu.org]:
Tree status URL:
ViewVC URL:
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
On Fri, Nov 04, 2011 at 01:14:00PM +, Graham Percival wrote: > On Fri, Nov 04, 2011 at 12:10:20PM +0000, Adam Spiers wrote: > > Sure, understood - but I still don't see why each commit within a > > single issue couldn't be checked accumulatively, rather than just > > applying all three together and only then doing the check. [snipped] > Bottom line: you're vastly over-estimating our (collective) skill > and comfort level with git. It's safe to assume that we're > similarly in the dark ages about many other aspects of software > development. Hey, give yourselves some credit - at least you're not using CVS; *that's* what I would label as dark ages :-) git is still relatively new for many many people. Also, being short on experience doesn't make it impossible, it just means it will take a bit longer to get there. > Over the past 12 months, almost half of our > development effort has come from windows users who have never > contributed to open source before. They face a pretty steep > learning curve. Sure - I'm finding this a reasonably steep curve, despite the superb documentation etc., and I've been working with F/OSS since 1994. I think that's just the nature of the beast - Lilypond is a large, complex codebase, with many facets to a necessarily complex development process. Sure, it can be improved, but I don't think it's worth beating ourselves up about it either. > > Of course it's more work, but arguably still less work (and less > > noise) than creating an issue per commit. > > True, and Patchy could be doing that for us. The brilliant (if I > may say so myself) of Patchy is that we don't need to teach > everybody how to use moderatly-skilled git commands, we don't need > to fumble around manually clicking on website links, etc etc. We > don't even need a single person who knows all aspects of Patchy -- > as long as people fix little problems with Patchy as we go along, > we can end up with a robust automatic system that does whatever we > want it to. I don't know Patchy, but I agree it certainly sounds like a lot of this work could be automated. http://en.wikipedia.org/wiki/Continuous_integration ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
On Fri, Nov 04, 2011 at 11:55:42AM +, Carl Sorensen wrote: > On 11/4/11 5:35 AM, "Adam Spiers" wrote: > >On Thu, Nov 03, 2011 at 06:28:55PM +, Carl Sorensen wrote: > >> I can't find the suggestion to replace tabs with spaces in this review > >> string, so I can't comment on the suggestions. > > > >http://codereview.appspot.com/4981052/#msg3 > > OK, I don't know how I missed that before. > Had I seen that review, I'd have mentioned that .scm indentation is not > yet a settled issue on the GOP. I'm sorry I didn't catch it earlier. No problem :-) > >> Our policy of testing each commit to ensure that it doesn't break > >> build prevents multiple patches per issue. > > > >I don't understand why this policy would prevent multiple patches per > >issue, but you probably shouldn't waste time explaining it to me :) > > Because the finest granularity we have in the review process is a Rietveld > issue. So we only check each Rietveld issue to verify that it doesn't > break build. > > It would be possible to have a series of three commits in a Rietveld > issue, with the first two commits breaking the build, and the third fixing > the problem. When this set of three is checked on Rietveld, we get a > clean make, so the push is approved. If I then push to master as a set of > three commits, two of them break build and therefore mess up git-bisect. Sure, understood - but I still don't see why each commit within a single issue couldn't be checked accumulatively, rather than just applying all three together and only then doing the check. Of course it's more work, but arguably still less work (and less noise) than creating an issue per commit. > In the case of your chords patch, I looked over each commit carefully and > I'm quite certain that if the build status of the final commit is > good, Sadly there is one regression :-( I've just posted a fix to: http://code.google.com/p/lilypond/issues/detail?id=1503 > P.S. Your patch is currently up for review, but with a different issue > number since I'm now the owner > > http://codereview.appspot.com/5320074/ Yep, I got the email alerts for that. Thanks for your work on this! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
On Thu, Nov 03, 2011 at 06:28:55PM +, Carl Sorensen wrote: > On 11/3/11 10:50 AM, "Adam Spiers" wrote: > >I originally avoided any pure-whitespace commits, but at the > >review of my initial patches, I was told to replace tabs with spaces > >in the files I was modifying: > > > > http://codereview.appspot.com/4981052/ > > I can't find the suggestion to replace tabs with spaces in this review > string, so I can't comment on the suggestions. http://codereview.appspot.com/4981052/#msg3 > Our policy of testing each commit to ensure that it doesn't break > build prevents multiple patches per issue. I don't understand why this policy would prevent multiple patches per issue, but you probably shouldn't waste time explaining it to me :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
On Thu, Nov 3, 2011 at 4:28 PM, Graham Percival wrote: > We're not comfortable with git. Other than 4 or 5 people, each > person who's started pushing to dev/staging has required between 3 > and 10 emails to get them able to reliably push to a branch > without screwing stuff up. I just discovered this git tutorial site which may be of use to some: http://think-like-a-git.net/sections/who-this-site-is-for.html I've seen many others, but this one looks really great, and is pretty funny too (to my twisted sense of humour, at least). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
On Thu, Nov 03, 2011 at 04:28:53PM +, Graham Percival wrote: > On Thu, Nov 03, 2011 at 04:00:41PM +0000, Adam Spiers wrote: > > On Thu, Nov 03, 2011 at 11:13:28AM +, Peekay Ex wrote: > > > One patch per tracker item? > > > > I can do that if noone objects to tracker items for patches as trivial > > as converting tabs to whitespace? > > I'd rather not see those patches. > > Hmm, I'm seeing 11 patches? how hard would it be to do some > intelligent rebasing here? i.e. rebase any programming features / > bugfixes into one (or more) patches, rebase the ly file fixes into > one (or more) patches, etc. I always do a lot of patch sculpting via git rebase -i before I deem my patches to be good enough to push upstream. So what you are seeing have already been rebased many times in order to obtain commits which logically group changes together. For example, each new feature being introduced is accompanied by its corresponding doc tweaks and regression tests where relevant. That said, I *could* squash a few of the smaller patches together. But I still think it would be a mistake to squash all these into one or two commits, which would then lack a lot of clarity. > I mean, c6fe8a can easily be... oh wait, no it can't. MAO! we > don't like changes like that. We really, really don't like > changes like that. > > Could I interest you in scheme indentation: > http://lilypond.org/~graham/gop/gop_10.html > > with about 30 - 90 minutes of work, we can settle these IDIOTIC > indentation commits once and for all. Get the tool finalized, run > it on all the scm files, and then celebrate. We (finally) did > this with C++ over the summer... the whole debate and work on the > tools took at least 40 hours of developer time, but it was worth > it. > > Unfortunately, the scheme indentation stuff stalled in August due > to a number of factors. Which was a shame, because scheme > indentation is WAY easier than C++ indentation, and also because > the indentation script was almost finished. Understood. I've already spent WAY more time on all this than budgeted, so I'm not sure I can afford to stretch any further for a while. I originally avoided any pure-whitespace commits, but at the review of my initial patches, I was told to replace tabs with spaces in the files I was modifying: http://codereview.appspot.com/4981052/ and given my strong aversion to (a) a mix of indentation styles within a single file, and (b) commits which mix whitespace changes with real coding changes, I thought this was the best way to proceed. But I agree the sensible thing would be to fix all .scm files in one go. > > > Sorry to belabor the point, but it is unlikely you are going to get > > > much review if those that understand this stuff (I don't, I just push > > > and pull and test formatted patches) have to get patches from a third > > > place. > > > > Hmm, well if everyone (including you) is already familiar with 'git > > pull' then doing 'git fetch' doesn't seem like a big stretch, > > We're not comfortable with git. Other than 4 or 5 people, each > person who's started pushing to dev/staging has required between 3 > and 10 emails to get them able to reliably push to a branch > without screwing stuff up. Ahah, OK. > > If Rietveld doesn't support multiple patches per issue then that > > sounds like a fundamental flaw to me and perhaps it's time to > > reconsider moving to Gerrit. > > Stop right there. This debate has chewed up about 25 hours of > developer time so far, with no end in sight. I realize that > you're an excellent person to move it forward, but I don't want to > hear about it right now. > > I'm vetoing this discussion for 5 weeks. Wait until you know us > better (in particular, the relative lack of technical ability), > wait until we know you better, wait until our Grand Organization > Project starts up again. this, incidently, is exactly GOP 13: > http://lilypond.org/~graham/gop/gop_13.html OK, I couldn't remember whether I'd already seen it somewhere :-) Just wanted to make sure it's on people's radar, so given GOP 13 I'm happy not to mention it again :-) > Moving back to the jazz patches: Carl, could you take a look at > his git repo and suggest any way of moving forward? Thanks, guidance would be welcome. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
On Thu, Nov 03, 2011 at 11:13:28AM +, Peekay Ex wrote: > Adam, > > On Wed, Nov 2, 2011 at 5:58 PM, wrote: > > I think I am now finished. The new patch series is available at > > > > https://github.com/aspiers/lilypond/commits/jazz > > > > IMHO there are now too many patches in the series to combine into a > > single commit for review. To do so would lose a lot of clarity in the > > git history. So I am not sure how this review process should proceed. > > One patch per tracker item? I can do that if noone objects to tracker items for patches as trivial as converting tabs to whitespace? > > Anyhow, you can fetch the patches via: > > > > git remote add aspiers git://github.com/aspiers/lilypond.git > > git fetch aspiers jazz > > Sorry to belabor the point, but it is unlikely you are going to get > much review if those that understand this stuff (I don't, I just push > and pull and test formatted patches) have to get patches from a third > place. Hmm, well if everyone (including you) is already familiar with 'git pull' then doing 'git fetch' doesn't seem like a big stretch, but OK I'll assume that there are other good reasons for not operating like this. As long as you're OK with a tracker item for even tiny commits then I can work like that. > Even if it is just a Rietveld Issue then that is better than having to > git fetch from another repo, we in the Bug Squad can create the > trackers for you. If Rietveld doesn't support multiple patches per issue then that sounds like a fundamental flaw to me and perhaps it's time to reconsider moving to Gerrit. I'm guessing that combined with a CI tool such as Jenkins it might be able to solve some of the review / staging / release issues which have been mentioned on this list of the last few days - but I don't know anywhere near enough about LilyPond's development yet for that to be more than a guess. https://gerrit.chromium.org/gerrit/#q,status:open,n,z http://source.android.com/source/life-of-a-patch.html > > The patches also adjust the regression tests and English documentation > > to be consistent with changes to the code. Translation work is required > > for other languages. > > > > http://codereview.appspot.com/4981052/ > > So should we now be ignoring the stuff in this Rietveld issue? Yes, they're old now. In light of the above I guess it will have to be closed and superceded by new issues. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: *.profile file changes in regression tests?
On Thu, Nov 03, 2011 at 06:31:23AM +, Graham Percival wrote:
> On Thu, Nov 03, 2011 at 12:38:02AM +0000, Adam Spiers wrote:
> > Do I need to create an issue and/or Rietveld entry for this and for
> > my other patch to {doc,cg}-section.sh, or will someone who knows the
> > processes (e.g. Bug Squad member) take care of this?
>
> Ideally, upload it with our git-cl:
> https://github.com/gperciva/git-cl
>
> that will automatically create rietveld and issue.
OK thanks, I'll give that a go.
> This isn't documented in the CG yet because it's still new and we're
> debugging it.
Really? Looks like it's documented here, unless I'm missing something:
http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review
> If you find an unhandled exception or something,
> let me know, and/or patch it.
>
> You can push directly to git-cl master; I've added aspiers as a
> collaborator to that repo.
Will do, thanks!
> I've also added you to the lilypond-extra repo:
> https://github.com/gperciva/lilypond-extra
> in case you're interested in the patches/ subdirectory. The plan
> is that we'll have a cronjob run
> patches/compily_lilypond_test.py
> every 12 hours, which will automatically merge (or rebase)
> dev/staging with master, compile the docs, and if they build, push
> that merge.
>
> also of interest may be
> patches/test-patches.py
> which automatically downloads all Patch-new issues from the issue
> tracker (after people upload them with our modified git-cl
> script), checks that the patch applies + compiles, then it keeps a
> regtest comparison around for a human to look at. Ideally, the
> rejection should be automatic (if it fails to apply or compile),
> whereas the final acceptance only happens once somebody has looked
> at the regtests. At the moment it's all manual, though.
OK, can't promise I'll have time for this, but you never know!
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: *.profile file changes in regression tests?
On Thu, Nov 3, 2011 at 12:38 AM, Adam Spiers wrote: > On Wed, Nov 2, 2011 at 1:02 PM, Graham Percival > wrote: >> On Wed, Nov 02, 2011 at 12:03:08PM +, Adam Spiers wrote: >>> I might have time to take a bash at adding Javascript buttons if >>> someone can give me a crash course in how those HTML files are >>> constructed (in particular, how I can add stuff to the >>> section). >> >> No clue, sorry. git grep is your friend, as is poking around in >> the makefiles and/or build scripts until you find something. > > Damn you - I couldn't resist ;-) See below. Urgh. Noticed an omission from the patch microseconds after hitting the Send button. Updated version now available from https://github.com/aspiers/lilypond/tree/regression To import this 'regression' branch into your own git repo, do git remote add aspiers git://github.com/aspiers/lilypond.git git fetch aspiers regression ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
I think I am now finished. The new patch series is available at https://github.com/aspiers/lilypond/commits/jazz IMHO there are now too many patches in the series to combine into a single commit for review. To do so would lose a lot of clarity in the git history. So I am not sure how this review process should proceed. Anyhow, you can fetch the patches via: git remote add aspiers git://github.com/aspiers/lilypond.git git fetch aspiers jazz The patches also adjust the regression tests and English documentation to be consistent with changes to the code. Translation work is required for other languages. http://codereview.appspot.com/4981052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: multiple issues with building docs (patch included)
On Wed, Nov 2, 2011 at 5:25 AM, Graham Percival wrote: > On Wed, Nov 02, 2011 at 02:14:13AM +, Carl Sorensen wrote: >> On 11/1/11 5:44 PM, "Adam Spiers" wrote: >> >`make doc' works, but takes too long to be of practical use except as >> >a final sanity check before submitting a patch upstream. > > You can use multiple threads. I already am. Even with make -j3 CPU_COUNT=3 it still takes ages on my rather modest AMD Athlon 64 X2. >> >http://lilypond.org/doc/v2.15/Documentation/contributor/generating-documen >> >tation#building-a-single-document >> > >> >explains how to build a single document, but only gives a PDF as an >> >example. I wanted to rebuild the split-page HTML version of the >> >Notation Reference, but couldn't figure out how. Instead I managed to >> >build the big page version via: >> > >> > make out=www out-www/notation-big-page.html >> >> AFAICS, the single manual doc build is not really functional. > > Nonsense, it should be perfectly fine. It *seemed* to work for me, but like I said, the images are missing, rendering it useless for my current work. > I'm not certain about the > big-page, but > make out=www out-www/notation/index.html > should be no problem. IIRC I tried that, and it seemed to behave as a NOOP - do the makefiles register dependencies on index.html for all the subsections? >> > This script will require customization for your site if your >> > LilyPond git repository is anyplace but $HOME/lilypond. >> >> Lilypond-git is the canonical location now, instead of lilypond. If >> scripts/auxiliar/doc-section.sh does not refer to liypond-git, it should >> be fixed. > > http://code.google.com/p/lilypond/issues/detail?id=1236 > > been on the books for over a year. Thanks, I've added my thoughts to that issue. >> >When building in a build/ subdirectory as recommended by the Guide, >> >this path is wrong; it should be: >> > >> > cp $LILYPOND/build/Documentation/out/version.itexi >> >$HOME/lilypond/tempdocs >> >> Actually, the script should be changed to refer to >> $LILYPOND/build/tempdocs. > > yep. Well, $LILYPOND_GIT/build/ Please see my comment on the above issue - any reason to prefer use of this environment variable over auto-detection even where it is easily achievable? >> >Couldn't this simply be included in the script rather than as an extra >> >step in the instructions? >> >> It certainly could. > > yep. I did it in my patch, in fact :-) See below. >> >"/home/adam/lilypond-git/tempdocs/chords/out/snippet-names--514510028.ly" >> >Child returned 1 >> >Lilypond-book returned code 1 >> >> Now you are running into the key challenge for building docs. >> >> If you run >> >> Lilypond tempdocs/out/e5/lily-0f1202dd.ly, you'll get to see the error >> message. In fact, there's probably a logfile in tempdocs/out/e5 that has >> the error message. I already looked for a logfile there but couldn't see one. Next time it happens I'll try running lilypond on that file manually. > or you could just look at tempdocs/out/e5/lily-0f1202dd.ly , > delete a few lines from it so you can compile it on the > command-line, then debug that. > >> >I'm not sure how to debug this because there doesn't seem to be a >> >useful error either on STDOUT or in a log file anywhere. > > yep. > after about 2 months of debate, we've adopted > http://lilypond.org/~graham/gop/gop_9.html > but not much work has gone into implementing it yet. Ahah! Looks very promising. > Incidently, you may want to browse the proposals: > http://lilypond.org/~graham/gop/index.html > to see what kind of mess we're in. Wow. There sure is a lot to do, but I certainly wouldn't call it a mess; in fact I think this is probably the most thoughtfully organized F/OSS project I've ever seen, and way better than many commercial ventures. >> >Finally, tempdocs is not in .gitignore. > > doc-section.sh isn't really supported, and in any case I would > personally set tempdocs to be /tmp/ramdisk/lily-quick-docs or > something like that... so I'm not keen on that change. OK, I've changed it to honour three environment variables: LILYPOND_GIT (auto-detects if not set) LILYPOND_BUILD_DIR (defaults to $LILYPOND_GIT/build) LILYPOND_TEMPDOCS(defaults to $LILYPOND_BUILD_DIR/tempdocs) Is that better? I've also adapted cg-section.sh in exactly the same way. Patch below ... > Thanks so much for the patch to our development stuff, th
Re: *.profile file changes in regression tests?
On Wed, Nov 2, 2011 at 8:29 AM, Graham Percival
wrote:
> On Tue, Nov 01, 2011 at 05:34:01PM +0000, Adam Spiers wrote:
>> I just invented a Javascript hack which I'm sharing in case there
>> isn't a better way; whilst viewing out/test-results/index.html, type
>> this into your Chrome / Firebug console:
>>
>> trs = $x("//tr"); for (i in trs) { tr = trs[i]; if
>> (tr.innerHTML.indexOf(".profile") != -1) tr.style.display = "none"; }
>>
>> Hides all rows which contain the string ".profile" :-)
>
> neat idea. I wouldn't object to adding a button to the regtest
> comparison which enabled/disabled the .profile lines.
>
> Longer-term, all the text output should happen on other pages
> anyway, but that'd be a 20-hour (or more!) task. Adding a "toggle
> .profile" button to the page would only take a few minutes for a
> html/javasacript-aware person.
Thanks for the reply Graham.
I might have time to take a bash at adding Javascript buttons if
someone can give me a crash course in how those HTML files are
constructed (in particular, how I can add stuff to the
section).
By the way, sorry I don't have time to figure that out for myself; I
find the documentation hierarchies and countless makefiles bewildering
right now - for instance, why is there both of these?
build/Documentation/notation/out
build/Documentation/out/notation
and what is the difference between out/ and out-www/ ?
No doubt some or all of my questions would be answered by section
12.4.1 of the CG, but it seems like that section is not necessarily
complete or reliable, and even if it was, I don't have time to digest
it.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
multiple issues with building docs (patch included)
I'm trying to make sure my patches include the right tweaks to the
documentation, but as a newbie to lilypond development (but with a lot
of development experience elsewhere), I'm sorry to say I'm really
struggling :-(
`make doc' works, but takes too long to be of practical use except as
a final sanity check before submitting a patch upstream.
http://lilypond.org/doc/v2.15/Documentation/contributor/generating-documentation#building-a-single-document
explains how to build a single document, but only gives a PDF as an
example. I wanted to rebuild the split-page HTML version of the
Notation Reference, but couldn't figure out how. Instead I managed to
build the big page version via:
make out=www out-www/notation-big-page.html
but the images are missing, so that's no use to me. I also found
http://lilypond.org/doc/v2.15/Documentation/contributor/scripts-to-ease-doc-work
which pointed me to scripts/auxiliar/doc-section.sh, but this had
multiple issues. Firstly, the Contributor's Guide says:
This script will require customization for your site if your
LilyPond git repository is anyplace but $HOME/lilypond.
Customizing the script is problematic, because that introduces
non-commitable changes to a file tracked by git. Adding a symlink
from ~/lilypond doesn't work either, because commit
c9ae4b4db5e9e147b9eebb68264f0d9928dca39a changed the location to
~/lilypond-git.
Another oddity in the Guide is where it tells you to do:
cp $HOME/lilypond/Documentation/out/version.itexi $HOME/lilypond/tempdocs
When building in a build/ subdirectory as recommended by the Guide,
this path is wrong; it should be:
cp $LILYPOND/build/Documentation/out/version.itexi $HOME/lilypond/tempdocs
Couldn't this simply be included in the script rather than as an extra
step in the instructions?
Anyway, after symlinking from ~/lilypond-git, I could successfully
run doc-section.sh, but then it inexplicably fails during the run:
Writing e6/lily-95d83000-systems.texi...
Writing e6/lily-95d83000-systems.tex...
Writing e6/lily-95d83000-systems.count...
error: failed files: "e5/lily-0f1202dd.ly"
command failed: /usr/bin/lilypond --formats=ps,png -dbackend=eps -I
"/home/adam/.GIT/3rd-party/lilypond.git" -I
"/home/adam/lilypond-git/Documentation/snippets" -I
"/home/adam/lilypond-git/Documentation/snippets/new" -I
"/home/adam/lilypond-git/input/manual" -I
"/home/adam/lilypond-git/Documentation" -I
"/home/adam/lilypond-git/Documentation/included" -I
"/home/adam/lilypond-git/Documentation/pictures" --formats=eps
-deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir
"/home/adam/lilypond-git/tempdocs/chords/out/snippet-names--514510028.ly"
Child returned 1
Lilypond-book returned code 1
I'm not sure how to debug this because there doesn't seem to be a
useful error either on STDOUT or in a log file anywhere. Having said
that, the fact that it's using /usr/bin/lilypond rather than my
locally compiled version is highly suspect. I see that doc-section.sh
contains:
LILYPONDBOOK="lilypond-book"
which picks up /usr/bin/lilypond-book. I changed it to
LILYPONDBOOK="$FROMDIR/build/out/bin/lilypond-book"
and now it seems to work, albeit with this mysterious-looking prompt
at the end of the run:
delete files? (y/n):
Finally, tempdocs is not in .gitignore.
Here is a patch which fixes all the issues in this email:
>From 3bb0571c8322d6da8e546955966952427f2ee6c2 Mon Sep 17 00:00:00 2001
From: Adam Spiers
Date: Tue, 1 Nov 2011 23:35:00 +
Subject: [PATCH] Fix several issues regarding scripts/auxiliar/doc-section.sh
---
.gitignore |1 +
Documentation/contributor/doc-work.itexi | 25 ++
scripts/auxiliar/doc-section.sh | 32 +
3 files changed, 31 insertions(+), 27 deletions(-)
diff --git a/.gitignore b/.gitignore
index e0fae2d..19a472c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -78,3 +78,4 @@ Documentation/lilypond
semantic.cache
.lock-wscript
build/
+/tempdocs
diff --git a/Documentation/contributor/doc-work.itexi
b/Documentation/contributor/doc-work.itexi
index 9f42e45..0aabc71 100644
--- a/Documentation/contributor/doc-work.itexi
+++ b/Documentation/contributor/doc-work.itexi
@@ -1416,24 +1416,7 @@ In order to save build time, a script is
available to build only
one section of the documentation in English with a default html
appearance.
-The script is available as:
-
-@example
-scripts/auxiliar/doc-section.sh
-@end example
-
-This script will require customization for your site if your
-LilyPond git repository is anyplace but @code{$HOME/lilypond}.
-
-Assuming that no customization is required, you can setup the
-single section build with:
-
-@example
-mkdir $HOME/lilypond/tempdocs
-cp $HOME/lilypond/Documentation/out/
Re: *.profile file changes in regression tests?
On Tue, Nov 1, 2011 at 5:11 PM, Adam Spiers
wrote:
> I'm starting to get the hang of regression tests, but my
> build/out/test-results/index.html shows a very large number of entries
> referring to *.profile files. I assume this is something to do with
> performance, but for once the Contributor's Guide isn't much help;
>
> http://lilypond.org/doc/v2.15/Documentation/contributor-big-page.html#precompiled-regression-tests
>
> says:
>
> Profile files: give information about TODO? I don’t know what they’re for.
>
> How do I know whether I should be worrying about these? And is there
> a way to just see the images? They are currently buried under
> hundreds of these .profile regressions, so they are a bit hard to
> find.
I just invented a Javascript hack which I'm sharing in case there
isn't a better way; whilst viewing out/test-results/index.html, type
this into your Chrome / Firebug console:
trs = $x("//tr"); for (i in trs) { tr = trs[i]; if
(tr.innerHTML.indexOf(".profile") != -1) tr.style.display = "none"; }
Hides all rows which contain the string ".profile" :-)
But if there is a less ugly hack I'd love to know about it.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
*.profile file changes in regression tests?
I'm starting to get the hang of regression tests, but my build/out/test-results/index.html shows a very large number of entries referring to *.profile files. I assume this is something to do with performance, but for once the Contributor's Guide isn't much help; http://lilypond.org/doc/v2.15/Documentation/contributor-big-page.html#precompiled-regression-tests says: Profile files: give information about TODO? I don’t know what they’re for. How do I know whether I should be worrying about these? And is there a way to just see the images? They are currently buried under hundreds of these .profile regressions, so they are a bit hard to find. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
I have finally figured out how to reproduce these regressions, and am working on a fix. http://codereview.appspot.com/4981052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: \hideNote
On Tue, Nov 1, 2011 at 3:17 PM, Peekay Ex wrote: > On Tue, Nov 1, 2011 at 2:29 PM, Adam Spiers > wrote: >> On Tue, Nov 1, 2011 at 1:35 PM, Kieren MacMillan >> wrote: >> Ah, that makes sense. I could do the rename, but is there some process >> for handling non-backwards-compatible changes in syntax? > > Don't want to sound like a bore but all this (and other things you > will probably run into) is pretty well documented in our Contributor;s > Guide. > > http://lilypond.org/doc/v2.15/Documentation/contributor/adding-or-modifying-features Perfect thanks. I'm pretty sure I've *never* seen a better documented F/OSS project. The level of attention to detail is incredible, although as a newbie developer it's a double-edged sword - on the one hand it's comforting to know that most of my questions are already answered, but on the other it's a bit overwhelming feeling like I have to read a huge manual even before I produce my first patch :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: \hideNote
On Tue, Nov 1, 2011 at 3:15 PM, Peekay Ex wrote: > On Tue, Nov 1, 2011 at 2:28 PM, Adam Spiers > wrote: >> Thanks James. I'm a little confused regarding snippets: I was aware >> that files in Documentation/snippets are autogenerated from files in >> Documentation/snippets/new, however I assumed that because the >> autogenerated files were checked into git, that for consistency's sake >> it would be cleaner to check in the changes to those too. Isn't that >> the case? > > No. See the documentation. The py script does that all for you - but > in a way I won't pretend to understand - that is different from just > doing the same edit in two places. Sure, but my point is that if the script updates the autogenerated files, then they should also be included in the patch, right? That's what 7.5.5 says, but I got the impression from you (perhaps mistakenly) that my patch shouldn't include *any* changes to autogenerated files. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Re: CG 5.8.3: updating committish of lsr snippets
On Tue, Nov 1, 2011 at 10:38 AM, Federico Bruni wrote: > Il 31/10/2011 21:05, Francisco Vila ha scritto: >>> >>> you haven't applied it yet, right? >> >> Now it is; please pull, test it and tell me. > > Ok, thanks. > Well, I had tested it before and I knew what it would have happened. > > 'make check-translation' is a mess now. > > If you run this command you'll see what I mean: > > cd Documentation > make ISOLANG=it NO_COLOR=1 check-translation | less > > > Is it normal? > I guess it's not. There's a lot of garbage. > I've tried the check-translation of spanish and in most (all?) of cases the > only change for each file in snippets/ is the committish. > > > BTW, it would be much better if check-translation could check only the > modifications in the texidoc="" and doctitle="" parts of the snippets (the > parts that must be translated). > Is it possible? (question for Python developers) Sorry for hijacking this thread, but I just noticed that what you are discussing may relate to a problem I just mentioned elsewhere in the "RFC: \hideNote" thread - running makelsr.py introduces spurious blank lines prior to lines which begin %% Translation of GIT committish: ... If I run it say 5 times in a row, then in each snippet file there is an extra 5 blank lines before this comment. Could this be related to the work you are doing? Thanks! Adam ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: \hideNote
On Tue, Nov 1, 2011 at 1:35 PM, Kieren MacMillan wrote: >> I am sure other more experienced programmers will chime in but having >> two 'similar' functions >> >> \hideNote >> \hideNotes >> >> Is a good idea. > > I thought we had settled on \functionOn and \functionOff (e.g., \sustainOn > and \sustainOff). > So we should have \hideNotesOn and \hideNotesOff, right? Then \hideNote could > stand for "\once \hideNotesOn". > That seems clear to me. Ah, that makes sense. I could do the rename, but is there some process for handling non-backwards-compatible changes in syntax? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: \hideNote
On Tue, Nov 1, 2011 at 12:23 PM, Peekay Ex wrote: > On Tue, Nov 1, 2011 at 10:21 AM, Adam Spiers > wrote: >> I noticed that we already have \hideNotes and \unHideNotes, but that >> is rather clumsy when you only want to hide a single note. So I wrote >> a patch to add \hideNote, and as a newbie to Lilypond development I >> wanted to check that this was a sensible idea. The patch is here, >> although I haven't tested it properly yet because I'm still getting to >> grips with the regression test suite: >> >> https://github.com/aspiers/lilypond/commit/125c734efa2815e358815cdd912acad81940c776 >> >> It adds one sentence to the documentation which would need >> translating. > > I am sure other more experienced programmers will chime in but having > two 'similar' functions > > \hideNote > \hideNotes > > Is a good idea. > > Although we do have > > \time > > and > > \times > > but they do very different things. > > Also with regard to updating documentation and translations you can > read all about that in the Contributor's Guide. > > http://lilypond.org/doc/v2.15/Documentation/contributor/translating-the-documentation > > Essentially the translations are handled in a separate branch. > > Also you cannot just edit snippets like your commit shows, there is a > process for this too that needs to be followed. > > http://lilypond.org/doc/v2.15/Documentation/contributor/adding-and-editing-snippets Thanks James. I'm a little confused regarding snippets: I was aware that files in Documentation/snippets are autogenerated from files in Documentation/snippets/new, however I assumed that because the autogenerated files were checked into git, that for consistency's sake it would be cleaner to check in the changes to those too. Isn't that the case? In this case, I'm only editing existing snippets, not adding new ones, and clearly I can't submit the edits to LSR before \hideNote has been implemented in Lilypond, so presumably in this case there is no need to interact with LSR? Having said that, running makelsr.py revealed two useful things: (a) I'd forgotten to update Documentation/es/texidocs/creating-slurs-across-voices.texidoc (b) running makelsr.py introduces spurious blank lines prior to lines which begin %% Translation of GIT committish: ... I've pushed a new patch to github to address (a): https://github.com/aspiers/lilypond/commits/hideNote (b) smells like a bug in makelsr.py, can anyone confirm? > If you like, for now I can add a tracker issue for you on this and if > you send me a git format patch I can post this up on Rietveld (our > current method of code verification) for you. Please feel free to create a new issue to track this. I guess you're probably OK just adding my github repo as a remote and grabbing that branch rather than me sending a git format patch? Thanks! Adam ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RFC: \hideNote
I noticed that we already have \hideNotes and \unHideNotes, but that is rather clumsy when you only want to hide a single note. So I wrote a patch to add \hideNote, and as a newbie to Lilypond development I wanted to check that this was a sensible idea. The patch is here, although I haven't tested it properly yet because I'm still getting to grips with the regression test suite: https://github.com/aspiers/lilypond/commit/125c734efa2815e358815cdd912acad81940c776 It adds one sentence to the documentation which would need translating. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patches for LilyPond issues 1503 and 1572
2011/9/10 Janek Warchoł > Uploaded to Rietveld: http://codereview.appspot.com/4981052/ I could be wrong but it looks like Rietveld has all the patches squashed into a single patch set. Does that mean that when they get pushed upstream to the official repo, they'll only appear as a single patch? I think it would be cleaner to keep them as separate ones. > One thing: please follow these guidelines concerning commit messages: > http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#commit-messages > I've changed the messages in my repository; i don't know if this > change can cause incompatibilities between our repositories, but if it > does (and we need to be compatible because the patches will probably > have some revisions which i will also have to upload) i attach patch > files created from my repository. That's fine - yes, changing the messages does affect the commit's SHA1, but I've switched my repository over to use your messages via a git push -f. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book.py: error: file not found: out-test/key-initial-midi.ly
2011/10/31 Carl Sorensen : > On 10/30/11 6:26 PM, "Adam Spiers" wrote: >>OK, I've gotten stuck whilst running regression tests against my >>feature branch. 'make test-redo' yields the following error, but I >>don't see how any of my patches could affect MIDI output, and the >>error persists even when I revert to the unpatched upstream master >>branch. Any ideas? >> >>ain not found. >>lilypond-book.py (GNU LilyPond) 2.15.17 >>Reading out-test/collated-files.tely... >>Running texi2pdf on file /tmp/tmpJvVxHS.texi to detect default page >>settings. >>Dissecting...lilypond-book.py: error: file not found: >>out-test/key-initial-midi.ly > > I have also had some problems with this file. I don't have good answers, > but you're not alone. Thanks for the feedback Carl. The problem vanished after `make test-clean' but I'm not sure why. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patches for LilyPond issues 1503 and 1572
2011/10/30 Adam Spiers : > Hi Janek, > > Just a quick note to say that I've started work on this again. > I'll be in touch again when I've made some progress. OK, I've gotten stuck whilst running regression tests against my feature branch. 'make test-redo' yields the following error, but I don't see how any of my patches could affect MIDI output, and the error persists even when I revert to the unpatched upstream master branch. Any ideas? make[3]: Entering directory `/data/music/software/lilypond.git/build/input/regression/midi' LILYPOND_VERSION=2.15.17 /usr/bin/python /home/adam/music/software/lilypond.git/scripts/lilypond-book.py -I /home/adam/music/software/lilypond.git/input/regression/midi/ -I ./out-test -I /home/adam/music/software/lilypond.git/input -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation/snippets -I /home/adam/music/software/lilypond.git/input/regression/ -I /home/adam/music/software/lilypond.git/Documentation/included/ -I /data/music/software/lilypond.git/build/mf/out/ -I /data/music/software/lilypond.git/build/mf/out/ -I /home/adam/music/software/lilypond.git/Documentation/pictures -I /data/music/software/lilypond.git/build/Documentation/pictures/./out-test --process='/data/music/software/lilypond.git/build/out/bin/lilypond -I /home/adam/music/software/lilypond.git/input/regression/midi/ -I ./out-test -I /home/adam/music/software/lilypond.git/input -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation/snippets -I /home/adam/music/software/lilypond.git/input/regression/ -I /home/adam/music/software/lilypond.git/Documentation/included/ -I /data/music/software/lilypond.git/build/mf/out/ -I /data/music/software/lilypond.git/build/mf/out/ -I /home/adam/music/software/lilypond.git/Documentation/pictures -I /data/music/software/lilypond.git/build/Documentation/pictures/./out-test -dbackend=eps --formats=ps -dseparate-log-files -dinclude-eps-fonts -dgs-load-lily-fonts --header=texidoc -I /home/adam/music/software/lilypond.git/Documentation/included/ -ddump-profile -dcheck-internal-types -ddump-signatures -danti-alias-factor=1' --output=./out-test --format=texi --skip-png-check --use-source-file-names --lily-output-dir /data/music/software/lilypond.git/build/out/lybook-testdb out-test/collated-files.tely langdefs.py: warning: lilypond-doc gettext domain not found. lilypond-book.py (GNU LilyPond) 2.15.17 Reading out-test/collated-files.tely... Running texi2pdf on file /tmp/tmpJvVxHS.texi to detect default page settings. Dissecting...lilypond-book.py: error: file not found: out-test/key-initial-midi.ly make[3]: *** [out-test/collated-files.texi] Error 1 make[3]: Leaving directory `/data/music/software/lilypond.git/build/input/regression/midi' make[2]: *** [local-test] Error 2 make[2]: Leaving directory `/data/music/software/lilypond.git/build/input/regression/midi' make[1]: *** [test] Error 2 make[1]: Leaving directory `/data/music/software/lilypond.git/build' make: *** [test-redo] Error 2 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patches for LilyPond issues 1503 and 1572
Hi Janek, Just a quick note to say that I've started work on this again. I'll be in touch again when I've made some progress. 2011/9/10 Janek Warchoł : > Hi Adam, > > 2011/9/10 Adam Spiers : >> Sorry Janek, I did receive the email but I've been away travelling for >> 3 months and only just got back. > > No problem! I was afraid that your disappearance meant that you lost > interest in these patches. > >> I would be glad to work with you on >> getting these patches finalised and submitted, although please bear >> with me over the next few days as I have some other pressing issues to >> attend to first. > > Of course, there's no rush. > >> I think the best way would be if I help you with github because it's >> an absolutely beautiful service and IMHO much nicer than emailing >> patches once you get used to it. If you haven't already done so, >> please try adding my github repository to your own as a remote: >> >> git remote add aspiers git://github.com/aspiers/lilypond.git >> >> and then simply fetch or pull the commits from my remote branch: >> >> git fetch aspiers master >> >> or: >> >> git pull aspiers master >> >> (pull is equivalent to fetch followed by a merge into your current >> branch). >> >> Let me know how you get on (but please be patient if I don't reply >> quickly!) > > Done - it was amaznigly painless! > > Uploaded to Rietveld: http://codereview.appspot.com/4981052/ > > One thing: please follow these guidelines concerning commit messages: > http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#commit-messages > I've changed the messages in my repository; i don't know if this > change can cause incompatibilities between our repositories, but if it > does (and we need to be compatible because the patches will probably > have some revisions which i will also have to upload) i attach patch > files created from my repository. > > thanks, > Janek > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patches for LilyPond issues 1503 and 1572
Sorry Janek, I did receive the email but I've been away travelling for 3 months and only just got back. I would be glad to work with you on getting these patches finalised and submitted, although please bear with me over the next few days as I have some other pressing issues to attend to first. I think the best way would be if I help you with github because it's an absolutely beautiful service and IMHO much nicer than emailing patches once you get used to it. If you haven't already done so, please try adding my github repository to your own as a remote: git remote add aspiers git://github.com/aspiers/lilypond.git and then simply fetch or pull the commits from my remote branch: git fetch aspiers master or: git pull aspiers master (pull is equivalent to fetch followed by a merge into your current branch). Let me know how you get on (but please be patient if I don't reply quickly!) Thanks, Adam 2011/8/22 Janek Warchoł : > Hi Adam, > > apparently you didn't receive my previous e-mail, so i'm writing again. > I'd like to help you with your patches about jazz chords display > (issue 1503, and also you said that you have some patches for 1572). > It looks like they are being overlooked. We should upload them to > Rietveld so that te development team will review them; could you send > me the patch files? I tried downloading them from github, but i'm > unfamiliar with it and got lost. > > thanks for your work, > Janek > > 2011/7/29 Janek Warchoł : >> Hi Adam, >> >> On Thu, Jul 28, 2011 at 08:41:31AM, adam.spi...@gmail.com wrote: >>> Patches are available here, although some are still a work in progress: >>> https://github.com/aspiers/lilypond/commits/master >> >> could you send me patch files directly? I've never used github and i >> must admit that i'm lost... Also, i'm not sure what should be >> uploaded. >> If you'd like, i can help you upload these patches yourself, it's not >> hard (the main problem is how to escape the vi-trap that other people >> set for us ;P). >> Are you using Lilydev? >> >> thanks for your work! >> Janek > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
