Il giorno dom, 02/09/2012 alle 15.31 +0100, James ha scritto: > I run ./test-patchy.py as normal. [snip] > If I look in the *.ly file corresponding to the log I get this: > > --snip-- > jlowe@jlowe26vm /tmp/show-2801/out$ more > /tmp/show-2801/out/lybook-testdb/snippet-names-892580628.ly > > snippet-map-892580628.ly > 84/lily-0f7c4871.ly > aa/lily-4858d0b7.ly > 0f/lily-cdc1d94e.ly > 8b/lily-ee7f7e54.ly > 53/lily-64dfb2d0.ly > b2/lily-1922a761.ly > de/lily-4483657e.ly > 3c/lily-14a6ed53.ly > ae/lily-838f2675.ly > > ... [lots more lines like this] > > b0/lily-7821c23e.ly > 68/lily-12d29b6a.ly > dc/lily-5d81e32b.ly > 8a/lily-3250e012.ly
At the end of such a file I sometimes see something like Error: failed files: () which is not very informative. Next time I reproduce it, I'll try to see where this information is generated, so we really get the input filename(s) of the failed file(s). > Now I can find all of those *.ly files but which one can I assume is > the problematic one of this list? The first one or the second one or > could it be any in between. That is does the list get appended to > before each test? You can grep for '(?<!programming )error:' (Python syntax) the 'xx/lily-xxxxxxxx.log' files for the .ly files in the list in the snippet-names-yyyyyyyyy.ly reported by lilypond-book, but this might give false positives in case not all errors cause a non-zero exit status (I doubt any non-programming error causes a zero exit status, but I wouldn't put my hand to cut on this as we say in French). > This used to be a bit easier IIRC to find the offending file, but that > may be me out of Patchy practice. Patchy could help by grepping the logs and output tails or excerpts of these. This is not the most urgent Patchy improvement to be done, but I had already thought of it so it is on my TODO. Best, John _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
