GNU Chess 6 (= Fruit)

[hgm]

It seems that what they are doing is use the old GNU Chess 5 front-end as main program, which internally runs Polyglot and Fruit as additional threads. The threads communicate through pipes in the usual way. So you would have XBoard communicate (through an external pipe) to the front-end, which then communicates in XBoard protocol to Polyglot, which then communicates in UCI to Fruit. The user would simply see this as a singlemulti-threaded process, started by calling the front-end. The front-end would be augmented by a UCI mode, in which case it would refrain from creating the Polyglot thread, but connect (through the internal pipe) directly to Fruit.

This is a bit contrived, and potential worries are:

* The long chain of command drives up communication delays. Simply re-writing the Fruit protocol driver to use XBoard protocol would have reduced the chain length by 1 (eliminating the need for Polyglot) rather than increasing it to 3.
* The GNU font-end is quite non-compliant with XBoard protocol to start with (although XBoard is unreasonably tolerant to GNU Chess' protocol violations), but also does not implement any of the new commands used by XBoard, and essential for providing an interface competitive to what you have running Fruit in UCI mode.
* The Polyglot they use is the hopelessly obsolete Polyglot 1.4, which also does not implement the new XBoard protocol, and cannot be compiled for Windows without making the program cygwin1.dll-dependent.

[Giorgio Medeot]

Thanks for your comments, Fabien. This way it makes a little more sense to me.

• Giorgio

[michiguel]

It seems that what they are doing is use the old GNU Chess 5 front-end as main program, which internally runs Polyglot and Fruit as additional threads. The threads communicate through pipes in the usual way. So you would have XBoard communicate (through an external pipe) to the front-end, which then communicates in XBoard protocol to Polyglot, which then communicates in UCI to Fruit. The user would simply see this as a singlemulti-threaded process, started by calling the front-end. The front-end would be augmented by a UCI mode, in which case it would refrain from creating the Polyglot thread, but connect (through the internal pipe) directly to Fruit.

This is a bit contrived, and potential worries are:

* The long chain of command drives up communication delays. Simply re-writing the Fruit protocol driver to use XBoard protocol would have reduced the chain length by 1 (eliminating the need for Polyglot) rather than increasing it to 3.
* The GNU font-end is quite non-compliant with XBoard protocol to start with (although XBoard is unreasonably tolerant to GNU Chess' protocol violations), but also does not implement any of the new commands used by XBoard, and essential for providing an interface competitive to what you have running Fruit in UCI mode.
* The Polyglot they use is the hopelessly obsolete Polyglot 1.4, which also does not implement the new XBoard protocol, and cannot be compiled for Windows without making the program cygwin1.dll-dependent.

One of the main problems of xboard has been its "unreasonable" tolerance to GNU chess over the years. You inherited the problem, which delayed the progress of the protocol, it was messy, encouraged useless backward compatibilities, and as a consequence, it generated the need of a new protocol. Unfortunately, UCI was not a perfect answer (IMHO). Now, xboard protocol picked it up to a point in which is at least equal in many aspects to UCI and superior in the rest (IMHO). However, the UCI inertia is not easy to overcome. So, if this GNU chess 6 see the light with new incompatibilities, it will create the effect of being counter productive w/o adding anything new. PLEASE, if that happens, DO NOT TRY to keep compatibility with it and drop it at once!

Miguel

[hgm]

Don't worry, I won't.

In fact I have already dropped GNU Chess as default engine, in favor of Fairy-Max, and WinBoard is distributed with Fruit 2.1 (the real thing) and Poltglot 1.4.63b. That works like a charm, and unless they can provide something that works at least as good with current WinBoard protocol, I won't consider to readopt it. In fact including the UCI version of Fruit has my preference, because apart from being a useful engine, it can act as example for how to install UCI engines, Fairy-Max already being the WB model engine.

[Michel]

he GNU font-end is quite non-compliant with XBoard protocol to start with

Well in the version 5.07 I had been maintaining I had adapted the frontend to make it completely compliant. Which I told them on the mailing list....

[hgm]

I guess they are more worried about preserving the original GNU Chess interface than about making a protocol-compliant engine. Otherwise their design choices would be hard to defend.

[Michel]

Hello Michel,

GnuChess supports UCI natively?

This is really news that I totally missed.

Sigh.

This is the version currently available for download?

Well the version I had been maintaining is here

http://alpha.uhasselt.be/Research/Algeb ... s-release/

I tried to make it a good citizen but with the release of GnuChess 6 I guess it has become a genuine fork, which was never my intention.

[michiguel]

Hello Michel,

GnuChess supports UCI natively?

This is really news that I totally missed.

Sigh.

This is the version currently available for download?

Well the version I had been maintaining is here

http://alpha.uhasselt.be/Research/Algeb ... s-release/

I tried to make it a good citizen but with the release of GnuChess 6 I guess it has become a genuine fork, which was never my intention.

I think I will soon download it and test it. I am always eager to find Gaviota sparrings, but I was too busy with other gazillion things. Previous GNUchess versions were too unstable.

Is the tablebase support already in this version? Just to update Gaviota's website.

Miguel

[Dann Corbit]

I guess they are more worried about preserving the original GNU Chess interface than about making a protocol-compliant engine. Otherwise their design choices would be hard to defend.

At least the current version compiles with Mingw, so in that sense it is better than 5.07 which won't even compile on my machines other than Posix.

Even so, I think that the modified versions are clearly an improvement in many ways.

[hgm]

If with 'current version' you mean 5.08: I am not talking about that. I am talking about GNU Chess 6.