hgm wrote:It is very annoying to users if your engine does ignore his general settings, and he has to reconfigure that engine sepatately through its own options menu, every time he wants to conduct a tournament with another number of CPUs.
True, and I fully support the efforts to standardize the chess protocols. But it's going to take an annoyingly long time for the engines to catch up. In the mean time we can make the configuration options in the GUI more flexible.
We could let scripts or at least aliases to act as adapters between the standardized options and the engine's non-standard options. So when the user is installing a UCI engine, he could tell the GUI (via a script or a simple alias) that the engine uses option "bar" to implement the standard UCI option "foo". We've thought about implementing something like this in Cute Chess.
We could let scripts or at least aliases to act as adapters between the standardized options and the engine's non-standard options.
Work arounds are possible. Polyglot supports already quite a large number of known thread options. Unfortunately people still invent new ones. As PG is open source is is not hard to add these new names to the source as they come along.
In addition I could add the ThreadAlias option to PG which has been discussed.
A similar alias could be provides for the Scorpio bitases path which is far from standard also.
We could let scripts or at least aliases to act as adapters between the standardized options and the engine's non-standard options.
Work arounds are possible. Polyglot supports already quite a large number of known thread options. Unfortunately people still invent new ones. As PG is open source is is not hard to add these new names to the source as they come along.
I didn't mean that GUIs (or Polyglot) should have hard-coded workarounds for every engine that does things differently - I wouldn't allow any engine-specific code in any part of a GUI. What I suggested was that the end-user could easily create said workarounds when installing the engine.
BTW, What is the preferred way to get patches accepted to Polyglot? Is the project under a version control system somewhere, and who's maintaining the official branch/version?
I didn't mean that GUIs (or Polyglot) should have hard-coded workarounds for every engine that does things differently
Well the "thread" option is a bit of a special case since there is no standard. So one can not really say that some engine authors are doing "things differently". I only think they are a bit stubborn by not sticking to names already in use by other engines. If they did it would not be a problem for PG (since PG already knows the thread options of most existing engines).
BTW, What is the preferred way to get patches accepted to Polyglot? Is the project under a version control system somewhere, and who's maintaining the official branch/version?
Unfortunately there are several versions now.... I started implemented some new
features on 1.4w10 (maintained by Fonzy Bleumers): UCI support and support for
new features of the xboard protocol as defined by H.G. Muller.
It was not meant to be a fork but it seems to be becoming one as I could not resist
refactoring the code in order to clean up the WIN32 port (mainly the number of
#ifdef _WIN32's).
I have been thinking of setting up a svn repository but it is not a panacea if people don't use it. The xboard svn repository seems not to be used either.
BTW, What is the preferred way to get patches accepted to Polyglot? Is the project under a version control system somewhere, and who's maintaining the official branch/version?
Unfortunately there are several versions now.... I started implemented some new features on 1.4w10 (maintained by Fonzy Bleumers): UCI support and support for new features of the xboard protocol as defined by H.G. Muller.
It was not meant to be a fork but it seems to be becoming one as I could not resist refactoring the code in order to clean up the WIN32 port mainly the number of #ifdef _WIN32's).
I have been thinking of setting up a svn repository but it is not a panacea if people don't use it. The xboard svn repository seems not to be used either.
It's an unfortunate situation-- there seems to be a fair bit of interest in polyglot by developers right now. Yet, we all seem to have our own areas of (dis)interest in the project.
I've decided it best to go back to my private source tree because I can't be re-implementing the changes I need into each new release.
Win95 support is already gone, but the option in the makefile still exists. None of my fixes for compiler warnings remain. There are still %lld bugs present, although failure to notice them at the time of that fix was as much my fault as anyone else's.
BTW, What is the preferred way to get patches accepted to Polyglot? Is the project under a version control system somewhere, and who's maintaining the official branch/version?
Unfortunately there are several versions now.... I started implemented some new features on 1.4w10 (maintained by Fonzy Bleumers): UCI support and support for new features of the xboard protocol as defined by H.G. Muller.
It was not meant to be a fork but it seems to be becoming one as I could not resist refactoring the code in order to clean up the WIN32 port mainly the number of #ifdef _WIN32's).
I have been thinking of setting up a svn repository but it is not a panacea if people don't use it. The xboard svn repository seems not to be used either.
It's an unfortunate situation-- there seems to be a fair bit of interest in polyglot by developers right now. Yet, we all seem to have our own areas of (dis)interest in the project.
I've decided it best to go back to my private source tree because I can't be re-implementing the changes I need into each new release.
Win95 support is already gone, but the option in the makefile still exists. None of my fixes for compiler warnings remain. There are still %lld bugs present, although failure to notice them at the time of that fix was as much my fault as anyone else's.
I searched the source code for any occurences of "%lld"
and could not find any.
Can you show them?I'll be glad to fix them
