h.g. muller wrote:
> Ok. I was always under the impression that the aim was to create
some generic mechanism by which the user
> would be unaware that PG is being used internally to handle UCI
engines. Apparently
> this was a communication problem.
Well, this is a good goal, but I just don't see how you could do it in
this case.
The fact that two versions of the same engine can co-exist is only because
Polyglot allows it. With native WinBoard engines this would not be
possible.
The user would either have to install it under a different name of the
executable,
or in a different folder.
I guess UCI engines could mimic that by using the -fd argument in the path
of the settings file. But it is an ugly kludge in the first place, so
I am not sure
it is worth mimicking. To make it possible in the scheme where
Polyglot would
derive the ini-file name from what the engine reports, it would need a
new argument
SettingsPath to make that possible. The default for this would then be
_PG,
but WB could use the adapterCommand
polyglot -ec %<fcp> -ed %<fd> -sp %<fd>
meaning that the settings files will always be stored with the engine.
Ok,
If traditional config files will remain the standard way of interfacing
with PG
then I will change my version of PG in such a way that the primary
config file and PersistenceFile
coincide.
In case PG is invoked with -noini then PG can make up the name of the
config file by starting the engine
first (as I do currently).
As a special exception (for WB 4.4.0 compatibility) if PG is invoked as
"polyglot polyglot_1st.ini"
and "polyglot_2nd.ini" it would just treat the entries of these config
files as command line
arguments (which is what they were in the first place!) and pretend
having been invoked
with -noini.
I think this would combine the positive aspects of the different approaches.
