Need help to make Crafty work

[MikeB]

I would grab the latest "official" crafty 25.2.

Crafty 25 welcomes then "scares" me a bit by a warning when I enter command "new":

Code: Select all

unable to open book file [./book.bin].
book is disabled
unable to open book file [./books.bin].

Crafty v25.3

machine has 8 processors

White(1): new
NOTICE:  new command not implemented, please exit and
restart crafty to re-initialize everything for a new game

That's correct - crafty should always be re-iniitalized for a new game, not all GUIs did that in the past.

[hgm]

Then it should specify 'feature reuse=0'. But it says reuse=1 instead.

[MikeB]

Then it should specify 'feature reuse=0'. But it says reuse=1 instead.

Yes, that's correct.

[bob]

something wrong here.

(1) Crafty ALWAYS sends "feature reuse=0". Just checked the source.

(2) Crafty NEVER executes commands out of sequence. It reads and executes them one at a time, in the order they are entered.

Are you running a standard Crafty 25.2 version (last released version by me) or are you using something modified by others? Something is certainly out of whack here...

Here's the relevant code from option.c:

Print(-1, "feature sigint=0 sigterm=0 reuse=0 analyze=1\n");

that is the ONLY place where "feature" is sent. There are several consecutive lines to set features other than the above, but only one occurrence of "reuse=0" is to be found, no instance of "reuse=1" anywhere in the code. IE:

scrappy% grep "reuse=1" *.h *.c
scrappy%

[phhnguyen]

something wrong here.

(1) Crafty ALWAYS sends "feature reuse=0". Just checked the source.

I am using 3 versions of Crafty. The 1st one 23.6 I have downloaded from somewhere as a Mac OS binary. Yes, it sent "feature reuse=1". I will discard it.

I downloaded two others in form of source code and compiled them myself: version 25.3 from Mike B's github and 25.2 from http://www.craftychess.com/downloads/source/. They all sent "feature reuse=0". So good

(2) Crafty NEVER executes commands out of sequence. It reads and executes them one at a time, in the order they are entered.

Are you running a standard Crafty 25.2 version (last released version by me) or are you using something modified by others? Something is certainly out of whack here...

Here's the relevant code from option.c:

Print(-1, "feature sigint=0 sigterm=0 reuse=0 analyze=1\n");

that is the ONLY place where "feature" is sent. There are several consecutive lines to set features other than the above, but only one occurrence of "reuse=0" is to be found, no instance of "reuse=1" anywhere in the code. IE:

scrappy% grep "reuse=1" *.h *.c
scrappy%

I agreed on Crafty runs commands in the right sequence!

However, (as a newbie of chess interface developers) sometimes I feel hard to make Crafty works smoothly under my interface program. Below are a few difficulties I have seen when working with 25.2 (from craftychess.com):

1) If I send command "variant normal", Crafty starts computing immediately. That is not what I want. Even worse, if now I send "force" Crafty will produce a move (e.g "move e4"). AFAIK, in typical situations, Crafty won't produce move for "force" if it is not after a "go". That move (by variant-force) may make troubles if the interface has sent "seaboard" and "go" and then understand the move as the result of the new position and go.

Code: Select all

xboard
protover 2
post
<wait a bit>
variant normal
<wait a bit>
force

Crafty: "move e4"

At the moment, I avoid that problem by not sending the command "variant", but that does not solve the root of the problem. Imagine: if a user uses a GUI and try to switch variants.

2) Crafty insists to work with SAN moves which are not standard of WB protocol:

Code: Select all

xboard
protover 2

<wait a bit>
rejected san
<wait a bit>
sd 10      
go

Crafty prints out:

Code: Select all

ERROR.  feature san rejected by xboard
move Nf3

2) IMHO, Crafty's behaviors for "force" may make some troubles:

- it does not stop computing nor pondering (as describing in WB protocol document):

Code: Select all

xboard
protover 2
post

<wait a bit>

sd 50      
go

<wait a second>

force

=> Crafty is still computing

- not consistent: sometimes it produces moves, sometimes not
- look like it is a redundant copy of command "?"

IMO, it is better it stops all kinds of computing and produces nothing.

(Note that for my chess interface program, "force" is a very important command to prevent engines from unaware computing.)

[hgm]

XBoard does not send a 'variant' command when the variant is 'normal', (as 'new' already switched the variant to 'normal'), so engines might not expect it, and react strangely. This is non-compliant, for sure, but unfortunately non-compliancies that are commonly hidden tend to spread like a plague. Engines that do not report they play any variants though 'feature variants="..."' might not recognize the 'variant' command at all. (Of course they should then just print the CECP-compliant error message "Error (unknown command): variant", but I would not bet on it...)

