Missing space character bug (xboard 4.3.15/FICS)

[sje]

Missing space character bug (xboard 4.3.15/FICS)

A blank character goes missing in the X Window terminal echo when sending analysis data via xboard "tellothers" command. Consider the two log file examples:

Code: Select all

2009.07.15 14:21:13.319 > tellall I have a checkmate in eight moves.
2009.07.15 14:21:13.319 > tellothers [MateIn8/13/0.700/777,836/101] 130... Kg4 131 Kb4 h3 132 Kxc4 h2 133 Kb4 Rb5+

2009.07.15 14:21:16.809 > tellall I have a checkmate in six moves.
2009.07.15 14:21:16.809 > tellothers [MateIn6/11/0.206/213,043/293] 131... Rb5 132 Ka3 h3 133 Ka4 h2 134 Ka3 h1=Q 135 Ka2 Ra5+ 136 Kb2 Qa1#

The FICS echo that appears:

Code: Select all

fics% Symbolic(C)(2249)[165] kibitzes: I have a checkmate in eight moves.
(kibitzed to 2 players)
fics% Symbolic(C)(2249)[165] whispers: [MateIn8/13/0.700/777,836/101] 130... Kg4 131Kb4 h3 132 Kxc4 h2 133 Kb4 Rb5+
(whispered to 1 player)

fics% Symbolic(C)(2249)[165] kibitzes: I have a checkmate in six moves.
(kibitzed to 2 players)
fics% Symbolic(C)(2249)[165] whispers: [MateIn6/11/0.206/213,043/293] 131... Rb5 132Ka3 h3 133 Ka4 h2 134 Ka3 h1=Q 135 Ka2 Ra5+ 136 Kb2 Qa1#
(whispered to 1 player)

For some totally mysterious reason, when a blank character appears in offset 45 (zero origin) of the analysis text, it doesn't get echoed to the terminal. It may not appear to listeners; I have no way to know.

Five simplified echoes:

Code: Select all

[+0.874/13/6.414/6,141,422/0] 78... b5 79 Ra1Ke6 80 Rb1 Ra5 81 Ra1 Ra7
[+1.032/11/0.688/650,673/0] 122... Rc1 123 a4bxa4 124 Kb2 Rg1
[MateIn6/11/0.206/213,043/293] 131... Rb5 132Ka3 h3 133 Ka4 h2 134 Ka3 h1=Q 135 Ka2 Ra5+ 136 Kb2 Qa1#
[MateIn8/13/0.700/777,836/101] 130... Kg4 131Kb4 h3 132 Kxc4 h2 133 Kb4 Rb5+
[+0.716/12/3.853/3,520,420/0] 108... Kxf5 109Kb2 Ra8 110 Rd6 Ra6 111 Rd7 e4 112 fxe4+ Kxe4 113 Rf7 Ke5 114 Re7+

0123456789012345678901234567890123456789012345
          1         2         3         4

[hgm]

I assume that is a FICS problem, as I don't see why WinBoard would delete characters.

[sje]

I assume that is a FICS problem, as I don't see why WinBoard would delete characters.

I haven't seen the problem occur on ICC, so you may be correct.

If the character at offset 45 is not a blank, then there appears to be no problem. Perhaps FICS is doing some text line folding and unfolding? I think things were working correctly when I last ran Symbolic on FICS six months ago.

[sje]

The missing space problem has also appeared when FICS sends an extra long finger note; therefore, both xboard and Symbolic are not to blame. Having the exact same finger note sent by ICS shows with no problem. In both cases I'm using the same xterm terminal emulator running on X11 running on Mac OS/X.

So it looks like either FICS is broken or I have an incorrect FICS variable setting.

[hgm]

You were right after all: XBoard is to blame. I saw it happen on ICC yesterday as well, on long tells. But it is the ICS that determines on what character this problem occurs.

What happens is this:

If an ICS thinks the line is too long, it breaks it by inserting "\r\n\\ " is stead of a space (or just anywhere if no suitable space is near). I added a patch to XBoard to delete this and join the lines. Not only because in general the console window is wide enough to accomodate much larger lines than the ICS is willing to send, and the breaking with '\' looks ugly, but also because some ICS break within a style-12 board (e.g. if the handles of the players are very long), after which XBoard could not parse the board anymore!

I will think of an alternative for fixing the latter problem.

[krazyken]

I saw this quite a bit over the weekend as well. ICC has a variable "width" to determine how wide the terminal is. Setting this to the appropriate number should solve the issue.

One other thing I noticed is that while playing on ICC with timestamp and pgnextendedinfo the saved pgn from xboard was littered with bad artifacts of the time in parentheses. Which appears to be not in compliance with pgn practice as many of my programs have a hard time parsing this reading it as if there are many 0 length variations.

e.g.

[Event "ICS rated blitz match"]
[Site "chessclub.com"]
[Date "2009.08.13"]
[Round "-"]
[White "jugador"]
[Black "spark02"]
[Result "0-1"]
[WhiteElo "1621"]
[BlackElo "1899"]
[TimeControl "300"]

1. e4 (0:02) c5 (0:00) 2. Nf3 (0:01) Nc6 (0:00) 3. d4 (0:01) cxd4 (0:00) 4.
Nxd4 (0:01) g6 (0:00) 5. Nc3 (0:01) Bg7 (0:00) 6. Be3 (0:01) Nf6 (0:00) 7.
Bc4 (0:02) O-O (0:00) 8. Bb3 (0:03) d6 (0:00) 9. f3 (0:02) Bd7 (0:00) 10.
Qd2 (0:01) Nxd4 (0:00) 11. Bxd4 (0:01) a5 (0:11) {-0.38/19 11} 12.
h4 (0:03) a4 (0:17) {+0.26/18 17} 13. Nxa4 (0:03)
{jugador resigns} 0-1

[hgm]

Yes, this is a bug that I inadvertanty introduced when I added an extra line-break point between move and comment. It was only reported to me for the first time this month. It turned out that XBoard appends the time spent on the move in parentheses behind the move in its stored list of SAN moves, in ICS mode. The idea is apparently that this time should appear in the message field when you later step through the game with the < and > buttons. But it should be stripped off when saving to PGN.

When I re-wrote that part of the code I just was not aware of this, as in the modes that I use this list contains nothing but the moves. So the call to the routine that does the stripping was lost. I had noticed since then that the time appeared in saved ICS games, when I started to play on ICS more, but I thought this was intentional. I actually added code in 4.3.16 to remove this if pgnExtendedInfo (which also contains timeing info now) was already present (but leave it in if it was not). But now I realize it should just have never been there.

I have already patched this for 4.4.0.