Winboard Forum

Some more minor tweaks

- The engine specific config files (<myname>.ini) are now stored in a separate directory. $HOME/.polyglot on Linux and ".\Polyglot Settings" on Windows (this is done by PG internally, the user does not need to worry about it).

- The engine specific config files are now complete config files. So they can in principle be used in a stand alone fashion (just copy them to wherever you want).

I am now quite happy with this version. It seems to behave as one would expect. Options of UCI engines are preserved just like for example in native UCI gui's such as Arena. If one does not use the Engine settings dialog or sets Persist=false then there is no change in behaviour.

A "Restore Defaults" button is implemented but it does not work yet since WB still has to implement its side of the protocol.

NB: I do not have access to a windows box at this moment so this version was only tested in wine and not on native windows.
Tonight I will do some more testing on native windows.

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

Saving the complete settings files seems solves the problem of having primary and persistance file the same, correct? Does Polyglot close its settings file while not actually using them? (I think I had some problems uninstalling, because of locked files when I had hanging Polyglot processes due to my tandem-Polyglot debacle.)

How exactly could you implement persitence of the Persitence option? Does it mean that "non-persistence" now is not persistent? WinBoard also works with "Save Settings On Exit", and you only have semi-persistence there (of the "on" state). In WinBoard this is solved by the presence of the menu item "Save Settings Now". If you want to have persistent /saveSettingsOnExit=false, you switch it off in the menu, and then click "Save Settings Now".

Would it be useful to also add a "Save Settings Now" (to the persistence file) -save button in Polyglot for this purpose?

Can't you make the Windows default name of the settings folder a bit shorter? With the current install I supply the settings file in a folder "PG". The idea was that people would have to type this for installing engines into the winboard.ini file for which they have per-existing settings files. Typing "polyglot PG/myfile.ini" is more user friendly (and easier to read back wen you later select the engine from the startup dialog combobox) then 'polyglot "Polyglot Settings\myfile.ini"'. Especially having a space in the default name is truly nasty (nested quoting and such...).

H.G.Muller wrote:Especially having a space in the default name is truly nasty (nested quoting and such...).

