threads.c:285:8: error: unknown type name 'pthread_t'
static pthread_t cmprs_threads[COMPRESSION_THREADS];
^~~~~~~~~
threads.c:287:8: error: unknown type name 'pthread_barrier_t'
static pthread_barrier_t cmprs_barrier;
^~~~~~~~~~~~~~~~~
I cannot help you fix a broken gcc installation. How can the compiler not find pthread_t without failing on #include <pthread.h> ????
Is there an option to use C++ 11 threads instead of pthreads?
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
syzygy wrote: ↑Thu Jun 28, 2018 10:51 pm
Thanks, I have found and fixed a problem. I have also fixed the -z option. Unfortunately it will be necessary to regenerate the .rtbz table.
I'm regenerating the table and deleted the old file.
Ah ok, apparently you're trying to compile on Windows. For the moment this is not supported, but you can use an old version from before the 7-men changes. (So if you have a machine with 1TB of RAM and want to generate 7-piece tables, you need to install Linux for now. If you don't have such a machine, there is no reason to use the new code.)
One drawback is tables like KPPPPvK?, they each tend to take 3 full days to build.
The ppppp branch should work though, as long as the tables do not need reductions?
Maybe also a few recent changes/fixes needs to be merged.
noobpwnftw wrote: ↑Sun Jul 01, 2018 4:50 am
One drawback is tables like KPPPPvK?, they each tend to take 3 full days to build.
The ppppp branch should work though, as long as the tables do not need reductions?
Maybe also a few recent changes/fixes needs to be merged.
Yes, the ppppp branch should work as long as no reductions are needed.
I don't think it needs recent changes or fixes (but I will have a look).
If reductions are needed for a table, it may be possible to hack around that problem by reducing (just for that table) DRAW_RULE from 100 to 80 or 60 or so. As long as there are no positions that need 80 (or 60) ply to win or lose, that should be fine. (So if DRAW_RULE is 60 and the statistics stop at 55 and then continue at 61, it should be OK. 61 should then be read as 101 and the .txt file should be fixed.)
My pawnful numa branch should solve all these problems, but it is not ready yet (and the modifications are quite tricky).
noobpwnftw wrote: ↑Sun Jul 01, 2018 4:50 am
One drawback is tables like KPPPPvK?, they each tend to take 3 full days to build.
The ppppp branch should work though, as long as the tables do not need reductions?
Maybe also a few recent changes/fixes needs to be merged.
Yes, the ppppp branch should work as long as no reductions are needed.
I don't think it needs recent changes or fixes (but I will have a look).
If reductions are needed for a table, it may be possible to hack around that problem by reducing (just for that table) DRAW_RULE from 100 to 80 or 60 or so. As long as there are no positions that need 80 (or 60) ply to win or lose, that should be fine. (So if DRAW_RULE is 60 and the statistics stop at 55 and then continue at 61, it should be OK. 61 should then be read as 101 and the .txt file should be fixed.)
My pawnful numa branch should solve all these problems, but it is not ready yet (and the modifications are quite tricky).
Luckily KPPPPvK? tables do not need reduction, now they are built using ppppp branch and I have double checked KPPPPvKQ built using master, they are exactly the same. All 5v2 pawnful tables are now built.