crafty-22.0

[Guetti]

Ok, I started all over again with the same result. Here is my take:

in chess.h line 131-132
# define lock_t volatile int
# include "lock.h"

lock_t is already defined in lock.h. I just commented it, no major problem.
But in lock.h you have for Unix (line 116-end):


#else
# define LockInit(p)
# define LockFree(p)
# define Lock(p)
# define Unlock(p)
# define lock_t "volatile int"
# define pthread_attr_t HANDLE
# define pthread_t HANDLE
# define thread_t HANDLE
#endif /* SMP code */

Now, the line #define lock_t "volatile" int"
leads to an error in all further appearances of lock_t in chess.h because of the "".

chess.h:353: error: expected specifier-qualifier-list before string constant
chess.h:393: error: expected specifier-qualifier-list before string constant

changing that to
# define lock_t volatile int
Now chess.h compiles, but the HANDLE stuff leads to an error in the includes of my gentoo system:
In file included from /usr/include/bits/sigthread.h:8,
from /usr/include/gentoo-multilib/amd64/signal.h:387,
from /usr/include/signal.h:8,
from utility.c:45,
from crafty.c:19:
/usr/include/gentoo-multilib/amd64/bits/sigthread.h:36: error: expected ')' before '__threadid'

Removing the 3 lines
# define pthread_attr_t HANDLE
# define pthread_t HANDLE
# define thread_t HANDLE
and now crafty compiles fine.

Compiled with:

linux64:
$(MAKE) target=LINUX \
CC=gcc CXX=g++ \
CFLAGS='$(CFLAGS) -Wall -pipe \
-fbranch-probabilities -fomit-frame-pointer -O3 -march=k8' \
CXFLAGS=$(CFLAGS) \
LDFLAGS='$(LDFLAGS) -lstdc++' \
opt='$(opt) -DINLINE64 -DCPUS=1' \
crafty-make

[bob]

it fails if you don't have CPUS defined in your makefile.

That is the purpose of checking to see if CPUS is defined, and setting it to 1 if it is not...

[bob]

A compile error, a feature request and a minor bug.
1. in epd.c you need to move chess.h above epddefs.h

Done...

2. Could you add a linelength command to control the display of PVs ? No one has 80 column terminals anymore, and it would also make parsing logfiles much easier.

non-trivial, but I will do this for 22.1 as well...

3. If you compile with DEBUG defined, and try to annotate a PGN file with a FEN string, crafty exits immediately with the message
ERROR! hash_key is bad.

That is more serious and I will look at it right now. Might take another 22.0 release to make this work right, although I am not sure why it is broken since that code was unchanged...

[Event "London"]
[Site "?"]
[Date "1922.??.??"]
[Round "?"]
[White "Reti"]
[Black "Borovsky, Znosko"]
[Result "1-0"]
[FEN "3q1r2/1p1b1pk1/pn5p/3pN1pQ/3P3P/2r3B1/P4PP1/3RR1K1 w - - 0 1"]

1. Nxf7 Rxf7 2. Be5+ Rf6 3. hxg5 hxg5 4. Qxg5+ Kf7 5. Qh5+
Kg7 (5... Kg8 6. Qh4) 6. g4 Nc4 7. Qg5+ Kf7 8. Bxf6 Qxf6 9. Qxd5+ Be6 10. Qxb7+
Kg8 11. Qxa6 $18 1-0

[bob]

It is compiling and running cleanly here... I should add are you sure that is the best target? that is a NUMA compile and you might or might not have libnuma installed... But for me, on my suse 10.2 and suse 10.3 64 bit boxes, either make linux-64 (uses intel compiler which is faster) and make linux-amd64 (uses gcc + libnuma) work perfectly. Do you have some old .h files laying around or perhaps old source that got mixed in? 22.0 is _drastically_ different from 21.7 in terms of data values, structures, etc...

Here is what I get on the make linux-amd64 on my suse laptop:

scrappy% make linux-amd64
make target=LINUX \
CC=gcc CXX=g++ \
CFLAGS=' -Wall -pipe \
-fbranch-probabilities -fomit-frame-pointer -O3 -march=k8' \
CXFLAGS= \
LDFLAGS=' -lnuma -lstdc++' \
opt=' -DINLINE64 -DCPUS=8 -DNUMA -DLIBNUMA' \
crafty-make
make[1]: Entering directory `/home/hyatt/crafty'
make[2]: Entering directory `/home/hyatt/crafty'
gcc -Wall -pipe \
-fbranch-probabilities -fomit-frame-pointer -O3 -march=k8 -DINLI
NE64 -DCPUS=8 -DNUMA -DLIBNUMA -DLINUX -c crafty.c
crafty.c: In function ‘ValidatePosition’:
crafty.c:46: note: file crafty.gcda not found, execution counts estimated
g++ -c -DINLINE64 -DCPUS=8 -DNUMA -DLIBNUMA -DLINUX egtb.cpp
egtb.cpp:4478: warning: ‘TB_CRC_CHECK’ initialized and declared ‘extern’
gcc -lnuma -lstdc++ -o crafty crafty.o egtb.o -lm
make[2]: Leaving directory `/home/hyatt/crafty'
make[1]: Leaving directory `/home/hyatt/crafty'

