I'm trying to do something like cutechess-cli. For the moment, it's very limited, but some of the basics are there (can play a single game, UCI only, POSIX only).
If anyone is interested in helping to develop it, feel free to join! People with experience in multi-threading are most welcome, as I have none myself.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
lucasart wrote:I'm trying to do something like cutechess-cli. For the moment, it's very limited, but some of the basics are there (can play a single game, UCI only, POSIX only).
I'm already following your project at Github and I wish you success. I remember when cutechess-cli was at that stage - you have quite a lot of work ahead of you.
lucasart wrote:
If anyone is interested in helping to develop it, feel free to join! People with experience in multi-threading are most welcome, as I have none myself.
I won't, but I will confess that I started a command-line based match/referee program based on my variant engine Sjaak (provisionally called Sjef) literally the other day. Its main purpose (for me) is to have a GUI-less referee program that I can use to play variant matches, something cutechess-cli isn't really suitable for.
It currently loads up the engines and initialises them, actually parsing the engine responses is next on the list, followed by being able to play an actual game.
I suspect it won't compile on Windows though, since I used fork() to split off the engine processes. I could switch to threads (I've used pthreads in the past), but I find fork() to be much easier (if a bit dirty) to be honest...
lucasart wrote:I'm trying to do something like cutechess-cli. For the moment, it's very limited, but some of the basics are there (can play a single game, UCI only, POSIX only).
Out of curiosity, is it just your own hobby project, or do you hope to fill a need that cutechess-cli doesn't fill?
Michel wrote:fork is not dirty at all. It is a very clean way to start up processes.
Don't get me wrong: I love fork and use it quite often. I probably prefer it to messing around with pthreads. However, I do feel that the idea of specifying a subroutine that you want to start parallel execution from is conceptually a bit cleaner than splitting the execution at the current line in the code.
However, I do feel that the idea of specifying a subroutine that you want to start parallel execution from is conceptually a bit cleaner than splitting the execution at the current line in the code.
I always have difficulty remembering the signature of such a function and how to pass data to it (usually mucking about with a (void *) pointer)... No such problem with fork()...
Michel wrote:
I always have difficulty remembering the signature of such a function and how to pass data to it (usually mucking about with a (void *) pointer)... No such problem with fork()...
eglebbk@morgaine $./sjef -fcp xsjaak -scp xleo -mg 4 -variant spartan -tc 40/0:05+0
Starting xsjaak
Starting xleo
Intialising program 1...done
Intialising program 2...done
Time control: 40/0:05+0
Starting variant 'spartan' (Sjaak 478M - Leonidas 50) game 1 of 4
0-1 (Black mates)
Starting variant 'spartan' (Leonidas 50 - Sjaak 478M) game 2 of 4
1/2-1/2
Starting variant 'spartan' (Sjaak 478M - Leonidas 50) game 3 of 4
0-1 (Black mates)
Starting variant 'spartan' (Leonidas 50 - Sjaak 478M) game 4 of 4
0-1 (Black mates)
Result: 1 - 1 - 2 (1.5-2.5)
eglebbk@morgaine $
The main thing that's missing is that the resulting games are not written to a .pgn file. Shouldn't be too hard to fix though. I also don't know how robust Sjef is with respect to misbehaving engines (not very, I suspect, since I didn't put a whole lot of effort in that). It currently aborts the match if one of the two engines crashes, while it should probably restart the engine instead. I also haven't tried ponder on matches.
