No Polyglot 1.4.39b- problem

[Michel]

There seems to be some deep communications problem here

Yes, but it is not sent to WinBoard.

What do you mean by that? The only time the options are sent to winboard is after the protover 2 command. I used your config file and it worked correctly.

[Polyglot]
EngineCommand = toga2
LogFile = foo.log
[Engine]
NullMove Pruning = Never

This is the answer to the xboard/protover 2 command.

feature done=0
feature analyze=1
feature colors=0
feature draw=1
feature ics=1
feature myname="Toga II 1.4.1SE"
feature name=1
feature pause=0
feature ping=1
feature playother=1
feature reuse=1
feature san=0
feature setboard=1
feature sigint=0
feature sigterm=0
feature time=1
feature usermove=1
feature memory=1
feature smp=1
feature egt=""
feature variants="normal"
feature option="Search Time -spin 0 0 3600"
feature option="Search Depth -spin 0 0 20"
feature option="OwnBook -check 1"
feature option="BookFile -string performance.bin"
feature option="Bitbases Path -string c:/egbb/"
feature option="Bitbases Cache Size -spin 16 16 1024"
feature option="MultiPV -spin 1 1 10"
feature option="NullMove Pruning -combo Always /// Fail High /// *Never" <------------------------
feature option="NullMove Reduction -spin 3 1 4"
feature option="Verification Search -combo *Always /// Endgame /// Never"
feature option="Verification Reduction -spin 5 1 6"
feature option="History Pruning -check 1"
feature option="History Threshold -spin 70 0 100"
feature option="Futility Pruning -check 1"
feature option="Futility Margin -spin 100 0 500"
feature option="Extended Futility Margin -spin 200 0 900"
feature option="Delta Pruning -check 1"
feature option="Delta Margin -spin 50 0 500"
feature option="Quiescence Check Plies -spin 1 0 2"
feature option="Material -spin 100 0 400"
feature option="Piece Activity -spin 100 0 400"
feature option="Piece Square Activity -spin 100 0 400"
feature option="King Safety -spin 100 0 400"
feature option="Pawn Structure -spin 100 0 400"
feature option="Passed Pawns -spin 100 0 400"
feature option="Toga Lazy Eval -check 1"
feature option="Toga Lazy Eval Margin -spin 200 0 900"
feature option="Toga King Safety -check 0"
feature option="Toga King Safety Margin -spin 1700 500 3000"
feature option="Toga Extended History Pruning -check 0"

.... snip ....

[Michel]

Actually I just tried in xboard 4.4.0 and the option NullMove pruning is correctly set as "Never" (and I used the posted windows executable). I would really love to understand what the problem on your end might be.

[Michel]

Ok I understand. The value from the config file is not sent to the engine. Sorry! That was stupid of me.

EDIT: No actually the correct value is sent to the engine. I looked in the log file and it shows correctly

1251378234.927 Adapter->Engine: setoption name NullMove Pruning value Never

[H.G.Muller]

I am getting thoroughly confused now too. It seems indeed from what you post that it works as it should. (At least for the "Never": you snipped before the Polyglot option LogFile was sent to WinBoard.) Was this with Polyglot 1.4.38b?

When I tried this, the setting that was sent to WinBoard (i.e. had the asterisk) was the default setting of the engine (Fail High), not the one in the polyglot.ini file (Never). I used Fruit 2.1, though, but I suppose Toga 2 does not have "Never" as default either. Could there be a race condition, that sometimes the protover 2 comes in before the options are red from the polyglot.ini file, and sometimes after they have?

I looked into the code, (to see if I could fix it), and in the features you sent opt->default_ to WinBoard as current value. But in uci_set_option(), which is used to send the settings in polygot.ini to the engine in parse_option(), you call my_string_set() on opt->value, not on opt->default_. So how can format_xboard_option_line() know what the value in the polyglot.ini line was?

