Polyglot1.4.41b

[Michel]

This version implements persistence of options. It should just work.

It is implemented by having an additional ini file whose name is <myname>.ini which is read at startup and written at exit (when SaveSettingsOnExit is true which is the default).
Currently this file is in in the current directory which on Linux is not quite natural. In the next version I will save it is in a dot-directory in the user's home directory.

I guess on Windows these savefiles should go into some subdirectory of Documents and Settings. Anyone knows what the correct api functions are to handle this?

The save button is not implemented yet. I guess that would only make sense if you want to set SaveSettingsOnExit to false.

[F.Huber]

Hi Michel,

a problem with this new version:
It seems to send commands for every defined 'button' type to the engine at startup, so for ChestUCI there are 3 Notepad windows opened automatically when it is started.

PS: I just saw that you store 'button' options in the ini-file (e.g. Show Solution=<empty>)!?
IMO that makes no sense at all, because buttons have no values (to store) and cause only an action when they are clicked.

[Michel]

PS: I just saw that you store 'button' options in the ini-file (e.g. Show Solution=<empty>)!?
IMO that makes no sense at all, because buttons have no values (to store) and cause only an action when they are clicked.

Oops. Yes of course that is a bug. I will fix it ASAP,

[F.Huber]

I guess on Windows these savefiles should go into some subdirectory of Documents and Settings.

Oh my god, please don't use the same crap like newer Windows versions!!!
(BTW, in which subfolder should it be stored?).
I think it would be better to use the engine's directory (or just stay with the current PG folder), and maybe a prefix PG_ might also be a good idea (to avoid conflicts when the engine has an own ini-file).

[Michel]

Oops. Yes of course that is a bug. I will fix it ASAP,

This should be fixed now. I didn't bump the version number.

and maybe a prefix PG_ might also be a good idea

Yes indeed. I now use a prefix PG_ as you suggest.

I think it would be better to use the engine's directory (or just stay with the current PG folder),

But I am bit worried that these directories might not be writeable. This would typically be the case on Linux.
Probably on Windows this is a less of a problem though.

[F.Huber]

But I am bit worried that these directories might not be writeable. This would typically be the case on Linux.
Probably on Windows this is a less of a problem though.

Well, it might also be a problem in Windows (at least in newer versions), but then it's the user's fault if he doesn't have enough permission to write in his engine folders.
E.g. my ChestUCI (and maybe also other engines) automatically writes some files into it's own folder while it is running, so if Windows doesn't allow this, a user won't be able to run the engine.

Writing everything into 'Documents and Settings' (without giving the user the choice) is one of the most annoying Windows 'features' IMO - only writing all settings into the registry is even worse.

[H.G.Muller]

a problem with this new version:
It seems to send commands for every defined 'button' type to the engine at startup, so for ChestUCI there are 3 Notepad windows opened automatically when it is started.

Oops! The version I patched to test saving of ini files had exactly the same bug. (I guess that is what you get for not testing with Chest... )

Btw, for those wanting to try the installer package, it is at http://home.hccnet.nl/h.g.muller/WinBoa ... 0beta2.exe

The solution I had chosen for saving is simply to save on the file that polyglot was called with (or polyglot.ini if no file argument was given), unle the user changes this before saving. (Nothing is saved automatically on exit.) If the polyglot.ini file was a protected one, the writing will fail (and WiBoard informs the user). The user could still use WB+Polyglot to edit such a file, if he acquires the permission first. Otherwise he has to alter the name to a folder where he doe have permission.

[Michel]

Writing everything into 'Documents and Settings' (without giving the user the choice) is one of the most annoying Windows 'features' IMO - only writing all settings into the registry is even worse.

Well I am not a windows user so I have no strong feelings about this. But this is data that the user would typically not see. So its actual location should not be so important.
The typical path for application data is

C:\Documents and Settings\username\Application Data.

and one can get it via the symbolic constant CSIDL_APPDATA

[F.Huber]

Oops! The version I patched to test saving of ini files had exactly the same bug. (I guess that is what you get for not testing with Chest... )

Well, I always knew that ChestUCI is not only a good matesolver but also an excellent test engine for PG+WB ...

[Michel]

