Some more WB protocol extensions

[Michel]

1) no unnecessary traffic from GUI to Engine

The GUI->engine traffic is only one "." character /sec which is tiny. So this argument I definitely don't buy.

the engine does not have to snd it exactly every N sec, but can send when it has something interesting, and start counting from there.

We are talking about node counts here. When is a node count interesting?

I am not saying that the . command is a jewel in the crown of the WB protocol but I don't think it is hideous either. It is a command which allows the GUI to query the engine asynchronously about what it is doing, which seems completely reasonable. The only unfortunate decision was to restrict the . command to analysis mode.

[adieguez]

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.)

Thanks for your fantastic work.

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?

[adieguez]

There is this: tellopponent MESSAGE

but it popups a window message, maybe could be an option not using popups. But oh well, I don't think am really going to use this yet anyway.

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.)

Thanks for your fantastic work.

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?

[michiguel]

There is this: tellopponent MESSAGE

but it popups a window message, maybe could be an option not using popups. But oh well, I don't think am really going to use this yet anyway.

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.)

Thanks for your fantastic work.

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?

IIRC, you can send only one line with that. The only one time you can send multiple lines is when the GUI asks you to with "bk". In fact, gaviota is using bk to send EGTB info to the user because there is no other option.
http://www.open-aurec.com/wbforum/viewt ... 19&t=50438

I suggested at time to implement the tb command, but now I think it could be expanded.
I suggest to have this as an "-info" button. You click that button, and the engine is ask to send a multiline message (as in bk). It could be used for TB info or many other things.

Miguel

[Michel]

How about a command

tellfatalerror <string>

for fatal errors (such as an engine not finding its configuration files). After such message the engine could quit without WB popping up it own ugly dialogbox.

Currently this is handled very badly in the WB protocol. WB simply reacts to 6 magic strings.

unknown host
No remote directory
not found
No such file
can't alloc
Permission denied

[hgm]

The GUI->engine traffic is only one "." character /sec which is tiny. So this argument I definitely don't buy.

Then you are wrong. There is in fact huge overhead, no matter how little the GUI sends. The GUI process has to be woken up by the timer interrupt. It has to use a pipe system call to copy data to kernel memory space. Several task switches and context switches are involved. In usual OS implementations they involve searching the process table to get the process that should be woken up.

We are talking about node counts here. When is a node count interesting?

When it is a round figure so that the user can easily interpret what he reads, or when sufficient time has elapsed for the user to actually read the old value.

How about a command

tellfatalerror <string>

for fatal errors (such as an engine not finding its configuration files). After such message the engine could quit without WB popping up it own ugly dialogbox.

Currently this is handled very badly in the WB protocol. WB simply reacts to 6 magic strings.

unknown host
No remote directory
not found
No such file
can't alloc
Permission denied

When the WB box for reporting fatal errors is ugly, it would be more logical to fix that. This is an implementation matter, not a protocol matter.

From what I understad, the "magic strings" are there for handling the case where the engine runs on a remote machine through rsh, and rsh somehow fails to startup the engine binary. We can be sure that no one will change rsh to give error messages in WB protocol, so we have no choice but to recognize the messages that rsh gives.

There already exists a command that allows the engine to popup a message. I don't see how the information of adding that the engine has a fatal error would help the GUI. The GUI gets a signal when the engine process terminates, which is a pretty unambiguous message that there was a fatal error in the engine.

Again, if the WB does not handle that well, it is an implementation problem.

[hgm]

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 suggested at time to implement the tb command, but now I think it could be expanded.
I suggest to have this as an "-info" button. You click that button, and the engine is ask to send a multiline message (as in bk). It could be used for TB info or many other things.

Of course a tablebase is nothing but a book. So why not simply let the engine use the bk command for relaying tablebase moves as well? It should be quite easy for the engine to figure out (e.g. from the number of men on the board) if is should look for the positon in its opening book or in its tablebases (and in which one).

[Michel]

Then you are wrong. There is in fact huge overhead, no matter how little the GUI sends. The GUI process has to be woken up by the timer interrupt. It has to use a pipe system call to copy data to kernel memory space. Several task switches and context switches are involved. In usual OS implementations they involve searching the process table to get the process that should be woken up.

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

But again: my issue was only with you calling the "." command hideous. Not with the relative merits of the different ways of regulating the communication flow between the engine and the GUI. This is an entirely separate issue and I have no strong feelings about that either way. I simply think one should not use emotionally charged words in a technical discussion.

There already exists a command that allows the engine to popup a message. I don't see how the information of adding that the engine has a fatal error would help the GUI.

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.

[michiguel]

I suggested at time to implement the tb command, but now I think it could be expanded.
I suggest to have this as an "-info" button. You click that button, and the engine is ask to send a multiline message (as in bk). It could be used for TB info or many other things.

Of course a tablebase is nothing but a book. So why not simply let the engine use the bk command for relaying tablebase moves as well? It should be quite easy for the engine to figure out (e.g. from the number of men on the board) if is should look for the positon in its opening book or in its tablebases (and in which one).

That is exactly what Gaviota is doing now. When you click "book" when tbs are installed and there are 5 or less pieces on the board, you get the info I show in the cited message.
I agree, bk could stay the same but be more flexible. However, the documentation should say something about this, and most importantly, the menu should change from book to something like "book/tables" or "positional info". Now it is not a problem of protocol, but the implementation.

Anyway, it would be really good to have a button -info because it will be useful for many other things. TBs were just only an example.

Miguel