Some more WB protocol extensions

[hgm]

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?

So why pop up the second dialog?
The fact that the engine exits after sending the error message is a pretty strong indication that the error was fatal, not? The GUI must be really stupid if it assumes it will be 'business as usual' after that...

[Michel]

So why pop up the second dialog?

Do you mean suppressing the "engine has exited dialog".

How would the GUI know the engine has not crashed if the engine has no way of telling the GUI that it is going to exit cleanly?

[hgm]

How would the GUI know the engine has not crashed ...

Because the last command received from the engine was tellusererror?

[Michel]

Because the last command received from the engine was tellusererror?

That doesn't mean a thing. The engine could inform the user that it has not found its book (normally a non fatal error) and then unintentionally crash anyway for some obscure file system configuration reason.

[hgm]

Who cares to know if the crash was intentional or unintentional? Certainly not the GUI. It could not care less why the engine exited. You can tell the user with the message if the error was fatal or not. When you report an obviously non-fatal error to the user (e.g. "tablebases absent; proceeding without tablebases") and XBoards exits without further notice, the user should understand that the engine has exited. Especially when he looks into the debug file, which should list events like dying engines in any case.

These popups are not meant to debug GUI or engine. For that, the debug file is provided. And you can write detailed error messages there through feature debug=1. The popups only serve to leave the naive user in a not all-too-puzzled state (such as: why is the engine not using its opening book?). Normally, a user should not have to deal with crashing engines at all. Assuming complex combinations of fatal and non-fatal errors is beyond the scope of normal GUI use. I don't think anything can be gained by showing a message to the user that tells him the engine exited unexpectedly when XBoard exits after getting an eror message from that engine. In all cases he will blame the engine. There is no need for the GUI to rub it in. It is up to the engine to present its excuses and argue its case in the preceeding error dialog.

[hgm]

We could of course beef up the specs a little on telluser and tellusererror, by including the phrase that on the latter the GUI should not be surprised if the engine exits, and suppress vague error messages like "broken pipe" because the engine likely gave a more informative description of the problem already.

Would that satisfy your needs?

It seems to me that tellusererror in the existing protocol is intended to be what you would call 'tellfatalerror', and that for messages you are not going to exit on, you should use telluser in stead. What else could be the difference between telluser and tellusererror? And if they were exactly the same, why should they both exists?

I like specs where the engine is allowed to exit (after giving a decent error message) on its own accord better than when it would be required to always ait for a quit command, as the latter could cause hangs in automatic testing.

Of course the handling of fatal engine errors in XBoard still leaves much to be desired. This should really not be a fatal error for XBoard at all, it could simply reload the engine, as it does with -reuse anyway. But this is all implementation, and I don't want to mess with it before we got rid of the startup dialog.

[michiguel]

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

No, it does not work. if
printf ("telluser Hello 1st line\n2nd line\nthird line\n");

I see Hello 1st line and of course the rest is sent as commands to xboard that are ignored.

If I send printf ("telluser Hello 1st line\\n2nd line\\nthird line\n");

I see Hello 1st line\n2nd line\nthird line

And that is actually how it was meant to work according to the protocol.

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

Not so sure because the protocol explicitly says:

telluser MESSAGE
xboard pops up an information dialog containing the message. MESSAGE consists of any characters, including whitespace, to the end of the line.

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?

There are certain things that the engine may be asked to output that do not belong to the engine-output window. TB information is one, helps, etc.

Miguel

[hgm]

And that is actually how it was meant to work according to the protocol.

...

Not so sure because the protocol explicitly says:

telluser MESSAGE
xboard pops up an information dialog containing the message. MESSAGE consists of any characters, including whitespace, to the end of the line.

I don't read anything in that which would imply that one cannot use standard escape sequences in the MESSAGE. To me it only says that no quoting is necessary.

