c-chess-cli

[lucasart]

The fact that readyok is stuck to the error msg is not related to c-chess-cli, but rather SlowChessBlitz, which forgot to write a '\n' there.

Yes, it was also my impression. I should report the bug to the author of SlowChess. Done.

There is one little trick to be aware of though. In order to capture the stderr of engines along with stdout, c-chess-cli puts them all in the same file using dup2() system call. This replicates the "2>&1" syntax in bash.

So it is possible that SlowChess wrote the error message in stderr without \n, and also wrote readyok in strdout. Still I think that would be wrong, and stderr messages should end with \n. But it would explain why this happens in c-chess-cli and not other tools that discard stderr.

I also fixed the current directory, deducing it from the command. Users with special needs may want to enter it as input parameter for each engine, but at least normal users will be satisfied with the default behavior.

[Roland Chastain]

There is one little trick to be aware of though. In order to capture the stderr of engines along with stdout, c-chess-cli puts them all in the same file using dup2() system call. This replicates the "2>&1" syntax in bash.

So it is possible that SlowChess wrote the error message in stderr without \n, and also wrote readyok in strdout. Still I think that would be wrong, and stderr messages should end with \n. But it would explain why this happens in c-chess-cli and not other tools that discard stderr.

Indeed.

I also fixed the current directory, deducing it from the command. Users with special needs may want to enter it as input parameter for each engine, but at least normal users will be satisfied with the default behavior.

Perfect, thank you. I will test it.

[lucasart]

I also fixed the current directory, deducing it from the command. Users with special needs may want to enter it as input parameter for each engine, but at least normal users will be satisfied with the default behavior.

Perfect, thank you. I will test it.

Actually, this will break something that worked before...

What if the user enters a string value containing spaces (using proper syntax to escape spaces in the shell), like so: "python ./engine.py" ?

The new logic of reading the current working directory, as everything before the last "/", results in cwd = "python .", which is not a valid directory...

A simple (but wrong) solution would be to read the first token, separated by " ", and apply the logic of the last "/" to that. Unfortunately, spaces are allowed in file names (and in directory names too, since directories are files as well).

Road to hell is paved with good intentions

[Roland Chastain]

Actually, this will break something that worked before...

What if the user enters a string value containing spaces (using proper syntax to escape spaces in the shell), like so: "python ./engine.py" ?

The new logic of reading the current working directory, as everything before the last "/", results in cwd = "python .", which is not a valid directory...

Indeed. I did not think about that. Maybe you could make an option for directory? This is what other software do.

Good luck in finding a solution!

[lucasart]

Actually, this will break something that worked before...

What if the user enters a string value containing spaces (using proper syntax to escape spaces in the shell), like so: "python ./engine.py" ?

The new logic of reading the current working directory, as everything before the last "/", results in cwd = "python .", which is not a valid directory...

Indeed. I did not think about that. Maybe you could make an option for directory? This is what other software do.

Good luck in finding a solution!

I had to reinvent the shell a little:

• First the a:b syntax reserves the ":" character, which is legal in file names, or command line arguments, so that's no good. Now a and b can contain ":" provided it is escaped "\:".
• Second, a and b may contain spaces, and to make matters worse, the space character is ambiguous. It can be part of a file name, or actually command line arguments. Again, the solution is to use escape sequence "\ ".
• Third, c-chess-cli now understands command line arguments for a and b (separated by unescaped spaces).
• And, of course, I kept the logic of deducing the current working directory from the filename (eg. "../Engines/stockfish" => run "./stockfish" in "../Engines").

This solves every case I can think of, except perhaps this corner case: eg. "/usr/bin/python /home/lucas/Python\ scripts\engine.py". Here, the engine is actually "/usr/bin/python", since it is the executable file that we run and do UCI communication with. Of course, users will naively hope for the cwd to be set to "/home/lucas/Python\ scripts", but that won't happen. The logic is to deduce it from the first token being the file we execute, which is "usr/bin/python", leading to cwd = "usr/bin" here. The solution to this problem is to make the script executable, and use a shebang to run it directly a "/home/lucas/Python\ scripts\engine.py" without having to specify the python interpreter.

[OliverBr]

@lucasart,
thank you!

