Ugly UCI

[hgm]

The debate about UCI/xBoard protocol seems to have interested a lot of people and the thread gets longer... so the real question is: "is it the right time for a new protocol?".

That question is easily answered. Making new protocols where existing ones could do the job should be considered a captital crime.

Introducing a new protocol produces all the problems you have in extending an existing protocol in an non-backward-compatible way, ten times worse. It is always preferable to extend an existing protocol, and usually this can be done in a perfectly backward-compatible way.

[D Sceviour]

The debate about UCI/xBoard protocol seems to have interested a lot of people and the thread gets longer... so the real question is: "is it the right time for a new protocol?".

That question is easily answered. Making new protocols where existing ones could do the job should be considered a captital crime.

Introducing a new protocol produces all the problems you have in extending an existing protocol in an non-backward-compatible way, ten times worse. It is always preferable to extend an existing protocol, and usually this can be done in a perfectly backward-compatible way.

I agree with most things you have said about WB protocol but this goes too far. There is little to gain by a new protocol, but there is a lot to do to clean up some of the known bugs and irritants in WB2.

[hgm]

What are these bugs and irritants you refer to, and how would you cure them?

[JoshPettus]

I'm no expert in chess programing so forgive me but this doesn't make a lot of sense to me.

Numerous people have complained about CECP (Could we agree to call it by the one name as oppose to Winboard Protocol and Xboard Protocol? That would be dandy) "Bloat".

The only bloat that could be possibly be an issue is any bloat in the documentation. Any other so called "ancient hacks that people don't typically use" are irreverent. What matters is the practice people use today moving forward. We don't need a whole new protocol. Just fix the documentation. A chess protocol is more then allowed to have ancient hacks. We aren't designing an operating system here. There are no security/performance issues at stake. Just move forward in a clean, efficient manner.

[JoshPettus]

Set a standard practice and stick to it. That doesn't require a new protocol.

[D Sceviour]

What are these bugs and irritants you refer to, and how would you cure them?

We have had a number of discussions:

(1) Put the documentation in alphabetical order so people can find things. This is standard practice in all library systems. Items listed in the order of their importance are a separate algorithm for logical presentation, and not standard practice for documentation. The unorganized documentation is an irritant.

(2) Include the polyglot version that does not display extra headers in the output window. I know it exists since I have used it before (I cannot find it since a HD crash).

(3) Some people have complained about a spurious "undo" although it does not bother me.

(4) Encourage Bob Hyatt to clean up "option.c" so you do not have to accuse Crafty of causing problems.

(5) Include a Fixed Search Depth box for games. This is a very convenient feature in Arena. One cannot assume all users of WB are instant experts.

(6) Eliminate duplicate GUI commands in the menu, such as "Tags" and "Edit Tags". (Sorry, I intended to forward a suggested menu but I have not gotten around to it.)

(7) The "force" command is still overloaded. I found it the most difficult command to start with, and a special note should show the various locations where the force variable has to be set or cleared, such as "go".

(8) Tie the "abort" command to "Match Machine".

(9) Stop timer when doing debug output from WB so there is no penalty on the clock.

(10) Fix the menu fonts for slim window sizes.

Let's hear some more bugs. I still like Winboard.

[hgm]

We have had a number of discussions:

What you mention are almost exclusively (perceived) defects of WinBoard. Which is completely off-topic in this thread, as we were having a discussion about communication protocols. Documentation of a protocol already gets closer to it, but still is an independent subject. Excellent protocols can be poorly documented, and greatly documented protocols can utterly suck. None of what you mention would require any change in the protocol, to be fixed/altered.

I can comment on some of your remarks, though:

(2) Include the polyglot version that does not display extra headers in the output window. I know it exists since I have used it before (I cannot find it since a HD crash).

It is WinBoard that puts the headers there, not Polyglot.

(3) Some people have complained about a spurious "undo" although it does not bother me.

Indeed, that happened in ICS play. Obviously a WinBoard/XBoard bug, but I am still thinking about a fix. It was not a simple matter.

(4) Encourage Bob Hyatt to clean up "option.c" so you do not have to accuse Crafty of causing problems.

Not sure what this has to do with anything...

(5) Include a Fixed Search Depth box for games. This is a very convenient feature in Arena. One cannot assume all users of WB are instant experts.

I happen to think fixed-depth searches are an evil thing, that should never be used by non-experts. I don't want to encourage the use of it.

(6) Eliminate duplicate GUI commands in the menu, such as "Tags" and "Edit Tags". (Sorry, I intended to forward a suggested menu but I have not gotten around to it.)

I don't think duplicate menu entries do any harm, and sometimes they can even be desirable. (E.g. if you want to regularly do the same thing in combination with other stuff that requires different dialogs, it would be much better to have it in both dialogs than requiring the user to close one and open the other, just so it can be in only one of them.)

(7) The "force" command is still overloaded. I found it the most difficult command to start with, and a special note should show the various locations where the force variable has to be set or cleared, such as "go".

There should not be such a thing as a 'force variable'. The specs certainly do not define one. An engine has 4 states: play white, play black, force mode and analyze mode. The 'go' command alters the state, (possibly from 'force mode'), to 'play white/black'. If you get into a new state, you automatically leave the old one. If you represent the states in a radio-button-like manner, there will exist impossible combinations, and you will have to take care of resetting all other buttons when one gets pressed. That is just because it is a clumsy implementation.

(8) Tie the "abort" command to "Match Machine".

Bad idea. Abort is for aborting a game. That does not automatically mean you want to terminate the match.

(9) Stop timer when doing debug output from WB so there is no penalty on the clock.

I don't believe there is any measurable penalty on the clock under normal circumstances.

