-mps seems to be broken

[Miguel A. Ballicora]

I send -tc 0:20 -mps 40 in the command line
and the engine receives level 0 0:20 0 when it should be level 40 0:20 0
The version is
xboard version master-20101020
(I am assuming this is 4.5? it is the latest I could find after several minutes of navigating)
It seems to be broken in 4.4.3 too.

My command line is (prepared by a script)

xboard -pixmap /media/bigdisk/cc/xboard/alpha/redmarble -ponder -smpCores 1 -defaultHashSize 32 -defaultCacheSizeEGTB 8 -defaultPathEGTB /media/MIGUEL2/gtb4/ -egtFormats "gaviota:/media/MIGUEL2/gtb4/" -xanimate -xdrag -xhighlight -xexit -size mediocre -thinking -highlight -autoflag -xbuttons -checkMates true -testClaims true -materialDraws true -trivialDraws true -ruleMoves 50 -repeatsToDraw 3 -tc 0:20 -mps 40 -lgi 1 -mg 1 -sgf temp.pgn -lgf /home/miguel/Desktop/cc/pgn/big/starters-big.pgn -fd "/home/miguel/cc/gaviota-match/" -fcp ./gaviota -sd "/home/miguel/cc/gaviota-uci/" -scp ./gaviota-polyglot.sh -debug > debug-debug2---2010-11-23-01_03.pgn--0001-0001.txt 2>&1

And the relevant part of the debug is

2751 <first : feature done=1
2751 >first : accepted done
2752 >first : memory 40
2752 >first : new
random
2753 >first : ics -
2753 >first : level 0 0:20 0
2753 >first : post
2753 >first : hard
2753 >first : ping 1
LoadGame(): on entry, gameMode 0
Parsed game start '[Event "0x1000131f"]' (38)
Parsed PGNTag: [Event "0x1000131f"]
Parsed PGNTag: [Site "?"]
Parsed PGNTag: [Date "????.??.??"]
Parsed PGNTag: [Round "?"]
Parsed PGNTag: [White "?"]
Parsed PGNTag: [Black "?"]
Parsed PGNTag: [Result "*"]
Parsed PGNTag: [ECO "C45"]
Parsed PGNTag: [Opening "Scotch game"]
recognized '' (-1) as variant normal
2754 >first : memory 40
2754 >first : new
random
2754 >first : ics -
2754 >first : level 0 0:20 0
2754 >first : post
2754 >first : hard
2754 >first : ping 2
2754 >first : force

[H.G.Muller]

