ChessGUI 0.245h

[Matthias Gemuh]

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.

GUIs try several weird things to help malfunctioning engines. ChessGUI, WB, Arena, cutechess-cli all do it, if it does not hurt any engine. In other words, a bit of evil is tolerated. The key is not to "overhelp" malfunctioning engines. Which of these GUIs would reject "o-o" or "0-0"(zeros) ?

[hgm]

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.

But the problem is that the fact you did not receive the 'bestmove' command does not mean the engine did not send it yet. So when you use 'stop' commands against a search that might also terminate by itself (through "go w/btime" or "go nodes"), there always is an intrinsic risk that it will arrive when the engine has already stopped searching by itself, and sent the 'bestmove' command on its way. This is why the the protocol specs are so explicit about this. It is really crucial to the viability of the protocol.

[hgm]

GUIs try several weird things to help malfunctioning engines. ChessGUI, WB, Arena, cutechess-cli all do it, if it does not hurt any engine. In other words, a bit of evil is tolerated. The key is not to "overhelp" malfunctioning engines. Which of these GUIs would reject "o-o" or "0-0"(zeros) ?

I am probably less forgiving in this respect than most. Catering to non-compliancies and bugs of other software not only guarantees the problem won't be fixed. It will also encourage new programmers to make the same mistakes. In the long run this will lead to erosion of standards and chaos, where you can never be sure what engine would work on which GUI.

Problems should be solved where they ly. The Fire developers visit here regularly. If there is a compliancy problem there we should not have a problem to get it fixed.

It is true that WinBoard alsoaccepts o-o and 00 as castling, but that is for an entirely different reason, with this as an (unfortunate?) side effect. WinBoard uses the same parser on game files as on engine moves. And the design goal is to make it possible for the user to copy-paste anything that remotely looks like a Chess game into it (e.g. from an on-line newspaper article, or a html table on a website of a browser-based Chess server.

[Ferdy]

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.

But the problem is that the fact you did not receive the 'bestmove' command does not mean the engine did not send it yet. So when you use 'stop' commands against a search that might also terminate by itself (through "go w/btime" or "go nodes"), there always is an intrinsic risk that it will arrive when the engine has already stopped searching by itself, and sent the 'bestmove' command on its way. This is why the the protocol specs are so explicit about this. It is really crucial to the viability of the protocol.

Case 1.
go infinite - In this mode the engine will wait for the gui stop command. The engine is not allowed to send bestmove. After the gui sends the stop command, the engine must stop searching and send its bestmove.

Case 2.
go wtime/btime - In playing games, the gui must wait for the bestmove of the engine.

In case 1 this is the mode where ChessGUI handles the test suite. Send the position, send go infinite. Since the engine is not allowed to stop searching, ChessGUI will send the stop command so that the engine will stop searching and send its bestmove as well. Now it is happy it received the bestmove reply from the engine. Sending again the stop command in this situation does not make any good sense, the engine had already sent the bestmove, do you agree with me?

In case 2, let the engine play its bestmove, the GUI should not interfere by sending a stop command even if the engine is about to lose on time. If after the allocated time is exceeded by this engine, the GUI will now send the stop command. If indeed the GUI sent the stop command and the engine now sent its bestmove too simultaneously for example,
a. The gui will get the bestmove zzzz for example.
b. The engine gets the stop command even if it already sent its bestmove.
Then the engine will send bestmove 0000.

In (a), the gui received two bestmoves, the first zzzz and the second 0000. But is clear to the GUI those moves did not come simultaneously, so it should consider the first bestmove zzzz.

But this thing does not matter anymore because the engine had already lose on time .

Now I sent the pos and go commands, if I sent stop command to the engine because I have not received the bestmove of the engine yet (though it sent already whatever), then I sent my stop command and there follows the bestmove of the engine. So from my point of view there is no problem, I sent the stop command and I receive the bestmove after.
Let's do the reverse, I sent the pos and go commands, then later I read the engine output "bestmove ...". Now that is bestmove to me, on that there is no need for me to send my stop command because I already get the bestmove.

Do we have a problem here?

[hgm]

I agree in case 1 sending the second 'stop' command does not make sense. I don't know what it was expected to do, but if an engine somehow ignored the first 'stop' command, why would you expect it to obey a second? But he protocol does not forbid it, so that it makes no sense can be no excuse for doing something non-compliant. In WB protocol it makes no sense to send two 'new' commands in a row, but if it happens (e.g. because a user presses 'New Game' twice because he was distracted and had forgotten he already did that), you cannot reply with a spurious 'move' command to it.

The problem is in case 2 when the engine is thinking in a game, and the user gets impatient and hits 'Move Now'. The GUI then has to send 'stop', and can never know if the engine received it while still thinking,and stopped because of it, or that it decided to move by itself before it received it.

Code: Select all

In (a), the gui received two bestmoves, the first zzzz and the second 0000. But is clear to the GUI those moves did not come simultaneously, so it should consider the first bestmove zzzz.

True, and ChessGUI does that. But the problem is that the world did not end there. It orders a new search, for the next EPD, and takes the second 'bestmove' for the result of that second search. As the protocol prescribes that it should. The UCI has no other way to determine which 'bestmove' belongs to which 'go' other than the order in which the were sent and arriving. There is no 'ID stamp' in the 'bestmove' echoing an ID that you sent with the 'go' command. That means the protocol is not resistant to interjection of spurious 'bestmove' commands.

[Graham Banks]

Thanks for taking the time to work on ChessGUI some more.

Your efforts are appreciated and you should feel proud of what you've achieved so far with ChessGUI.

There will always be little issues with any GUI, but you shouldn't let that discourage you.

Graham.

Hi Graham,

some of those ICC games did not even have moves.
I hope book creation now works as intended.

Matthias.

I will try it out and let you know how I get on.

I tried to create quite a large book using ICCF games, but ChessGUI crashed part way through.

[Matthias Gemuh]

I tried to create quite a large book using ICCF games, but ChessGUI crashed part way through.

Can you send me a download link so that I can reproduce the crash ?
The book shall be limited to 250000 lines maximum, though.

[Graham Banks]

I tried to create quite a large book using ICCF games, but ChessGUI crashed part way through.

Can you send me a download link so that I can reproduce the crash ?
The book shall be limited to 250000 lines maximum, though.

The file is 35mb in size (7-zipped) with roughly 35000 games.
I'm not sure how to make a file that big available.

[Matthias Gemuh]

I tried to create quite a large book using ICCF games, but ChessGUI crashed part way through.

Can you send me a download link so that I can reproduce the crash ?
The book shall be limited to 250000 lines maximum, though.

The file is 35mb in size (7-zipped) with roughly 35000 games.
I'm not sure how to make a file that big available.

www.hugedrive.com is free. I used it often 3 yrs ago.
You upload there, create a link and email the link.

[Graham Banks]

I tried to create quite a large book using ICCF games, but ChessGUI crashed part way through.

Can you send me a download link so that I can reproduce the crash ?
The book shall be limited to 250000 lines maximum, though.

The file is 35mb in size (7-zipped) with roughly 35000 games.
I'm not sure how to make a file that big available.

www.hugedrive.com is free. I used it often 3 yrs ago.
You upload there, create a link and email the link.

Let me try making some smaller books first, but I will try and get that file to you soon.