Re: [Bug-XBoard] Infinite recursion
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. It is not that simple. One would want the engines to run in the same locale as XBoard, in order to get translation of the engine-defined options in the Engine Settings dialogs. The libc messages that are recognized by XBoard are supposed to come from intermediaries like ssh, which you typically use when you run the engines on a remote machine (using -firstHost, -secondHost). This is needed because such interediaries might not exit when they fail to execute the engine binary. The engine itself, when run locally, can inform XBoard of its failure to start by simply quitting. Failure to exectute the engine is announced by XBoard to itself (i.e. from the child process to the main process through the pipe) using perror(), which presumably would use the current locale. So perhaps we should make the child switch to the C locale after exec failure, before using perror(). Is that possible? If the engine really runs on a remote machine, I don't think it would pay attention to any environment variables on the local one. Or would it? ___ Bug-XBoard mailing list Bug-XBoard@gnu.org https://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] Infinite recursion
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
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