For the Polyglot options, you are right, though. In parse_option() you do both option_set() and option_set_default() for each value read from the [Polyglot] section. (Why do you do that, btw? Why not just set opt->value and have format_xboard_option_line sent that in stead of opt->default_?) I had a problem when I exported OptionFile to WinBoard (it was always exported as polyglot.ini, no matter with what argument Polyglot was called with). But this is of course not coming from the polyglot.ini file, you set it in the "compatibility hack" in main.c, and only the value, not the default, so this is understandable.

But for me Polygot was really sending the Fruit 2.1 engine defaults to WinBoard al the time, no matter what was in the fruit.ini file. Untill I replaced the opt->default_ by opt->value in format_xboard_option_line().

[Michel]

The logic for setting the engine options is given below (the PG options are similar but slightly different since PG needs some options for its
internal workings).

(1) ini_parse() parses the ini file and dumps it in a suitable data structure.
(2) We then add the options set from the command line to the ini data structure.
(3) engine_open() starts the engine.
(4) uci_open() sends "uci" and then calls uci_parse() repeatedly until "uciok" is received (this is done through blocking reads).
(5) uci_parse() (see (3)) calls parse_option()
(6) parse_option() (see (4)) sets both opt->value and opt->default. Here is the code snippet

Code: Select all

else if (my_string_equal(option,"default")) {

         // ASSERT(!my_string_empty(argument)); // HACK for Pepito

         if (!my_string_empty(argument)) {
            my_string_set(&opt->default_,argument);
            my_string_set(&opt->value,argument);
         }

      }


(Ignore the "hack" for pepito. This was in the source before)

(7) We now use the ini structure to send the options from the ini file to the engine
This is done through calling uci_send_option() repeatedly. This sets only opt->value.
Hence we also set opt->default for each option manually,

Code: Select all

    ini_start_iter(ini);
    while((entry=ini_next(ini))){
        if(my_string_case_equal(entry->section,"engine")){
                // also updates value in Uci->option
            uci_send_option(Uci,entry->name,"%s",entry->value);
                // since this comes from the ini file, also update default
            option_set_default(Uci->option,entry->name,entry->value);
                         .....
           }
        }
    }

(8) Finally we start the mainloop. Only now will PG listen for GUI commands. So I don't think a race condition is possible.

[H.G.Muller]

I guess the confusion is caused by the fact that we are looking at completely different code.
For me, ini_start_iter does not seem to occur anywhere in the source (grep cannot find it).
In stead I have the code:

Code: Select all

   uci_open(Uci,Engine);
   Init = TRUE;
   while (my_file_read_line(file,line,256)) {
       if (line[0] == '[') my_fatal("parse_option(): unknown section %s\n",line);
       if (parse_line(line,&name,&value)) {
           uci_send_option(Uci,name,"%s",value);
               //to get a decent display in winboard_x we need to now if an engine really is

doing multipv analysis
               // "multipv 1" in the pv is meaningless,f.i. toga sends that all the time
               //therefore check if MultiPV is set to a decent value in the polyglot ini file
           if(my_string_case_equal(name,"MultiPV") && atoi(value)>1)  Uci->multipv_mode=TRUE;
       }
   }


There is no option_set_default() in this loop, which cases the problem.

About the logic you explained: Why would you want to change the opt->default_ values from the compiled-in values (for [Polyglot] options) or what the engine sends as UCI option commands (for [Engine] options)? I don't know what these values are used for, but it seems problematic that you lose the info what the engine defaults are. The latter would for instance be useful when writing the settings to a polyglot.ini file, when you want to suppress writing of settings that would be used even if they do not occur in the polyglot.ini.

[Michel]

I guess the confusion is caused by the fact that we are looking at completely different code.

Well I downloaded the version of 1.4.39b which is here

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

and it contains the code I showed.. The only way I can explain that your version is different is that I must have forgotten
to bump the version number at one point and that there was another version also labeled 1.4.39b which was overwritten by the current one
(I have a script that makes the releases). This would also explain the OptionFile confusion.
OptionFile is not exported and completely internal. So I couldn't understand why you have a problem with it.

Other people were definitely using the current version otherwise they would not have gotten the "Syntax error in configfile"
messages which are new.