The 'force' problem is endemic to CECP. In particular the initial specs did not specify whether an interrupted search should print a move or not. There will always be a race condition when sending 'force' to a thinking engine, as the think could end spontaneously, and the move it results in could then cross the 'force' command. So you cannot rely on never receiving a move when you send 'force'. This is the main reason protocol v2 introduced 'ping'; you should always follow 'force' by 'ping', so that you can discard, or force the engine to retract ('undo') any move that you received before the 'pong'. It is like 'force'+'ping' are a force command like it should have been, one that can never be met with silence, but is always acknowledged by either move+'pong' or just 'pong', so you can be sure the optional move was from the interrupted search.

[phhnguyen]

The 'force' problem is endemic to CECP. In particular the initial specs did not specify whether an interrupted search should print a move or not. There will always be a race condition when sending 'force' to a thinking engine, as the think could end spontaneously, and the move it results in could then cross the 'force' command. So you cannot rely on never receiving a move when you send 'force'. This is the main reason protocol v2 introduced 'ping'; you should always follow 'force' by 'ping', so that you can discard, or force the engine to retract ('undo') any move that you received before the 'pong'. It is like 'force'+'ping' are a force command like it should have been, one that can never be met with silence, but is always acknowledged by either move+'pong' or just 'pong', so you can be sure the optional move was from the interrupted search.

That is not an obvious solution to me. If an engine responds "force" immediately and violently stops computing, all are done even before processing to the next command "ping". However, what happens if the engine decides to respond gently by giving a bit more time for its threads for completing? Thus it may print out "move" after "pong". We may have another order: force-ping-pong-move. I think that is popular nowadays because engines may respond to ping very fast since they process input/output in a specific thread when requesting and waiting for all threads to finish current tasks may take a while.

BTW, I don't like some engines start computing unaware, thus I manage to send "force" everywhere I doubt engines may start computing. Can you or someone check if they are overkill and/or be potential trouble? Can any command be discarded? Should any command be added? Thanks

1) Starting:
force
hard/easy
new
force
setboard
force

2) Compute a move:
level
go

3) Opponent made a move:
force
usermove

[hgm]

That is not an obvious solution to me. If an engine responds "force" immediately and violently stops computing, all are done even before processing to the next command "ping". However, what happens if the engine decides to respond gently by giving a bit more time for its threads for completing? Thus it may print out "move" after "pong".

No, that would be a protocol violation. The engine is not allowed to respond to 'ping' before it fully processed all earlier commands, and that includes the 'force'. If 'force' would lead to printing of a move, (or a move would already have been printed when the 'force' was under way), that move would thus surely come before the 'pong'.

We may have another order: force-ping-pong-move. I think that is popular nowadays because engines may respond to ping very fast since they process input/output in a specific thread when requesting and waiting for all threads to finish current tasks may take a while.

Popular or not, it still is a protocol violation.

BTW, I don't like some engines start computing unaware, thus I manage to send "force" everywhere I doubt engines may start computing. Can you or someone check if they are overkill and/or be potential trouble? Can any command be discarded? Should any command be added? Thanks

1) Starting:
force
hard/easy
new
force
setboard
force

2) Compute a move:
level
go

3) Opponent made a move:
force
usermove

You should not send 'level' during the game; XBoard doesn't do that, and engines might interpret it as if it is the start of a game (i.e. reset the move count of the session in classical TC).

There is no need for too much paranoia. Engines should not start thinking unless they are set to play white or black and that color is on move. If they do they are not compliant, and you should just forget about them. Catering to non-compliant engines will encourage non-compliancy to spread; it is evil.

[phhnguyen]

No, that would be a protocol violation. The engine is not allowed to respond to 'ping' before it fully processed all earlier commands, and that includes the 'force'. If 'force' would lead to printing of a move, (or a move would already have been printed when the 'force' was under way), that move would thus surely come before the 'pong'.

...
Popular or not, it still is a protocol violation.

Ah, I missed understanding completely the purpose of ping/pong in Xboard, though they are just similar to the pair isready/readyok of UCI (just to inform interface that the engine is still alive)!

You should not send 'level' during the game; XBoard doesn't do that, and engines might interpret it as if it is the start of a game (i.e. reset the move count of the session in classical TC).

There is no need for too much paranoia. Engines should not start thinking unless they are set to play white or black and that color is on move. If they do they are not compliant, and you should just forget about them. Catering to non-compliant engines will encourage non-compliancy to spread; it is evil.

Thanks, I will fix my program like that.

[bob]

For the record, after I type "go" and wait a couple of seconds and type "force" crafty stops the search instantly. It will probably announce a move, but since you put it into force mode, you probably have something else in mind anyway. Winboard protocol is quite simple. Which means it has a few ambiguities and race conditions. Crafty seems to work perfectly with winboard/xboard as well as my custom tournament manager, which is my goal.

That you can find some convoluted set of commands that cause unexpected behavior is not that surprising. It was never designed to allow all combinations of all possible commands, it was specifically designed to work with winboard/xboard, period. If you use the command set in the way xboard/winboard does, all will be well.