Sending pure comments using UCI protocol

[xr_a_y]

To send things that won't be read by the GUI in xboard protocol, the # sign is used at the beginning of the line.
(not read is a bit false as some key word are still parsed by some GUI, like the word "error" for example in winboard itself, anyway).

What is the syntax in UCI protocol ? It seems to me that the paradigm is in a way reversed and only lines starting with some known words to the GUI will be read (for instance "info" strings). So it seems I can also send comments starting with the # sign when using UCI protocol ? Am I correct ?

Because I am a little scared by the following specification

* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string.

"unknown command" refers to a full line ? or just a word ?
"string" refers to the rest of the stream or the next word in the line ?

[Joost Buijs]

To send things that won't be read by the GUI in xboard protocol, the # sign is used at the beginning of the line.
(not read is a bit false as some key word are still parsed by some GUI, like the word "error" for example in winboard itself, anyway).

What is the syntax in UCI protocol ? It seems to me that the paradigm is in a way reversed and only lines starting with some known words to the GUI will be read (for instance "info" strings). So it seems I can also send comments starting with the # sign when using UCI protocol ? Am I correct ?

Because I am a little scared by the following specification

* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string.

"unknown command" refers to a full line ? or just a word ?
"string" refers to the rest of the stream or the next word in the line ?

If you want to send comments the UCI specification says you first have to send "info string" and after this the comment e.g. "info string comment". At least that is what I do, and I never saw any adversary effect of it.

[Ras]

Because I am a little scared by the following specification

* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string.

"unknown command" refers to a full line ? or just a word ?

The very next line in the UCI spec holds the answer:

Examples: "joho debug on\n" should switch the debug mode on given that joho is not defined, "debug joho on\n" will be undefined however.

A strict implementation will continue to parse after the # sign.

[xr_a_y]

Thanks got it.

[hgm]

My guess is that you could simply use "info <message>", provided the message would not contain any keywords.

WinBoard + UCI2WB would interpret 'info string <message>' as something that should be presented to the user in the engine Output window

[xr_a_y]

Ok. So this is not so clear in fact...

Maybe a

info comments ....

sequence could be helpful in the protocol ?

[Ras]

Maybe a

info comments ....

sequence could be helpful in the protocol ?

The "info string" sequence already allows any free form comments. If the issue is that the GUI shall not evaluate the strings in any way, the easiest solution would be not to send them. Extending UCI is pretty much out of question because one of the reasons for its success is that it hasn't been extended over and over.

[hgm]

But the problem is that 'info string' is used both for messages you want to communicate to the user, as for extra output that is given in response to the 'debug' option being 'on' (and which you would likely want to appear only in some log).

[Ras]

But the problem is that 'info string' is used both for messages you want to communicate to the user, as for extra output that is given in response to the 'debug' option being 'on' (and which you would likely want to appear only in some log).

IMHO, this is a feature, not a problem. If a user encounters an issue that the dev can't readily reproduce, which is about the only scenario where a regular user would even use the engine with "debug on", then copy/pasting that from the GUI's message/info area into an email for the bug report is something most users will be able to do. Using a log file, finding it, and putting that as attachment into an email - probably not so much.

[hgm]

Perhaps you are right. That reminds me that UCI2WB doesn't support the UCI 'debug' command. You can put it in debug mode through a command-line argument, but that only means it will report all communication with the engine to the GUI. Perhaps I should also make it run the engine in debug mode, in such a case.