c-chess-cli: experimental windows support

[Ferdy]

If an epd contains hmvc and fmvn opcodes like the following,

Code: Select all

1r1qkb1r/1p1bpppp/p4n2/3P4/5Q2/2N5/PP1P1PPP/R1B1K1NR b KQk - ce 29; hmvc 40; fmvn 12; c0 "white has doubled pawn";

wow, I always thought that an EPD record starts with a FEN, but this doesn't seem to be the case...
what's the reasoning behind this silliness? was EPD designed before FEN or is there another reason? the opcodes seem to start with an identifier (which shouldn't start with a number)
so parsing two extra numbers should be no problem at all

I think fen was first. EPD is extended position description, it has some advantages of communicating info like ce=centipawn evaluation, bm=best move and other opcodes. PGN standard section 16.2.

That doesn't explain why. This is plain wrong design, and delimiters are there for delimiting. To add meta data to the position, one should use ';' delimiters, not mix them into the FEN in a way that breaks compatibility with FEN standard itself.

The chess programming community is still fairly small. We can still change things, at least marginally. By purposely refusing to support such bugs, we will weed them out. So I will make a point to keep EPD in the Readme, and not support this EPD bug. I encourage others to do the same.

I see your chess960.epd has the following format.

Code: Select all

bbqnnrkr/pppppppp/8/8/8/8/PPPPPPPP/BBQNNRKR w HFhf - 0 1;

Just remove the semicolon ";" and call it chess960.fen and your are good.

[mar]

I pushed some fixes:
1/ explicit "b" or "t" mode for fopen() in Windows (vs. "e" in both cases for POSIX).
2/ remove the -Wpadded pedantic warning in make.py. Heeding this when struct elements have platform-dependant sizeof() is just too annoying.
3/ do not inherit parent handled in child processes on Windows.

There is still the problem of '\' vs. '/' in Windows file system. For example, cmd=../engine.exe should work, but cmd=..\engine.exe will not (it will launch ..\engine.exe, but will not break it into its components cwd=..\ and run=engine.exe, so the engine will run from the cwd in which c-chess-cli.exe was launched).

nice!
I have one problem though, removing the inherit parent causes a failure on fflush for some reason (line 296 in engine.c) so I had to put it back to TRUE
it's ok though, because breaking c-chess-cli in the console doesn't leave any zombies - windows probably auto-kills child processes, if that was your concern. this should also auto-close any pending file handles

as for the backslashes, well... another silly thing from the DOS past.
I believe that forward slashes in fopen might work, either way not a big deal for me as I run the engines locally from the same folder

[mar]

That doesn't explain why. This is plain wrong design, and delimiters are there for delimiting. To add meta data to the position, one should use ';' delimiters, not mix them into the FEN in a way that breaks compatibility with FEN standard itself.

also don't forget that you still have to parse strings anyway, because a delimiter can be part of a string,
still it's just odd to break the FEN into parts he way EPD does without any good reason to do so...
starting with a FEN would be so much easier - just parse FEN and ignore the rest of the EPD record, but it seems we can't have nice things

EDIT: in fact extending EPD spec to allow EPD records to start with a full FEN (and in fact encourage this)
still won't clash with anything (because opcode is an identifier) and for existing EPD parsers this would mean none or just trivial changes, hmvc and other silly opcodes might still work and just "overwrite" what's in FEN already if present...
of course the best thing would be to simply force FEN and remove hmvc and fmvn, but this seems unlikely to happen

[lucasart]

I pushed some fixes:
1/ explicit "b" or "t" mode for fopen() in Windows (vs. "e" in both cases for POSIX).
2/ remove the -Wpadded pedantic warning in make.py. Heeding this when struct elements have platform-dependant sizeof() is just too annoying.
3/ do not inherit parent handled in child processes on Windows.

There is still the problem of '\' vs. '/' in Windows file system. For example, cmd=../engine.exe should work, but cmd=..\engine.exe will not (it will launch ..\engine.exe, but will not break it into its components cwd=..\ and run=engine.exe, so the engine will run from the cwd in which c-chess-cli.exe was launched).

nice!
I have one problem though, removing the inherit parent causes a failure on fflush for some reason (line 296 in engine.c) so I had to put it back to TRUE
it's ok though, because breaking c-chess-cli in the console doesn't leave any zombies - windows probably auto-kills child processes, if that was your concern. this should also auto-close any pending file handles

