undo without force mode

[Volker Annuss]

Hi Harm Geert,

I just played some games on your ICS-Server with winboard 4.2.CCT12 (and had the same effect today with Version 4.4.1)

For some reason winboard wants Hermann to take back his first move. Hermann is not in force mode but in ponder mode, so the undo is ignored and the game does not start.

I can see some missing pong's in the winboard.debug file, but I don't think Hermann has dropped them.

BTW, the last game against CraftyRB on your server ended with a K-KBN endgame.

Greetings
Volker

GameEnds(38, CraftyRB resigns, 0)
4179279 >first : result 0-1 {CraftyRB resigns}
silence
4179279 >first : force
4179279 >first : ping 8
>ICS: gameend\012
>ICS: \012
Reset(1, 1) from gameMode 11
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
4179279 >first : new
random
4179279 >first : post
4179279 >first : hard
4179279 >first : ping 9
<ICS: gameend: Command not found.\012\015fics%
ics input 0, castling = 7 0 4 7 0 4
<ICS: fics%
ics input 0, castling = 7 0 4 7 0 4
>ICS: match Zappa 5 1 black\012
<ICS: Issuing: Hermann (1828) [black] Zappa (1962) rated blitz 5 1.\012\015Your blitz rating will change: Win: +11, Draw: +3, Loss: -5\012\015Your new RD will be 53.1\012\015fics%
ics input 0, castling = 7 0 4 7 0 4
<ICS: \012\015Zappa accepts your challenge.\012\015fics% \012\015Creating: Zappa (1962) Hermann (1828) rated blitz 3000 10\012\015\012\015{Game 1 (Zappa vs. Hermann) Creating rated blitz match.}\012\015\012\015<12> rnbqkbnr pppppppp -------- -------- -------- -------- PPPPPPPP RNBQKBNR W -1 1 1 1 1 0 1 Zappa Hermann -1 5 1 39 39 300 300 1 none (0:00) none 1 0\012\015\012\015\015fics% \012\015<12> rnbqkbnr pppppppp -------- -------- ----P--- -------- PPPP-PPP RNBQKBNR B 4 1 1 1 1 0 1 Zappa Hermann 1 5 1 39 39 300 300 1 P/e2-e4 (0:00) e4 1 0\012\015\012\015\015fics% \012\015Zappa(1962) kibitzes: !!! +0.00/63 (0.00 sec, 0 nodes, 0 knps) PV=1. e2-e4\012\015fics%
ics input 0, castling = 7 0 4 7 0 4
Ratings from 'Creating:' Zappa 1962, Hermann 1828
recognized 'rated blitz match.' (-1) as variant normal
Parsing board: rnbqkbnr pppppppp -------- -------- -------- -------- PPPPPPPP RNBQKBNR W -1 1 1 1 1 0 1 Zappa Hermann -1 5 1 39 39 300 300 1 none (0:00) none 1 0

recognized 'ICS rated blitz match' (-1) as variant normal
ParseBoard says variant = 'ICS rated blitz match'
recognized as normal
Remembered ratings: W 1962, B 1828
load 8x8 board
4214254 >first : level 0 5 1
4214254 >first : name Zappa
4214254 >first : rating 1828 1962
Display title 'Zappa(39) Hermann(39) {5 1}, gameInfo.variant = 0'
Parsing board: rnbqkbnr pppppppp -------- -------- ----P--- -------- PPPP-PPP RNBQKBNR B 4 1 1 1 1 0 1 Zappa Hermann 1 5 1 39 39 300 300 1 P/e2-e4 (0:00) e4 1 0

load 8x8 board
parseboard 1, castling = 7 0 4 7 0 4
accepted move e4 from ICS, parse it.
moveNum = 1
board = 0-8 x 8
move to parse: e4
Move parsed to 'e4 (0:00)'
time odds: 1.000000 1.000000
4214270 >first : time 30000
4214270 >first : otim 30000
book hit = (NULL)
4214270 >first : usermove 4214270 >first : e2e4
Display title 'Zappa(39) Hermann(39) {5 1}, gameInfo.variant = 0'
silence
4215534 <first : move c7c5
Undoing extra move from first, gameMode 13
4215534 >first : undo

[H.G.Muller]

Why do you think Hermann did not drop the pongs? Unless you set /engineDebugOutput=0 WinBoard should print everything it gets from the engine in the debug file. And it should print received pongs under any setting.

What happens is exactly what should happen if WinBoard has not received all pongs yet. It assumes the move is from the previous game, because it has not even received the pong in response to the pingfrom before the 'new' command. So it assumes Herman has not yet processed that 'new' command. Apparently Hermann had done the last move of the previous game, so this would then be an out-of-turn move in that game, which WinBoard habitually undoes. This is all consistent with not having received the pongs, even apart from the printing of them.

I guess that in a situation like this WinBoard assumes the program is already in force mode, because it has sent it a 'force' command before. Not sure though how you can receive a 'new' without first responding to the "ping 8". This might be a zippy bug. Zippy likes to start games early, to allow the engine to initialize before an actual challenge comes in. Perhaps it does so without paying attention to pong status. I will check that out.

[Volker Annuss]

Why do you think Hermann did not drop the pongs?

Because Hermann reads input line by line and whenever he gets a ping, it is immediately answered with a pong. The code ist quite simple. Nevertheless I will insert some logging code into Hermann and see what happens.

[H.G.Muller]

