MacPorts/xboard: Timing anomalies

[sje]

But wait, your string does work, just not the version with the unescaped outer quotes.

[matthewlai]

But wait, your string does work, just not the version with the unescaped outer quotes.

Yeah I'm pretty sure I added those extra escapes for a reason. I just don't remember what the reason was.

[hgm]

-noGUI so far is only a makeshift implementation, which suppresses the time-consuming GUI tasks of updating the board window during the game. It was intended to allow ultra-fast games, not for running without X-server.

The problem is that even without a GUI XBoard would depend on the widget set (gtk or Xaw) for dispatching events. To make it truly run as a console application would require a complete rewrite of its event loop. Perhaps using pthreads to do a tight loop with blocking input on every input channel (engine or ICS), and calling the handler assigned to that input channel as soon as there is input. (This would require thread synchronization, as the handlers are not thread safe.) And it would also have to organize timer events of various kinds (clock updates, scheduled events.)

This requires so much incompatible rewriting that it basically becomes another front end, next to GTK and Xaw, so that it makes little sense to activate it through an option. So I changed my plans to just create that as a separate build, called 'noboard' rather than 'xboard'.

[hgm]

Yeah I'm pretty sure I added those extra escapes for a reason. I just don't remember what the reason was.

I think I can explain what happens. The option-parsing code of XBoard was actually ported from WinBoard. Originally XBoard delegated parsing of the command line to the X-server, by logging all its options with it, and let the X-server then return a struct appData with all option values in it (be it the specified ones or defaults). That system could not be used on settings files, however.

The WinBoard code expected the complete command line, including quoting and such. And it accepted 3 styles of quoting: single, double or braces. To port that to XBoard I wrote a pre-processor that takes the (argc, argv) command line, and tries to turn it back into the original line like it was before the shell mutilated it. The shell does not recognize {} 'quoting', so something like

-stringOption {this is a single value}

would be split up in argv elements

-stringOption
{this
is
a
single
value}

and double quoting like

-zippyGameEnd "sleep 5"

would be delivered as

-zippyGameEnd
sleep 5

So to get the line it is not enough to concatenate all the argv elements with spaces separating them, but arguments containing spaces, that on re-parsing would be seen as separate elements, would have to be refurbished with quotes.

When you escape the quotes in the command line you make the shell pass them to XBoard. Furthermore, you prevent the shell becoming blind to \\ being an escape for \, which it would be inside a quoted string. So when sending

-zippyGameEnd "seek 5\\nseek 2 12\\n"

XBoard would get as argv[]

-zippyGameEnd
"seek
5\nseek
2
12\n"

None of these would be space-containing, so XBoard would glue them together as

-zippyGameEnd "seek 5\nseek 2 12\n"

The WinBoard option parser would then work on this, and now it would recognize the \n (which is really a backslash plus an 'n' at this stage) as an escape for linefeed, because now it appears between quotes that XBoard can see. If XBoard doesn't see them because the shell stripped them, it also would not expand \n; it only does that in single- or double-quoted strings that are not filenames. (In Windows filenames backslashes are of course pretty common, and are not part of escape sequences!)

Note that all this only applies to a true command line that went through the hands of a shell. When XBoard reads it from a settings file, the option would be delivered to XBoard exactly as you write it, so that you could simply use the last line above. So when you would write that line in a file called zippy.ini, and would invoke XBoard as

xboard @zippy.ini

it would also work (and IMO be less error-prone). Advantage is that you could write all options you want to invoke XBoard with in that file, even on separate lines for readability (because unlike the shell XBoard reads the options past linefeeds until EOF).

[bob]

Perhaps I misinterpreted, I was thinking that ICC handles it's own time stamping of moves, which as Harm explained, we can't change even if it's not working. (I admit I haven't tested it much as I don't have an ICC account except to see if ICC treats it as active, which it does.) But Is his problem that his engine moves are being recorded by xboard rounded to the nearest second and not centi second? Why would that be?

No idea. I am using xboard + timestamp on my iMac and MacBook, and I see no such problems at all. That tells me it is not the apple timestamp that is causing the problem. I do use an ip address rather than a domain name, but if domain name doesn't work, you are not going to connect at all so that can't be the issue.

The only difference I see is that he is running the OS X-specific version where I am not, and I don't have the problem, leaving the apparent problem related only to the OS X version.

[bob]

1) When running locally (no ICS) between two programs, the time and otim directives correctly present time value to the nearest centisecond. But when running in ICS mode, all time and otim values are rounded or truncated to the nearest second; i.e., each value ends with "00".

In ICS mode the ICS is in charge of the clocks. XBoard just passes on the timing information that the ICS sends it (sent together with the board you receive after every own move, opponent move or refresh command). Some ICS account in seconds. You could look in the xboard.debug file to se exactly what the ICS sends you, and it will likely be integer seconds.

2) When using the helper program timestamp packaged in the Mac native XBoard application, having the name of the ICS ("chessclub.com") as a parameter to xboard does not work as advertised. (This may have been like this for a long time.) The dotted quad IP address is needed.

This is a timestamp issue; timestamp is distributed by ICC.

3) The help files at chessclub.com give the wrong IP address for the site. The current IP address is (207.192.66.15).

Not much I can do about that either...

That's an oddity. I have been using this ip for months: 207.99.83.228

[sje]

Code: Select all

gail:~ sje$ ping -c 1 chessclub.com
PING chessclub.com (207.192.66.15): 56 data bytes

Code: Select all

gail:~ sje$ ping -c 1 freechess.org
PING freechess.org (167.114.65.195): 56 data bytes