Engines with interfaces for slightly nerdish people

[bob]

Thanks; I will give your micro-Max a try.

Note that it only has two commands (and guaranteed bug-free!): type a move, or type an empty line to make it think up an play a move.

For WinBoard, I tried it again tonight. I installed a recent version and decided to install a recent Stockfish development version as an UCI engine. It was added smoothly, Then I wanted to setup the number of CPUs it should use. I failed, as there was no parameter to configure to be found anywhere. I looked around for a while, then gave up. Please don't think of this as a WinBoard bug report. I am confident that this is sth that could have been worked out rather easily. It is just that it would have meant more effort than I liked to invest.

It is not a bug report, but second only to reliability user-friendliness is an important design goal of WinBoard. So I consider it quite important to minimize the chances for experiences like this, for which reports like yours are potentially very helpful.

In this particular case, the option you were looking for was in the Common Engine Settings dialog, next to Hash Size, EGTB cache and book settings. This seems the logical place for settings that apply to all engines, so the important question is why you could not find it while "looking around for a while", and whether the interface can be improved such that you would have immediately found it. Where exactly did you look for it?

For instance, would it have helped if the Common Engine Settings dialog would have been accessible through the Engine menu, say just above the Engine #1/#2 Settings items? I am considering to move that menu item there in WinBoard 4.9. (I believe in XBoard I have already done that.) Would it then have been the first place you have looked after the Engine #1 Settings dialog? I am usually quite reluctant to change the menu structure, because for every novice that might be helped by a reorganization that conforms better to his intuition, there might be 100 experienced users that grumble because they can no longer find the menu item anymore in the place where they are used to finding it.

Another question is how much help the help actually is. In the index of the chm help file, looking under 'N' you would find 'Number of CPUs', which would bring you directly to the description of the Common Engine dialog. If that proves to be insufficient to be of any use, is it any help at all that WinBoard is supplied with an elaborate, indexed help file, or might I as well drop the help function completely, because users would rather die than use the help menu?

Here's a quibble:

How about doing this two ways. Set it in general engine options as you do now, and then have it as a specific engine option as well. IE some want to try 2 thread vs 4 thread to see performance gains, etc? Only bit of complexity would be to try to be informative. IE if you set the general engine option for thread, you might ask "do you want to use this to override all individual engine thread settings?" Otherwise I could see some confusion and complaints when one forgets it was set here, sets it over there, and it doesn't work.

[bob]

Of course I am also very curious as to what sort of behavior annoys you in WinBoard.

Fully qualified nerd here , xBoard is cool. Would like the ability to select game 10/sec Inc 1.7 sec in tournament mode. A Swiss tourney mode would be pretty cool too. Did I ever send you my dark and light wood color pieces. Created from my chessboard and then touching up the photo for the screen. You are free to use them in your distribution as my contribution.

From a screenshot of my desktop using my iPhone remotely via splashtop - so the quality is not the best here

-inc 0.17 works just fine....

[bob]

Would like the ability to select game 10/sec Inc 1.7 sec in tournament mode.

Through the command-line you can do that: -inc is a floating-point option. In the XBoard Time-Control dialog it can only be entered as an integer, though. The problem is that this is a bit of a moot point, because the protocol specs do not allow the increment to be passed to the engine in the level command as a float. (And even if we would extend the protocol to allow this, almost no engine would support it.) The engine would notice that its remaining time on the clock would not go down as fast as it expects, of course, as it gets that in centi-sec. But it would not plan for using it, and thus only profit from it when in the long run a lot of it accumulates.

A Swiss tourney mode would be pretty cool too.

