lucasart wrote: ↑Fri Aug 21, 2020 3:03 pm
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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
lucasart wrote: ↑Sat Aug 22, 2020 7:30 am
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.
lucasart wrote: ↑Sat Aug 22, 2020 7:30 am
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.
lucasart wrote: ↑Sat Aug 22, 2020 7:30 am
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
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
lucasart wrote: ↑Sun Aug 23, 2020 3:31 am
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.
lucasart wrote: ↑Sun Aug 23, 2020 3:31 am
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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
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.
OliverBr wrote: ↑Tue Aug 25, 2020 11:18 am
@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.
lucasart wrote: ↑Tue Aug 25, 2020 12:48 pm
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.
lucasart wrote: ↑Tue Aug 25, 2020 12:48 pm
Features I may implement, but low priority
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?
#WeAreAllDraude #JusticeForDraude #RememberDraude #LeptirBigUltra "Those who can't do, clone instead" - Eduard ( A real life friend, not this forum's Eduard )
lucasart wrote: ↑Mon Aug 24, 2020 1:54 am
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.
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.