Yes, such spaces (also in engine names) are absolutely annoying and have been quite often a source of problems for many users.
(IMO Microsoft should even have forbidden this nonsense - but they're using it themselves in their foldernames)

BTW, it would be nice to have the most recent Winboard version again in your winboard.zip link - the last one is quite old ...

The problem is that I have internally forked. Winboard.zip is a WinBoard 4.4.1 version, including the -keepAlive option and chat windows, but it does not contain the fixes recently made to WinBoard 4.4.0. The most recent version of that is included in http://home.hccnet.nl/h.g.muller/WinBoa ... 0beta2.exe , though.

H.G.Muller wrote:The problem is that I have internally forked.

Always those forkers!

Ok thanks, I've downloaded the installer now.

H.G.Muller wrote:Can't you make the Windows default name of the settings folder a bit shorter?

It's already shorter than you think: "Polylot Settings"
( does that mean 'Poly has a lot of Settings'? )

And also for WB a small (cosmetic) error:
In the engine settings opening a file selection window always shows "Choos Book" in the window title bar - should better be something like "Choose file or folder".

Saving the complete settings files seems solves the problem of having primary and persistance file the same, correct?

I do not save the complete settings file. This would be a problem with 4.3.15. At exit the engine specific settings file would be saved
and then in the next session the command line options of WB, which end up in polyglot_1st.ini would be immediately overridden.
So they would be ineffective. The same applies to people using ini files on the command line. My goal was that if one does not use the Engine settings dialog then the behaviour of PG should remain the same as before.

Currently I think of the engine specific config files as internal to PG. However they are genuine config files
so if you want to use them as such you can copy them out of the "Polyglot Settings" folder and then use them in the traditional way.
Further the engine specific config files can be edited using Notepad. So they can play the role of the traditional config files.
They contain an elaborate comment to that effect.

Code: Select all

; Fri Sep  4 13:13:21 2009

; This ini file is used internally by PolyGlot
; to remember the settings for the UCI engine
; whose name is "Rybka 2.2n2 mp 32-bit".

; The values for these settings would be typicallly
; obtained from the engine settings dialog
; in WinBoard/xboard 4.4.0 and higher.

; It is allowed to manually edit this file
; and you may safely delete it as well.

<snip>


I am of course open to suggestions in this matter.

How exactly could you implement persitence of the Persitence option? Does it mean that "non-persistence" now is not persistent? WinBoard also works with "Save Settings On Exit", and you only have semi-persistence there (of the "on" state). In WinBoard this is solved by the presence of the menu item "Save Settings Now". If you want to have persistent /saveSettingsOnExit=false, you switch it off in the menu, and then click "Save Settings Now".

Well if you turn persistence off then PG will save an engine specific config file of the form

Code: Select all

[PolyGlot]
Persist=false
[Engine]

On restart PG will parse the engine specific config file and note that Persist=false.

Can't you make the Windows default name of the settings folder a bit shorter? With the current install I supply the settings file in a folder "PG". The idea was that people would have to type this for installing engines into the winboard.ini file for which they have per-existing settings files. Typing "polyglot PG/myfile.ini" is more user friendly (and easier to read back wen you later select the engine from the startup dialog combobox) then 'polyglot "Polyglot Settings\myfile.ini"'. Especially having a space in the default name is truly nasty (nested quoting and such...).

Well I can make it shorter. Any suggestions?

But as you know "polyglot \"Polyglot Settings\Rybka 2.2n2 mp 32-bit.ini\"" does not do what you expect (it was not designed this way). The idea is that you should do

xboard -fcp rybka.exe -fUCI

or perhaps

xboard -fcp "polyglot PG/rybka.ini"

and Polyglot loads the file used for persistence (named .\Polyglot Settings\Rybka\ 2.2n2\ mp\ 32-bit.ini) by itself. In the second case I guess Polyglot could overwrite PG/rybka.ini but not in the first case (the config file polyglot_1st.ini is recreated each time). Also I think people should not be forced to deal with config files explicitly (unless they want to).

I run crafty like

xboard -fcp crafty

I don't care what or where crafty's config file is. I trust it that crafty itself knows how to find it.

My home directory contains 111 config files and directories. Obviously I cannot know what these all do.

Does Polyglot close its settings file while not actually using them? (I think I had some problems uninstalling, because of locked files when I had hanging Polyglot processes due to my tandem-Polyglot debacle.)

I think so. There would be no point in keeping a config file open after it has been parsed. It does keep the LogFile constantly open though. So if you have two polyglots doing logging to the default .log file polyglot.log they will perhaps trample on each others feet. But this has always been the case. .

Polylot Setting

Grr.

New version. The name is now Polyglot Settings. I have not changed it yet since it is not clear to me that a name without spaces
would provide additional functionality.

Oops! That is what you get when you clone code without making an attempt to look at it...

I guess I should call it "Choose File", as I haven't found out yet how I can use that selector dialog for selecting a folder. It seems you need another function for that. This is really very stupid design, that you cannot use the same browser for selecting files or folders. In WB protocol I therfore defined them as different option types, but UCI2 does not have that yet. So Polyglot will have a hard time translating UCI2 to WB in an optimal way, and for the time being I have WinBoard display -file -path and -string types all as if they were -file.

Come to think of this, I guess it would be best if Polyglot would actually translate any UCI String option in UCI2 as -file, if it does not want to use a heuristic to guess what options are filenames or pathnames. The -file control is the most versatile, as it does provide the browser button, and selecting a folder can still be done in a semi-convenient way by selecting a file in it and then erasing the filename part with a few backspaces.

Can you still do that, Michel? (In UCI2 or UCI1 translate every String by -file, in stead of -string?) Then the Polyglot version will remain usable with GUIs that finally implement the full protocol, which would display -string options without a browse button. Perhaps I can even change WinBoard 4.4.0 such that it actually makes the distinction. (Internally it already does, but I displaced all case labels at the final dialog creation to the -file case.)

Michel wrote:New version. The name is now Polyglot Settings. I have not changed it yet since it is not clear to me that a name without spaces would provide additional functionality.

The aim is not so much additional functionality as reduced annoyance. Names with spaces are the pits....

Would it be useful to also add a "Save Settings Now" (to the persistence file) -save button in Polyglot for this purpose?

Sorry I forgot to reply to this. I have thought about this but in my current setup this would not work. I guess PG could write
an engine specific config file with the flag Persist=false but also containing the other options. But these would never be recovered
as PG would not load the persistence file if it contains Persist=false.

Ah, you control persistence at the time of loading. WB controls it at the time of saving. So where the user in WB can overrule with "Save Now",you would have to overrule with "Load Now" (irrespective of persistence setting contained in the file).

Can you still do that, Michel? (In UCI2 or UCI1 translate every String by -file, in stead of -string?) Then the Polyglot version will remain usable with GUIs that finally implement the full protocol, which would display -string options without a browse button. Perhaps I can even change WinBoard 4.4.0 such that it actually makes the distinction. (Internally it already does, but I displaced all case labels at the final dialog creation to the -file case.)

Do you mean

Sending PG options which are Files or Paths as -file (not using -path)?

Sending all string UCI options as -file?

In the second case one ultimately wants to use some heuristics. So I should write a little subroutine guess_string_type(opt) which currently would always return -file but which later might contain some more elaborate heuristics (it would take some time to get that right).

Yes, the latter sounds like a good idea. I guess the ultimate solution is that everyone switches to UCI3 and we can translate String to -string, Path to -path and File to -file. But for UCI2 we either need clever heuristics, or err on the safe side and treat everything as -file.

The Polyglot options you can of course send as what they truly are.

I should admit that WinBoard 4.4.0 also collapses all these three types on -file, so there will be no visible difference now. (Even for the Polyglot options.) But in the future there will be WinBoard versions (and hopefully other GUIs) that will. And adapters that translate UCI2 String always to -string would then never get a browse button next to Strings that happen to represent files, and I guess that is much worse than the opposite, genuine strings getting a Browser button.

Then, after the 4.4.0 release, we have plenty of time. For you to develop the Polyglot heuristics, and for me to improve the Engine Settings dialog with more diverse controls (real spins, implementing -slider ptions as scroll bars, and providing the applicable browsing functionality to the text-edits).

Ok here is 1.4.46b with feature requests

I changed "Polyglot Settings" to _PG and also mangled the file names so that they don't contain spaces.

What was before

.\Polyglot Settings\Rybka 2.2n2 mp 32-bit.ini

is now

.\_PG\Rybka_2.2n2_mp_32-bit.ini

The first one seemed to be more consistent with the typical Windows look and feel In reality it
does not matter since this file is handled internally by Polyglot.

Polyglot now tries to gues the UCI3 type of a string option. Currently it looks for substrings
File and Path. I tried a few engines (toga, glaurung, rybka) and that seemed to be sufficient,
perhaps because that is the way how Arena does it (I think).

I included 1.4.46b with the WinBoard-4.4.0 installer as the polyglot.exe that would be automatically used by WinBoard in reaction to the -fUCI and -sUCI. I also included 1.4.38x, installed with a pre-existing polyglot.ini file for Fruit.

I am not sure that the way 1.4.46 does things will have much merit in the future. To me this usage of different files for persitence and origin of the settings seems purely a patch to solve a WinBoard deficiency. (Namely that it use the polyglot_1st and polylot_2nd file kludge to pass the engine name, rather than passing it on the command line.) In future WinBoard versions this will be fixed, and we might be left with a Polyglot that for backward compatibility is much more complex and clumsy to use than needed...

For future WinBoards I would much rather have a Polyglot with a single settings file, with a name constructed from the engine name if it was not given as argument (and the engine was). The -fUCI, -sUCI options would then call this with only the engine command and directory as argument.

For future WinBoards I would much rather have a Polyglot with a single settings file, with a name constructed from the engine name if it was not given as argument (and the engine was). The -fUCI, -sUCI options would then call this with only the engine command and directory as argument.

Well I have thought about this. We can discuss alternative approaches.

The problem, as I see it, is that to know the engine name PG must start the engine first. So you automatically end up with the current design.

If you think of using the name of the executable: that would be fragile because people rename executables, use symbolic links and batch files etc.... And perhaps the engine command is actually not a single executable but a genuine command.

I propose that WB would invoke PG without config file

polyglot -noini -ec <EngineCommand>

and then polyglot would use its config file for that specific engine (whose name is constructed from the engine name).

So I am simply proposing to change the order of things from

(1) read config file --> start engine

to

(2) start engine --> read config file.

The apparent complexity is because at this point PG has to support both modes of operation.