Polyglot now supports the UCI protocol:-)

[Michel]

Polyglot1.4w10UCIb2 is here

http://alpha.uhasselt.be/Research/Algebra/Toga/

Some bug fixes and support for the "cores N" and "memory N" commands.

The "cores N" command requires that the engine can change the number of threads
at arbitrary times, not just in the initialization faze.

The current versions of Toga can not do this (except Cyclone).

An experimental version of Toga 1.4.1SE that can do this can be found at

http://alpha.uhasselt.be/Research/Algeb ... x_versions

For an explanation of the changes necessary for a generic Toga see here

http://alpha.uhasselt.be/Research/Algeb ... reads.html


Michel

[H.G.Muller]

Great! I will experiment with it a little!

I must admit that the current WB release I am preparing does not yet send intra-game cores commands, because they can only be generated from the menu, and previous versions did not have a menu for the nr of cores at all. But I certainly want to add that to future versions, so I had to put the requirement in the protocol description.

[Michel]

must admit that the current WB release I am preparing does not yet send intra-game cores commands

Unfortunately that does not help for Toga. The initialization sequence of PG is as follows.

Send "uci"
Record options
Wait for "uciok"
Send PG options from the Engine section
Send "isready"
Wait for "readyok" (roughly)
Process commands from GUI

The versions I know of Toga (except cyclone) create the threads at the "isready" command and you cannot change their number afterwards. So to make "cores N" work for Toga PG would have to delay the "isready" command and there is no well defined moment to send it afterwards.

[H.G.Muller]

Would it help if I would let xboard send the cores command before the first new command, so that you could delay sending the isready to the first new command? I guess the same should hold for the memory command; I could imagine that some engines would have trouble changing their hash-table size after isready, or even would object against receiving a second hash-size option in the first place.

In the current way of doing it (memory and cores after new), you could wait for the first ping, which is basically the WB equivalent of isready. WB sends it after the memory and cores commands. But the protocol does not prescribe when the pings should come, (or, indeed, that it should come at all) so other GUIs might do this differently. But there is always guaranteed to be a new. The ponder-control commands hard and easy are send after the new, though.

You could start reading the polyglot.ini only after the new comes in.

[Michel]

If "new" is guaranteed to be sent by winboard the protocol it could be a good moment to send "isready" to the engine, allowing winboard to do some extra stuff in the initialization faze.

[[ Although I would prefer Toga to change also. It is the only engine I know that has trouble changing the numbers of cores after initialization. This is about 20 lines of c-code and there is a sample implementation and a detailed description of how to do it. ]].

[H.G.Muller]

There cannot start any game without a new command first. WB starts sending

xboard
protover 2

and then delays some time to make sure any feature commands will be received before anything else is sent. (Because what has to be sent depends on the features.) Only after the waiting periods times out, or after reception of feature done=1, WB does proceed sending stuff to the engine. The first thing it used to send in that case was always

new
random

The trial version I posted now does send memory, cores and egtpath just before the new, in case you want to experiment with it.

[Michel]

Ok the new version (1.4wUCIb3)

http://alpha.uhasselt.be/Research/Algebra/Toga/

delays "isready" till the new command.

I have only tested it command line. I hope there are no timing issues when used in real life.

Maybe the situation for Toga is not so bad after all. It seems DLT also supports changing the # of threads outside initialization (but not GrapeFruit).

[Michel]

There is a bug with time management.

I'll post a new version later.

Michel

[Michel]

New version (1.4w10UCIb4)

http://alpha.uhasselt.be/Research/Algebra/Toga/

Michel

[H.G.Muller]

Because of an issue that came up in another thread. You probably know the answer to it off hand:

Does this negociation of options before the 'isready' go on before every game, and does Polyglot re-read the .ini file each time? Or is this done only at startup?

An unrelated question:
Wy the extremely cumbersome name. This seems a major modification. Wouldn't it be better to symply call it Polyglot1.5w ? (Perhaps after we are done with beta testing.)

[Michel]

Does this negociation of options before the 'isready' go on before every game, and does Polyglot re-read the .ini file each time? Or is this done only at startup?

No PG does not reread or resend its options.

Wouldn't it be better to symply call it Polyglot1.5w ? (Perhaps after we are done with beta testing.)

I would like to wait for Fonzy Bleumer's agreement. One thing in favor for it to be Polyglot 1.5 is that it then should be trivial to get it into Debian/Ubuntu since Polyglot 1.4 is already there. If it is a fork it is trickier (it would involve convincing a potential sponsor why a fork was useful).

