Ignore lines in winboard protocol

[H.G.Muller]

If careful compatibility with older versions of WinBoard/xboard is of concern (as it is with me, trying to support both Windows and Linux with the same C++ chess engine source code), perhaps there are other options available if "feature debug=1" is rejected.

What you suggest seems indeed a perfectly safe kludge to get stuff in the debug (unless some later version would define parts of what you print as new features). Nevertheless, I would like to encourage people to try the debug=1 feature first, and not immediately go for the kludge.

Note that WinBoard 4.3.14 is also available for Linux (as xboard 4.3.14).

Usually it is not the older versions of WinBoard or compatible GUIs that cause problems: people that have their engines print spurious output by now know pretty well what to avoid. The "do so at your own risk" pertains mostly to the risk that some future version will attach a meaning to something you happened to print. This could in principle also happen inside 'feature' commands.

Most versions of WinBoard do actually have a bug, in the sense that the free-form of the PV field in the Thinking Output is not as free as the protocol specifies, but can confuse WinBoard. I have seen the case where an engine printed the word "Draw" in its PV when it encountered a repetition. WinBoard took this for a result claim!

The suggestion of using '#' for commenting out engine lines actually came from the original WinBoard team's draft for the protocol v3 specs, which one of the team members was kind enough to leak to me. As a similar feature was high on my to-do list as well, it seems better to do it according to their specs, than devise a different mechanism to do the same thing independently.

[Don Cross]

As you write, H.G., it makes a lot of sense for a chess engine to try "feature debug=1" first. And this is what my engine now does. But I am entering my engine in a contest where I don't have choice in the hosting software:

http://www.open-aurec.com/chesswar/Open ... penwar.htm

Note that it links to the version of WinBoard that will be used for this contest:

http://www.ascotti.org/programming/chess/winboard_x.htm

So naturally I want to develop and test for the software that will be used. It responds to my "feature debug=1" with a "rejected debug". Even if my testing indicates that sending debug prints anyway is OK, I don't want to run across some surprise special case in the middle of a game.

I have decided that my program will send "#"-prefixed debug output to stdout only if I get "accepted debug". Otherwise I am going to have my code send debug output to my own separate file.

[H.G.Muller]

Olivier just assured me on the chat that he will be using WinBoard 4.3 for Open War 5. The links given in the announcement page are admittedly a bit confusing; Tim Mann, Alessandro Scotti and I are all mentioned in connection with the WinBoard used, and which version you arrive at depends on which name you click! But the version actually used will be WinBoard 4.3, which suppots the debug feature.

[Don Cross]

Ahhh... thanks for clearing that up, H.G.! I will still write my code as I outlined in my previous post, but now I know I need to download WinBoard 4.3 and use it for my testing.

[Olivier Deville]

Hi Don and HG

I have made the GUI statement more clear Sorry for the confusion.

Olivier

[Michel]

Note that WinBoard 4.3.14 is also available for Linux (as xboard 4.3.14).

I do not really understand this.

I had a quick look at the source of WinBoard 4.3.14 and it seems to contain windows specific code even in backend features. For example uci.c includes window.h (not shielded by an #ifdef). Does this mean that xboard 4.3.14 is not really equivalent to winboard 4.3.14?

Tim Mann has unofficially let me know that his current interest in computer Chess is "roughly zero". I don't think it would be decent to publish an e-mail here that he sent me in private, but when I asked him if he could clarify something that was ambiguous in the protocol specs, his reaction was something along the line: "to know what is wrong, I would have to read your mail, and as it is about computer Chess, and nearly a page long, don't hold your breath". Since then I haven't heard anything from him...

Thanks for the explanation. I am always worried when someone takes an existing program and releases a new version with the same name and a new version number.
I think it is best to have the official permission of the original author (like what happened for the latest versions of Fruit for example).

I think for xboard 4.3 to be included by default in linux distributions it would need a new name unless Tim Mann officially releases his maintainership.

[H.G.Muller]

You are right: the Linux version is not strictly equivalent to the Windows version. For one, it lacks menu support for all the new features added since 4.2.7 (i.e. those of Alessandor and me). And only the back-end features can be used through command-line options in the Linux version, which unfortunately excludes most options added by Alessandro: most of those, such as the font-based rendering, board texture, auxilary windows all were front-end extensions, in the Windows-specific code. So except for a few Winboard_x options, such as the pgnExtendedInfo and the adjudicateLossThreshold, the new options that work in xboard 4.3.14 are mainly the options that I added (which are nearly all pure back-end options).

Apparently the UCI support is implemented by Alessandro by platform-dependent code, and hence not included in the Linux build. Indeed, after checking, I now see that the routines in UCI.c are called from winboard.c, not from backend.c. This seems a bit unnecessary: the code in the UCI.c file does not seem platform-dependent to me at all. It simply escaped my attention when re-integrating the Windows back-end with the xboard front-end. This because I did not have any Linux to try it out on, and have never used the UCI options of WinBoard anyway. So thank you for pointing it out. I will make sure that this will be corrected in the next release. I hope to add some more of the front-end features to xboard anyway in this release, in particular the auxilary windows for engine output and game history.

[Michel]

I hope to add some more of the front-end features to xboard anyway in this release, in particular the auxilary windows for engine output and game history.

Thanks!

Michel