Winboard Forum

I would like to use the command-line to run a match between a winboard engine with its own book and a UCI engine with a specified polyglot book (I don't want to mess with .ini files or the GUI). I am using 4.7.0. I tried this:

winboard -debugMode true -smpCores 2 -defaultHashSize 256 -mg 200 -tc 4:0 -inc 1 -mps -1 -ponder -zp -xexit -fcp "\chess\engines\arasan16.2\arasanx-64-popcnt -H 256m -c 2 -ics -t" -scp "\chess\engines\fruit23\fruit23-em64t.exe" -sd "\chess\engines\fruit23" -sUCI true -usePolyglotBook true -polyglotBook "c:\chess\data\book\medium.bin" -sNoOwnBookUCI true

and I get this mysterious message in the winboard debug log:

Fatal Error: Can't have a match with no chess programs
GameEnds(28, xboard exit, 2)

If I leave off the Polyglot options though the match does run with the 2nd program not using a book.

--Jon

The Polyglot options themselves look OK, but -sUCI should not have an argument. Iut is the short form for -firstIsUCI true (just like -debug is the short form of -debugMode true). This must confuse WinBoard somehow by getting out-of-register during command-line parsing, although I must admit that I don't understand precisely how this could result in this particular error message. Perhaps it interprets the 'true' after -sUCI as a filename without an option to specify what the file is for, and switches to game-viewer (-ncp) mode because of that. (This is the sort of command that the Windows desktop generates when you drag a file on top of a .exe; it then calls the .exe with the name of the dragged file as only argument. WinBoard assumes that files without recognized extension are PGN files by default.)

You also have a spurious -zp amongst the options, but apparently that does not hurt. And specifying -inc should overrule any -mps setting anyway, so there is no need to explicitly invalidating -mps. (When you use valid -mps there used to be a need to specify -inc -1 in old WinBoard versions, however, as a valid -inc could be stored in the settings file, and would overrule the requested -mps. This is no longer needed, as recent WinBoard now stores the -inc setting as -inc option in the settings file anymore, but encodes it through a kludge in the -mps setting, as the negated value of -inc in msec. But this could make use of -mps with a negative value confusing to WinBoard.)

Code: Select all

winboard -debug -smpCores 2 -defaultHashSize 256 -mg 200 -tc 4:0 -inc 1 -ponder -xexit -fcp "\chess\engines\arasan16.2\arasanx-64-popcnt -H 256m -c 2 -ics -t" -scp "fruit23-em64t.exe" -sd "\chess\engines\fruit23" -sUCI -usePolyglotBook true -polyglotBook "c:\chess\data\book\medium.bin" -secondXBook

Ok, if I take out the spurious "true" and add -secondXbook instead of -sNoOwnBookUCI true then it works. Thanks for the hints.

Btw. I didn't mention this, but in fooling around with the options I did see cases where winboard just failed silently with no console error message or stuff in the logs.

I think the command-line parsing needs to be tightened up.

The problem could be that the syntax is too liberal. For instance, it is not mandatory to put file names in quotes, and there is no guarantee that a filename will not start with a '-' sign, to look like an option name. It is also not forbidden to put a value on the command line without a preceding option name. In that case a default option is assumed, depending on the file extension. Of course at some point it would likely be discovered that the file doesn't exist, but that could be much later (e.g. in case of a book file, it might not be probed at all).

Perhaps the latter should be limited to the first argument on the command line only. That would have flagged the error in this case, because the 'true' after -sUCI would be encountered when an option name was expected. The optionless arguments should only occur as first argument, when you drag and drop a file on top of winboard.exe. There is no need to allow their use in any other position on the command line.

Another problem is that conflicting options are part of the intended operation, so you cannot generate an error on that. Normally you read a value for every persistent option from the settings file (and in the recent configurations first from the master settings file, and then a different value from the user settings file), and then from the command line. (And perhaps after that even new ones that came with the engine you selected in the startup dialog). WinBoard does not keep track for every option value where exactly it received its value. And even if it did, it would not be obvious when some overruling of a setting by a new one should be considered an error, or even suspect.

It wold be helpful to have some actual examples of the cases you mention. So if it happens again, please post the offending command line here.