Xboard, CECP, how to handle long inits

[phhnguyen]

Thanks HGM for very detail and clear reply!

Just a bit out of topic: for UCI, what are commands similar to the pair "feature done='0'/'1'" of WB? In other words, how to make GUI wait longer for engine initialization?

Thanks

Code: Select all

* isready
	this is used to synchronize the engine with the GUI. When the GUI has sent a command or
	multiple commands that can take some time to complete,
	this command can be used to wait for the engine to be ready again or
	to ping the engine to find out if it is still alive.
	E.g. this should be sent after setting the path to the tablebases as this can take some time.
	This command is also required once before the engine is asked to do any search
	to wait for the engine to finish initializing.
	This command must always be answered with "readyok" and can be sent also when the engine is calculating
	in which case the engine should also immediately answer with "readyok" without stopping the search.

No, IMHO, isready / readyok is kind of ping / pong only. If an engine does not reply to 'isready' in time, it may be killed. Thus it is not the right thing to tell GUI: "Be patient, I am going to be silent / no reply for an unusually long period for initializing".

[pedrox]

If the GUI developer waits 1 hour to receive the readyok command, then you will have the same time to start the engine as in the xboard protocol.

I do not see anything in the protocol that indicates a certain waiting time to the isready command, so I understand that this will depend on the GUI developer (uci) and can only be changed if said programmer gives the option to the user in the GUI, but it can not be changed from the engine.

Daniel has said that cutechess has a maximum initialization time of 30 seconds, I imagine that this time will be the same for xboard and uci. I also had problems loading the scorpio bitbases even though I sent the command "feature done = 0" for xboard mode, if the bitbases were not loaded before starting the tournament the cutechess tournament started and the engine was not ready, when playing 8 concurrent games I found 8 lost games by connection stalls. I have tried in cutechess (uci) to start the loading the openings book and the gaviota tablebases when receiving the command isready and after making it answer with readyok. In this case I have no problems and I can play 8 concurrent games, not sure if I would have problems with bitbases and uci on cutechess.

[Ferdy]

Another off topic issue since I am confused in what is correct reactions between GUI and engines. I am trying to support WB protocol for my app (Banksia the chess tournament manager) and prefer to work with moves in coordinate format which I think it is standard in WB protocol document. When testing with Crafty v23.6, it sent me some features:

Code: Select all

   feature ping=1 setboard=1 san=1 time=1 draw=1

I accepted all but "san" one:

Code: Select all

   accepted setboard
   rejected san
   accepted time
   accepted draw

However Crafty replied me in a un-formal way:

Code: Select all

   ERROR.  feature san rejected by xboard

and then it gave me the first move in san format:

Code: Select all

   move h3

My questions:
- How to control engines to work with coordinate moves? Do GUIs have to "obey" engines in those cases?

Both gui and engine are required to follow the protocol. If the engine violates the protocol, send a message to the user thru popup, saying that the engine violates a protocol. So that the user will be aware of why the engine is not allowed to run on your gui. If you have gui log, log it too.

- How to deal with unformal anwsers (how to understand them)?

In the case of Crafty, since you did not support san, you can send a message to the user saying for example, "san move format is not supported by this gui". Then terminate crafty. But don't terminate the gui.

I am working on a gui at https://github.com/fsmosca/Python-Easy-Chess-GUI
Only uci engines are supported so far.

[hgm]

Just a bit out of topic: for UCI, what are commands similar to the pair "feature done='0'/'1'" of WB? In other words, how to make GUI wait longer for engine initialization?

The UCI equivalent of 'feature done=1' is 'uciok'. There is no equivalent to 'feature done=0'. It is not needed, as (unlike in CECP, where the engine could be v1 and not respond at all) the 'uciok' response is mandatory. This also removes the need for a timeout, assuming you don't care what happens if the engine is non-compliant. (Note that UCI was designed as a protocol for Shredder only, not to be suitable for general use.)

Both 'feature done=1' and 'uciok' really only serve the purpose to inform the GUI that it has received all the features/options, and can thus start to communicate with the engine. It does not promise that the engine will respond instantly on any command that can follow. If the engine has time-consuming tasks that need to be done only at start-up, and not before every game, it can take advantage of the protocol by doing it during the period it knows the GUI will be waiting for it to say something.

UCI has isready/readyok pinging that can be used to test completion of earlier commands (with the caveat that searching is not considered execution of a command, only starting a search is), and could be used to test if the engine will be able to process position+go without delay, which could be a criterion for the GUI to start the engine's clock. For this reason the UCI specs recommend to use isready after ucinewgame. Unfortunately many USI engines would not respond to isready at this time.

CECP has ping/pong, but there is no suggestion in the specs that the GUI would actually wait for the pong reply (before sending new commands or starting the clock). So in that respect it is not really equivalent to isready. In UCI2WB 'ping' is answered purely based on the state of the adapter, without probing the engine with 'isready' first. So when running a UCI engine under WinBoard + UCI2WB it wouldn't help the engine to hold up the 'readyok' response after 'ucinewgame' because it first wants to do some initialization: it would not make UCI2WB delay the 'pong' response after 'new', and even if it would, a delayed 'pong' might not cause the GUI to delay starting of the clocks.

