Ferdy wrote:If the GUI received the second bestmove 0000, it should have ignored this move, because the GUI knew that it was just testing the engine using the second stop command.
No, that is exactly the point. The GUI cannot know that. It probably sends "stop\nucinewgame\nposition FEN\ngo infinite\n" in a single print statement, and even if it didn't, because it has the CPU's attention and the engine (or at least its input thread) is stalled waiting for input and first has to conquer a CPU time slice, even if it used separate write calls it would already have finished writing them all to the pipe before the engine even sees the second 'stop', let alone before it sends the 'bestmove 0000' reply to it. So the GUI will receive the 'bestmove' after having sent the "go infinite", and it has no other choice than to believe it was a reply to it.
You cannot have a GUI wait after receiving a 'bestmove' it is expecting, based on "let's see if the engine prints some more, so we can take the last".
I agree that it is silly to send a second 'stop', but it is not forbidden. But sending spurious 'bestmove' commands is a sure way to wreck things. There are also legitimate uses of 'stop' that could lead it to arrive after the engine already stopped searching and sent 'bestmove'.
Ferdy wrote:If the GUI received the second bestmove 0000, it should have ignored this move, because the GUI knew that it was just testing the engine using the second stop command.
No, that is exactly the point. The GUI cannot know that.
ChessGUI GUI knows it.
Matthias Gemuh wrote:The delibrate "stop" before a new FEN was meant to stop any engine that may be searching "out of sync".
Matthias Gemuh wrote:The delibrate "stop" before a new FEN was meant to stop any engine that may be searching "out of sync".
Not at all. It sends an extra 'stop' for whatever reason. Some engines are compliant, and would ignore it. So the 'bestmove' they send will be the response to the following "go infinite". Other engines are non-compliant, and hiccup a spurious 'bestmove'.
So how can ChessGUI possibly know whether the 'bestmove' is spurious, or the valid reply? It seems a logical impossibility.
Ferdy wrote:If the GUI received the second bestmove 0000, it should have ignored this move, because the GUI knew that it was just testing the engine using the second stop command.
No, that is exactly the point. The GUI cannot know that.
ChessGUI GUI knows it.
Matthias Gemuh wrote:The delibrate "stop" before a new FEN was meant to stop any engine that may be searching "out of sync".
Hi Ferdinand,
I am surprised what ChessGUI knows ! Seriously, ChessGUI has no clue.
Matthias.
Matthias Gemuh wrote:The delibrate "stop" before a new FEN was meant to stop any engine that may be searching "out of sync".
You do wait for 'bestmove' before ordering a new search? Are there really engines that still search on after emitting a 'bestmove', and choke on altering the position? (If so, I don't think there is any reason to believe repeating 'stop' would help.)
I know there are engines that cannot handle commands received after 'stop', but before they printed 'bestmove'. Apparently they do not queue such commands while busy. This is why Polyglot has the SyncStop option, and in UCI2WB I always use that mode.
I was trying a sort of "hard terminate" that should not completely shutdown the engine.
Ferdy wrote:If the GUI received the second bestmove 0000, it should have ignored this move, because the GUI knew that it was just testing the engine using the second stop command.
No, that is exactly the point. The GUI cannot know that.
ChessGUI GUI knows it.
Matthias Gemuh wrote:The delibrate "stop" before a new FEN was meant to stop any engine that may be searching "out of sync".
Hi Ferdinand,
I am surprised what ChessGUI knows ! Seriously, ChessGUI has no clue.
Matthias.
After sending the first position in that test suite, Deuterium sent its bestmove after receiving the first stop command. This can be found in the output result table, and in Deuterium log.
Based from Deuterium log, ChessGUI sent another stop command before the second position. Is Deuterium log wrong here? Did ChessGUI actually sent that second stop command before sending the 2nd position?
Ferdy wrote:
After sending the first position in that test suite, Deuterium sent its bestmove after receiving the first stop command. This can be found in the output result table, and in Deuterium log.
Based from Deuterium log, ChessGUI sent another stop command before the second position. Is Deuterium log wrong here? Did ChessGUI actually sent that second stop command before sending the 2nd position?
I frankly did not consider the possibility that an engine which has not been told to search, and is thus not searching, would react to "stop searching".
Ferdy wrote:
After sending the first position in that test suite, Deuterium sent its bestmove after receiving the first stop command. This can be found in the output result table, and in Deuterium log.
Based from Deuterium log, ChessGUI sent another stop command before the second position. Is Deuterium log wrong here? Did ChessGUI actually sent that second stop command before sending the 2nd position?
I frankly did not consider the possibility that an engine which has not been told to search, and is thus not searching, would react to "stop searching".
I understand that, but I am not expecting also that a GUI would
send stop command even if the engine is already not searching, and already sent its bestmove too.
I am into these little scripts interfacing uci engines. I only sent 1 stop command to the engine for every position/go command that I sent.
I also make sure that before sending the one-time stop command, I have not received the bestmove reply from the engine. But this is easier to handle than your full GUI app.
