Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
Hello, On Fri, Sep 23, 2011 at 8:59 AM, Graham Percival wrote: > On Fri, Sep 23, 2011 at 09:55:26AM +0200, David Kastrup wrote: >> I am somewhat surprised that the patch passed testing by someone else, >> though. It would seem that doc builds are not part of that. > > I think that James only does a normal make and make check; Yes that is correct - I just follow the CG for reg test checking but add the make test too. > that's > doable in 3 minutes on his computer, rather than the horrible wait > of 30 minutes or something for a complete "make doc" from scratch. a full Make doc takes about 15 minutes and I don't mind doing that if it saves someone 3 hours (like Mr Kainhofer), but obviously I can't make doc on all patches else i'd get through about 2 a day with the make check as well and do nothing else. I've done plenty of make docs if asked to help the project (put it in the tracker / Rietveld specifically stated you'd like a make doc and set the tracker to patch-new) and sometimes I will do a make doc if *I* think it might need one even if not asked - for instance if someone does something to the tely/texi of lilypond-book files. I just don't have the knowledge to recognize when something in a .cc or other file (like David's code changes) is a significant risk to break the doc build - as ANY checkin could break a doc build potentially. So I just need guidance and some patience on the submitter's behalf in case I have other things to do first. I tend to test FIFO but may defer as I also need to get some of the doc issues done too :) -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
Reinhold Kainhofer writes: > On Fr., 23. Sep. 2011 09:55:26 CEST, David Kastrup wrote: >> I am somewhat surprised that the patch passed testing by someone else, >> though. It would seem that doc builds are not part of that. > > Nope, because it's the regtetsts' task, so only the regtests are > checked. It's also a practical issue: On my machine a regtest run > takes ~20 minutes, while a docs build takes about 3 hours, so it's > impossible to check the docs build for every patch. > > If a regtest run succeeds, but a docs build fails, that's basically a > bug in our regtests (and we have many missing regtests still). In the current situation with the optional music function patch, there is clearly buggy code in the documentation itself (or rather: it calls functions in a way that is documented but not supported). So this is something that can't be spotted with regtests, but only with a documentation build. > That's also why it's so important to have a proper regtest for each > new feature. It would not have helped at all here. For "make all", I already added commit 31e79fa5f9d1b1af03ca3fc29ce049b39b485529 Author: David Kastrup Date: Tue Sep 20 22:28:08 2011 +0200 define-markup-commands.scm: Fix bad parameter type for \on-the-fly some time ago, again since it had been exposed by the better type-checking. I have been considering changing \with-link to use string-or-symbol? and thus get the argument accepted. However, \label is clearly documented as taking a symbol, so this is more likely a problem with the caller, autogenerated code in the documentation. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
On Fr., 23. Sep. 2011 09:55:26 CEST, David Kastrup wrote: > I am somewhat surprised that the patch passed testing by someone else, > though. It would seem that doc builds are not part of that. Nope, because it's the regtetsts' task, so only the regtests are checked. It's also a practical issue: On my machine a regtest run takes ~20 minutes, while a docs build takes about 3 hours, so it's impossible to check the docs build for every patch. If a regtest run succeeds, but a docs build fails, that's basically a bug in our regtests (and we have many missing regtests still). That's also why it's so important to have a proper regtest for each new feature. Cheers, Reinhold ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
David Kastrup writes: > Here is the problem: \with-link declares its argument type wrong > (declares symbol? and uses #"label", a string). My patch has the > side-effect that markup commands actually check their argument lists for > correctness. Previously it just let any Scheme argument through > completely unchecked. Worse. All regtests employ symbols, the docstring gives an example with a string, and autogenerated code uses a string. Whatever. I am not taking the blame and pressure for fixing everybody else's bugs timely, so I am simply reverting the whole merge commit. I'll see whether it is feasible to prepare a separate patch that just does the typechecking and nothing else, then people can clean up the current Lilypond code base without bothering about the rest. > Now I could revert my branch merge, or I could prepare a patch that > stops type-checking the argument lists to markup commands, but I think > it is saner if we grit our teeth and just fix the previously unnoticed > bugs as they get exposed. Obviously not. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
On Fri, Sep 23, 2011 at 09:55:26AM +0200, David Kastrup wrote: > I am somewhat surprised that the patch passed testing by someone else, > though. It would seem that doc builds are not part of that. I think that James only does a normal make and make check; that's doable in 3 minutes on his computer, rather than the horrible wait of 30 minutes or something for a complete "make doc" from scratch. Once this latest round of breakage is fixed, would you PLEASE seriously consider pushing stuff to a dev/staging branch, and let either James or me merge that with master when it passes a full make doc from scratch? I've lost count of how many times master has broken in the past two months. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
David Kastrup writes: > Peekay Ex writes: > >> Hello again.. >> >> On Fri, Sep 23, 2011 at 5:34 AM, Peekay Ex wrote: >>> Hello, >>> >>> On Fri, Sep 23, 2011 at 3:46 AM, Reinhold Kainhofer >>> wrote: Am Friday, 23. September 2011, 04:35:06 schrieben Sie: > > fatal error: failed files: "be/lily-48175def.ly" > > A decent build system would take that filename, grep it for > "\sourcefilename", and tell us *that* information, instead of the > current useless output. :) >> >> I used gitk to roll back the head to David's first branch merge >> >> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=31dc6e0a1b454c1186052f36cfac3e2e7c20325e >> >> and a full make doc (from a fresh build dir) worked fine. >> >> So the issue, by deduction, is somewhere in his second merged branch >> (Merge branch 'musicfunction-optional-arguments' - >> 83055a30e52c14b0fd49d6df3eb1c7af476ecb4b) and/or onwards. >> >> Hope that helps. >> >> Sorry David :( > > Would have been too lucky. Sigh. Looks like the rebasing managed to > make a non-working version out of several working (and regtest passing) > patches. > > I'll try fixing this in the next hour, otherwise I am going to revert. > Documentation is in the queue close to be checked in, specific regtests > will follow. Here is the problem: \with-link declares its argument type wrong (declares symbol? and uses #"label", a string). My patch has the side-effect that markup commands actually check their argument lists for correctness. Previously it just let any Scheme argument through completely unchecked. Now I could revert my branch merge, or I could prepare a patch that stops type-checking the argument lists to markup commands, but I think it is saner if we grit our teeth and just fix the previously unnoticed bugs as they get exposed. Sorry about that. I am fixing the one with \with-link in the next 15 minutes. Given my slow computer, it might help if others do the regtest runs after that. I am somewhat surprised that the patch passed testing by someone else, though. It would seem that doc builds are not part of that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
Peekay Ex writes: > Hello again.. > > On Fri, Sep 23, 2011 at 5:34 AM, Peekay Ex wrote: >> Hello, >> >> On Fri, Sep 23, 2011 at 3:46 AM, Reinhold Kainhofer >> wrote: >>> Am Friday, 23. September 2011, 04:35:06 schrieben Sie: > fatal error: failed files: "be/lily-48175def.ly" A decent build system would take that filename, grep it for "\sourcefilename", and tell us *that* information, instead of the current useless output. :) > > I used gitk to roll back the head to David's first branch merge > > http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=31dc6e0a1b454c1186052f36cfac3e2e7c20325e > > and a full make doc (from a fresh build dir) worked fine. > > So the issue, by deduction, is somewhere in his second merged branch > (Merge branch 'musicfunction-optional-arguments' - > 83055a30e52c14b0fd49d6df3eb1c7af476ecb4b) and/or onwards. > > Hope that helps. > > Sorry David :( Would have been too lucky. Sigh. Looks like the rebasing managed to make a non-working version out of several working (and regtest passing) patches. I'll try fixing this in the next hour, otherwise I am going to revert. Documentation is in the queue close to be checked in, specific regtests will follow. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
Hello again.. On Fri, Sep 23, 2011 at 5:34 AM, Peekay Ex wrote: > Hello, > > On Fri, Sep 23, 2011 at 3:46 AM, Reinhold Kainhofer > wrote: >> Am Friday, 23. September 2011, 04:35:06 schrieben Sie: >>> > fatal error: failed files: "be/lily-48175def.ly" >>> >>> A decent build system would take that filename, grep it for >>> "\sourcefilename", and tell us *that* information, instead of the >>> current useless output. :) I used gitk to roll back the head to David's first branch merge http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=31dc6e0a1b454c1186052f36cfac3e2e7c20325e and a full make doc (from a fresh build dir) worked fine. So the issue, by deduction, is somewhere in his second merged branch (Merge branch 'musicfunction-optional-arguments' - 83055a30e52c14b0fd49d6df3eb1c7af476ecb4b) and/or onwards. Hope that helps. Sorry David :( -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
Hello,
On Fri, Sep 23, 2011 at 3:46 AM, Reinhold Kainhofer
wrote:
> Am Friday, 23. September 2011, 04:35:06 schrieben Sie:
>> > fatal error: failed files: "be/lily-48175def.ly"
>>
>> A decent build system would take that filename, grep it for
>> "\sourcefilename", and tell us *that* information, instead of the
>> current useless output. :)
>
> A decent build system (or rather lilypond itself) would have already printed
> out the correct file name, and it would automatically display the error
> message, which should have appeared on stderr anyway.
>
This is the file that is failing:
--snip--
%% Generated by lilypond-book.py
%% Options: [exampleindent=10.16\mm,indent=0\mm,line-width=160\mm,quote]
\include "lilypond-book-preamble.ly"
%
% Start cut-&-pastable-section
%
\paper {
indent = 0\mm
line-width = 160\mm
line-width = 160\mm - 2.0 * 10.16\mm
% offset the left padding, also add 1mm as lilypond creates cropped
% images with a little space on the right
line-width = #(- line-width (* mm 3.00) (* mm 1))
}
\layout {
}
%
% ly snippet:
%
\sourcefileline 3228
\markup {
\with-link #"label" {
\italic { This links to the page containing the label... }
}
}
%
% end ly snippet
%
--snip--
--
--
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
Am Friday, 23. September 2011, 04:35:06 schrieben Sie: > > fatal error: failed files: "be/lily-48175def.ly" > > A decent build system would take that filename, grep it for > "\sourcefilename", and tell us *that* information, instead of the > current useless output. :) A decent build system (or rather lilypond itself) would have already printed out the correct file name, and it would automatically display the error message, which should have appeared on stderr anyway. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
On Fri, Sep 23, 2011 at 03:35:26AM +0200, Reinhold Kainhofer wrote: > While we are at it: the docs compilation failed tonight... Thanks! > Unfortunately, the output does not give any error message, so I have no idea > what is wrong. Well, the output contains this: ... > fatal error: failed files: "be/lily-48175def.ly" A decent build system would take that filename, grep it for "\sourcefilename", and tell us *that* information, instead of the current useless output. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
While we are at it: the docs compilation failed tonight... Unfortunately, the output does not give any error message, so I have no idea what is wrong. Cheers, Reinhold -- Weitergeleitete Nachricht -- Betreff: GDP Docs compilation FAILED (2011.09.23-03:32) Datum: Friday, 23. September 2011, 03:32:10 Von: Lilypond developmen An: reinh...@fam.tuwien.ac.at possibilities for six: (six sixT sixRT sixTR sixR sixRT1q six1qTR sixRT1h six1hTR sixRT3q six3qTR sixRTF sixFTR six1qT sixT1q six1q six1qT1h six1hT1q six1qT3q six3qT1q six1qTF sixFT1q six1hT sixT1h six1h six1hT3q six3qT1h six1hTF sixFT1h six3qT sixT3q six3q six3qTF sixFT3q sixFT sixF) lh possibilities for high-e: (high-e high-eT) possibilities for high-ees: (high-ees high-eesT) possibilities for ees: (ees eesT) possibilities for cis: (cis cisT) possibilities for low-bes: (low-bes low-besT) possibilities for low-b: (low-b low-bT) possibilities for low-c: (low-c low-cT) possibilities for low-d: (low-d low-dT) possibilities for d: (d dT) possibilities for c: (c cT) possibilities for thumb-cis: (thumb-cis thumb-cisT) rh possibilities for bes: (bes besT) possibilities for f: (f fT) possibilities for fis: (fis fisT) possibilities for gis: (gis gisT) possibilities for thumb-bes: (thumb-bes thumb-besT) possibilities for thumb-e: (thumb-e thumb-eT) possibilities for thumb-fis: (thumb-fis thumb-fisT) Printing keys in verbose mode for: flute cc possibilities for one: (one oneT oneRT oneTR oneR oneRT1q one1qTR oneRT1h one1hTR oneRT3q one3qTR oneRTF oneFTR one1qT oneT1q one1q one1qT1h one1hT1q one1qT3q one3qT1q one1qTF oneFT1q one1hT oneT1h one1h one1hT3q one3qT1h one1hTF oneFT1h one3qT oneT3q one3q one3qTF oneFT3q oneFT oneF) possibilities for two: (two twoT twoRT twoTR twoR twoRT1q two1qTR twoRT1h two1hTR twoRT3q two3qTR twoRTF twoFTR two1qT twoT1q two1q two1qT1h two1hT1q two1qT3q two3qT1q two1qTF twoFT1q two1hT twoT1h two1h two1hT3q two3qT1h two1hTF twoFT1h two3qT twoT3q two3q two3qTF twoFT3q twoFT twoF) possibilities for three: (three threeT threeRT threeTR threeR threeRT1q three1qTR threeRT1h three1hTR threeRT3q three3qTR threeRTF threeFTR three1qT threeT1q three1q three1qT1h three1hT1q three1qT3q three3qT1q three1qTF threeFT1q three1hT threeT1h three1h three1hT3q three3qT1h three1hTF threeFT1h three3qT threeT3q three3q three3qTF threeFT3q threeFT threeF) possibilities for four: (four fourT fourRT fourTR fourR fourRT1q four1qTR fourRT1h four1hTR fourRT3q four3qTR fourRTF fourFTR four1qT fourT1q four1q four1qT1h four1hT1q four1qT3q four3qT1q four1qTF fourFT1q four1hT fourT1h four1h four1hT3q four3qT1h four1hTF fourFT1h four3qT fourT3q four3q four3qTF fourFT3q fourFT fourF) possibilities for five: (five fiveT fiveRT fiveTR fiveR fiveRT1q five1qTR fiveRT1h five1hTR fiveRT3q five3qTR fiveRTF fiveFTR five1qT fiveT1q five1q five1qT1h five1hT1q five1qT3q five3qT1q five1qTF fiveFT1q five1hT fiveT1h five1h five1hT3q five3qT1h five1hTF fiveFT1h five3qT fiveT3q five3q five3qTF fiveFT3q fiveFT fiveF) possibilities for six: (six sixT sixRT sixTR sixR sixRT1q six1qTR sixRT1h six1hTR sixRT3q six3qTR sixRTF sixFTR six1qT sixT1q six1q six1qT1h six1hT1q six1qT3q six3qT1q six1qTF sixFT1q six1hT sixT1h six1h six1hT3q six3qT1h six1hTF sixFT1h six3qT sixT3q six3q six3qTF sixFT3q sixFT sixF) lh possibilities for bes: (bes besT) possibilities for b: (b bT) possibilities for gis: (gis gisT) rh possibilities for bes: (bes besT) possibilities for d: (d dT) possibilities for dis: (dis disT) possibilities for ees: (ees eesT) possibilities for cis: (cis cisT) possibilities for c: (c cT) possibilities for gz: (gz gzT) Success: compilation successfully completed Compiling /data/lilypond/build/Documentation/out-www/notation/wind.texi... Writing `/data/lilypond/build/Documentation/out-www/notation/wind.texi'... Processing include: notation/chords.itely Reading /data/lilypond/lilypond/Documentation/notation/chords.itely... Dissecting... Writing snippets... Processing... Running lilypond... Forking into jobs: (9702 9701) Success: compilation successfully completed Compiling /data/lilypond/build/Documentation/out-www/notation/chords.texi... Writing `/data/lilypond/build/Documentation/out-www/notation/chords.texi'... Processing include: notation/contemporary.itely Reading /data/lilypond/lilypond/Documentation/notation/contemporary.itely... Dissecting... Writing snippets... All snippets are up to date... Compiling /data/lilypond/build/Documentation/out- www/notation/contemporary.texi... Writing `/data/lilypond/build/Documentation/out- www/notation/contemporary.texi'... Processing include: notation/ancient.itely Reading /data/lilypond/lilypond/Do
