Arena autodetection for CECP/XBoard

[unserializable]

There is report by Manuel Rivera that:

Arena seems unable to autodetect that Hippocampe and Monchester are Winboard engines so just select the option before loading.

Possibly Monchester CECP chatter could be amended so that Arena autodetect for it would function, anyone have idea how Arena does the CECP engine autodetection or what open-source CECP/XBoard engines are definitely and reliably autodetected by Arena?

This is how Monchester acts at startup ('#' prefix is CECP/XBoard commentary that interface should ignore, 'command' is Monchester's user-friendly' prompt that will be switched off after 'xboard' command is received, bold text is command/protocol input given):

$ ./monchester
# Monchester 1.0-20-g094fcee ~(9325 kN/s)
command : xboard
# received xboard
protover 2
feature myname="Monchester 1.0-20-g094fcee" name=1 setboard=1 ping=1 edit=0 memory=0 usermove=0 analyze=0 colors=0 sigint=0 sigterm=0 done=1

If it were to receive 'uci' instead as first input, Monchester behaves as follows:

$ ./monchester
# Monchester 1.0-20-g094fcee ~(9287 kN/s)
command : uci
Unrecognized command
command :

For comparison, the Hippocampe that Arena also supposedly does not detect as CECP engine behaves as follows when fed 'xboard' and then 'protover 2', it is completely quiet when fed 'uci' as first input.

$ ./hippocampe
xboard
protover 2
feature myname="Hippocampe 0.4.2.0.2"
feature ping=1
feature sigint=0
feature sigterm=0
feature variants="normal"
feature done=1

[Pi4Chess]

Take into account that it is on ARM64 linux beta version of Arena and with a non static compilation on Pi4. Default Auto in protocol.
I don't know if behavior is the same on Windows or amd64 linux with non beta Arena version.
Also testing various engines that do not work may have corrupt memory or something in Arena in that moment. I did not tried to reproduce that.

[unserializable]

Take into account that it is on ARM64 linux beta version of Arena and with a non static compilation on Pi4. Default Auto in protocol.
I don't know if behavior is the same on Windows or amd64 linux with non beta Arena version.
Also testing various engines that do not work may have corrupt memory or something in Arena in that moment. I did not tried to reproduce that.

Thanks Manuel, I do not think there are any non-beta versions for Linux, the detection code is unlikely to be different for platform versions though, as per protocols it is likely to rely on standard I/O operations.

From your experience with packaging Pi4 engines, can you name some open-source CECP/XBoard engines that are reliably autodetected by Arena (whichever version), so that I could peek at their behaviour?

[Pi4Chess]

Take into account that it is on ARM64 linux beta version of Arena and with a non static compilation on Pi4. Default Auto in protocol.
I don't know if behavior is the same on Windows or amd64 linux with non beta Arena version.
Also testing various engines that do not work may have corrupt memory or something in Arena in that moment. I did not tried to reproduce that.

Thanks Manuel, I do not think there are any non-beta versions for Linux, the detection code is unlikely to be different for platform versions though, as per protocols it is likely to rely on standard I/O operations.

From your experience with packaging Pi4 engines, can you name some open-source CECP/XBoard engines that are reliably autodetected by Arena (whichever version), so that I could peek at their behaviour?

Crafty is xboard until 25.6 uci version. You can try peek at it.

[unserializable]

Crafty is xboard until 25.6 uci version. You can try peek at it.

Thanks Manuel, I compiled and tried Crafty 25.2. Its I/O chatter is more extensive than Monchesters', so no obvious clues on how to support Arena autodetection, but some assurance that chatter should be okay. It surprised me that Crafty does not support CECP engine instance re-use.

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

Crafty v25.2

machine has 16 processors

White(1): xboard

tellicsnoalias set 1 Crafty v25.2 (1 cpus)
tellicsnoalias kibitz Hello from Crafty v25.2! (1 cpus)
protover 2
feature ping=1 setboard=1 san=1 time=1 draw=1
feature sigint=0 sigterm=0 reuse=0 analyze=1
feature myname="Crafty-25.2" name=1
feature playother=1 colors=0 memory=1
feature smp=1
feature variants="normal,nocastle"
feature done=1
new
NOTICE: new command not implemented, please exit and
restart crafty to re-initialize everything for a new game

Crafty does have some interesting behaviour when started with command-line parameter xboard or when setting environment variable CRAFTY_XBOARD, then it puts some of its chatter between 'feature done=0' and 'feature done=1' blocks when starting up, but as that is not default behaviour, it is unlikely to be useful for autodetection.

$ ./crafty xboard
feature done=0
unable to open book file [./book.bin].
book is disabled
unable to open book file [./books.bin].
(info) command line option "xboard"

tellicsnoalias set 1 Crafty v25.2 (1 cpus)
tellicsnoalias kibitz Hello from Crafty v25.2! (1 cpus)
feature done=1
protover 2
feature ping=1 setboard=1 san=1 time=1 draw=1
feature sigint=0 sigterm=0 reuse=0 analyze=1
feature myname="Crafty-25.2" name=1
feature playother=1 colors=0 memory=1
feature smp=1
feature variants="normal,nocastle"
feature done=1

[Ras]

Crafty is xboard until 25.6 uci version.

Crafty will never be UCI because Bob really doesn't like it.

[Pi4Chess]

Crafty is xboard until 25.6 uci version.

Crafty will never be UCI because Bob really doesn't like it.

Yeah someone else made a UCI version or is it not crafty ?

[Ras]

Yeah someone else made a UCI version or is it not crafty ?

I'd guess it's Crafty, but not UCI. The 25.6 version under https://github.com/MichaelB7/Crafty (tagged as 25.6 in sc/main.c) is CECP like it has always been. Forking Crafty would be a copyright violation because Crafty is not open source, given that it's not under an OSI approved open source licence. You can read the source code, but not more.

[tmokonen]

There were a few compiles made by Jim Ablett which integrated Crafty and WB2UCI into one executable, so that Crafty was usable within Chessbase GUIs without requiring a separate adapter. 25.1 is the most recent "UCI" version that I have.

[Guenther]

There were a few compiles made by Jim Ablett which integrated Crafty and WB2UCI into one executable, so that Crafty was usable within Chessbase GUIs without requiring a separate adapter. 25.1 is the most recent "UCI" version that I have.

A lot of people also simply don't know the difference between the WB2UCI adapter and the real program.
So, if they meet a renamed binary of the original program they just think, 'oh nice', program x is now uci ;)
They don't even care looking at the folder structure and what's behind all of this.
(I should add that some programmers even somehow add to this myth by acting, as if they had now uci implemented - Ed is an example)