It also ran just fine...

So, which is the correct target to build for gcc, Linux 64-bit, Athlon64 and 1 CPU?
I think it was failing because I have only 1 CPU. As you can see I removed the -DLIBNUMA -DNUMA and -lnuma -DCPUS from linux-amd64 in the Makefile. But it didn't work.

chess.h:353: error: expected specifier-qualifier-list before string constant
chess.h:393: error: expected specifier-qualifier-list before string constant

You should always have -DCPUS defined, just set to 1 if you don't want an SMP executable... Otherwise I use linux-64 myself because it uses the Intel compiler which is better, but I use linux-amd64 on 64 bit boxes that don't have ICC installed...

[bob]

Ok, I started all over again with the same result. Here is my take:

in chess.h line 131-132
# define lock_t volatile int
# include "lock.h"

lock_t is already defined in lock.h. I just commented it, no major problem.
But in lock.h you have for Unix (line 116-end):


#else
# define LockInit(p)
# define LockFree(p)
# define Lock(p)
# define Unlock(p)
# define lock_t "volatile int"
# define pthread_attr_t HANDLE
# define pthread_t HANDLE
# define thread_t HANDLE
#endif /* SMP code */

Now, the line #define lock_t "volatile" int"
leads to an error in all further appearances of lock_t in chess.h because of the "".

chess.h:353: error: expected specifier-qualifier-list before string constant
chess.h:393: error: expected specifier-qualifier-list before string constant

changing that to
# define lock_t volatile int
Now chess.h compiles, but the HANDLE stuff leads to an error in the includes of my gentoo system:
In file included from /usr/include/bits/sigthread.h:8,
from /usr/include/gentoo-multilib/amd64/signal.h:387,
from /usr/include/signal.h:8,
from utility.c:45,
from crafty.c:19:
/usr/include/gentoo-multilib/amd64/bits/sigthread.h:36: error: expected ')' before '__threadid'

Removing the 3 lines
# define pthread_attr_t HANDLE
# define pthread_t HANDLE
# define thread_t HANDLE
and now crafty compiles fine.

Compiled with:

linux64:
$(MAKE) target=LINUX \
CC=gcc CXX=g++ \
CFLAGS='$(CFLAGS) -Wall -pipe \
-fbranch-probabilities -fomit-frame-pointer -O3 -march=k8' \
CXFLAGS=$(CFLAGS) \
LDFLAGS='$(LDFLAGS) -lstdc++' \
opt='$(opt) -DINLINE64 -DCPUS=1' \
crafty-make

OK, I didn't even notice the quotes and am not sure where they came from in fact. I have removed them however...

[bob]

A compile error, a feature request and a minor bug.
1. in epd.c you need to move chess.h above epddefs.h
2. Could you add a linelength command to control the display of PVs ? No one has 80 column terminals anymore, and it would also make parsing logfiles much easier.
3. If you compile with DEBUG defined, and try to annotate a PGN file with a FEN string, crafty exits immediately with the message
ERROR! hash_key is bad.

[Event "London"]
[Site "?"]
[Date "1922.??.??"]
[Round "?"]
[White "Reti"]
[Black "Borovsky, Znosko"]
[Result "1-0"]
[FEN "3q1r2/1p1b1pk1/pn5p/3pN1pQ/3P3P/2r3B1/P4PP1/3RR1K1 w - - 0 1"]

1. Nxf7 Rxf7 2. Be5+ Rf6 3. hxg5 hxg5 4. Qxg5+ Kf7 5. Qh5+
Kg7 (5... Kg8 6. Qh4) 6. g4 Nc4 7. Qg5+ Kf7 8. Bxf6 Qxf6 9. Qxd5+ Be6 10. Qxb7+
Kg8 11. Qxa6 $18 1-0

This last bug I can't reproduce. Can you give me the exact annotate command you are using? I used your PGN above but it worked fine...

[jwes]

It fails for me with any legal annotate string. i used
annotate a.pgn bw 1 1 1

It seems to work fine in release versions, but it fails for me in any debug version since 19.19 (it worked in 19.12).

[jwes]

2. Could you add a linelength command to control the display of PVs ? No one has 80 column terminals anymore, and it would also make parsing logfiles much easier.

non-trivial, but I will do this for 22.1 as well...

I just changed the constant 34 to linelength-46 at lines 689-690 and it worked for me.

[bob]

2. Could you add a linelength command to control the display of PVs ? No one has 80 column terminals anymore, and it would also make parsing logfiles much easier.

non-trivial, but I will do this for 22.1 as well...

I just changed the constant 34 to linelength-46 at lines 689-690 and it worked for me.

So you only want to change the PV length? I was thinking about all output, which includes those long egtb mate pvs and the like...

[jwes]

The PV length is the only one that concerns me.