(10) Fix the menu fonts for slim window sizes.

Aren't menu fonts controlled by the operating system? I am not aware of any place in the WinBoard source code where we specify a font for that. (Unlike with the XBoard Xaw build, where -messageFont is a command-line option.)

[D Sceviour]

We have had a number of discussions:

What you mention are almost exclusively (perceived) defects of WinBoard. Which is completely off-topic in this thread, as we were having a discussion about communication protocols. Documentation of a protocol already gets closer to it, but still is an independent subject. Excellent protocols can be poorly documented, and greatly documented protocols can utterly suck. None of what you mention would require any change in the protocol, to be fixed/altered.

I can comment on some of your remarks, though:

(2) Include the polyglot version that does not display extra headers in the output window. I know it exists since I have used it before (I cannot find it since a HD crash).

It is WinBoard that puts the headers there, not Polyglot.

(3) Some people have complained about a spurious "undo" although it does not bother me.

Indeed, that happened in ICS play. Obviously a WinBoard/XBoard bug, but I am still thinking about a fix. It was not a simple matter.

(4) Encourage Bob Hyatt to clean up "option.c" so you do not have to accuse Crafty of causing problems.

Not sure what this has to do with anything...

(5) Include a Fixed Search Depth box for games. This is a very convenient feature in Arena. One cannot assume all users of WB are instant experts.

I happen to think fixed-depth searches are an evil thing, that should never be used by non-experts. I don't want to encourage the use of it.

(6) Eliminate duplicate GUI commands in the menu, such as "Tags" and "Edit Tags". (Sorry, I intended to forward a suggested menu but I have not gotten around to it.)

I don't think duplicate menu entries do any harm, and sometimes they can even be desirable. (E.g. if you want to regularly do the same thing in combination with other stuff that requires different dialogs, it would be much better to have it in both dialogs than requiring the user to close one and open the other, just so it can be in only one of them.)

(7) The "force" command is still overloaded. I found it the most difficult command to start with, and a special note should show the various locations where the force variable has to be set or cleared, such as "go".

There should not be such a thing as a 'force variable'. The specs certainly do not define one. An engine has 4 states: play white, play black, force mode and analyze mode. The 'go' command alters the state, (possibly from 'force mode'), to 'play white/black'. If you get into a new state, you automatically leave the old one. If you represent the states in a radio-button-like manner, there will exist impossible combinations, and you will have to take care of resetting all other buttons when one gets pressed. That is just because it is a clumsy implementation.

(8) Tie the "abort" command to "Match Machine".

Bad idea. Abort is for aborting a game. That does not automatically mean you want to terminate the match.

(9) Stop timer when doing debug output from WB so there is no penalty on the clock.

I don't believe there is any measurable penalty on the clock under normal circumstances.

(10) Fix the menu fonts for slim window sizes.

Aren't menu fonts controlled by the operating system? I am not aware of any place in the WinBoard source code where we specify a font for that. (Unlike with the XBoard Xaw build, where -messageFont is a command-line option.)

The discussion is directed towards ugly WinBoard.

(2) Polyglot must have something to do with it because the problem occurs/disappears with different Polyglot compile dates.

(5) Set depth levels are essential for engine developers. As I recall, the early stand-alone machines (Chess Challenger) deliberately included depth level searches, so it is common and certainly not unused. What is so evil about them?

(8) Then add an "Abort Match" command.

(10) For the appropriate window sizes, use a three-letter combination for menu headers so the headers do not overlap:

Fil Edi Vie Mod Act Eng Opt Hlp

[hgm]

The discussion is directed towards ugly WinBoard.

That is known as 'thread hijacking', and action considered loathsome by many...

(2) Polyglot must have something to do with it because the problem occurs/disappears with different Polyglot compile dates.

Well, it is not entirely clear which headers you are talking about. There is a multi-PV header (which should only appear for engines that support a MultiPV option in analyze mode), and exclusion header, and a header for opening and closing the engine-output column. The latter can be switched on or off in the General Options dialog. The exclusion header should really only appear during analysis for engines that support the exclude feature. But it seems that it appears always, which should be considered a WinBoard bug. Only recent Polyglots support the exclude feature, even when the UCI engine does not (as one of the defects of UCI is that there is no way for engines to tell the GUI whether they support move exclusion or not). But I don't see how that could affect matters if the WinBoard bug causes the line to be displayed even for engines (and thus Polyglots) that do not support the exclude feature.

(5) Set depth levels are essential for engine developers. As I recall, the early stand-alone machines (Chess Challenger) deliberately included depth level searches, so it is common and certainly not unused. What is so evil about them?

I developed many engines, and never used fixed depth... Chess Challenger played Chess that sucked beyond description, so it hardly deserves following. Evil is that all engines interpret depth in a different way, and that setting fixed depth leads to highly unnatral allocation of thinking time over the game. E.g. at d=10 it plays middle game at master level, and then as a complete idiot lets the opponent's Pawns queen in a Pawn ending.

And if you are an engine developer, and you feel you rally need this, it seems trivial to allow setting it on your engine through a command-line option.

(8) Then add an "Abort Match" command.

You can switch off the match by clicking Machine Match again; it is a toggle, and the checkmark in front of it indicates the state. It will stop after completion of the current game. (Which is what you usually want.) If you want to stop immediately you can then abort that game. (Or you can simply close WinBoard.)

(10) For the appropriate window sizes, use a three-letter combination for menu headers so the headers do not overlap:

Fil Edi Vie Mod Act Eng Opt Hlp

I think I already fixed that, in the development version.

[flok]

I really don't get why (some) UCI fans feel the need to put down CECP or people who prefer that as a protocol.

Funny. I thought the same of the CECP people.