Re: Patch-testing-problem

[James]

Hello,

On 30 September 2012 16:06, Thomas Morley <address@hidden> wrote:
...

>>> Please see 
>>> /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log
>>>
>>> make[2]: *** [out-test/collated-files.texi] Error 1
>>> make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
>>> make[1]: *** [local-test] Error 2
>>> make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression'
>>> make: *** [test] Error 2
>>> %%%%%%%%%%%%%%%%
>>>
>>> Looking at:
>>>  
>>> /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log
>>>
>>> The file contains nothing else than:
>>> GNU LilyPond 2.17.4
>>>
>>>
>>> Obviously I did sth wrong and again I've no clue what and how to proceed.
>>
>> Why do you think you did something wrong?
>
> Well, I'm still a newbie with this kind of tasks.
> If sth crashes my first thought is, damn, what did _I_ wrong.
>
>> That was exactly what I got when I tested the patch originally.
>>
>> You need to find the problem of why it failed to compile.
>>
>> See
>>
>> http://code.google.com/p/lilypond/issues/detail?id=2790#c33
>>
>> Did you get the same problem?
>
> I couldn't comprehend your own work.

The problem is that not all errors are the same - I am no expert but
after testing patches for the last year or so, you get a feel for this
I guess. Phil's work (et al) has helped simplify the log, but if you
see

http://code.google.com/p/lilypond/issues/detail?id=2790#c16

for instance, this was a differnet kind of failure and was easy to
spot simply because the log file references did point to a .ly file.

This instance here is different and so it was trickier to follow the
chain, in fact I couldn't. Phil's suggestion of looking at the latest
file generated is a good one, but I simply use basic grep commands

grep -r -C 10 "Error"

for instance, in the top level of the build dir.

I get a ton of hits, but the -C makes it easy to see if the return is
just a comment of the string 'Error' or a function call, rather than a
log file.

The trick here is to know the error message being generated in the log
file, "fatal" is one, or you can just do "Processing files" and the -C
gives you a few lines above and below so you can see a completed file
or an error.

> But after typing 'make check' the first two lines the terminal returns are:

>
> For tracking crashes: use
>
>         grep sourcefilename `grep -L systems.texi
> out/lybook-testdb/*/*log|sed s/log/ly/g`

I can't comment on that but it seems awfully complicated.

>
> Trying to enter this (in the build-directory) returns:
> \sourcefilename
> "/home/harm/lilypond-git/input/regression/instrument-name-volta.ly"
>
> This is exactly the file Marc mentioned here:
> http://codereview.appspot.com/6498052/#msg13

OK but that ly file will also occur in a snippet*.log file. So you can
cross reference I guess but that would need another grep search.

I guess I am just used to looking at lines and lines of output to use
a simpler grep command, but not all crashes/compilation failures are
the same and don't generate the same error messages even if the
initial crash message looks the same.

At least from my experience.

However the offending log file *will* contain the error message (as if
you had run lilypond-book on the individual snippet)

Hence my comment

--snip--
lily-7dccbf09.log:programming error: number of pages is out of bounds
lily-7dccbf09.log:programming error: tried to space systems on a bad
number of pages
lily-7dccbf09.log:programming error: number of pages is out of bounds
lily-7dccbf09.log:programming error: tried to space systems on a bad
number of pages
--snip--

The file 'lily-7dccbf09.log' contained the error message (from the
grep command) and also in that log was the name of the snippet.

James

James