It would nice to support xboard protocol, too.

What about the handling when an ending crashes? cutechess-cli abort the tourney which can be very annoying, on the other hand you must fix bug, which is got.
Which format is pgn? I like "pgnout min" in cutechess, but is misses the "Time Control" tag.

[lucasart]

@lucasart,
thank you!

It would nice to support xboard protocol, too.

What about the handling when an ending crashes? cutechess-cli abort the tourney which can be very annoying, on the other hand you must fix bug, which is got.
Which format is pgn? I like "pgnout min" in cutechess, but is misses the "Time Control" tag.

Features I won't implement:

• PGN parsing: input is FEN (or EPD discard after ";" anyway), output is PGN.
• Xboard protocol

Features I may implement, but low priority

• recovering crashed engines. actually cutechess-cli supports this feature (but c-chess-cli doesn't)
• tournaments, at least gauntlet
• native windows support (the infamous Win32 API, still alive and kicking in 2020, unfortunately )

[AndrewGrant]

Features I won't implement:

• PGN parsing: input is FEN (or EPD discard after ";" anyway), output is PGN.
• Xboard protocol

Xboard is a nightmare. UCI has flaws, but at least its clear. Is anyone out there using Xboard in the top #10? #25? #50?
PGN parsing is also silly. Its nice maybe, but it just tosses everything except the FEN and moves. Save yourself time by providing an EPD.

Features I may implement, but low priority

• recovering crashed engines. actually cutechess-cli supports this feature (but c-chess-cli doesn't)
• tournaments, at least gauntlet
• native windows support (the infamous Win32 API, still alive and kicking in 2020, unfortunately )

I personally don't care about crash info. Existence of a crash is enough to send you looking.
I've quite literally never used Cutechess's tournaments or gauntlet features.
Does c-chess-cli work if you have a POSIX/pthread based mingw?

[OliverBr]

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.

Is anyone out there using Xboard in the top #10? #25? #50?

There are some xboard engines with ELO about 3000. Some can both, xboard and UCI.

But why the question? Is an engine only important if it is in the #10?

Other engines may be more important than the 13th clone of Stockfish. Or another fork of another strong engine. Those use UCI, of course.

I very much prefer a unique engine with own ideas, even though it is not in the #10.

Just one Example: Tord Romstad's Glaurung is not even in the #100, yet it is one of the most important (and unique) chess engines ever.

[Roland Chastain]

I had to reinvent the shell a little:

• First the a:b syntax reserves the ":" character, which is legal in file names, or command line arguments, so that's no good. Now a and b can contain ":" provided it is escaped "\:".
• Second, a and b may contain spaces, and to make matters worse, the space character is ambiguous. It can be part of a file name, or actually command line arguments. Again, the solution is to use escape sequence "\ ".
• Third, c-chess-cli now understands command line arguments for a and b (separated by unescaped spaces).
• And, of course, I kept the logic of deducing the current working directory from the filename (eg. "../Engines/stockfish" => run "./stockfish" in "../Engines").

I have just done another test (with the latest code from the GitHub repository), without success. Maybe I did something wrong.

Here is my command:

Code: Select all

./c-chess-cli \
-cmd /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux:/home/roland/Applications/Moteurs/alouette-0.1.2-lin64/alouette64 \
-games 2 \
-concurrency 1 \
-repeat \
-tc 2+0.02 \
-pgnout out.pgn \
-debug

And the debug file:

Code: Select all

deadline set: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux must respond by 2982479
/home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux <- uci
deadline ok: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2981578, 901ms before the deadline.
deadline ok: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2981678, 801ms before the deadline.
deadline ok: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2981779, 700ms before the deadline.
deadline ok: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2981879, 600ms before the deadline.
deadline ok: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2981979, 500ms before the deadline.
deadline ok: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2982079, 400ms before the deadline.
deadline ok: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2982179, 300ms before the deadline.
deadline ok: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2982279, 200ms before the deadline.
deadline ok: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2982380, 99ms before the deadline.
deadline failed: /home/roland/Applications/Moteurs/SlowChessClassic-Linux-2.2/slow64_linux responded at 2982480, 1ms after the deadline.

I see less informations than previously in the debug file. It was useful IMHO to see the messages exchanged.