WB protocol: pause / resume

[Evert]

This is indeed what Sjaak and Leonidas do. I thought I'd implemented this in Jazz as well, but it seems not. Adding it would be trivial, of course.

EDIT: hmm... it looks like it's only implemented during search, so if the engine is not searching or pondering, it will respond to a pause command with "Illegal move: pause"...

[hgm]

Well, not recognizing the command isn't a problem. WinBoard is not using this response to concludewthether 'pause' is supported; it solely goes by the feature pause=1. Which, according to the protocol specs, should be sufficient.

What is bad is that you send an illegal-move command on something that is not a move. That you do it here suggests you would do it for any unknown command, and in general it will wreck the game (because WinBoard would take the last move back, or forfeit the engine for a false claim).

[Giorgio Medeot]

Hi,
I made some more investigations, and it turned out it was my fault: I had inadvertently put /debug=winboard.debug in my settings file, instead of just /debug, and this was messing things up, causing those strange side effects.

I'm sorry for the noise...
(BTW, maybe Winboard could handle this kind of situation a little bit more robustly... .

Thank you for your time,
Ciao.

• Giorgio

[hgm]

Indeed, it seems a bit illogical that it ignores the '=' here. I guess this is an unintended side effect of letting it understand both the Windows-style and Linux-style option format; in Linux-style the same option would read

-debug winboard.debug ...

i.e. the separator between option and value is indistinguishable from the separator between different (option, value) pairs (or lone options). But I guess it should never consider the item after an '=' as a new option.

Also helpful could be if the message 'Game not found in file' reported the filename.

[Evert]

What is bad is that you send an illegal-move command on something that is not a move. That you do it here suggests you would do it for any unknown command, and in general it will wreck the game (because WinBoard would take the last move back, or forfeit the engine for a false claim).

Perhaps. It's not a likely problem in practice though: (almost?) all commands described in the protocol are recognised and handled (which may just be a case of ignoring them). After all commands have been tested for, the input is parsed as a move. If that fails I simply return an illegal move claim and rely on the completeness of the parser.

I could go through the hassle of checking that the input corresponds to a move first, but it's not high on my list of priorities.

[hgm]

feature usermove=1