c-chess-cli

Discussion of chess software programming and technical issues.

Moderators: Harvey Williamson, Dann Corbit, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
User avatar
lucasart
Posts: 3168
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: c-chess-cli

Post by lucasart » Fri Aug 28, 2020 11:55 pm

AndrewGrant wrote:
Fri Aug 28, 2020 4:54 pm
lucasart wrote:
Thu Aug 27, 2020 5:09 am
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 :lol:
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!
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

AndrewGrant
Posts: 876
Joined: Tue Apr 19, 2016 4:08 am
Location: U.S.A
Full name: Andrew Grant
Contact:

Re: c-chess-cli

Post by AndrewGrant » Sat Aug 29, 2020 1:00 am

lucasart wrote:
Fri Aug 28, 2020 11:55 pm
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.

User avatar
lucasart
Posts: 3168
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: c-chess-cli

Post by lucasart » Sat Aug 29, 2020 1:51 am

AndrewGrant wrote:
Sat Aug 29, 2020 1:00 am
lucasart wrote:
Fri Aug 28, 2020 11:55 pm
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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

AndrewGrant
Posts: 876
Joined: Tue Apr 19, 2016 4:08 am
Location: U.S.A
Full name: Andrew Grant
Contact:

Re: c-chess-cli

Post by AndrewGrant » Sat Aug 29, 2020 3:21 am

lucasart wrote:
Sat Aug 29, 2020 1:51 am
AndrewGrant wrote:
Sat Aug 29, 2020 1:00 am
lucasart wrote:
Fri Aug 28, 2020 11:55 pm
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
Posts: 1620
Joined: Tue Aug 30, 2016 6:19 pm
Full name: Rasmus Althoff
Contact:

Re: c-chess-cli

Post by Ras » Sat Aug 29, 2020 6:48 am

lucasart wrote:
Sat Aug 29, 2020 1:51 am
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.
Rasmus Althoff
https://www.ct800.net

User avatar
lucasart
Posts: 3168
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: c-chess-cli

Post by lucasart » Sat Aug 29, 2020 8:26 am

Ras wrote:
Sat Aug 29, 2020 6:48 am
lucasart wrote:
Sat Aug 29, 2020 1:51 am
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
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

Ras
Posts: 1620
Joined: Tue Aug 30, 2016 6:19 pm
Full name: Rasmus Althoff
Contact:

Re: c-chess-cli

Post by Ras » Sun Sep 27, 2020 3:55 pm

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.
Rasmus Althoff
https://www.ct800.net

User avatar
lucasart
Posts: 3168
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: c-chess-cli

Post by lucasart » Thu Oct 01, 2020 12:02 am

Ras wrote:
Sun Sep 27, 2020 3:55 pm
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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

User avatar
lucasart
Posts: 3168
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: c-chess-cli

Post by lucasart » Mon Oct 26, 2020 12:21 am

lucasart wrote:
Thu Oct 01, 2020 12:02 am
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/.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

User avatar
Roland Chastain
Posts: 442
Joined: Sat Jun 08, 2013 8:07 am
Location: France
Full name: Roland Chastain
Contact:

Re: c-chess-cli

Post by Roland Chastain » Mon Oct 26, 2020 5:29 am

lucasart wrote:
Mon Oct 26, 2020 12:21 am
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. 8-)
Qui trop embrasse mal étreint.

Post Reply