c-chess-cli

[lucasart]

Xboard is a nightmare. UCI has flaws, but at least its clear.

Not in my opinion. With xboard you don't need an extra thread. The commands integrate very well in the search.
...

Interesting! Do you know why xboard engines can run without extra thread but not UCI ones? Because of “ping” command or something else?

BTW, engines without extra thread for reading input may have not advantages nowadays and they are so laggy on response some commands such as “quit”, isn’t it?

Engine must be responsive while searching regardless of protocol. Unless xboard state that GUI should kill and restart process whenever it needs to communicate, because xboard engines are badly coded and can't process input while busy… I doubt it.

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.

[OliverBr]

Engine must be responsive while searching regardless of protocol. Unless xboard state that GUI should kill and restart process whenever it needs to communicate, because xboard engines are badly coded and can't process input while busy… I doubt it.

Actually there is a xboard option "reuse" weather an engine must be killed and restarted or not. Of course, this is not fine. Even OliPow 2.2 from year 1997 is reusable.

[phhnguyen]

PS: The Java version of OliThink uses an extra thread, because I didn't find a method to peek if there has been an input. It should be possible though with an library like Apache Commons and PeekableInputStream.

So you can run your chess engine without any extra thread because of your program technique, not because XBoard protocol has anything special, doesn’t it?

I guess, if you want, you can support UCI without using any extra thread too

[OliverBr]

PS: The Java version of OliThink uses an extra thread, because I didn't find a method to peek if there has been an input. It should be possible though with an library like Apache Commons and PeekableInputStream.

So you can run your chess engine without any extra thread because of your program technique, not because XBoard protocol has anything special, doesn’t it?

No, this is not what I was saying and it's not correct either.
Xboard protocol is designed that it works very well with a single thread. This has nothing to do with the reason why I am using an extra thread in the Java Version.

I guess, if you want, you can support UCI without using any extra thread too

Perhaps you may check this article: [/quote]

[abulmo2]

Engine must be responsive while searching regardless of protocol. Unless xboard state that GUI should kill and restart process whenever it needs to communicate, because xboard engines are badly coded and can't process input while busy… I doubt it.

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.

The xboard (or CECP) protocol is very permissive and many basic commands are optional. The '?' command is similar to the UCI 'stop' command, but the protocol states: "It is permissible for your engine to always ignore the ? command." The 'ping [N]' command resembles the 'isready' command, but is also optional, and should be answered once a command (like a move) is terminated and not immediately. There is no ponderhit equivalence.
The core of the xboard protocol is simpler to implement than the UCI protocol, and I guess this is why it is so common on many basic engines. The complete xboard protocol can be very powerful too, but then its implementation is more complex than the UCI protocol. The xboard protocol is also an evolving protocol whereas the UCI protocol is stable dead.

[Roland Chastain]

Hello!

I have just made a new test, with the latest code from the GitHub repository.

test.sh

Code: Select all

./c-chess-cli -cmd /home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux:/home/roland/Applications/moteurs/alouette/012/alouette64 \
-tc 2+0.02 \
-games 2 \
-concurrency 1 \
-pgnout out.pgn \
-debug

test.log

Code: Select all

[roland@localhost c-chess-cli]$ sh test.sh
[1] could not read from /home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux
[roland@localhost c-chess-cli]$ 

c-chess-cli.1.log

Code: Select all

deadline set: /home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux must respond by 10091570
/home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux <- uci
/home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux -> [1] error in src/engine.c: (56). No such file or directory

There seems to be a problem again with the directory. Or did I make something wrong?

Regards.

Roland

[phhnguyen]

The xboard protocol is also an evolving protocol whereas the UCI protocol is stable dead.

No evidence for your claim, isn’t it?

Winboard protocol has stopped at version 2, no more evolved since. The UCI protocol was invented after Winboard ver 2, learnt and could replace Winboard, thus it is good enough from that day and doesn’t require a big improvement even some defects found.

It (UCI) actually doesn’t stay in one place but has been changing slightly. It has an open way for further extensions: the prefix UCI_ for new commands and many new commands have been added already. Above all, the protocol works with keywords thus programmers can add more items without worrying too much to break chess GUIs (and they added many items). In contrast, Winboard works with some assumptions about data orders/positions and maybe in trouble to add and/or change orders. In general, Winboard GUIs almost can’t work with new things which are out of the protocol from the day the protocol was written down.

[Guenther]

The xboard protocol is also an evolving protocol whereas the UCI protocol is stable dead.

No evidence for your claim, isn’t it? ;)

Winboard protocol has stopped at version 2, no more evolved since. The UCI protocol was invented after Winboard ver 2, learnt and could replace Winboard, thus it is good enough from that day and doesn’t require a big improvement even some defects found

...

No, uci is dead since around 2005, while xboard protocol version 2 was extended several times by HGM.
Ever heard of e.g. 'cores', 'memory', 'egtpath', 'include (move)', 'exclude (move)', 'setscore' commands? Guess when they were added...

http://hgm.nubati.net/CECP.html
https://www.gnu.org/software/xboard/engine-intf.html

[AndrewGrant]

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.

[lucasart]

Hello!

I have just made a new test, with the latest code from the GitHub repository.

test.sh

Code: Select all

./c-chess-cli -cmd /home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux:/home/roland/Applications/moteurs/alouette/012/alouette64 \
-tc 2+0.02 \
-games 2 \
-concurrency 1 \
-pgnout out.pgn \
-debug

test.log

Code: Select all

[roland@localhost c-chess-cli]$ sh test.sh
[1] could not read from /home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux
[roland@localhost c-chess-cli]$ 

c-chess-cli.1.log

Code: Select all

deadline set: /home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux must respond by 10091570
/home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux <- uci
/home/roland/Applications/moteurs/slowchess/classic/22/slow64_linux -> [1] error in src/engine.c: (56). No such file or directory

There seems to be a problem again with the directory. Or did I make something wrong?

Regards.

Roland

Oops, that was a stupid copy/paste typo on the last patch. Should be fine now.