c-chess-cli

[lucasart]

Extra thread is just correct software design, but is not mandatory (you can poll() every few nodes and read input sequentially). The reason for this is that the engine must be responsive while searching. At the very least, it must be responsive to "isready", "stop", and "ponderhit". Ideally the protocol should also state that these are the only commands that a GUI is allowed to send to a searching engine.

From the UCI spec:

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.

Those things are in conflict. I refuse to respond with isready while searching.

Selective reading

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

which is not contradicting (but rather reinforcing):

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.

Besides, this is logical and necessary. How else would you implement ping in a GUI ?

In c-chess-cli, I don't ping, because I'm lazy. All I have is a timeout mechanism to escape blocking I/O, because str_getline() will block until a full line is read. And the searching engine can spend an unbounded amount of time before writing anything to stdout...

But ping is necessary in any good GUI (or CLI). If the engine has 2h on the clock, and is hanging already, a ping could detect it quasi immediately (modulo time out margin), whereas waiting for the clock to time out is another 2h away!

[AndrewGrant]

But ping is necessary in any good GUI (or CLI). If the engine has 2h on the clock, and is hanging already, a ping could detect it quasi immediately (modulo time out margin), whereas waiting for the clock to time out is another 2h away!

Is that statement true though? If I have a UCI thread polling for isready, my engine can be on fire and it will still respond. Only if you are actively polling from the searching thread is your statement true.

[lucasart]

But ping is necessary in any good GUI (or CLI). If the engine has 2h on the clock, and is hanging already, a ping could detect it quasi immediately (modulo time out margin), whereas waiting for the clock to time out is another 2h away!

Is that statement true though? If I have a UCI thread polling for isready, my engine can be on fire and it will still respond. Only if you are actively polling from the searching thread is your statement true.

Good point. Well then, that gives me another excuse to be lazy, and not implement ping in c-chess-cli.

But, from the engine pov, you don't have a choice. You have to respond readyok, or the GUI may kill you for failing to pong when pinged.

[AndrewGrant]

But ping is necessary in any good GUI (or CLI). If the engine has 2h on the clock, and is hanging already, a ping could detect it quasi immediately (modulo time out margin), whereas waiting for the clock to time out is another 2h away!

Is that statement true though? If I have a UCI thread polling for isready, my engine can be on fire and it will still respond. Only if you are actively polling from the searching thread is your statement true.

Good point. Well then, that gives me another excuse to be lazy, and not implement ping in c-chess-cli.

But, from the engine pov, you don't have a choice. You have to respond readyok, or the GUI may kill you for failing to pong when pinged.

I'll revert the change when someone writes a GUI that complains

[Ras]

Good point. Well then, that gives me another excuse to be lazy, and not implement ping in c-chess-cli.

"isready" is still useful during the config phase to wait with new commands until lengthy ones are finished, like setting up EGTBs. Otherwise, you might start a game right away and erroneously subtract the config time from the game thinking time.

[lucasart]

Good point. Well then, that gives me another excuse to be lazy, and not implement ping in c-chess-cli.

"isready" is still useful during the config phase to wait with new commands until lengthy ones are finished, like setting up EGTBs. Otherwise, you might start a game right away and erroneously subtract the config time from the game thinking time.

position must be followed by isready /readyok, before go can be sent. so there can never be miscalculations of time.

But I think you're missing the point of Andrew. Yes, isready must be treated, but not while searching

[Ras]

Now that I've changed back to the Linux camp, I'm using c-chess-cli and like it!

Some questions that aren't entirely clear from the documentation:
1) -random and -repeat are not mutually exclusive, right?
2) -depth isn't described, but I guess it's for fixed depth search?
3) Is it for exactly two engines? If more than two are possible, is it a tournament or a gauntlet?

Btw., for workers_add_result(), definition and prototype have different variable naming.

[lucasart]

Now that I've changed back to the Linux camp, I'm using c-chess-cli and like it!

Some questions that aren't entirely clear from the documentation:
1) -random and -repeat are not mutually exclusive, right?
2) -depth isn't described, but I guess it's for fixed depth search?
3) Is it for exactly two engines? If more than two are possible, is it a tournament or a gauntlet?

Btw., for workers_add_result(), definition and prototype have different variable naming.

1/ random and repeat are completely othgonolal and can be combined. random tells how openings are selected in the file. repeat just means that we select one opening, and play 2 games (rather than draw a new opening for each game).

2/ yes. it just adds "depth N" to the go command. note that tc, depth, movetime, nodes can all be combined.

3/ no tournaments yet. just started working on it. first i need to revamp the command line parsing logic to replicate that of cutechess-cli. the whole -option value1[:value2], doesn't work well in the context of N engines.

[lucasart]

3/ no tournaments yet. just started working on it. first i need to revamp the command line parsing logic to replicate that of cutechess-cli. the whole -option value1[:value2], doesn't work well in the context of N engines.

c-chess-cli is now capable of running tournaments. Gauntlets only for now, Round-Robin will follow soon. The syntax is now mostly identical to cutechess-cli. https://github.com/lucasart/c-chess-cli/.

[Roland Chastain]

c-chess-cli is now capable of running tournaments. Gauntlets only for now, Round-Robin will follow soon. The syntax is now mostly identical to cutechess-cli. https://github.com/lucasart/c-chess-cli/.

Congratulations! I can't wait to try it.