It is debatable anyway whether time-consuming tasks the engine needs to do before every game should not be accounted against its thinking time. There is no FIDE rule that says clocks should only run when you use CPU time; if you want to load huge amounts of precalculated data from disk into memory, you do so at your own risk. You can be sure that, when playing in an external event such as an ICS or operator-mediated OTB tournament your clock will stay running whatever your computer does. This is a lot like doing the triathlon and after the swimming demanding that your clock be stopped while you dry warming up in the sun, because being warm, comfortable and well rested makes you cycle faster. It is bad enough that engines are allowed to cheat this way at startup. This is a bit of a moot point, though, because UCI2WB specifies 'feature reuse=0', so that the engine will be restarted for every game, and can thus do stuff for that one game before the 'uciok'.

[smatovic]

XBoard sends 'ping' after each 'new', and in tournament mode actually waits with starting the clock until both engines have submitted the corresponding 'pong's. Not sure if it also does that in old-fashioned two-player matches, though. (The tournament mode has another, much more complex NextGame function, because this could involve changing engines.) This might depend on the version. But there is nothing that would stop you from playing a tournament with only two participants instead.

Nice, implemented, works, at least for XBoard GUI, thanks.

I had already 'feature done=0' for gpu inits. But with more memory on newer gpus my engine lost some seconds for each new game cos of memory inits. And I do not like the 'reuse=0' feature.

--
Srdja

[phhnguyen]

I have tried in cutechess (uci) to start the loading the openings book and the gaviota tablebases when receiving the command isready and after making it answer with readyok. In this case I have no problems and I can play 8 concurrent games, not sure if I would have problems with bitbases and uci on cutechess.

Nice solution! The key here the GUI and the engines keep "chatting" so the GUI will be happy to wait for a longer period for readyok! I will implement that logic for my program (Banksia). Thanks for clarifying!

[phhnguyen]

Both gui and engine are required to follow the protocol. If the engine violates the protocol, send a message to the user thru popup, saying that the engine violates a protocol. So that the user will be aware of why the engine is not allowed to run on your gui. If you have gui log, log it too.
...
In the case of Crafty, since you did not support san, you can send a message to the user saying for example, "san move format is not supported by this gui". Then terminate crafty. But don't terminate the gui.

The main problem: Crafty is kind of "standard" one for Winboard protocol engine world. I guess we should follow and adapt it but not vice versa (my question is actually how to adapt). We should support Crafty unconditionally or leave that world.

IMO, supporting of a GUI for WB protocol is much harder (since there are more assumptions, unclear situations) than UCI one but it is doable. My chess GUI starts working with Crafty even it is still too far from completion.

The other problem AFAIK is that Bob (the author of Crafty) is almost retired from computer chess!

I am working on a gui at https://github.com/fsmosca/Python-Easy-Chess-GUI
Only uci engines are supported so far.

Nice graphics program! (mine has no graphics at all )
Keep up the excellent work!

[hgm]

I don't agree at all. I always considered Crafty as one of the most non-compliant WB engines. Only GNU Chess used to be worse. I don't know what the current situation is. I don't see any reason to give Crafty special treatment.

That being said, the specs for feature san say that it controls the format of moves the GUI sends to the engine. It doesn't specify whether the setting (which might be implied by rejection of the feature) has any consequences for what the engine can send to the GUI.

IMO allowing engines to send SAN was one of the worst ideas ever. This inSANe design was no doubt a consequence of the fact that XBoard started as a graphical front-end for an already existing stand-alone chess program (GNU Chess) that had its own ascii-based user interface. Such interfaces would cater to the desires of their human users, who would highly prefer SAN over coordinate notation. Now in XBoard this was not too much of a hardship; reading games from a file, which conceivably might contain SAN, was also a design goal. So it needed a SAN parser anyway, and might as well use it on the engine moves.

I remember having read somewhere (perhaps Tim Mann's website) that WinBoard would always accept engine moves in SAN, but that engine-developers should not be surprised if other interfaces would not. This remark never seems to have made it into the specs, though. Sad fact is that many engines print their moves as SAN. So the choice for a GUI developer is to just not support those engines, or to include a SAN parser.

[phhnguyen]

lol, deeply I agreed. I cannot say I am happy to work with Crafty. I have been tracing some issues between Crafty and my program. It is... a nightmare for GUI developers

[Ras]

The UCI equivalent of 'feature done=1' is 'uciok'.

No, it isn't. "uciok" is only meant for acknowledging UCI mode, not for doing init. Therefore, "uciok" has to appear quickly after the GUI sent "uci", and lengthy init stuff is not allowed.

"isready" is meant as ping/pong replacement AND feature done with init, and the UCI spec explicitely mentions tablebase initialistion as example that may take some time. The engine only responds with "readyok" after it has processed the setoptions commands. The case where "isready" must be answered immediately is only after init and during search because then there is no reason why the engine should be hanging.