About the logic you explained: Why would you want to change the opt->default_ values from the compiled-in values (for [Polyglot] options) or what the engine sends as UCI option commands (for [Engine] options)? I don't know what these values are used for, but it seems problematic that you lose the info what the engine defaults are. The latter would for instance be useful when writing the settings to a polyglot.ini file, when you want to suppress writing of settings that would be used even if they do not occur in the polyglot.ini.

Well saving is not implemented yet. When I do it I will probably add another field to option_t "initial_default" or something which contains the original values. This
is only a few lines of code. opt->default is what shown as reply to the protover 2 command (or as reply to the "uci" command).

[H.G.Muller]

Well I downloaded the version of 1.4.39b which is here

Yes, but I was explicitly asking about 1.4.38b.

So I gues the short answer would hve been:
"This is already fixed in 1.4.39b"

Well saving is not implemented yet. When I do it I will probably add another field to option_t "initial_default" or something which contains the original values. This is only a few lines of code. opt->default is what shown as reply to the protover 2 command (or as reply to the "uci" command).

OK, that would work. The feature or uci command are supposed to send the settings that are in force if the GUI doesn't alter them, though, which is what is contained in the opt->value fields. So you could have sent the opt->value fields. Of course when you want to make copies for remembering what you sent to the GUI, it does not matter f you sent the original or the copies, as at this point they are always equal.

I am just not sure why you would Polyglot to remember what it sent to the GUI? Are you plannng on some "RestoreDefaults" button option? That would be hard to implement, as the GUI would have to know what the defaults were, and that this option has the side effects of changing all the current values. So it would require the definition of a new class of options (-reset ?) similar to a button but triggering completely different action in the GUI.

[Michel]

The title of the thread was "No Polyglot 1.4.39b- problem". So I thought your question
was also about that version.

I am just not sure why you would Polyglot to remember what it sent to the GUI?

Well in uci if you reexecute the uci command the defacto engine behaviour seems to be to send the default
options rather than the ones that currently apply. I wanted to be able to emulate that behaviour. Strictly
speaking the protocol description seems to imply that the GUI is allowed to send the uci command only once
but all engines I know allow it to be sent multiple times.

[H.G.Muller]

I noticed another problem with Polyglot 1.4.38b (probably shared by 39b):

When you run a UCI engine with a polyglot.ini file under WinBoard, ....

I posted in this thread because I assumed (wrongly, as it turn out now) from the description of the change (allowing command-line setting of al options) that reading of the polyglot.ini file was not touched. And thus that 1.4.39b would suffer from the same problem.

OK, if you want to emulate that behavior, I can see why you need to remember the settings. I guess in WinBoard 4.4.0 things would go disastrously wrong if you sent another protover command to interrogate the engine again, as I don't test for dupilcate options. So it is probbly not a good idea to put it in the protocol specs that this command can be sent at any other time than start-up.

Come to think of it, this might be a serious WinBoard bug. If an engine is used with the -xreuse option, it is started over and over again, and each time it starts it would add a new set of options to the list...

[edit] Ah, fortunately not. I clear the entire list of options in StartChessProgram, so that it is ready to receive the option features again. I could of course do that after resending protover (or, more logically, xboard + protover) as well. Sending protover or xboard to an already initialized engine could be defined as a way to re-initialize it, in particularly clear the hash table (as well as killers, etc.). Protocol v3 proposed a "reset" command for this, but using an existing command would IMO be preferable.

[Michel]

Well in uci if you reexecute the uci command the defacto engine behaviour seems to be to send the default
options rather than the ones that currently apply

I now notice that this is not universally true. fruit/toga send the current options whereas glaurung and rybka don't. glaurung also does not seem to consider a new uci command
as a reset (although I have not looked at the source code to confirm this).

So in contrast to what I believed there is no universal agreement on what should happen if you repeat the uci command. So it makes no sense to use it as a model
for the protover 2 command.

So perhaps it is indeed better that protover 2 uses the actual values instead of the default values. In that way you can use protover 2 to check the current value of
an option (for example for debugging).

[H.G.Muller]

I guess it it depends on the implementation, and everyone does as he pleases as there are no specs to obey...