XBoard beta tar ball

[hgm]

For people that are willing to test beta versions of XBoard, I posted a source tar ball at http://hgm.nubati.net/xboard-master-20120410.tar.gz . It contains an XBoard with a largely rewritten front-end (which you should not notice at all, if I did it well). There are some slight interface improvements (tabbing between text edits, mouse-wheel scrolling on listboxes, a new file-browse window, dual-board ICS background observing in an extra board window), and it also supports the exclude-moves feature (if you have the matching Polyglot), and position-search narrowing.



For a more elaborate description, see the usual news page.

[Michel]

Just tried it. It feels indeed a bit smoother.

One comment: the issue that when you specify a non-existing engine
you have to wait 5 seconds or so before you can proceed is still there for
UCI engines.

polyglot itself quits immediately with a tellusererror
which (as you argued some time ago) should be a sufficient indication that polyglot failed to start the engine.

[hgm]

Hmm, yes, you are right. The problem is that in parsing the engine input, XBoard first checks for 'telluser', and only after that for 'No such file'. A 'No such file' in a 'telluser' command thus has no special significance. XBoard just assumes it is a v1 engine after the timeout.

Not sure how to solve this. If I let XBoard test for 'No such file' first, the command would not be recognized as a 'telluser', and would not lead to the corrsponding popup. 'tellusererror' should in itself not be fatal. Of course XBoard then produces its own error popup (which used to be from DisplayFatalError, but now is just DisplayError, and switches to -ncp mode).

I guess Polyglot tries to do it too cleanly, and XBoard, not being used to that, cannot understand it!

Perhaps the best solution is to simply let Polyglot relay the error message without prefixing by 'tellusererror'. That is what other (non-chess-specific) adapters such as ssh would do, so to do it differently just complicates matters for XBoard.

[hgm]

I guess best is if I let Polyglot print both a polite error message (through 'telluser'), and a raw one ('execvp(): No such file or directory') in case of an error from pipex_open. (I assume these are all startup engines.) In XBoard I can the suppress the regular (but awful) error message immediately after a tellusererror, but nevertheless take the associated action (switching to -ncp mode).

What still worries me is that it seems XBoard is made such that an engine that does not feel like completing its game can send 'No such file' at any time to abort the game without a forfeit. In the old days this would have made XBoard exit, now it switches to -ncp mode (probably making the tourney hang). I guess I must only pay attention to this when really starting up an engine.

[Michel]

Well we discussed this issue at length some time ago.

The problem will also occur with an engine that starts up, decides it cannot find its resources and then quits (or simply crashes).

I think it would be best if during the 5 second timeout, xboard would simply monitor the engine to see if it is still alive. If not, and the engine has emitted a tellusererror, xboard should silently return to ncp mode.

If the engine dies silently then xboard could generate its own dialog box.

The idea would be to avoid a cascade of error dialogs which the old xboard used to suffer from badly.

[hgm]

Indeed, but the detection if the engine was still alive somehow seemed to fail here. It is done in the low-level read/write routines on the pipe. If the engine dies I would expect the input thread to generate an EOF, which would then trigger the error handling. But it didn't.

Besides that, the error handling has changed a bit since the introduction of on-the-fly engine loading: during a game it should still cause GameEnd (with a forfeit, but no longer fatal for XBoard, because it could happen in a tourney), but during engine startup I wanted it to switch to -ncp mode. I let the latter be triggered by the 'No such file' error message from the engine.

This could be a bad idea, though. For one, I really should make a distinction between tourney games and a user loading engines from the menu, because in a tourney switching to -ncp mode without calling GameEnds would stall the tourney. (Or is this what we want, for a tourney with a non-existing participant?) For user loading, the switch to -ncp would not affect the game state, like any loading of engines would not affect the game state. The idea is that he should be able to switch engine during analysis, and an inadvertant typo in th enegine name should not destroy his existing analysis. He should just get the opportunity to switch to an existing engine.

In addition there seems to be the cheating problem during a game, when engines would send these fatal messages themselves. This is easy to remedy by paying attention to the variable 'initDone' in the ChessProgramState, though. When it is set, these error messages should always result in a regular forfeit.

[Michel]

If the engine dies I would expect the input thread to generate an EOF, which would then trigger the error handling. But it didn't.

Well this seems like a bad bug which should be fixed first before
talking about "No such file" hacks, doesn't it?

As I said, the issue is not specific to UCI engines. I.e. do

xboard -fcp ps

The ps command itself quits very quicky (you can see this by starting it with polyglot)

Code: Select all

polyglot -noini -ec ps
PolyGlot 1.4.67b by Fabien Letouzey.
tellusererror POLYGLOT: pipex_exit(): ps: child exited with status 0.

Yet xboard is not able to see that ps has quit and considers it as a wb 1 engine(!).

[hgm]

Well, the 'hack' is necessary, since there is no guarantee the 'engine' will quit after sending a 'No such file' message (e.g. shells in general would not, but just prompt you for another command). So solely relying on the process to die is not a reliable method.

I assumed that it was a system feature that I could not alter, if XBoard is not properly notified of the pipe breaking. But is seems I am responsible for this myself, having added an "if(!cps-initDone) return;" in the handling of the EOF condition, and forgetting all about it. So you are right: this can, and thus should be fixed. I guess I will relocate the code for switching back to -ncp mode in a subroutine, and call it both when receiving the 'not found' type of messages as well as an EOF.

[Michel]

So you are right: this can, and thus should be fixed.

Great!

Well, the 'hack' is necessary, since there is no guarantee the 'engine' will quit after sending a 'No such file' message (e.g. shells in general would not, but just prompt you for another command). So solely relying on the process to die is not a reliable method.

Well it is only necessary as a fallback for remote connections since there is nothing else one can use.

However one cannot expect an engine that is about to crash to first send a "No such file" message to xboard. So xboard should handle quitting engines properly.

Hence there is no need I think for Polyglot to print "No such file" when it encounters an error condition.... Sending tellusererror and quitting should be sufficient (I am actually repeating your own arguments here )

[hgm]

OK, it should be fixed now. (In the GNU Savannah git, not in the tar ball I posted yesterday.) Both for the pending v4.6.1 release and in the master branch. It seems to produce the desired effect in terms of error popups and switch to -ncp mode for all combinations of UCI/WB and exiting/non-existing engines. (And indeed with old Polyglot behavior.)

The only thing I am not sure of is what to do when an engine startup fails during a tourney. Currently it would also switch to -ncp (+ EditGame) mode in case of first-engine failure, which would terminate the tourney play. In case of the second engine, however, it would not do a mode switch, which presumably means the engine would sooner or later be forfeited on time, and the tourney would continue. I guess the inconsistency between first and second engine is undesirable in itself.