Note that quite recently I fixed a very basic bug in XBoard, where a "\n" in the InitString command-line argument was relayed to the engine as a backslash plus an 'n'. (Not in the compiled-in default "new\nrandom\n", which appeared as a string in the C source where the compiler took care of it, but when you would say

xboard -firstInitString "new\nrandom\n"

the engine would not start.)

I think this is just a manifestation of the same bug.

[michiguel]

And that is actually how it was meant to work according to the protocol.

...

Not so sure because the protocol explicitly says:

telluser MESSAGE
xboard pops up an information dialog containing the message. MESSAGE consists of any characters, including whitespace, to the end of the line.

I don't read anything in that which would imply that one cannot use standard escape sequences in the MESSAGE. To me it only says that no quoting is necessary.

It implies that end of line (EOL or \n in C) finishes MESSAGE and it does not say that "\\n" should be interpreted to break a line, so I cannot assume that your suggestion should work. On top of that, it does not work.

If this was meant to be multi line, then Tim did everything possible to obfuscate the protocol and hide its original purpose making WB to behave exactly in the opposite direction.

I am digressing, but I would really wish to read the WB protocol without playing guessing games all the time. We should read this and implement it, without trying to guess where the loopholes are. Things should be spelled out. This document should be written for engineers, not lawyers Besides, the whole thing needs to be rewritten from scratch, with short examples and dumping all the backward compatibility issues to an appendix. I do not mean that you should do this task, but someone should. Maybe some sort of a team effort.

Miguel

Note that quite recently I fixed a very basic bug in XBoard, where a "\n" in the InitString command-line argument was relayed to the engine as a backslash plus an 'n'. (Not in the compiled-in default "new\nrandom\n", which appeared as a string in the C source where the compiler took care of it, but when you would say

xboard -firstInitString "new\nrandom\n"

the engine would not start.)

I think this is just a manifestation of the same bug.

[hgm]

It implies that end of line (EOL or \n in C) finishes MESSAGE and it does not say that "\\n" should be interpreted to break a line, so I cannot assume that your suggestion should work. On top of that, it does not work.

For clarity: the description deals with what you send, not what you have in the source code of your engine if it happens to be written in C. If your engine source contains "\\n", you send '\' + 'n'. If it contains "\n", you send a LINEFEED.

That being said, the specs imply that the message ends when you send LINEFEED. It does not say anything about how sending a backslash followed by an 'n' should be treated. I, for one, would have expected almost universal conventions for embedding control characters in text would work.

If this was meant to be multi line, then Tim did everything possible to obfuscate the protocol and hide its original purpose making WB to behave exactly in the opposite direction.

This is not without precedent. What do you think about xboard sending new\nrandom\n (on a single line!) to an engine, when the user specified -firstInitString "new\nrandom\n"? But I brought up the point on the GNU bug-xboard mailing list, so we will get to see Tim's reaction.

I am digressing, but I would really wish to read the WB protocol without playing guessing games all the time. We should read this and implement it, without trying to guess where the loopholes are. Things should be spelled out. This document should be written for engineers, not lawyers Besides, the whole thing needs to be rewritten from scratch, with short examples and dumping all the backward compatibility issues to an appendix. I do not mean that you should do this task, but someone should. Maybe some sort of a team effort.

I fully agree. The specs as they are are too ambiguous. To the point where engine authors really are in doubt whether they should count moves that are forced to them as part of the current TC session. (This breaks many engines for running on classical TC with an external book.)

So the specs should be made more explicit. But for the telluser and tellusererror commands I think it would be sensible to specify that standard escape sequences work, rather than that they should not work. I don't see any harm in that, and lot of advantages. I don't think there would be _any_ existing engine that relies on '\' + 'n' sent in a telluser MESSAGE currently being printed as a backslash and an 'n'. Why would anyone want to print that?

And if we want to intentionally allow multiple interpretations, like in the case of clearing hash tables on a new command or not, we should explicitly mention that in the specs.