MacPorts/xboard: Timing anomalies

[sje]

The xboard -keepAlive option documentation seems to be missing from https://www.gnu.org/software/xboard/manual/xboard.html

I assume that it has a single integer argument giving a minute count time-out.

[hgm]

Probably the best treatment would be to convince the ICS operators to report times using a precision better than the current one second resolution.

This might actually be possible already. ICC has enormously expanded on the original ICS protocol, as has freechess.org. Unfortunately they did that in completely different and incompatible ways. IIRC chessclub.com works with 'datagrams'; non-printable escape sequences interjected in the text stream, which can be selectively requested by the client (bythrough other datagrams). XBoard, for instance, enables the datagram that informs it on removal of seek ads, when you enabled automatic seek-graph update. It is very possible that msec clock timing is one of the datagram services you could enable.

It is also possible that there is a conventional (i.e. text-based) setting on ICC (e.g. via the user's vars or ivars) that controls whether the clock settings included in the boards will be seconds or msec.

[hgm]

The xboard -keepAlive option documentation seems to be missing from https://www.gnu.org/software/xboard/manual/xboard.html

I assume that it has a single integer argument giving a minute count time-out.

Yes, that is correct. I have intentionally be a little hush-hush on this option, as I was not sure ICS operators would appreciate it. I assume they did not instate the timeout feature on connections just for the fun of annoying users, and if everyone would subvert it by using the -keepAlive option, they might ban the interfaces that implement something like it.

[sje]

At one time, I could have xboard connect to FICS and use the -xrm option to post ads for a new match at game end:

Code: Select all

        -xrm "*zippyGameEnd: seek 5\nseek 15\n"

which no longer seems to work.

With ICC, I use:

Code: Select all

        -zippyGameEnd "multi seek 5 ; seek 15"

which does work.

How do I make the FICS xboard call post seeks at game end?

[hgm]

An idea here is to add a clock directive feature to xboard which would replace the time/otim directives upon request. A clock directive sent to a program would contain two operands; the first being the program's remaining time and the second the opponent's remaining time. (Or maybe White's, then Black's.) Time values would be represented in decimal seconds for generality and for the possibility of future improvements in clock value precision.

Well, I am not so hot for making changes to the protocol that are mostly cosmetic. Precision is a real issue, but it could also be addressed in a more backward-compatible way by having a general feature fractions=1 that would allow the GUI and engine to send any value that the protocol defines as an integer as a float instead. That would leave the ugliness of using csec units in some commands, seconds or minutes in others, but again, that is just cosmetic.

An issue that is pretty annoying in engine design is that time and otim commands preceed the usermove, so that you are forced to process them during ponder search before you can conclude if there is a ponder miss. I think this is a far more objectionable feature of the protocol than inhomogeneity in the use of units. So if anything, I would go for a command that piggy-backs clock settings on the usermove command. The engine could then request feature times=2 to suppress the time and otim, and get the times appended to the move instead. That could then simplify his ponder handling. Problem is that you also need to send times with the go command.

[hgm]

At one time, I could have xboard connect to FICS and use the -xrm option to post ads for a new match at game end:

Code: Select all

        -xrm "*zippyGameEnd: seek 5\nseek 15\n"

which no longer seems to work.

Indeed. XBoard is no longer an X-application, so general X-server options like -xrm do not work anymore.

With ICC, I use:

Code: Select all

        -zippyGameEnd "multi seek 5 ; seek 15"

which does work.

How do I make the FICS xboard call post seeks at game end?

I suppose that the problem is in how FICS handles multiple commands? Does it not recognize the semicolon as a command separator anymore? (The public version of the FICS code still recognizes it, much to my annoyance when I use a semicolon in a long tell message...) I suppose using \n in XBoard string arguments is taking literally, rather than as escape for a linefeed. I thought the trick to get linefeeds in arguments of XBoard string options was to use a real linefeed preceded by a backslash, so that the shell would not consider it command termination. Like

xboard -zippyGameEnd AAA\
BBB -keepAlive 10

Not completely sure, though; I am not that much of a Unix adept.

[sje]

I believe that multi is specific to ICC and is not available at FICS.

On FICS,

Code: Select all

        -zippyGameEnd "seek 5"

Will issue a single seek. But I want more than one of them, and passing "\n" inside a string doesn't work. I haven't tried a backslash escape yet. I've been doing a lot of flailing without much progress; somewhere there must be documentation on how to do multiple seeks on FICS via xboard.

[JoshPettus]

Yes, this could be done. But I am a firm believer in the philosophy that problems should be solved where they ly, and it is clearly (the Mac version of) timestamp that is broken here. ICC should fix it.

Please correct me if I'm wrong, but last I saw, this was an issue in the linux version of timeseal as well

[hgm]

I believe that multi is specific to ICC and is not available at FICS.

On FICS,

Code: Select all

        -zippyGameEnd "seek 5"

Will issue a single seek. But I want more than one of them, and passing "\n" inside a string doesn't work. I haven't tried a backslash escape yet. I've been doing a lot of flailing without much progress; somewhere there must be documentation on how to do multiple seeks on FICS via xboard.

I first encountered the '\n' problem in XBoard when we were trying to add a command to the -initString, which normally is "new\nrandom\n". WinBoard expands the '\n' escape in string arguments, but it turned out XBoard didn't. I then added code to expand C escape sequences in the initStrings. But when we later discussed on the XBoard mailing list whether this should be made a general feature, Tim Mann pointed out that it was intentionally omitted from XBoard, because the \ + LINEFEED trick was available on Linux to put linefeeds in a string without needing to represent them as a '\n' escape.

I don't know enough of the Linux shell behavior to know if this interferes with the use of quoting, however. The initString does not contain spaces, so its value could be given without quoting. XBoard doesn't see the difference, as the shell already strips the quotes. "seek 5" needs the quoting for the shell to pass it as a single argument to XBoard, however, and not split it into a "sleep" and a "5" argument.

In an XBoard settings file (as opposed to a shell script) the behavior might be different, because no shell is involved. So I don't expect the \ + LINEFEED trick to work there; this seems to be a shell thing. But XBoard does save multi-line string options in its settings file, in particular the engine list (-firstChessProgramNames). It does this by using {} 'quoting' around multiple lines. So in a settings file you should be able to write things like

-zippyGameEnd {shout Oof, that was a tough game!
seek 5
seek 10
tell 49 I am ready for a new game now!
}

without any backslashes or semicolumns. XBoard would parse this as a string with ascii linefeed codes in it.

[hgm]

Please correct me if I'm wrong, but last I saw, this was an issue in the linux version of timeseal as well

For timeseal there is an open-source version called OpenSeal. This is also what I distribute with WinBoard. I never tried it on Linux, however. I never ran engines on an ICS from a Linux machine, except Fairy-Max on the same machine as where I was hosting my own ICS, and in that case there wasn't any network lag, so I did not need timeseal.