That sounds very bad. You are not supposed to repond immediately to a ping, that would depend the very purpose of it. You would only have to delay the respons to when all previously given commands have been executed to completion. E.g. on 'new' after cleaing the hash table and loading any tablebases.

[Volker Annuss]

So I have to correct that. My implementation is definitely wrong with "?" immediately followed by "ping", but I see no problem with "force\nping" or "new\n post\nhard\nping" as long as the engine does not send an error message for one of these commands after sending pong.

[Michel]

That sounds very bad. You are not supposed to repond immediately to a ping, that would depend the very purpose of it. You would only have to delay the respons to when all previously given commands have been executed to completion. E.g. on 'new' after cleaing the hash table and loading any tablebases.

This is true in principle but it means that the engine would become unresponsive if xboard would send a ping during searching (since it would only be allowed to reply to the ping after the search is completed and consequently it would have to queue all other commands).

xboard perhaps doesn't send pings while the engine is searching but other gui's might as I don't think it is forbidden by the xboard protocol.

So PG replies immediately to pings, even when searching. I now do the same in GnuChess.

[H.G.Muller]

That is wrong. WinBoard sends the ping for no other reason than to know when the search is finish. If the engine cannot abort a search, it should wait with the pong, to make WinBoard wait for it. If not, WinBoard might start the clock for a new game while the engine is still searching on the old game.

[Michel]

That is wrong. WinBoard sends the ping for no other reason than to know when the search is finish. If the engine cannot abort a search, it should wait with the pong, to make WinBoard wait for it. If not, WinBoard might start the clock for a new game while the engine is still searching on the old game.

Hmm are you saying that the engine should preferably abort a search after ping (at the risk of sending a bad move)? This is not clear at all
from the way the protocol is written.

As I said, not stopping the search leads to an unresponsive engine (at longer time controls) which makes a very amateurish impression.

[H.G.Muller]

No, that is not what I am saying. What I say is that it should _wait_ sending the pong until the search is finished. Although I don't think that WinBoard would ping the engine unless it has no business thinking anymore. (E.g. because the opponent resigned.) After ? (move now) WB would send ping to be sure it will only continue with other commands after the engine is done searching, even if it does not implement move now.

As I said, not stopping the search leads to an unresponsive engine (at longer time controls) which makes a very amateurish impression.

Indeed, but this is an engine problem. An engine that cannot abort its search is amateurish. The GUI cannot help that. Making engines lose on time in the next game, because you start their clock too early, or forfeiting them for an illegal move while they were perfectly following protocol (albeit amateurishly tardy) does look even more amateurish. With the difference that in that case it would be the GUI's / adapter's fault...

[Michel]

No, that is not what I am saying. What I say is that it should _wait_ sending the pong until the search is finished.

Indeed, but this is an engine problem. An engine that cannot abort its search is amateurish.

So what is it then? Should it complete or abort the search after ping?

Note this is NOT an engine problem. If you don't abort the search after ping and you do

ping
quit

while searching the engine is not allowed to react to the quit command until the search is over. I don't like
it if an engine does not react to quit at all times.

EDIT: Unless of course if after receiving ping the engine would be allowed to process commands before sending pong.
The description of ping does not seem to say if this is allowed or not (there are other commands that could be sensibly
sent during search such as easy, hard, post,...).

[H.G.Muller]

I don't think WinBoard sends ping before it sends quit. A GUI should only do that if it was designed to not terminate the engine while the search is in progress. And then an engine should not try to subvert that design.

I get the impression that ping is mainly used in XBoard to solve the problem of undefined behavior when a searching engine receives a force command. Many engines would not even read the command before they finished the search and printed a the move they found, but others abort the search. The latter behavior is actually the intended one, e.g. when you are in Two-Machines mode (so that always one engine is thinking) and want to interrupt the game by switching to Edit-Game mode. WinBoard switches to Edit Game with the current game position in the display, but the searching engine might still or might not produce a move. If such a move comes in, it will be undone.

But the user might switch from Edit Game to a mode that again requires the engine, e.g. click New Game and make it the engines turn (Two Machines, Mchine White or doing a move). If the engine would still be searching, its clock is now running, and its move might be accepted for the new game. So WB pings it after the force, to be abe to distinguish if the next move it will get is a resut of the interrupted search, or of any command given after the ping.

[Tim Mann]

Very late reply:

ping is used primarily (maybe only, I don't remember) to deal with a situation where we have asked the engine to stop searching (with force, maybe also with "?") and we aren't 100% sure whether the engine will send a move before it stops searching. In the force case, there is a race: the engine might have finished searching and sent us a move at the same time we wanted to stop the search with "force". So it was not feasible for the protocol to say that "force" must immediately stop the search without generating a move. On the other hand, the engine might see the "force" and stop the search cleanly without making a move, so the protocol doesn't specifiy that the engine must always send a move.

Therefore, if you get "ping" while searching, you should not send "pong" until you've stopped the search. If stopping the search results in making a move, the move must be sent before the pong.

HG is also correct that if you can't stop the search immediately, you must not send "pong" until you do stop it, because we don't (for example) want to try to start a new game and start the engine's clock while it is still hung up searching some move in a previous game.

Basically, the protocol here is designed to be straightforward. The engine should handle and respond to commands in order, never out of order. One simple way to handle this: if you get any command while searching, no matter what it is, stop the search before processing that command or reading any further commands. It's OK for stopping the search this way to cause a move to be made. I'm sure some engines do things this way (or at least they used to last time I looked), and the protocol was designed to make that legal.