Anyway I made an autoconf'ed version of PG which should make it easier to package it on Linux/BSD. There are no changes in functionality and no changes on Windows. It is at the usual place

http://alpha.uhasselt.be/Research/Algebra/Toga/

[H.G.Muller]

Well, to make it a fork would not be useful, and in fact highly detrimental. The version we make should be 100% upward compatible with Polyglot 1.4.

Fonzy was not very happy with delaying the 'isready' to the new. There is another way to do it, but it requires a bit more thinking by Polyglot:

After sending feature smp=1 memory=1 Polyglot can wait for the WB replies accepted smp and accepted memory (or rejected ... on older WB). For the features that were accepted, it can 100% rely on WB sending the memory or cores command, so it can afford to wait for those before sending any 'setoption' commands to the engine.

I could add in the protocol specs that of all option settings to be sent by the GUI before every new, memory will be the first and cores will be the last. So the truly optional, that are not guaranteed to be sent even if the feature enabling them is accepted (such as egtpath) will be bracketed by them.

[F. Bluemers]

Does this negociation of options before the 'isready' go on before every game, and does Polyglot re-read the .ini file each time? Or is this done only at startup?

No PG does not reread or resend its options.

Wouldn't it be better to symply call it Polyglot1.5w ? (Perhaps after we are done with beta testing.)

I would like to wait for Fonzy Bleumer's agreement. One thing in favor for it to be Polyglot 1.5 is that it then should be trivial to get it into Debian/Ubuntu since Polyglot 1.4 is already there. If it is a fork it is trickier (it would involve convincing a potential sponsor why a fork was useful).

Anyway I made an autoconf'ed version of PG which should make it easier to package it on Linux/BSD. There are no changes in functionality and no changes on Windows. It is at the usual place

http://alpha.uhasselt.be/Research/Algebra/Toga/

You got it.
We can always fork later if needed.
Still hadn't much time to have look at it so don't wait for me.
BTW imo its better to fix toga than to adapt winboard and polyglot .
Best
Fonzy

[H.G.Muller]

Still hadn't much time to have look at it so don't wait for me.
BTW imo its better to fix toga than to adapt winboard and polyglot .

True, but Toga might be exemplary of what we could expect with other UCI engines. We are creating new protocol here, which we will later be stuck with, so it is worthwile to not paint ourselves into a corner here.

This is an excerpt from the UCI protocol specs:

Code: Select all

      *  = Hash, type is spin
         the value in MB for memory for hash tables can be changed,
         this should be answered with the first "setoptions" command at program boot
         if the engine has sent the appropriate "option name Hash" command,
         which should be supported by all engines!
         So the engine should use a very small hash first as default.



This seems to specify that UCI engines are not required to be able to change their hash size except at startup, and even then they can play hard-to-get by not sending the 'option name hash spin ...' to the GUI.

So it is essential that Polyglot waits sending any 'setoption' from the .ini file to the engine before it has recieved the memory command from WinBoard. Otherwise the memory command might not work on any UCI engine at all, or even crash them.

The 'NalimovCache' and 'NalimovPath' options are also specified to only occur at engine startup. (Although I see no logical reason why it would be difficult to change the latter at any time.) So they must come before the first 'isready', and sending them after the same option with another value from the .ini file has been sent will be asking for trouble. So PG must really delay sending any options before it is sure it has all the values from WB.

Eventually we might want to have PG restart the engine when WB requests (through user intervention) a new hash+egtbCache size, or egtpath, to make sure the engine gets the change.

[F. Bluemers]

Still hadn't much time to have look at it so don't wait for me.
BTW imo its better to fix toga than to adapt winboard and polyglot .

True, but Toga might be exemplary of what we could expect with other UCI engines. We are creating new protocol here, which we will later be stuck with, so it is worthwile to not paint ourselves into a corner here.

This is an excerpt from the UCI protocol specs:

Code: Select all

      *  = Hash, type is spin
         the value in MB for memory for hash tables can be changed,
         this should be answered with the first "setoptions" command at program boot
         if the engine has sent the appropriate "option name Hash" command,
         which should be supported by all engines!
         So the engine should use a very small hash first as default.



This seems to specify that UCI engines are not required to be able to change their hash size except at startup, and even then they can play hard-to-get by not sending the 'option name hash spin ...' to the GUI.