Some cosmetical changes. I had written a comment in PG_<myname>.ini that you are not supposed
to edit this file but of course you can edit it safely. It is just an ordinary config file.
I have changed the comment. I have also added a comment that you can safely delete this
engine specific ini file which has the effect of restoring the default options (there should
be a button for this but currently there isn't).

I didn't bump the version number.

http://alpha.uhasselt.be/Research/Algeb ... t-release/

[H.G.Muller]

I am not sure how this dual settings files work. Are the settings used at startup stil those in polyglot.ini? (Or whatever name the user has given on the command line)? When it encounters a name for the SaveFile in this primry OptionsFile, will it switch to loading options from that? Or will it be used only for writing and not reading? To the user this would not really seem like persistence of options; next time they start up they would not start with the same options as they ended with last time.

Wouldn't it be better to just save on the file that is also used to read from (unless the user changes the file name)? That would really create the feeling of persistence. Of course a user could make the two names the same. But then why allow them to set them separately? I am not sure how you have in mind that this should be used.

I would also appreciate some user feedback as to the desirability of automatically saving settings on exit, as opposed to having a 'save settings now' button. (WinBoard supports both for its own settings.)

[Giorgio Medeot]

I guess on Windows these savefiles should go into some subdirectory of Documents and Settings.

For me this behaviour is really undesirable: I have all my chess applications installed on a usb stick, so I can take them with me wherever I go, and having an application start writing his own files around on whatever pc it happens to be mounted would break the portability of my setup.
Maybe, if you want to go on with it that way, you might consider a "PortabilityMode" option to let PG save the file in his current directory (or the engine's one). This would be pretty much appreciated, at least by me

Thanks for all your work,

Giorgio

[H.G.Muller]

Why would the current directory be an inconvenient place to make user files, on Linux? Usually it would be his own directory.

On Windows I would not try to outsmart the user. Just let him decide what file he wants to save on. Even under Linux. There are different uses for this, and only the user knows which one applies. He could be a system administrator that wants to install an engine with certain settings for system-wide use. He could be an ordinary user that knows he is the only user that plays chess on this computer. He could be a user that wants to make a special version of an engine he also wants to keep under default settings. Or he could be a user that wants to maintain his own private collection of settings for UCI engines on a multi-user computer that keeps the default settings in a place that he cannot write.

The advantage of only saving on request is that there is more room for error handling. In my version, if the user presses "save polyglot.ini", and he was using settings from a shared file on which he has no write access, he is simply informed by an error popup from WinBoard. (I.e. Polyglot sends "tellusererror file could not be written" to the GUI.) Then he can change the name of the settings file, and try again. Users that run from a memory stick that they do not want changed could simply not press the save button, or make the files read-only.

[Michel]

I am not sure how this dual settings files work.

It is mainly used for running PG without a configfile. I.e.

polyglot -noini -ec fruit

At exit Polyglot will save the setting in PG_Fruit 2.1.ini and the next time will load its settings from that file (when it
is using the engine fruit2.1 that is).

It can also be used for example with

polyglot polyglot_1st.ini

Then polyglot gets the engine name from polyglot_1st.ini and loads the corresponding PG_<myname>.ini file (if it
already exists).

When setting SaveSettingsOnExit=false in polyglot.ini persistence is disabled (no loading or saving engine specific
configfiles). SaveSettingsOnExit is really a bad name. I will rename it as "Persistence".

[H.G.Muller]

I am still thinking about this aloud a bit:

If you would call Polyglot with -noini, there actually is only one setting file. So why not make that "the" settings file, that is also used for startup. My problem is that with Persistence on, if I call Polyglot like that, and it saves on PG_fruit.ini on exit, next time I call it the same way it would not automticlly reload the options. So I would not see any persistence. I would first have to change the engine command in the GUI.

Wouldn't it be possible to make this automatic? Deriving the settings file name from the engine is a neat idea, but you could always do that if there is no settings-file argument given (but there is an engine-command argument). So with "polyglot -ec fruit" it would try to open PG_fruit.ini if there is one, and if not, use compiled-in default settings for all Polyglot options. (It could even derive a default engine directory from the engine command.) On exit (with persistance on) it would either overwrite the settings file or create it.

When it is first called with polyglot_1st.ini, to pass the engine name, this would not wrk so well. But I wouldn't worry about that; with the possibility to pass the engine command on the command line I will switch to that method, and user would have to live with the inconvenience of having to change the settigs file name until then. (He would have to change the engine command anyway.) An intermediate kludge for WinBoard would be to not use polyglot_1st.ini and polyglot_2nd.ini s files to pass the engine command, but derive them from the engine name itself. But I guess this is not really worth it, as the way to communicate through files is really inferior to communicating through command-line options.

[Michel]

My problem is that with Persistence on, if I call Polyglot like that, and it saves on PG_fruit.ini on exit, next time I call it the same way it would not automticlly reload the options.

Why not. Of course it would. Why do you think it wouldn't?

[H.G.Muller]

Then I misunderstood the part about "additional" ini file. If the <myname>.ini is both used for reading at startup, and saving on exit, it seems to me it is the only inifile, and what you changed is just the default naming convention of the polyglot.ini file.

So let me see if I get it now. On startup:
1) If a file argument is given it is used as the ini file.
2) With -noini and an engine-command given, it uses PG_<engine name>.ini. If it cannot find it, it uses compiled-in defaults.
3) With an engine command, no file, but also no -noini, it uses polyglot.ini.
3) Without file or engine command it uses polyglot.ini.
4) With -noini and no engine command it cannot know what to do (play from book?).

On exit:
a) You save on on PG_<engine name>.ini when an engine commmand was given.
b) Without engine command you save on the settings file that was given (possibly polyglot.ini).

The user gets the chance to alter the name of the save file before he exits.

[Michel]

Somewhat like that yes.

PG starts up through a combination of the usual ini file and command line options (if -noini is given then the ordinary (possibly default) ini
file will not be used, so everything has to be supplied on the command line).

Then PG starts up the engine and gets the engine name. Then it tries to load additional options from a file named PG_<myname>.ini.

On exit PG saves the values of the options to PG_<myname>.ini which are different from the ones that can be obtained from the usual ini file and engine defaults.

The difference with the ordinary ini file is that to have access to the options in PG_<myname>.ini PG needs to start to engine first to find out
the engine name.

My idea was that both

polyglot polyglot_1st.ini
polyglot -noini -ec fruit

would give persistence in a way which is transparent to the user.

EDIT

I forgot to mention one point. If you want to use the same engine with different sets of options you can override the engine name on the
command line. Like this

polyglot -noini -ec fruit -en "Fruit Wild"
polyglot -noini -ec fruit -en "Fruit Tame"

This will give engine specific ini files PG_Fruit Wild.ini and PG_Fruit Tame.ini. But using the default PG_<myname>.ini will be more typical.