as for the backslashes, well... another silly thing from the DOS past.
I believe that forward slashes in fopen might work, either way not a big deal for me as I run the engines locally from the same folder

Thanks. Reverted the offending patch.

Regarding the auto-kill of child process, this is explicitely done using AssignProcessToJobObject().

[mar]

Regarding the auto-kill of child process, this is explicitely done using AssignProcessToJobObject().

ah ok, didn't know that... learned something new

[lucasart]

I pushed some fixes:
1/ explicit "b" or "t" mode for fopen() in Windows (vs. "e" in both cases for POSIX).
2/ remove the -Wpadded pedantic warning in make.py. Heeding this when struct elements have platform-dependant sizeof() is just too annoying.
3/ do not inherit parent handled in child processes on Windows.

There is still the problem of '\' vs. '/' in Windows file system. For example, cmd=../engine.exe should work, but cmd=..\engine.exe will not (it will launch ..\engine.exe, but will not break it into its components cwd=..\ and run=engine.exe, so the engine will run from the cwd in which c-chess-cli.exe was launched).

nice!
I have one problem though, removing the inherit parent causes a failure on fflush for some reason (line 296 in engine.c) so I had to put it back to TRUE
it's ok though, because breaking c-chess-cli in the console doesn't leave any zombies - windows probably auto-kills child processes, if that was your concern. this should also auto-close any pending file handles

as for the backslashes, well... another silly thing from the DOS past.
I believe that forward slashes in fopen might work, either way not a big deal for me as I run the engines locally from the same folder

Pushed another patch to enable program arguments. For natively compiled engines, this is typically useless, but for scripting languages where the engine is the interpreter (eg. "cmd=python engine.py"), this is needed.

There is still the issue of '\' vs. '/'. It seems easier to banish '\', because they break string parsing, and Windows tolerates '/' anyway.

Here's the super annoying example that demonstrates the problem:

Code: Select all

"cmd=python my\ engine.py"

Here the user (an obvious troll), decided to put a space in the name of the python source file. There are 2 levels of parsing and tokenisation:
* the command line interpreter (bash or its windows equivalent), which is where the double quotes are needed to force parsing the whole string as a single token, verbatim.
* c-chess-cli then receives the token "cmd=python my\ engine.py", which is parsed as ("python", "my engine.py"), and not ("python", "my", "engine.py"), which is why the '\' escape sequence is needed.

[mar]

There is still the issue of '\' vs. '/'. It seems easier to banish '\', because they break string parsing, and Windows tolerates '/' anyway.

hmm, why not simply support forward slashes only and make a note of this in the readme/manual

[Michel]

There is still the issue of '\' vs. '/'. It seems easier to banish '\', because they break string parsing, and Windows tolerates '/' anyway.

hmm, why not simply support forward slashes only and make a note of this in the readme/manual

I had to deal with this in polyglot and I think I solved it satisfactorily. I give \ the role of an escape character in a limited number of cases. But in almost all cases it just stands for itself. An unconditional non escape \ can be created by using \\ (e.g. in the highly theoretical case that the directory is my and the file name ‘ engine.py’ one could write my\\\ engine.py).

Ps. It seems filenames starting with a space are indeed allowed on windows https://stackoverflow.com/questions/391 ... 0#39141640 .

[lucasart]

There is still the issue of '\' vs. '/'. It seems easier to banish '\', because they break string parsing, and Windows tolerates '/' anyway.

hmm, why not simply support forward slashes only and make a note of this in the readme/manual

After some thought, I decided to fix this as follows:
* use '\' as directory separator -> as users expect (no README doc required) + consistent with tab-auto-complete from shell (ease typing burden). When in Rome, do like the Romans...
* use '`' as escape sequence. This is potentially controversial. The reality is that Windows is not even self-consistent in this area, so I chose the PowerShell convention, since it is the sanest and easiest to implement (recursive parsing of double quotes!? erm... no thanks!). See https://www.howtogeek.com/694949/how-to ... mand-line/

The parsing of escape sequence is only used in the rare case where spaces exist in any of the argv[] values in "cmd=argv[0] ... argv[n-1]". People who don't want to pollute their brain with shell specific parsing rules should just use '_' to create spaces in filenames (that's why _ was invented, isn't it?).