Ugly UCI

[D Sceviour]

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.

(5) It is difficult to see how an engine developer could proceed without using a depth first search. For example, I completed an overhaul of the futility prunes. The first thing was to do a sanity test with sd=3 to find any omissions. Sure enough, there were errors, and they were much easier to trace than trying to find the error at a ply depth of 17. I have never used the Winboard command line option for depth, so I suppose I should look at it, but Arena seems much easier since I only need to click a flag to get on with business.

[bob]

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.

What problems are being caused by option.c in Crafty??? I run xboard matches all the time and don't see any issues whatsoever, except with other engines that send far too much output and tend to cause xboard itself to lag...

My one suggestion would be to always, after the select() unblocks, read from the on-move engine's pipe first, so that a pondering opponent can't penalize my time after I have already made a move but xboard is busy reading all the output from the opponent.

[bob]

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.

The only time I use fixed depth is for Crafty vs Crafty. There I set the depth in the .craftyrc file anyway. But between two different programs, "depth" is completely meaningless and it would introduce more confusion for most users and only be of benefit to a very small group.

The good of the many...

[D Sceviour]

What problems are being caused by option.c in Crafty??? I run xboard matches all the time and don't see any issues whatsoever, except with other engines that send far too much output and tend to cause xboard itself to lag...

This is from an old thread:
http://talkchess.com/forum/viewtopic.ph ... 48&t=57446

[bob]

What problems are being caused by option.c in Crafty??? I run xboard matches all the time and don't see any issues whatsoever, except with other engines that send far too much output and tend to cause xboard itself to lag...

This is from an old thread:
http://talkchess.com/forum/viewtopic.ph ... 48&t=57446

There's a bit of inaccuracy quoted in that thread. xboard was originally designed for gnu chess. It only supported a bare minimum of commands, including only "edit" to restart a game once it was interrupted (people on ICC learned to take advantage of this so that they could get draws by rep with gnu since using edit excludes game history). I started working with Tim (Mann) in very early 1995 as I began to find issues (I asked him to add the force mode idea so that he could stuff a move list into crafty and get rid of the edit stuff, after adding the 'seaboard' support to make a one-line command to set a position). So the "mechanism" for force was done as a result of a request from me, but I did not give him any suggestions on how to handle it. All of the other commands came from crafty, except for the very basic time, otim and level. rating. computer. opponent, kibitz, tellics, the list goes on and on. As crafty played games on ICC, it became apparent that knowing more than just the color to play and the time control was needed. I was not thinking of this as being a major protocol, I just asked Tim for (or actually sent him code most of the time) changes that I saw a need for. Would be nice to do a protocol version 3, or maybe a protocol version X, and completely clean this stuff up. Completely ignoring compatibility. I'd be quite happy to modify my code, just so a new protocol doesn't try to subsume engine activities. I want to handle my own book, end game tables, pondering, resigning, how much time to use, accepting/declining draws, etc, etc, etc.

But as I said, I know of absolutely zero issues with Crafty playing games via xboard. I use that when I want to watch the games (as in HGM's monthly tourneys, or when on ICC, or when I play long SMP games locally and want to watch all the output carefully.

I suspect HGM meant that Crafty is a difficult pattern to look at, because I have several things that are overloaded. IE I use force to force crafty to retract the previous move and play the given move instead, when in normal console mode, and then use the xboard semantics when running under board.

I can't imagine it misbehaving. Crafty has played over 175,000 games on ICC (Crafty + scrappy) plus a ton on FICS, EICS, old chess.net, etc... And for quite a while it was playing millions of games on our cluster until I decided to write a much more lightweight referee for cluster testing since I don't need thousands of xboard displays showing up.

[hgm]

I suspect HGM meant that Crafty is a difficult pattern to look at, because I have several things that are overloaded. IE I use force to force crafty to retract the previous move and play the given move instead, when in normal console mode, and then use the xboard semantics when running under board.

Indeed, what I mainly meant is that beside XBoard protocol supports its own protocol. So that you run the risk of confusing the two and pick the wrong one to implement in your own engine, and then start complaining that WinBoard is ugly because it does not understand or use Crafty protocol...

[bob]

I suspect HGM meant that Crafty is a difficult pattern to look at, because I have several things that are overloaded. IE I use force to force crafty to retract the previous move and play the given move instead, when in normal console mode, and then use the xboard semantics when running under board.

Indeed, what I mainly meant is that beside XBoard protocol supports its own protocol. So that you run the risk of confusing the two and pick the wrong one to implement in your own engine, and then start complaining that WinBoard is ugly because it does not understand or use Crafty protocol...

That's what I thought. To explain this, first there was Cray Blitz. I then implemented Crafty (different language, different everything, but same "user interface") and wanted everything to work the same for simplicity. Then Stuart Cracraft suggested I do an xboard interface because he wanted to run Crafty on ICC. Caught my interest as well, so I added the rather minimalistic commands it used back then. And for the next couple of years or so, I wrote lots of changes and Tim and I had long conversations about various issues (I wanted a move list, which I didn't write, I wanted rating info, opponent name info, etc, which I did write and send to him) and the "protocol" grew.

It was not exactly how I would design a protocol, sort of like the hacking software development life-cycle called "code and fix". Tim was going to clean things up with protocol version 2, but he went overboard in several places... And it actually ended up even more complex with the ping, pong, etc stuff...

[hgm]

Well, the ping command is pretty essential, to repair some defects in the original protocol. In particular that some commands can terminate with or without output (e.g. a search interrupted by a 'force' command), so that you never know if you just haven't seen the output because the command is still running, or that it isn't going to come at all. With 'ping' you can check for any command whether it terminated without output or not.

[bob]

Well, the ping command is pretty essential, to repair some defects in the original protocol. In particular that some commands can terminate with or without output (e.g. a search interrupted by a 'force' command), so that you never know if you just haven't seen the output because the command is still running, or that it isn't going to come at all. With 'ping' you can check for any command whether it terminated without output or not.

I agree, but then "done=1"??

[Harald]

Well, the ping command is pretty essential, to repair some defects in the original protocol. In particular that some commands can terminate with or without output (e.g. a search interrupted by a 'force' command), so that you never know if you just haven't seen the output because the command is still running, or that it isn't going to come at all. With 'ping' you can check for any command whether it terminated without output or not.

Does that always help? Is the following design ok?
In Elephant the input is tested in the main loop and every 10000(?) nodes in
the search. The input can change some state variables and it can decide to
stop the search, the game or the program. In that case it throws an
exception that is catched in the main loop. But it immediately responds to
ping N with pong N without even telling the ongoing search about it.