booot 7.0 final release

[pohl4711]

Cutechess-cli is not the problem. If it is used for testing by engine-developers, it is the solution for getting a proper working engine in all GUIs!

Forgot to say: Cutechess-cli is also used, playing the TCEC. Another good reason for using cuteches-cli for testing, not any of these "GUI"s, doing weird things...

[Modern Times]

One of our testers a while ago reported that a handful of engines do have issues with concurrency under Cutechess-CLi, maybe Booot is one more.

[booot]

Our tester Jörg uses Cutechess GUI , not "cli".
No problems there too

Hm.... So the bug nest is located. I will take a look to "cli' - i have never used it before.

The bug nest is the booot7 engine. Cutechess-cli is a commandline-tool. If an engine does not work there, it is buggy. If other GUIs ignore bogus engine outputs, that does not make the engine working correctly. Just hiding its buggy behaviour.
So, Cutechess-cli should always be the first test-tool for any engine. If an engine runs fine on this deep command-line level, without any GUI (doing weird things on their own), the engine is OK.
Strange thing here is: If I try to start a booot7-test gauntlet on a fresh restarted (offline) PC, some of the 20 booot-instances are terminating (as I wrote before). When I stop cutechess-cli and restart the gautlet immediately, then all 20 booot7 instances seem to run. So, perhaps a memory-allocation bug or so in booot7. Mention, that I tested more than 150 engines/versions in the last 2 years on this PC, using cutechess-cli. Never had such a strange behaviour of an engine until now. The illegal PV-move warnings were caused by some (rare) engines/versions before (first Uralochka for example). But they were all fixed by the engine authors.
Cutechess-cli is not the problem. If it is used for testing by engine-developers, it is the solution for getting a proper working engine in all GUIs!

I understand : problem is in Booot. May be some mistakes in UCI protocol implementation, may be some other bugs. I will take a look on this. It is interesting.

[booot]

One of our testers a while ago reported that a handful of engines do have issues with concurrency under Cutechess-CLi, maybe Booot is one more.

Most probably the problem is somewhere in stdout-stdin implementation (for uci protocol). Delphi is quite uncommon language to make terminal applications. And i am not a programmer to 'feel' this. So the task could be even more difficult than increasing engine strength.

[Pvt. Ryan]

Hi. How would you turn off the embedded neural network for chess engine matches under cutechess-cli? Cheers.

[Steve Maughan]

Hi Alex,

My main language is Delphi (although Maverick is written in C) and I'm creating a new chess engine in Delphi and grappling with the stdin and stdout interface at the moment. ChatGPT has been somewhat helpful. Currently I'm using the main thread to read the input (with a simple Readln command) and have the engine in a separate thread. I believe stdout is thread safe in that the engine thread, which will be the only thread to send output to stdout, can safely send commands.

— Steve

One of our testers a while ago reported that a handful of engines do have issues with concurrency under Cutechess-CLi, maybe Booot is one more.

Most probably the problem is somewhere in stdout-stdin implementation (for uci protocol). Delphi is quite uncommon language to make terminal applications. And i am not a programmer to 'feel' this. So the task could be even more difficult than increasing engine strength.

[GONeill]

Hi Alex,

My main language is Delphi (although Maverick is written in C) and I'm creating a new chess engine in Delphi and grappling with the stdin and stdout interface at the moment. ChatGPT has been somewhat helpful. Currently I'm using the main thread to read the input (with a simple Readln command) and have the engine in a separate thread. I believe stdout is thread safe in that the engine thread, which will be the only thread to send output to stdout, can safely send commands.

— Steve

Hi Steve,

I don't know about Delphi, but Lazarus/FPC has a Pipes unit and I use:

Code: Select all

   GUIinput:=TInputPipeStream.Create(StdInputHandle);
   GUIoutput:=TOutputPipeStream.Create(StdOutputHandle);

Seems to work OK.

Graham

[Steve Maughan]

Thanks Graham,

It looks like Delphi doesn't have this unit. I'll investigate further — maybe I can copy it from FPC.

— Steve

Hi Steve,

I don't know about Delphi, but Lazarus/FPC has a Pipes unit and I use:

Code: Select all

   GUIinput:=TInputPipeStream.Create(StdInputHandle);
   GUIoutput:=TOutputPipeStream.Create(StdOutputHandle);

Seems to work OK.

Graham

[Roland Chastain]

Hello everybody!

It looks like Delphi doesn't have this unit. I'll investigate further — maybe I can copy it from FPC.

I don't believe that you need pipes for an engine. You would need it rather for a GUI.

By the way, I remember that there is a Delphi version of the Process unit, but I cannot find where I downloaded it, and I no longer have it on my HD. I could search more if you are interested. But, once again, it is not needed for an engine.

Currently I'm using the main thread to read the input (with a simple Readln command) and have the engine in a separate thread. I believe stdout is thread safe in that the engine thread, which will be the only thread to send output to stdout, can safely send commands.

This is what I do in my Pascal engines, and I never had problems. It has the advantage to make engines multiplatform, since you don't use any OS specific stuff. This is also what I did in a previous version of Booot that I modified to make it compatible with Linux.

Regards.

Roland