Good point. I actually distribute a Swiss tourney module with WinBoard. When I was implementing Swiss, people were urging me to implement it s a plugin. It is far from trivial to implement a good Swiss pairing program, (and there are different flavors of Swiss as well), and the idea was that every GUI then could then use it, and also that in the longer run people would write better pairing modules of which all GUIs then would benefit. In hindsight this was a very stupid idea; GUI developers would rather die than make use of other people's code, so they would certainly prefer to limp by with a crappy implementation of Swiss written by themselves then using an external module for it. But a primitive Swiss paring engine does exist (it doesnot do back-tracing in an attemot to improve the first pairing it finds that satisfies the exclusion and color rules), and I distribute it with WinBoard. It could be compiled for Linux or Mac, and would work just as well on XBoard.

Did I ever send you my dark and light wood color pieces. Created from my chessboard and then touching up the photo for the screen. You are free to use them in your distribution as my contribution.

From a screenshot of my desktop using my iPhone remotely via splashtop - so the quality is not the best here

Nice. We currently don't have an organized effort to distribute piece themes, however, or even designed a standard way to package and distribute them. For instance, the Chu Shogi bare kanji-pieces for Chu Shogi are currently distributed in the package of the HaChu engine, because that is so far the only engine that can play Chu Shogi. But when other engines would emerge, this would of course be a very unsatisfactory state of affairs.

It should be possible to make separate packages for board themes, containing the image files for installing in /usr/(local/)share/games/xboard/themes/THEMENAME/, possibly accompanied with PNG texture files for the light and dark board squares, and some settings file that would configure XBoard to use them. OTOH, since we added the 'themes' listbox to the View->Board dialog, it would be nice if installing a theme package would automatically create a new entry in that listbox (i.e. add a line with the required settings options to the -themeNames persistent multi-line option).

It works fine for my testing. IE I don't pay much attention to the level command except for the first move out of book, because then xboard takes care of the increment internally and updates my clock in centiseconds... I run with 10s + 0.17s all the time here...

[hgm]

How about doing this two ways. Set it in general engine options as you do now, and then have it as a specific engine option as well. IE some want to try 2 thread vs 4 thread to see performance gains, etc? Only bit of complexity would be to try to be informative. IE if you set the general engine option for thread, you might ask "do you want to use this to override all individual engine thread settings?" Otherwise I could see some confusion and complaints when one forgets it was set here, sets it over there, and it doesn't work.

Yes, this would be possible. E.g. I could have XBoard add a spin control 'Threads' in the Engine #N Settings dialog depending on whether the engine supports SMP (i.e. sent feature smp=1 at startup) and whether the common setting for this is 0. Any non-zero value for the common setting would prevail over an individual setting, and suppress appearance of the spin control in the individual settings dialogs.

[Evert]

Would like the ability to select game 10/sec Inc 1.7 sec in tournament mode.

Through the command-line you can do that: -inc is a floating-point option. In the XBoard Time-Control dialog it can only be entered as an integer, though. The problem is that this is a bit of a moot point, because the protocol specs do not allow the increment to be passed to the engine in the level command as a float. (And even if we would extend the protocol to allow this, almost no engine would support it.)

