Re: [Bug-XBoard] Latest developments

2012-04-11 Thread h.g. muller

At 14:41 10-4-2012 -0700, Arun Persaud wrote:

didn't have time to test, but a second window with clocks and move
highlight sounds better... does this automatically open if you play or
observe a bughouse game or a simul-game on FICS? That would be great!


It behaves like the old dual-board option (except that it displays the second
board in a separate window, rather than both in the same). That is, it 
automatically

pops up the window when you receive a board from the ICS while you are playing
a game, which is not from that game, when background-observe and dual-board
are both on.

It should not be too difficult to have the active clock count down as well,
handling that from the timer callback that decrements your own clock.
(The clocks of the dual board does not require msec accuracy, so there
is little harm in decrementing them simultaneously. In ICS mode clocks
are only an indication anyway.) The point is that this would have to be done
from the back-end, so it would affect WinBoard, and I would have to provide
(dummy?) support in WB for the calls to update the second set of clocks there.

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard


Re: [Bug-XBoard] Infinite recursion

2012-04-11 Thread h.g. muller


However if start xboard in my normal Danish locale the error error does 
not come up, and the engine setting menu item are enabled. If I click on 
Engine #1 settings, xboard will crash.

...
But the point is that the behavoir depends on the locale in a way it 
shouldn't.


I guess the problem is that XBoard (as described in the protocol specs) 
triggers on receiving a message containing No such file from the engine 
process, and that the engine probably sent a translated version of that 
message. That is a bit hard to fix. We could translate the system standard 
error messages it compares to in backend.c. But that is tricky; they really 
would have to be translated to the exact messages that the system in that 
locale would produce. We could of course let XBoard request the messages by 
error number in its own locale, and use those in the comparison. But also 
that will not always do what we need, because you could be running the 
engine on a machine with a different locale as wher XBoard is running.


One problem, which I have just been fixing even before I saw your report on 
this, is that the master version that does this is indeed a bit broken: it 
ignores pipe breaks before engine initialization is complete. While in fact 
detection of EOF while reading from the engine process would have been a 
good alternative method to produce an error popup and trigger the switch 
back to -ncp mode. (It would be a different error popup, engine exited 
unexpectedly in stead of failed to start engine, but I could live with 
that.) This problem came up when starting non-existent UCI engines, as 
Polyglot wraps the error message in a tellusererror command, which 
effectively hides it from XBoard, so that the only signal to go on is 
Polyglot exiting.


I have fixed that with the most-recent commit. This should prevent the 
other problem, because it would disable the menu you had to click to cause 
it. I guess it was not so much caused by recursion as well as repetitive 
triggering of the same error condition ('broken pipe'), and failure to make 
that trigger the required action to solve the problem.


___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard


Re: [Bug-XBoard] Infinite recursion

2012-04-11 Thread Byrial Jensen

Den 11-04-2012 12:06, h.g. muller skrev:

However if start xboard in my normal Danish locale the error error 
does not come up, and the engine setting menu item are enabled. If I 
click on Engine #1 settings, xboard will crash.

...
But the point is that the behavoir depends on the locale in a way it 
shouldn't.


I guess the problem is that XBoard (as described in the protocol 
specs) triggers on receiving a message containing No such file from 
the engine process, and that the engine probably sent a translated 
version of that message. That is a bit hard to fix. We could translate 
the system standard error messages it compares to in backend.c. But 
that is tricky; they really would have to be translated to the exact 
messages that the system in that locale would produce. We could of 
course let XBoard request the messages by error number in its own 
locale, and use those in the comparison. But also that will not always 
do what we need, because you could be running the engine on a machine 
with a different locale as wher XBoard is running.


If Xboard is dependent on untranslated error messages from libc, it 
should run the engines in the C locale. It can be done by calling 
putenv(LANGUAGE=C) in the child proces before the exec() call.



___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard


Re: [Bug-XBoard] Latest developments

2012-04-11 Thread Tim Mann
The second board, with clocks that count down, would be super for bughouse.

On Wed, Apr 11, 2012 at 2:32 AM, h.g. muller h.g.mul...@hccnet.nl wrote:
 At 14:41 10-4-2012 -0700, Arun Persaud wrote:

 didn't have time to test, but a second window with clocks and move
 highlight sounds better... does this automatically open if you play or
 observe a bughouse game or a simul-game on FICS? That would be great!


 It behaves like the old dual-board option (except that it displays the
 second
 board in a separate window, rather than both in the same). That is, it
 automatically
 pops up the window when you receive a board from the ICS while you are
 playing
 a game, which is not from that game, when background-observe and dual-board
 are both on.

 It should not be too difficult to have the active clock count down as well,
 handling that from the timer callback that decrements your own clock.
 (The clocks of the dual board does not require msec accuracy, so there
 is little harm in decrementing them simultaneously. In ICS mode clocks
 are only an indication anyway.) The point is that this would have to be done
 from the back-end, so it would affect WinBoard, and I would have to provide
 (dummy?) support in WB for the calls to update the second set of clocks
 there.


 ___
 Bug-XBoard mailing list
 Bug-XBoard@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-xboard

___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-xboard