winboard exclude movelist view bug?

[F. Bluemers]

Adding the exclude /include moves feature to Dirty,I noticed that in winboard as well as xboard the "status-line" stays put ("exclude: none best tail") and does not change after adding/removing moves to exclude.
It does update using a uci engine (fruit) as (the first) engine.

Best
Fonzy

[hgm]

Are you sure it emits the 'feature exclude=1' command at startup? Polyglot does, which would explain the Fruit behavior. (Although Fruit does not support searchmoves. But there is no way for a GUI to know whether a UCI engine does.)

When WinBoard thinks the engine supports in/exclude, it should not execute moves on the board you perform with Ctrl pressed, but instead leave the piece you move also on the from-square while you drag a copy of it to the to-square, and then discard the copy when you relaese it (making the performed move appear in the statius line).

[F. Bluemers]

This is from a recent winboard debug file:

Code: Select all

752 <first &#58; 
757 <first &#58; 
757 <first &#58; feature done=0
<snip>
763 <first &#58; feature exclude=1
763 >first &#58; accepted exclude
763 <first &#58; feature option="ResetHash -button"
764 >first &#58; accepted option
<snip>
786 >first &#58; new
random
786 >first &#58; ics -
786 >first &#58; level 40 5 0
786 >first &#58; post
786 >first &#58; hard
786 >first &#58; ping 1
Impossible move , type = 0
794 <first &#58; pong 1
12941 >first &#58; force
12941 >first &#58; analyze
Impossible move , type = 0
12948 <first &#58; 1 -7 0 1 a4
12949 <first &#58; 1 2 0 3 b4
12950 <first &#58; 1 3 0 5 c4
12951 <first &#58; 1 9 0 7 d4
12952 <first &#58; 1 10 0 15 c3
12954 <first &#58; 1 23 0 18 e3
12955 <first &#58; 1 50 0 24 Nc3
<snip>
14306 <first &#58; 15 13 135 1965263 Nc3 Nf6 Nf3 Nc6 e4 d5 e5 d4 exf6 dxc3 bxc3 exf6 Be2 Bf5 O-O
14936 >first &#58; .
15465 <first &#58; 15 24 251 3657003 e4 Nc6 Nf3 Nf6 e5 Nd5 Nc3 Nxc3 dxc3 e6 Bb5 Bc5 Bg5 Be7 Bxe7
15505 >first &#58; exclude g1f3
15602 <first &#58; 15 24 265 3852586 e4 Nc6 Nf3 Nf6 e5 Nd5 Nc3 Nxc3 dxc3 e6 Bb5 Bc5 Bg5 Be7 Bxe7
16213 <first &#58; 16 24 326 4807271 e4 Nc6 Nf3 Nf6 e5 Nd5 Nc3 Nxc3 dxc3 e6 Bb5 Bc5 Bg5 Be7 Bxe7 Qxe7
16218 <first &#58; #skipping move Nf3
16484 <first &#58; 16 24 354 5216668 e4 Nc6 Nf3 Nf6 e5 Nd5 Nc3 Nxc3 dxc3 e6 Bb5 Bc5 Bg5 Be7 Bxe7 Qxe7
18439 <first &#58; 17 24 550 8126458 e4 Nc6 Nf3 e5 Nc3 Nf6 a3 Be7 Bb5 O-O O-O Nd4 Bc4 Nxf3+ Qxf3 c6 Re1 b5
18444 <first &#58; #skipping move Nf3
18609 >first &#58; exclude b1c3
18901 <first &#58; 17 24 595 8816956 e4 Nc6 Nf3 e5 Nc3 Nf6 a3 Be7 Bb5 O-O O-O Nd4 Bc4 Nxf3+ Qxf3 c6 Re1 b5

Best
Fonzy

[hgm]

I guess the problem is that WinBoard only updates the status line at the start of a new search. UCI engines can only exclude other moves when you do start a new search. The WB protocol spec of in/exclude allows the engine to continue the existing search after an 'exclude', and Dirty uses this method.

I guess I will have to add some code to substitute the status line for another immediately, when the exclude status changes.

[F. Bluemers]

I guess the problem is that WinBoard only updates the status line at the start of a new search. UCI engines can only exclude other moves when you do start a new search. The WB protocol spec of in/exclude allows the engine to continue the existing search after an 'exclude', and Dirty uses this method.

I guess I will have to add some code to substitute the status line for another immediately, when the exclude status changes.

Yes,that seems to be the issue.
After I modified Dirty to restart the search after an update,
the status line gets updated too.
This works much better,also for the user analyzing,so I'll use this.
Thanks
Best
Fonzy

[hgm]

Well, I am not sure it is always better for the user. This is why I did not want to require it in the specs of the exclude command. It is conceivable that after an analysis of several hours a move surfaces which the user dislikes on strategic grounds, and which he wants to exclude from future iterations. It would be a waste if that means he has to redo the several hours of previous iterations.

So one can argure the better engine implementation is where it just continues the analysis after exclude. The GUI can always force a new search by exiting analysis mode and reentering it, and there could be a button (or a 'restart' word in the status line you could click) for the user to force that.

[F. Bluemers]

Well, I am not sure it is always better for the user. This is why I did not want to require it in the specs of the exclude command. It is conceivable that after an analysis of several hours a move surfaces which the user dislikes on strategic grounds, and which he wants to exclude from future iterations. It would be a waste if that means he has to redo the several hours of previous iterations.

So one can argure the better engine implementation is where it just continues the analysis after exclude. The GUI can always force a new search by exiting analysis mode and reentering it, and there could be a button (or a 'restart' word in the status line you could click) for the user to force that.

Another display bug : when one adds about 9 exclude moves,
Xboard (4.7) as well as xboard 4.8(gtk) appends the last pv line to the exclude-status line.
No idea about winboard,running some test there.
Best
Fonzy

[F. Bluemers]

Seems I cannot always recreate this bug.
It will look like this when it happens though:

Best
Fonzy