Where does it say that "inc" cannot be a float? As far as I can tell it is undefined (but all examples use integers, and I'm quite sure it was intended to be one). Does anything actually break if you send a float instead?

All my engines understand a float for the "inc" argument (and for the argument to time/otim).

[bob]

How about doing this two ways. Set it in general engine options as you do now, and then have it as a specific engine option as well. IE some want to try 2 thread vs 4 thread to see performance gains, etc? Only bit of complexity would be to try to be informative. IE if you set the general engine option for thread, you might ask "do you want to use this to override all individual engine thread settings?" Otherwise I could see some confusion and complaints when one forgets it was set here, sets it over there, and it doesn't work.

Yes, this would be possible. E.g. I could have XBoard add a spin control 'Threads' in the Engine #N Settings dialog depending on whether the engine supports SMP (i.e. sent feature smp=1 at startup) and whether the common setting for this is 0. Any non-zero value for the common setting would prevail over an individual setting, and suppress appearance of the spin control in the individual settings dialogs.

The main thing you need to add is a "sanity tester" for the settings. And then flash a large red flashing "STUPID" in a box that is hard to get to go away, whenever anyone does anything obviously stupid. Perhaps even generate an automatic post to CCC that says "user x did something incredibly asinine with the following xboard settings: ..."

[Peter Berger]

In this particular case, the option you were looking for was in the Common Engine Settings dialog, next to Hash Size, EGTB cache and book settings. This seems the logical place for settings that apply to all engines, so the important question is why you could not find it while "looking around for a while", and whether the interface can be improved such that you would have immediately found it. Where exactly did you look for it?


I looked for it in the Stockfish engine settings and nowhere else. I didn't think of it as something that could be expected to be a general GUI setting, and I still feel this way.
For book settings, hash size and EGTB settings I would probably have been more likely to look around for a general setting .


For instance, would it have helped if the Common Engine Settings dialog would have been accessible through the Engine menu, say just above the Engine #1/#2 Settings items?


Yes, this would have helped here.
Actually I'd still prefer to have this as a specific engine setting anyway, but it is not for me to design the program .


Another question is how much help the help actually is. In the index of the chm help file, looking under 'N' you would find 'Number of CPUs', which would bring you directly to the description of the Common Engine dialog. If that proves to be insufficient to be of any use, is it any help at all that WinBoard is supplied with an elaborate, indexed help file, or might I as well drop the help function completely, because users would rather die than use the help menu?


Want to hear the truth? No one and I mean REALLY NO ONE reads and uses these indexed helpfiles these days , and this is true for any program less complex than Microsoft Word IMHO .
So yes, in case you decide to give up on this feature completely I bet it will take MONTHS before you even get a report about it .
What people who care do these days is go to Google and type sth like
"Stockfish don't use no multiple threads under WinBoard"
which btw would have provided a pretty useful answer by yours truely .
Peter

PS: A real bug report from my second new WinBoard experience. If I start WinBoard in "Play against engine mode" under the Engine rider it displays the two used Engines at the bottom ( in my case Stockfish and Fruit 2.1) . If I switch between them 2 or 3 times by clicking on said entries WinBoard will definiteky crash ( reproducable behaviour under Windows 10)

[MikeB]

From a screenshot of my desktop using my iPhone remotely via splashtop - so the quality is not the best here

OSX can do it's own screen shots just so you know Shift-cmd-3 for fullscreen shot shift-cmd-4 for screenshot with a mouse selection.

Thanks - the problem was that I was about 50 miles from MacPro - , hence the reason for the iPhone. It was not like I was sitting at the desktop and took a snapshot ;>)

[MikeB]

Of course I am also very curious as to what sort of behavior annoys you in WinBoard.

Fully qualified nerd here , xBoard is cool. Would like the ability to select game 10/sec Inc 1.7 sec in tournament mode. A Swiss tourney mode would be pretty cool too. Did I ever send you my dark and light wood color pieces. Created from my chessboard and then touching up the photo for the screen. You are free to use them in your distribution as my contribution.

From a screenshot of my desktop using my iPhone remotely via splashtop - so the quality is not the best here

-inc 0.17 works just fine....

Yes it does. Jus the the GUI does not let you set it to .17 for reasons HGM explain. Likewise a base of 10 seconds need to be set through the the editing the trn file as well.

[hgm]

Yes it does. Jus the the GUI does not let you set it to .17 for reasons HGM explain. Likewise a base of 10 seconds need to be set through the the editing the trn file as well.

Actually the latter should be counted as a TODO of the GTK port; in the Xaw version you could type 0:10 in the applicable field of the Time Control dialog, and it would understand it. GTK has specialized spin widgets, however, and they refuse you type an arbitrary text in there.

In most cases you could simply define a time odds of (say) 60 to enter the base time in seconds and the increment in 1/60 sec. But the time odds are engine-specific options, so I am not sure they would work in tournament mode.

Perhaps I should simply add a checkbox option in the Time Control dialog 'divide entered times by 60' to get around the problem that the GTK spins do not accept non-integers?