regress.pike -d0xTOP_MOVE ninestones:630 gives weird output

[alain]

regress.pike seems to do extra job after having given the answer. This does not seem to happen for others tests.

./regress.pike -v -e "/usr/local/bin/gnugo" \
                -o "--mode gtp -d0x400000" ninestones:630

Top moves:
1. F5  75.87
2. B11 72.31
3. G16 16.92
4. J14 14.21
5. O13 10.73
6. F18 8.75
7. G15 8.55
8. S13 7.99
9. H14 7.99
10. O15 7.82
ninestones:630  pass F5 [F5|H7]

Top moves:
1. A4  41.01
2. N9  21.23
3. H9  19.47
4. O7  13.95
5. C1  12.80
6. C8  11.20
7. C10 8.53
8. P11 7.00
9. K8  6.65
10. C12 6.37

Top moves:
1. E6  138.03
2. F7  133.35
3. H7  102.08
4. G7  91.73
5. H8  78.00
6. G8  73.90
7. J7  68.83
8. C1  42.20
9. C8  29.20
10. D1  28.97

Top moves:
1. C8  41.01
2. N9  21.23
3. H9  17.96
4. H8  17.33
5. H7  15.62
6. O7  13.95
7. D8  8.84
8. G8  8.82
9. G7  8.63
10. E10 8.08
ninestones                              15.22   3167312    7453    35437
Total nodes: 3167312 7453 35437
Total time: 15.22 (29.22)
Total uncertainty: 0.00

[arend]

To debug problems like this, use the 'gtp-dump-commands <file>' option of GNU Go.

What happens is that regress.pike is replaying all the reg_genmove commands preparing the ninestones:670 test later on. One could argue that regress.pike should stop as soon as it has reached the relevant line for the 630 test, but that's hardly an urgent problem.

[alain]

tiny patch. In the test file, some reg_genmove does not correspond to a test/answer, and are always executed, even if only one test is aked for.

[gunnar]

I don't see any value in adding dummy tests. Regress.pike doesn't have any actual problem with unnumbered reg_gemoves. To see move values for a given test I recommend trying out view.pike instead.

The reason why regress.pike doesn't stop immediately after the 630 test command is that for testcases like trevor:262

loadsgf games/trevor/trevor_26.sgf 33
trymove black C1
trymove white C2
trymove black F1
262 defend C2
#? [0]
popgo
popgo
popgo

the popgo commands must be run to get the engine back into a proper state for (possible) later tests. The policy is that unnumbered commands are always run, to guarantee as well as possible against surprises.