Some more WB protocol extensions

[michiguel]

Hi, could be a way (if there is not yet) to the engine to send any multiline info to the gui? (in order to send comments for the user to read. Presumably about the position.)

For communicating with Polyglot, WinBoard now uses the kludge that Thinking Output with nodes, score and time all zero (but current depth in the depth field) is treated as an info line, and displayed in the Engine-Output widow without the leading zero fields. (This is how Polyglot communicates UCI info lines to WB.) This offers reasonable backward compatibility with existing interfaces (althoough they would display a number of redundant zeroes). It could be elevated to protocol.

To show the user something in a separate window, there already exits the telluser command.

That is the whole issue, telluser is not multiline

Miguel

pd: am using winboard 4.4.0, and when using crafty 23.0, often crafty loses games when it is in fact a draw. I guess it is crafty's problem adjudicating a draw when it is not allowed yet?

Indeed, Crafty is know to make false draw claims (like in KBKN).

[hgm]

telluser is not multiline? Not even if you bury "\\n" in the string you send with it?

This would surprise me, but if it were true it could be changed. (And again, this is an implementation matter.)

Of course the telluser popup culd be turned into a multi-line display like the Engine-Output window, collecting everything (scrolling) until the user closes it. (Yet another implementation issue. In WinBoard I could auto-popup a chat window for that...) But what is the point? We already have an Engine-Output window. So why not direct information you want to be displayed in that fashion there?

[hgm]

If the engine sends a node count update every second then the GUI has to be woken up every second also.... Same overhead.

No. Because when you poll, the GUI still has to receive the answer, so it would have to be woken up twice. After sending the poll command it gets suspended again.

The current command tellusererror works well for non-fatal errors (like an engine not finding its book) but not for fatal errors.

Currently the engine typically pops up a message and then quits. The engine message is immediately obscured by some WB message about broken pipes or something (IIRC) which besides being very ugly gives the user no idea of what actually happened.

If WB knows that the engine has encountered a fatal error and will quit afterwards then it can handle this much more gracefully. This is actually a real issue with PG since PG can encounter many fatal error situations.

OK, so the implementation sucks. That doesn't mean there is anything wrong with the protocol, or that adding new protocol would fix it. GUIs that would immediately exit upon receiving the tellfatalerror command rather than deferring any reaction to it until after they finished their own initiaization would still show exactly the same behavior.

Everything could be solved by having tellusererror + exiting work properly, i.e. fully within existing protocol.

[Michel]

OK, so the implementation sucks. That doesn't mean there is anything wrong with the protocol, or that adding new protocol would fix it. GUIs that would immediately exit upon receiving the tellfatalerror command rather than deferring any reaction to it until after they finished their own initiaization would still show exactly the same behavior.

Everything could be solved by having tellusererror + exiting work properly, i.e. fully within existing protocol.

So what do you propose?

All I am asking is for a simple way to customize the message that xboard shows when the engine exits. I am proposing a simple mechanism but if you can come up with a different mechanism that accomplishes the same thing then fine by me.

EDIT: The problem is that currently xboard is simply not aware the engine is going to exit after its last error message. So it cannot save the error message for the final "engine has exited unexpectedly" dialog.

[adieguez]

Telluser shows a popup in winboard. I was thinking something more durable, like the thinking output split on two. And the engine sending addAnalyzeComment and replaceAnalyzeComment for example.

crafty lose here even just before a repetition, or before there are bare kings. Only with playing against other programs. It appears to send the game result even before sending its move:

199141 >first : go
nps: w=-1, b=-1
199156 <first : NOTICE: 1000 moves to next time control
199156 <first : tellicsnoalias kibitz Hello from Crafty v23.0! (1 cpus)
199156 <first : 1/2-1/2 {Insufficient material}
GameEnds(39, Insufficient material, 5)
GE(38, False draw claim: 'Insufficient material', 5) bare king k=2 color=22
199156 >first : result 0-1 {False draw claim: 'Insufficient material'}
199156 >second: result 0-1 {False draw claim: 'Insufficient material'}
199156 >first : force
199156 >first : ping 7
199156 >second: quit
199156 <first : move Kxd2

Hi, could be a way (if there is not yet) to the engine to send any multiline info to the gui? (in order to send comments for the user to read. Presumably about the position.)

For communicating with Polyglot, WinBoard now uses the kludge that Thinking Output with nodes, score and time all zero (but current depth in the depth field) is treated as an info line, and displayed in the Engine-Output widow without the leading zero fields. (This is how Polyglot communicates UCI info lines to WB.) This offers reasonable backward compatibility with existing interfaces (althoough they would display a number of redundant zeroes). It could be elevated to protocol.

To show the user something in a separate window, there already exits the telluser command.

pd: am using winboard 4.4.0, and when using crafty 23.0, often crafty loses games when it is in fact a draw. I guess it is crafty's problem adjudicating a draw when it is not allowed yet?

Indeed, Crafty is know to make false draw claims (like in KBKN).

[hgm]

I propose to do tellusererror and then exit. It is up to the GUI author to make sure that the GUI handles this combination in an acceptable way. E.g. while the error popup is still up it should refrain from exiting, even when the engine process exits.

If you want to have a work-around for GUIs that do not handle this well, you could wait for a go command or move before you exit, and ignore everything else (except quit). Normally you would not get such commands before the user takes action, which gives him time to see the error message. If the fatal error happens before the feature handshaking, you could send feature done=0, leaving the user with no other possible thing to do than close XBoard.

But we don't want to anchor work-arounds in the protocol.

[hgm]

It appears to send the game result even before sending its move:

...

Indeed. And that is a protocol violation, as the specs describe you cn only use the 1/2-1/2 command when the game is "definitely" over. In this position the game is not definitely over yet, and Crafty could still lose by plying a wrong move. So if you decide to run under rules where false claims are punished by forfeit, Crafty loses. If you want to play under rules where draw claims are accepted even when they are false, you should switch off -testClaims, either through the command-line option or the Options -> Adjudications menu dialog.

Crafty is designed to play under rules that accept all Crafty claims, and reject all claims of other engines.
But we do not support that mode in XBoard.

[Michel]

I propose to do tellusererror and then exit. It is up to the GUI author to make sure that the GUI handles this combination in an acceptable way.

Well xboard doesn't that's for sure. And I don't see how it could within the current protocol.

There is a dirty hack which makes xboard behave correctly and that is to cleverly embed the string "not found" in your error message. In that case xboard will notice this is a fatal error and display the message is a suitable way.

I was just proposing a clean way to achieve this.

[hgm]

And I don't see how it could within the current protocol.

What would be the problem, in current protocol?

[Michel]

What would be the problem, in current protocol?

The GUI is not aware the message is fatal. So it pops up a dialog. The engine exits and the GUI pops up a new dialog. Even it it would wait until the user closes the first dialog it would still be ugly in my opinion.

Why requiring the user to click twice for one event?