So it is essential that Polyglot waits sending any 'setoption' from the .ini file to the engine before it has recieved the memory command from WinBoard. Otherwise the memory command might not work on any UCI engine at all, or even crash them.

Fixing things for toga in polyglot hacks might also break things too for other uci engines.
Not sure I understand the example,if an engine does not send "option name hash ..." it will ignore setoption commands on hash-size later anyway.
edit:
Concerning the sequence of the commands,what if winboard would write them to a special *.ini file (e.g. _init.ini).Poyglot could look for it and handle them in any special required way?
Fonzy

[H.G.Muller]

Well, what worries me is the phrase 'should be answered with the first "setoptions" command at program boot'. This suggest undefined, and possibly disastrous consequences if it would be sent as the second setoption command, even in engines that do define the Hash option. Especially if they already received a 'setoption Hash' before, with another size.

This is not a Toga problem. It is a UCI protocol problem. If we get it wrong, PG ceases to be a WB2UCI adapter, but in stead becomes a WB2XXX adapter, with XXX a protocol that no existing engine understands...

As to your last command: why communicate through files if you can communicate through pipes? This approach of communicating between processes was abandoned with the invention of Unix in the 60s...

[Michel]

True, but Toga might be exemplary of what we could expect with other UCI engines

As far as I know Toga is the only misbehaving one. And it is easy to fix (and has been fixed in some versions). The main problem is that people keep forking Toga with little coordination. I don't think we should encourage this. Glaurung is an example of a correctly behaving open source engine.

I feel that an UCI engine should be able to react at any time to a change of its properties.

Otherwise the memory command might not work on any UCI engine at all, or even crash them.

I am quite sure that would not happen. UCI engines just silently ignore the commands they do not understand or support. Also changing the amount of memory is just a free/malloc, so I would be quite surprised if there were engines that did not support this.

This being said delaying isready to the first new command seems like a painless compromise to me.

[F. Bluemers]

Well, what worries me is the phrase 'should be answered with the first "setoptions" command at program boot'. This suggest undefined, and possibly disastrous consequences if it would be sent as the second setoption command, even in engines that do define the Hash option. Especially if they already received a 'setoption Hash' before, with another size.

This is not a Toga problem. It is a UCI protocol problem. If we get it wrong, PG ceases to be a WB2UCI adapter, but in stead becomes a WB2XXX adapter, with XXX a protocol that no existing engine understands...

As to your last command: why communicate through files if you can communicate through pipes? This approach of communicating between processes was abandoned with the invention of Unix in the 60s...

I think that phrase from the interface text is just a bit unlucky uhm shaped 'should be answered with the first "setoptions" command at program boot',so it does not say it has to be the first setoption.
example polyglot:it depends where the user has put an "hash = XXX" in the ini file when "setoption hash ..." will be send.
Also note this from the protocol:

Note that the GUI need not send the setoption command when starting the engine for every option if it doesn't want to change the default value.

"As to your last command" : really,it was a suggestion.
Best
Fonzy

[Michel]

New version here.

http://alpha.uhasselt.be/Research/Algebra/Toga/

Mainly cosmetic changes to make PG more Linux compliant.

A proper man page has been written. The README is generated automatically from it

http://alpha.uhasselt.be/Research/Algebra/Toga/README

I extracted the ChangeLog part of README2.TXT and made it into a proper ChangeLog.

http://alpha.uhasselt.be/Research/Algeb ... /ChangeLog

I gave more sane names to the existing readme files. They are now

README1.3, README1.4, README1.4w, README1.4w10UCI

Michel

[H.G.Muller]

OK, I was able to compile under cygwin, and tried it out with BikJump as UCI engine. It nicely reacts to the memory command, even during a session. If you change it while BikJump is playing, the new setting becomes effective on the next game, if you change it in between games and BikJump is first engine, it will require you to give an extra "New Game" command for it to become immediately active. I guess WB engines would suffer from that too. Perhaps I will eliminate the need for that extra "New game" in the future, but for this version of WB it should be good enough.

I included the polygot.exe I made in the WinBoard Gold Pack.

Would it be possible to also have Polyglot transmit the

egtpath nalimov <path name>

command, and ten rename it to Polyglot 1.5w?

Next WinBoard (4.3.16) will likely support the setting of all UCI options of the engine, but as the protocol for that has not crystallized yet,