Probably you have -timeIncrement at 0 in stead of -1. This is an ever recurring pitfall in the way the command-line options work. Non-negative increment implies incremental TC and makes XBoard ignore mps (although the value of the -mps option is remembered in the settings.

Within the current system of option processing this is very hard to fix, as XBoard frst collects all the option values, and only then starts to initialize based on them. So it no longer knows the orderof the options. Conflicting options further more cannot be made an error condition, as they basically always occur, because you read options from the settings file first forpretty much everything, so that what you specify on the command line (or an indirect settings file) will always be conflicting with the settings-file value for the same option. To get around this XBoard would have to keep track of which options are set at which level of option processing, to become aware of conflicts and resolve them in a meaningful way. This would solve conflicts between different values of the same option, butyou would still be left with the problem of different options having incompatible values.

I guess the main problem is that different options can have conflicting values at all (like -mps and -inc). If the values affect each other, they should really beset in the same option. I have re-written the clockmanagement in XBoard to internally depend completely on a single variable, in which the (MPS, TC, INC) parameters are combined as a PGN timecontrol string. (So -mps 40 -tc 5 -inc -1 would become "40/300",and -mps 40 -tc 1 -inc 1 becomes "60+1". This can of course also handle multi-session TC like "40/3600:20/900:300+5".) It would be much better to deprecate the -mps, -tc and -inc options, and replace them by a single (persistent) option -tcString.

One way to do this without breaking backward compatibility would be to no longer write them in the settings file, and give them default values that make them recognizable as invalid / absent, like negative MPS and INC, and only use them to build the tcString if they have valid values, (as then apparently the user specified them on the command line).

[Miguel A. Ballicora]

Probably you have -timeIncrement at 0 in stead of -1. This is an ever recurring pitfall in the way the command-line options work. Non-negative increment implies incremental TC and makes XBoard ignore mps (although the value of the -mps option is remembered in the settings.

As you could see from the line above, I do not have that. However, after reading your whole post, I am suspecting that at one point I used -inc 0 and it was silently saved in an ini file somewhere. If that happened, the default became -inc 0 and it is not removed unless I send -inc -1. Is that correct? Since now -inc 0 is the default, -mps will not work. So, the solution will be to use -inc -1 at the same time that -mps? or I have to use -inc -1, quit and restart with -mps?
I will try tonight.

If I am correct, this is a problem... Please do not worry about backward compatibility and if you make it right, whatever it is, it will be fine. The current implementation already broke all my scripts. I am guessing that saving the status of the TC was the trigger (not the culprit, but the trigger).

Miguel

Within the current system of option processing this is very hard to fix, as XBoard frst collects all the option values, and only then starts to initialize based on them. So it no longer knows the orderof the options. Conflicting options further more cannot be made an error condition, as they basically always occur, because you read options from the settings file first forpretty much everything, so that what you specify on the command line (or an indirect settings file) will always be conflicting with the settings-file value for the same option. To get around this XBoard would have to keep track of which options are set at which level of option processing, to become aware of conflicts and resolve them in a meaningful way. This would solve conflicts between different values of the same option, butyou would still be left with the problem of different options having incompatible values.

I guess the main problem is that different options can have conflicting values at all (like -mps and -inc). If the values affect each other, they should really beset in the same option. I have re-written the clockmanagement in XBoard to internally depend completely on a single variable, in which the (MPS, TC, INC) parameters are combined as a PGN timecontrol string. (So -mps 40 -tc 5 -inc -1 would become "40/300",and -mps 40 -tc 1 -inc 1 becomes "60+1". This can of course also handle multi-session TC like "40/3600:20/900:300+5".) It would be much better to deprecate the -mps, -tc and -inc options, and replace them by a single (persistent) option -tcString.

One way to do this without breaking backward compatibility would be to no longer write them in the settings file, and give them default values that make them recognizable as invalid / absent, like negative MPS and INC, and only use them to build the tcString if they have valid values, (as then apparently the user specified them on the command line).

[H.G.Muller]

Indeed, the persistence the the -inc setting is a problem. WinBoard users sooner or later always fall into this trap (happened to me too). The problem is the incompatibility of the -inc and -mps options, and that because of the persistence you always specify both. In the level command, either MPS or INC must be 0, and this is implemented as a valid value for INC forcing MPS to 0. It could have been the opposite, but you would have the opposite problem (an -inc argument being ignored because of a persistent valid MPS.)

There is an eay way to revive your scripts, though:

Open /etc/xboard.conf in an editor, and add at the end (after -settingsFile ~/.xboardrc) the line

-inc -1

This effectively turns -inc back into a volatile option with default value -1, as it will be read after the user settings file holding your persistent options, and thus resets any value you might have saved last time. There is no need to do the same for -mps, as a valid MPS never perturbs a TC with an explicitly specified -inc.

Perhaps it would be better to make this standard in the configuration file we distribute?

[Giorgio Medeot]

Open /etc/xboard.conf in an editor, and add at the end (after -settingsFile ~/.xboardrc) the line

Hi H.G.,

just for sake of clarity, does this mean that the options in the main Winboard.ini file are read and processed line by line? That is, when WB encounter a line with

-settingsFile whatever.ini

it stops processing the main file, eats and processes every option in the whatever.ini file, and then it comes back to the main file, reading and processing options following that -settingsFile. Do I get it right?

Thanks,

Giorgio

[H.G.Muller]

Indeed, that is how it works, and how it has always worked. The main ini file is processed as if it were a command line (treating linefeeds as spaces), and everything in it was prefixed to the real command line. Both -settingsFile XXX (-ini XXX, for short) and @XXX cause the file XXX to be inserted at that point, and this works recursively. (I.e., XXX can again contain @YYY etc.) The difference between @ and -ini is that in the latter case the name is remembered as the file to save settings on.

What I changed in 4.5.0 is that the file where the settings are saved on is the last -ini argument encountered (or the one set explicitly by /saveSettingsFile). It used to be the outer-most succesfully read settings file, which was less useful, because in that case you could never redirect the file to save on from within another file. (You could do that only from the command line).

[matematiko]

Mr. Muller,

I am not even following what this thread is about.... I can not help to notice thou your willingness to help and answer to most of the WinBoard related posts in this forum.

God bless you.

[Giorgio Medeot]

Thanks,
you are clear and complete, as always

Regards,

Giorgio