I wrote a simple tool, similar to cutechess-cli. The source code is 100% original, and uses no third party libraries, so it's very lightweight (ie. no C++ STL, Qt, Glib, or whatever). Just plain C and POSIX. Hopefully it's all explained in the readme, how to compile and use: https://github.com/lucasart/c-chess-cli
Compatibility:
OS: should work on any POSIX system, including MacOS, Android, perhaps even Windows with msys2. But I've only tested on Linux.
Compiler: only supports GCC or Clang. tested with both.
C standard library: only tested with glibc or musl.
Of course, it doesn't have nearly as many features as cutechess-cli. But I think I've built all the basics right (molulo bugs ), and can easily extend from there.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
lucasart wrote: ↑Sun May 17, 2020 3:56 am
I wrote a simple tool, similar to cutechess-cli. The source code is 100% original, and uses no third party libraries, so it's very lightweight (ie. no C++ STL, Qt, Glib, or whatever). Just plain C and POSIX. Hopefully it's all explained in the readme, how to compile and use: https://github.com/lucasart/c-chess-cli
Compatibility:
OS: should work on any POSIX system, including MacOS, Android, perhaps even Windows with msys2. But I've only tested on Linux.
Compiler: only supports GCC or Clang. tested with both.
C standard library: only tested with glibc or musl.
Of course, it doesn't have nearly as many features as cutechess-cli. But I think I've built all the basics right (molulo bugs ), and can easily extend from there.
When compiling I'm getting a warning (gcc version 8.4.0 (Ubuntu 8.4.0-1ubuntu1~18.04)):
void* threadedFunction(void *args) {
int threadID = (long long) args;
printf("Starting a Thread! (#%d)", threadID);
return NULL;
}
int main() {
pthread_t thread;
pthread_create(&thread, NULL, &threadedFunction, (void*)1);
pthread_join(thread, NULL);
}
#WeAreAllDraude #JusticeForDraude #RememberDraude #LeptirBigUltra "Those who can't do, clone instead" - Eduard ( A real life friend, not this forum's Eduard )
lucasart wrote: ↑Sun May 17, 2020 3:56 am
I wrote a simple tool, similar to cutechess-cli. The source code is 100% original, and uses no third party libraries, so it's very lightweight (ie. no C++ STL, Qt, Glib, or whatever). Just plain C and POSIX. Hopefully it's all explained in the readme, how to compile and use: https://github.com/lucasart/c-chess-cli
Compatibility:
OS: should work on any POSIX system, including MacOS, Android, perhaps even Windows with msys2. But I've only tested on Linux.
Compiler: only supports GCC or Clang. tested with both.
C standard library: only tested with glibc or musl.
Of course, it doesn't have nearly as many features as cutechess-cli. But I think I've built all the basics right (molulo bugs ), and can easily extend from there.
AndrewGrant wrote: ↑Tue May 19, 2020 4:21 pmHe does this to get a threadID. Its a nice solution to passing just an integer.
I'm not sure, but I suspect this is undefined behaviour. A proper solution isn't even that ugly - just change the array of integers into an array of structs with thread ID and integer argument, and then pass the addresses of the struct components for the i-th thread.
lucasart wrote: ↑Sun May 17, 2020 3:56 am
I wrote a simple tool, similar to cutechess-cli. The source code is 100% original, and uses no third party libraries, so it's very lightweight (ie. no C++ STL, Qt, Glib, or whatever). Just plain C and POSIX. Hopefully it's all explained in the readme, how to compile and use: https://github.com/lucasart/c-chess-cli
Compatibility:
OS: should work on any POSIX system, including MacOS, Android, perhaps even Windows with msys2. But I've only tested on Linux.
Compiler: only supports GCC or Clang. tested with both.
C standard library: only tested with glibc or musl.
Of course, it doesn't have nearly as many features as cutechess-cli. But I think I've built all the basics right (molulo bugs ), and can easily extend from there.
AndrewGrant wrote: ↑Tue May 19, 2020 4:21 pmHe does this to get a threadID. Its a nice solution to passing just an integer.
I'm not sure, but I suspect this is undefined behaviour. A proper solution isn't even that ugly - just change the array of integers into an array of structs with thread ID and integer argument, and then pass the addresses of the struct components for the i-th thread.
Yes, that's the plan. Eventually, I will need such an array of struct, as I will do some synchronization for main thread to ping engines, and detect timeouts.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
Joerg Oster wrote: ↑Tue May 19, 2020 10:08 pmA summary of the result at the end would be nice.
Yes, I have 3 things to implement, which must be done in the main thread, and require some synchronization. Here they are, by level of difficulty:
Periodic updates on results: main thread read results of worker threads, add them up, and show the user (with proper locking, of course).
Detect timeout. This can't be done in the worker threads, just checking time after each read (eg. info line waiting for bestmove line). I can't put any upper bound to the time between 2 such reads, and must assume that engines are buggy, so they crash and don't respect the time allocated. I think the proper solution is to do this in the main thread periodically.
Ping engines periodically: send isready, and wait (with a timeout) for readyok. Problem is, reading a line with a timeout is surprisingly complicated. No, a simple select() of poll() won't work, at least not 100% of the time (engine could be trolling and send a few char without \n then never send anything). Unless anyone has an idea, it seems the only reliable solution is to spwan yet another thread, just for the purpose of reading a line with a timeout (a controlling thread, which checks time periodically, and if the reading thread hasn't ready, then die).
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.