How to suspend a Winboard tournament?

Discussions about Winboard/Xboard. News about engines or programs to use with these GUIs (e.g. tournament managers or adapters) belong in this sub forum.

Moderator: Andres Valverde

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 15 Dec 2012, 20:02

cnchang wrote:There should be a more updated UCI protocol standard, newer than this 2004 edition, which includes the consideration of SMP. Is the person chartered UCI still operating?

This is the latest version I am aware of. UCI is sort of 'carved in stone'; I consider it a 'dead protocol' in the same way as Latin is a dead language. The person that invented it is Stephan Mayer-Kahlen, the author of the commercial Chess engine Shredder. He is still active, but he sees no need to make any modifications. In his opinion there is no need for any protocol extensions, as he considers the announcing of options by the engine a general extension mechanism. Most customers don't play engines against each other, but use them for analysis of their own games. With only a single active engine, it becomes kind of immaterial whether you control options as a common or an individual option. I once explained him it would be very useful to have a standard option for maxthreads, but he was apparently not convinced.

If UCI is an open standard, there should be no secret options allowed in public, at least, not on such an important one. Secret ones or no standard at all are both unacceptable. Winboard just randomly picked some name for threads# out of the thin air?? Are you kidding me?

You should realize that WB protocol was developed in a time where 256KB was huge amount of memory, and even hash tables a technical impossibility except on the World's largest super-computers. So originally commands to control hash size and threads were not part of the protocol. When I took up work on WB this is one of the first things I corrected. After some brain-storming with other engine authors I picked the commands 'memory' and 'cores' for this. Unlike UCI, WB protocol is a living protocol, which is constantly evolving to satisfy the needs of engine programmers.

Regarding the possible use of different hash settings for each engine, I just tested something related to that. I wonder how Shiga 64MB/1core stacks up against 512MB/4cores. When I set both to run with time control 40 steps/10minutes. They drawed. But, with the time control 10 steps/10 minutes, Shiga 512/4 won. This kind of test can only be done with the help of Shiga.ini now because of Winboard's decision. UCI doesn't list hash size as "not need to appear in this dialog" may find a cause here.

Indeed, but this is a GUI-design issue, not a protocol matter. Some people want to play 'core-odds' games, where engine versions with different threads are pitted against each other. They are unhappy with this design. But WB has work-around options that can be used to subvert the ordinary design, albeit not through the GUI. There are command-line options -first/secondInitString, which control the command(s) send at the beginning of every game to the engine. Normally this is just the 'new' command, but people that want to do core odds could set it to 'cores N\nnew' to precede the 'new' command with the desired cores setting, overruling a possible earlier 'cores' command corresonding to the Common Engine settings. So I don't consider it a big problem. My philosophy for WB development is that normal things (like fair games) should work simple and intuitive, while advanced special applications can be a bit more 'hidden', so they don't confuse normal and beginning users.

"Ponder" must be a common engine option for any meaningful game. Thus, it should be centrally controlled. Isn't it?

Indeed. And in WB it is (from the General Options dialog). Note, however, that not all engines can ponder, and that the support of the Ponder option by the engine should be taken as a signal to the GUI that it can. And that 'Ponder' is not the option that controls whether UCI engines ponder or not. To set the engine pondering there are other commands "go ponder ..." (so not any ' setoption'), and the GUI has to set up the position on which the engine must ponder first. Commands the GUI never should use for an engine that does not support a 'Ponder' option. So much more is at stake than just a 'setoption name Ponder' command which you might be able to send blindly without adverse effects. The 'Ponder' option is a time management option, which would be more properly described by 'TakeMoreTimeThanYouCanAffordForEachMove' (anticipating on that you will gain extra time through ponder hits).

Above all, I can't see the reasoning behind this:
UCI wrote:...

It sets the "confess all your options first at startup before putting em into use" rigid rule on the engines while setting a relatively lax rule on the GUI side, "need not to send setoptions if GUI doesn't feel like it", without elaboration. How arbitrary and strange!

Well, all protocols need arbitrary decisions in their design. This is where there can exist more than one protocol for the same task. Important is that there is handshaking, and any handshaking could be initiated from either side. UCI has arbitrarily chosen to let the engine start it. In WB protocol we also did this, for backward-compatibility reasons (which were of no concern when UCI was designed). Engines announce which protocol extensions they support, and the GUI will refrain from using protocol that could confuse older engines and break their operation. This because even the handshaking capability was only added later. So an attempt of the GUI to initiate the handshaking would already look a non-compliancy to very old (so called WB v1) engines, and confuse them. So the engines must start the handshaking to let the GUI know they support, and if they don't, the GUI assumes they are v1 after a timeout.

UCI seems based on a philosophy that standard options should be disguised as engine-specific options, thus minimizing the number of dedicated commands in the protocol. For engine-specific options it is obvious that the engine has to announce them, or the GUI could never know they existed. Which options should be controllable from which dialog (or indeed, should be controllable at all by the user) is a matter of GUI design. The task of the protocol is to not restrict the GUI-designer in this respect.

But don't expect me to defend UCI; personally I think it utterly sucks, and I would rather die than have my own engines use it. Poor standardization of is options is the least of its problems. But it is what it is, and I had no say in its design. As long as there are engine authors stupid enough to use it, we are stuck with it...
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 16 Dec 2012, 09:59

Oh, btw, something that slipped my mind: WinBoard will only command an engine to change hash size at the start of a new game. Never during a game. So when you alter the hash size in Common Engine, it won't have any effect until you also press 'New Game'. This was a design choice, as changing hash size is in general not possible without severely disturbing the engine's thought processes, and I did not see any reason for changing the size that would outweigh this. In practice people hardly ever change the hash size at all; they set it to what is good for their hardware, and that is it.

But it can affect your testing for the automatic sizing of hash to work, as it might create the erroneous impression the engine does not react to the Hash command, while WB in fact never sent it, because it is still waiting for a new game to start.

This is unlike the Max CPU setting, which will be send to the engine (through the WB 'cores' command) as soon as it is changed. But currently UCI2WB will not relay it to the engine, as it has no idea what UCI option name to translate it to.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby cnchang » 16 Dec 2012, 16:52

I looked into winboard.debug trying to get a picture of what you just mentioned, e.g., "feature smp=1", "cores #", and "new". Really can't decipher it. Thought you said GUI sends out "feature smp=1" to test the engine. But, I take it the opposite by reading the log. The extracted portion is posted here, for which I believe it covers the dialog starting from hitting "New Game" and till the first engine made the first move. Anyway to tell how the UCI engines responded to GUI's attempting to set its max threads # from this log?

Code: Select all
Reset Clocks: full string=:40/600
Reset Clocks: w=600000, b=600000
StartChildProcess (dir=".") UCI2WB Shiga.exe ..\Shijia
nice engine proc to 10
212203 >first : xboard
protover 2
212203 >first : cores 1
212203 >first : new
random
212203 >first : variant xiangqi
212203 >first : level 40 10 0
212203 >first : post
212203 >first : hard
212203 >first : easy
212203 >first : ping 2
Impossible move f4d5, type = 0
212375 <first : feature variants="normal,xiangqi" setboard=1 usermove=1 debug=1 ping=1 reuse=0 exclude=1 pause=1 done=0
212375 >first : accepted variants
212375 >first : accepted setboard
212375 >first : accepted usermove
212375 >first : accepted debug
212375 >first : accepted ping
212375 >first : accepted reuse
212390 >first : accepted exclude
212390 >first : accepted pause
212390 >first : accepted done
212390 <first : feature option="UCI2WB debug output -check 0"
212390 >first : accepted option
212390 <first : feature myname="Shiga ver. 100644 (UCI2WB)"
212390 >first : accepted myname
212406 <first : feature smp=1 memory=0 done=1
212406 >first : accepted smp
212406 >first : accepted memory
212406 >first : accepted done
212406 <first : pong 2
 
                               
                          or specify one below:
Nickname (optional): [______________________________________]
[x] Use nickname in PGN tag   
     Engine (*.exe): [______________________________________]
command-line paramet [______________________________________]
Special WinBoard opt [______________________________________]
          directory: [______________________________________]
(Directory will be derived from engine pa
[x] UCI                        [x] Add this engine to the li
[x] WB protocol v1 (skip wait  [x] Must not use GUI book     
[x] UCCI / USI (uses specifie  [x] Force current variant wit
238484 >first : force
Unload second
451265 >first : cores 2
StartChildProcess (dir="..\Anita") UCI2WB cyclone.exe ..\cyclone2011
nice engine proc to 10
464562 >second: xboard
protover 2
469078 <second: feature variants="normal,xiangqi" setboard=1 usermove=1 debug=1 ping=1 reuse=0 exclude=1 pause=1 done=0
469078 >second: accepted variants
469078 >second: accepted setboard
469078 >second: accepted usermove
469078 >second: accepted debug
469078 >second: accepted ping
469078 >second: accepted reuse
469093 >second: accepted exclude
469093 >second: accepted pause
469093 >second: accepted done
469093 <second: feature option="UCI2WB debug output -check 0"
469093 >second: accepted option
469093 <second: feature myname="ggChess-UCI-4U (UCI2WB)"
469093 >second: accepted myname
469093 <second: feature smp=1 memory=0 done=1
469093 >second: accepted smp
469093 >second: accepted memory
469093 >second: accepted done
469109 >second: cores 2
469109 >second: new
random
469109 >second: variant xiangqi
469109 >second: level 40 10 0
469109 >second: post
469109 >second: hard
469109 >second: easy
469109 >second: ping 1
Impossible move f4d5, type = 0
469125 >second: force
469125 <second: pong 1
New game (0): Shiga ver. 100644 (UCI2WB)-ggChess-UCI-4U (UCI2WB) (w)
469140 >first : computer
469140 >second: computer
Reset Clocks: full string=:40/600
Reset Clocks: w=600000, b=600000
469140 >first : black
469140 >first : time 60000
469140 >first : otim 60000
469140 >first : white
book hit = (NULL)
469140 >first : go
nps: w=-1, b=-1
469328 <first :   2      21     18       3268 b0c2 b9c7
469359 <first :   3      50     20       6640 b0c2 b9c7 a0a1
469359 <first :   3      66     21       8076 b2e2 b9c7 a0a1
469375 <first :   4      15     23      12436 b2e2 h9g7 a0a1 a9a8
469406 <first :   4      21     25      16584 h0g2 b9c7 i0i1 a9a8
469453 <first :   5      40     31      33240 h0g2 h9g7 i0i1 i9i8 i1f1
469546 <first :   6      21     40      42904 h0g2 h9g7 i0i1 i9i8 i1f1 i8d8
469703 <first :   7      38     56      90816 h0g2 h7e7 b2e2 h9g7 a0a1 i9h9 i0i1
469890 <first :   8      21     75     153672 h0g2 h7e7 b2e2 h9g7 b0c2 i9h9 a0b0 b9c7
470156 <first :   8      27    100     216112 b2e2 h9g7 b0c2 a9a8 a0b0 a8f8 h0g2 g6g5
470812 <first :   9      54    165     415460 b2e2 h9g7 b0c2 a9a8 a0b0 i9i8 i0i1 b7e7 b0b9 h7h0 b9c9
472046 <first :  10      21    289     774680 b2e2 b9c7 b0c2 h7e7 a0b0 h9g7 i0i1 i9h9 h0g2 a9a8
474640 <first :  10      32    550    1498204 h2e2 h9g7 h0g2 b7e7 b2b4 h7h5 b4g4 h5g5 i0h0 a9a8
476828 <first :  11      43    761    2136240 h2e2 h9g7 h0g2 b7e7 b2b4 g6g5 i0h0 i9h9 b4c4 b9a7 a0a1
480656 <first :  12      21   1151    3179636 h2e2 h9g7 h0g2 b7e7 b0c2 b9c7 i0h0 a9b9 a0a1 i9i8 a1d1 i8f8
490953 <first :  13      39   2178    6162156 h2e2 h9g7 h0g2 b7e7 b0c2 b9c7 i0h0 a9b9 h0h6 b9b3 h6g6 b3c3 c2e1 c7e8 e2e6 g7e6 g6e6
495531 <first : move h2e2
495531 >second: time 60000
495531 >second: otim 57360
cnchang
 
Posts: 49
Joined: 03 Dec 2012, 09:08

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 16 Dec 2012, 19:27

The 'feature' command is indeed an engine->GUI command, which tells the GUI which protocol extensions the engine supports. I commented most of the output below; I hope that helps.

Code: Select all
212203 >first : xboard                            // tells engine it is running on a GUI that uses WB protocol
protover 2                                             // prompts engine for 'feature' commands (version 2 of WB protocol)
212203 >first : cores 1                           // sets cores (Hmmm... Has it seen 'feature smp=1' from an earlier load of the same engine?)
212203 >first : new                                // start new game (engine sets up initial position)
random
212203 >first : variant xiangqi                 // it will be an XQ game
212203 >first : level 40 10 0                   // 40 moves in 10 min
212203 >first : post                               // switches on reporting of scores/PVs during search
212203 >first : hard                               // switches ponder on
212203 >first : easy                              // switches ponder off
212203 >first : ping 2                            // synchronization
212375 <first : feature variants="normal,xiangqi" setboard=1 usermove=1 debug=1 ping=1 reuse=0 exclude=1 pause=1 done=0
// engine (here UCI2WB) announces its capabilities:
// variants: it can play normal Chess or Xiangqi
// setboard: you can set up a position with FEN
// usermove: GUI must prefix all moves with the keyword 'usermove'
// debug: engine want to send debug info as lines starting with #
// ping: engine supports sync commands (will echo each 'ping' as 'pong')
// reuse: engine process must be restarted for each new game
// exclude: supports exclusion of moves from analysis
// pause: supports pause/resume commands
// done: more is to follow
212375 >first : accepted variants     // GUI informs the engine it supports all these features (ignored by most engines)
212375 >first : accepted setboard
212375 >first : accepted usermove
212375 >first : accepted debug
212375 >first : accepted ping
212375 >first : accepted reuse
212390 >first : accepted exclude
212390 >first : accepted pause
212390 >first : accepted done
212390 <first : feature option="UCI2WB debug output -check 0"                 // engine defines option 'debug output' as checkbox
212390 >first : accepted option
212390 <first : feature myname="Shiga ver. 100644 (UCI2WB)"                 // engine reports its name
212390 >first : accepted myname
212406 <first : feature smp=1 memory=0 done=1  // more protocol extensions:
// smp: wants to receive 'cores' command to indicate nr of threads
// memory: cannot receive 'memory' command to specify hash size
// done: all features have been send; GUI can proceed
212406 >first : accepted smp
212406 >first : accepted memory
212406 >first : accepted done
212406 <first : pong 2                                         // replies to ping 2, so GUI knows what engine is doing
238484 >first : force
451265 >first : cores 2
StartChildProcess (dir="..\Anita") UCI2WB cyclone.exe ..\cyclone2011 // same stuff for second engine
464562 >second: xboard
protover 2
469078 <second: feature variants="normal,xiangqi" setboard=1 usermove=1 debug=1 ping=1 reuse=0 exclude=1 pause=1 done=0
469078 >second: accepted variants
469078 >second: accepted setboard
469078 >second: accepted usermove
469078 >second: accepted debug
469078 >second: accepted ping
469078 >second: accepted reuse
469093 >second: accepted exclude
469093 >second: accepted pause
469093 >second: accepted done
469093 <second: feature option="UCI2WB debug output -check 0"
469093 >second: accepted option
469093 <second: feature myname="ggChess-UCI-4U (UCI2WB)"
469093 >second: accepted myname
469093 <second: feature smp=1 memory=0 done=1
469093 >second: accepted smp
469093 >second: accepted memory
469093 >second: accepted done
469109 >second: cores 2
469109 >second: new
random
469109 >second: variant xiangqi
469109 >second: level 40 10 0
469109 >second: post
469109 >second: hard
469109 >second: easy
469109 >second: ping 1
469125 >second: force          // set engine to play neither side
469125 <second: pong 1
469140 >first : computer       // opponent is engine
469140 >second: computer
469140 >first : black            // black to move
469140 >first : time 60000    // 10 min on own clock
469140 >first : otim 60000    // 10 min on opponent clock
469140 >first : white            // white to move
469140 >first : go                // set engine to play current side (= white)
469328 <first :   2      21     18       3268 b0c2 b9c7    //engine starts reporting search info
469359 <first :   3      50     20       6640 b0c2 b9c7 a0a1
469359 <first :   3      66     21       8076 b2e2 b9c7 a0a1
469375 <first :   4      15     23      12436 b2e2 h9g7 a0a1 a9a8
469406 <first :   4      21     25      16584 h0g2 b9c7 i0i1 a9a8
469453 <first :   5      40     31      33240 h0g2 h9g7 i0i1 i9i8 i1f1
469546 <first :   6      21     40      42904 h0g2 h9g7 i0i1 i9i8 i1f1 i8d8
469703 <first :   7      38     56      90816 h0g2 h7e7 b2e2 h9g7 a0a1 i9h9 i0i1
469890 <first :   8      21     75     153672 h0g2 h7e7 b2e2 h9g7 b0c2 i9h9 a0b0 b9c7
470156 <first :   8      27    100     216112 b2e2 h9g7 b0c2 a9a8 a0b0 a8f8 h0g2 g6g5
470812 <first :   9      54    165     415460 b2e2 h9g7 b0c2 a9a8 a0b0 i9i8 i0i1 b7e7 b0b9 h7h0 b9c9
472046 <first :  10      21    289     774680 b2e2 b9c7 b0c2 h7e7 a0b0 h9g7 i0i1 i9h9 h0g2 a9a8
474640 <first :  10      32    550    1498204 h2e2 h9g7 h0g2 b7e7 b2b4 h7h5 b4g4 h5g5 i0h0 a9a8
476828 <first :  11      43    761    2136240 h2e2 h9g7 h0g2 b7e7 b2b4 g6g5 i0h0 i9h9 b4c4 b9a7 a0a1
480656 <first :  12      21   1151    3179636 h2e2 h9g7 h0g2 b7e7 b0c2 b9c7 i0h0 a9b9 a0a1 i9i8 a1d1 i8f8
490953 <first :  13      39   2178    6162156 h2e2 h9g7 h0g2 b7e7 b0c2 b9c7 i0h0 a9b9 h0h6 b9b3 h6g6 b3c3 c2e1 c7e8 e2e6 g7e6 g6e6
495531 <first : move h2e2        // engine moves
495531 >second: time 60000    // 10 min on own clock
495531 >second: otim 57360    // 9:26 min on opponent clock


Note that you cannot see what goes on between adapter and engine, though. For that you would have to install the engine with 'debug' in the UCI2WB command line, like

"UCI2WB debug ENGINE.exe ENGINEFOLDER"

in the engine list.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby cnchang » 17 Dec 2012, 08:34

Note that you cannot see what goes on between adapter and engine, though. For that you would have to install the engine with 'debug' in the UCI2WB command line, like
"UCI2WB debug ENGINE.exe ENGINEFOLDER"
in the engine list.

The above command is similar to what I used to generate the what you called GUI-adapter debug log. The only difference is I added a "-debug" argument at the end.
i.e., "UCI2WB debug Shiga.exe ../Shijia" -debug
Now, to see the engine-adapter dialog, I tried your command with "-debug" removed, but no winboard.debug or any other obvious log file got created.

This is the command I used before, and it generated a GUI-adapter log file without adapter-engine side:
"Shijia" -fcp "UCI2WB debug Shiga.exe ..\Shijia" -debug /variant=xiangqi

This is the command I put in Edit Engine List to gather UCI engine debug info but it ends up getting no log file:
"Shijia" -fcp "UCI2WB debug Shiga.exe ..\Shijia" /variant=xiangqi

Then, I tried something different:
"Shijia" -fcp "UCI2WB -debug Shiga.exe ..\Shijia" -debug /variant=xiangqi

This generates the attached winboard.debug. But in this mode, I can't have two machines play with each other. I tried to set 256MB/2cores from GUI. Not sure what engines' responses are from this excerpt.
BTW, I am using your beta winboard.exe, ucci2wb.exe, and uci2wb.exe, with defectiveEngineOptions.ini loaded.
Code: Select all
recognized 'xiangqi' (-1) as variant xiangqi
Parse TC: tc=10
Parse TC: full string = :40/600
recognized 'xiangqi' (-1) as variant xiangqi
WinBoard master-20121209 + UCI2WB
Reset(1, 0) from gameMode 0
recognized 'xiangqi' (-1) as variant xiangqi
GameEnds(0, (null), 2)
shuffleOpenings = 0
Reset Clocks: full string=:40/600
Reset Clocks: w=600000, b=600000
StartChildProcess (dir=".") UCI2WB -debug Shiga.exe ..\Shijia
nice engine proc to 10
1218 >first : xboard
protover 2
1312 <first : # fake engine input
1312 <first : feature option="Threads -spin 2 1 8"
1312 >first : accepted option
1343 <first : # end fake
1453 <first : feature variants="normal,xiangqi" setboard=1 usermove=1 debug=1 ping=1 reuse=0 exclude=1 pause=1 done=0
1453 >first : accepted variants
1468 >first : accepted setboard
1468 >first : accepted usermove
1468 >first : accepted debug
1468 >first : accepted ping
1468 >first : accepted reuse
1468 >first : accepted exclude
1468 >first : accepted pause
1468 >first : accepted done
1468 <first : feature option="UCI2WB debug output -check 0"
1468 >first : accepted option
1468 <first : feature option="Ponder -check 0"
1468 >first : accepted option
size-move
moving
moving
moving
moving
moving
exit size-move, size = 49
square size = 49
GameEnds(28, xboard exit, 2)
115421 >first : result * {xboard exit}
115421 >first : quit
Process 696 still alive after timeout, killing... result=1


I think the following excerpt, extracted from the above bigger chunk of codes, is still the dialog, regarding Threads#, between GUI and UCI adapter. I don't see engine's debug dialog.
Code: Select all
1312 <first : # fake engine input
1312 <first : feature option="Threads -spin 2 1 8"
1312 >first : accepted option
1343 <first : # end fake
cnchang
 
Posts: 49
Joined: 03 Dec 2012, 09:08

Re: How to suspend a Winboard tournament?

Postby cnchang » 17 Dec 2012, 14:24

Since you don't have many UCI engines to test with and Threads# option may be not quite standardized, shall we focus on UCCI engines first and see if WBGUI can set them up right?
It is easier to collect debug info from UCCI engines because engines are in debug mode by default. I only need to turn on debug option for Winboard.
I chose Bugcchess to play with Elephant Eye with both debug mode turned on, and I tried to set 256MB/4cores via WBGUI.
As a result, Bugcchess stays ~40MB/1core, and Elephant Eye turns into 260MB/1core.
Here is the debug log. I noticed <second: # to engine : setoption hashsize 260 just appeared once, and it seems only Elephant Eye engine received this command, but not Bugcchess.
I think the reason it only sent to Elephant Eye is because UCCI adapter received this from EleEye a while ago.
<second: # from engine: option hashsize type spin min 16 max 1024 default 16
Code: Select all
recognized 'xiangqi' (-1) as variant xiangqi
Parse TC: tc=10
Parse TC: full string = :40/600
recognized 'xiangqi' (-1) as variant xiangqi
WinBoard master-20121209 + BugCChess
Reset(1, 0) from gameMode 0
recognized 'xiangqi' (-1) as variant xiangqi
GameEnds(0, (null), 2)
shuffleOpenings = 0
Reset Clocks: full string=:40/600
Reset Clocks: w=600000, b=600000
StartChildProcess (dir=".") UCCI2WB -noini "..\Bugcchess\BugCChess.exe"
nice engine proc to 10
1422 >first : xboard
protover 2
1500 <first : UCCI2WB by Morning Yellow and H.G.Muller
1500 <first : # to engine  : ucci
1500 <first : # from engine: alloc material table for thread 0
1500 <first : # from engine: id name bgc 1.0a-11-02-18         
1500 <first : # from engine: id version 1.0a-11-02-18             
1500 <first : # from engine: id author BugCChess team
1500 <first : # from engine: id copyright 2011 BugCChess team
1500 <first : # from engine: option usemillisec type check default true
1500 <first : # from engine: ucciok
1516 <first : feature myname="bgc 1.0a-11-02-18         1.0a-11-02-18               (UCCI2WB)"
1516 >first : accepted myname
1516 <first :
1516 <first : feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1
1532 >first : accepted variants
1532 >first : accepted setboard
1532 >first : accepted debug
1532 >first : accepted reuse
1532 >first : accepted memory
1532 <first : feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 done=1
1532 >first : accepted usermove
1532 >first : accepted sigint
1532 >first : accepted sigterm
1532 >first : accepted colors
1532 >first : accepted pause
1532 >first : accepted done
1547 >first : memory 132
1547 >first : new
random
1547 >first : variant xiangqi
1547 >first : level 40 10 0
1547 >first : post
1547 >first : hard
1547 >first : easy
Impossible move , type = 0
1594 <first : # to engine  : setoption newgame
Reset(1, 1) from gameMode 0
recognized 'xiangqi' (-1) as variant xiangqi
GameEnds(0, (null), 2)
99313 >first : quit
shuffleOpenings = 0
Reset Clocks: full string=:40/600
Reset Clocks: w=600000, b=600000
StartChildProcess (dir=".") UCCI2WB -noini "..\Bugcchess\BugCChess.exe"
nice engine proc to 10
99844 >first : xboard
protover 2
99844 >first : memory 260
99844 >first : new
random
99844 >first : variant xiangqi
99844 >first : level 40 10 0
99844 >first : post
99844 >first : hard
99844 >first : easy
Impossible move , type = 0
99922 <first : UCCI2WB by Morning Yellow and H.G.Muller
99922 <first : # to engine  : ucci
99922 <first : # from engine: alloc material table for thread 0
99922 <first : # from engine: id name bgc 1.0a-11-02-18         
99922 <first : # from engine: id version 1.0a-11-02-18             
99922 <first : # from engine: id author BugCChess team
99922 <first : # from engine: id copyright 2011 BugCChess team
99922 <first : # from engine: option usemillisec type check default true
99922 <first : # from engine: ucciok
99922 <first : feature myname="bgc 1.0a-11-02-18         1.0a-11-02-18               (UCCI2WB)"
99922 >first : accepted myname
99938 <first :
99938 <first : feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1
99938 >first : accepted variants
99938 >first : accepted setboard
99938 >first : accepted debug
99938 >first : accepted reuse
99938 >first : accepted memory
99938 <first : feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 done=1
99938 >first : accepted usermove
99938 >first : accepted sigint
99938 >first : accepted sigterm
99938 >first : accepted colors
99938 >first : accepted pause
99938 >first : accepted done
99938 <first : # to engine  : setoption newgame
184985 >first : force
StartChildProcess (dir=".") UCCI2WB -noini "..\EleEye\eleeye.exe"
nice engine proc to 10
185563 >second: xboard
protover 2
185579 <second: UCCI2WB by Morning Yellow and H.G.Muller
185579 <second: # to engine  : ucci
185579 <second: # from engine: id name ElephantEye 3.1
185579 <second: # from engine: id copyright 2004-2007 www.elephantbase.net
185579 <second: # from engine: id author Morning Yellow
185579 <second: # from engine: id user ElephantEye Test Team
185579 <second: # from engine: option usemillisec type check default true
185579 <second: # from engine: option promotion type check default false
185579 <second: feature option="promotion -check 0"
185579 >second: accepted option
185579 <second:
185579 <second: # from engine: option batch type check default false
185579 <second: feature option="batch -check 0"
185579 >second: accepted option
185579 <second:
185579 <second: # from engine: option debug type check default false
185579 <second: feature option="debug -check 0"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option ponder type check default false
185594 <second: feature option="ponder -check 0"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option usebook type check default true
185594 <second: feature option="usebook -check 1"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option bookfiles type string default D:\cchess\WinBoardPortable\App\WinBoard\EleEye\BOOK.DAT
185594 <second: feature option="bookfiles -string D:\cchess\WinBoardPortable\App\WinBoard\EleEye\BOOK.DAT"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option evalapi type string default D:\cchess\WinBoardPortable\App\WinBoard\EleEye\EVALUATE.DLL
185594 <second: feature option="evalapi -string D:\cchess\WinBoardPortable\App\WinBoard\EleEye\EVALUATE.DLL"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option hashsize type spin min 16 max 1024 default 16
185594 <second: # from engine: option idle type combo var none var small var medium var large default none
185610 <second: feature option="idle -combo *none /// small /// medium /// large"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: option pruning type combo var none var small var medium var large default large
185610 <second: feature option="pruning -combo none /// small /// medium /// *large"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: option knowledge type combo var none var small var medium var large default large
185610 <second: feature option="knowledge -combo none /// small /// medium /// *large"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: option randomness type combo var none var small var medium var large default none
185610 <second: feature option="randomness -combo *none /// small /// medium /// large"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: option newgame type button
185610 <second: feature option="newgame -button"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: ucciok
185625 <second: feature myname="ElephantEye 3.1 (UCCI2WB)"
185625 >second: accepted myname
185625 <second:
185625 <second: feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1
185625 >second: accepted variants
185625 >second: accepted setboard
185625 >second: accepted debug
185625 >second: accepted reuse
185625 >second: accepted memory
185625 <second: feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 done=1
185625 >second: accepted usermove
185625 >second: accepted sigint
185625 >second: accepted sigterm
185625 >second: accepted colors
185625 >second: accepted pause
185625 >second: accepted done
185672 >second: memory 260
185672 >second: new
random
185672 >second: variant xiangqi
185672 >second: level 40 10 0
185672 >second: post
185672 >second: hard
185672 >second: easy
Impossible move , type = 0
185672 >second: force
New game (0): bgc 1.0a-11-02-18         1.0a-11-02-18               (UCCI2WB)-ElephantEye 3.1 (UCCI2WB) (w)
185704 >first : computer
185704 >second: computer
Reset Clocks: full string=:40/600
Reset Clocks: w=600000, b=600000
185704 >first : time 60000
185704 >first : otim 60000
book hit = (NULL)
185704 >first : go
nps: w=-1, b=-1
185704 <second: # to engine  : setoption hashsize 260
185704 <second: # to engine  : setoption newgame
185719 <first : # to engine  : position fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR w - - 0 1
185719 <first : # to engine  : go time 599900 movestogo 40
185735 <first : # from engine:  =
185844 <first : # from engine: total move number 44
185844 <first : # from engine: info depth 2 score 21 time 110 nodes 1324 nps 12036 pv b0c2 b9c7
185844 <first :  2    21    11      1324 b0c2 b9c7
185860 <first : # from engine: info depth 3 score 78 time 125 nodes 3880 nps 31040 pv b0c2 b9c7 h0g2
185860 <first :  3    78    12      3880 b0c2 b9c7 h0g2


Then, to confirm UCCI adapter will faithfully send Threads# and Hashsize settings as long as engines announce such options are available, I searched around and finally found engine UFX.
UFX announced Threads and HashSize options.
Code: Select all
1094 <first : # from engine: option hashsize type spin min 16 max 1024 default 64
1094 <first : # from engine: option threads type spin min 0 max 64 default 0

I use Winboard GUI to set it to 128MB/2Cores.
WinBoard set up UFX as ~128MB/4cores, per Task Manager's report. So, Winboard did start the SMP feature, but not to the threads number I specified, i.e., 2.
How the hash is set to 128MB can be found in debug log as well.
Code: Select all
1204 <first : # to engine  : setoption hashsize 132

** But, I can't seem to find the portion of the log to show adapter sent "# to engine :setoption threads 2" or "# to engine :setoption threads 4". Would you help?
Here is the winboard.debug.
Code: Select all
recognized 'xiangqi' (-1) as variant xiangqi
Parse TC: tc=10
Parse TC: full string = :40/600
recognized 'xiangqi' (-1) as variant xiangqi
WinBoard master-20121209 + ufx
Reset(1, 0) from gameMode 0
recognized 'xiangqi' (-1) as variant xiangqi
GameEnds(0, (null), 2)
shuffleOpenings = 0
Reset Clocks: full string=:40/600
Reset Clocks: w=600000, b=600000
StartChildProcess (dir=".") UCCI2WB -noini "..\ufx\ufx.EXE"
nice engine proc to 10
969 >first : xboard
protover 2
1063 <first : UCCI2WB by Morning Yellow and H.G.Muller
1063 <first : # to engine  : ucci
1079 <first : # from engine: Load book 52425
1079 <first : # from engine: id name Deep Ultimate Fight of Xiangqi 0.18
1079 <first : # from engine: id copyright 2006...2007 nowcan.yeah.net
1079 <first : # from engine: id author NowCan
1079 <first : # from engine: id user UFX Users
1079 <first : # from engine: option usemillisec type check default true
1079 <first : # from engine: option usedualtime type check default true
1079 <first : feature option="usedualtime -check 1"
1094 >first : accepted option
1094 <first :
1094 <first : # from engine: option hashsize type spin min 16 max 1024 default 64
1094 <first : # from engine: option ponder type check default false
1094 <first : feature option="ponder -check 0"
1094 >first : accepted option
1094 <first :
1094 <first : # from engine: option threads type spin min 0 max 64 default 0
1094 <first : feature option="threads -spin 0 0 64"
1094 >first : accepted option
1094 <first :
1094 <first : # from engine: ucciok
1094 <first : feature myname="Deep Ultimate Fight of Xiangqi 0.18 (UCCI2WB)"
1110 >first : accepted myname
1110 <first :
1110 <first : feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1
1110 >first : accepted variants
1110 >first : accepted setboard
1110 >first : accepted debug
1110 >first : accepted reuse
1125 >first : accepted memory
1125 <first : feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 done=1
1125 >first : accepted usermove
1125 >first : accepted sigint
1125 >first : accepted sigterm
1125 >first : accepted colors
1125 >first : accepted pause
1125 >first : accepted done
1141 >first : memory 132
1141 >first : new
random
1141 >first : variant xiangqi
1141 >first : level 40 10 0
1157 >first : post
1157 >first : hard
1157 >first : easy
Impossible move , type = 0
1204 <first : # to engine  : setoption hashsize 132
1204 <first : # to engine  : setoption newgame
63563 >first : force
StartChildProcess (dir=".") UCCI2WB -noini "..\EleEye\eleeye.exe"
nice engine proc to 10
64079 >second: xboard
protover 2
64094 <second: UCCI2WB by Morning Yellow and H.G.Muller
64094 <second: # to engine  : ucci
64094 <second: # from engine: id name ElephantEye 3.1
64094 <second: # from engine: id copyright 2004-2007 www.elephantbase.net
64094 <second: # from engine: id author Morning Yellow
64094 <second: # from engine: id user ElephantEye Test Team
64094 <second: # from engine: option usemillisec type check default true
64094 <second: # from engine: option promotion type check default false
64094 <second: feature option="promotion -check 0"
64094 >second: accepted option
64094 <second:
64094 <second: # from engine: option batch type check default false
64094 <second: feature option="batch -check 0"
64094 >second: accepted option
64094 <second:
64094 <second: # from engine: option debug type check default false
64094 <second: feature option="debug -check 0"
64094 >second: accepted option
64094 <second:
64094 <second: # from engine: option ponder type check default false
64094 <second: feature option="ponder -check 0"
64110 >second: accepted option
64110 <second:
64110 <second: # from engine: option usebook type check default true
64110 <second: feature option="usebook -check 1"
64110 >second: accepted option
64110 <second:
64110 <second: # from engine: option bookfiles type string default D:\cchess\WinBoardPortable\App\WinBoard\EleEye\BOOK.DAT
64110 <second: feature option="bookfiles -string D:\cchess\WinBoardPortable\App\WinBoard\EleEye\BOOK.DAT"
64110 >second: accepted option
64110 <second:
64110 <second: # from engine: option evalapi type string default D:\cchess\WinBoardPortable\App\WinBoard\EleEye\EVALUATE.DLL
64110 <second: feature option="evalapi -string D:\cchess\WinBoardPortable\App\WinBoard\EleEye\EVALUATE.DLL"
64110 >second: accepted option
64110 <second:
64110 <second: # from engine: option hashsize type spin min 16 max 1024 default 16
64110 <second: # from engine: option idle type combo var none var small var medium var large default none
64110 <second: feature option="idle -combo *none /// small /// medium /// large"
64125 >second: accepted option
64125 <second:
64125 <second: # from engine: option pruning type combo var none var small var medium var large default large
64125 <second: feature option="pruning -combo none /// small /// medium /// *large"
64125 >second: accepted option
64125 <second:
64125 <second: # from engine: option knowledge type combo var none var small var medium var large default large
64125 <second: feature option="knowledge -combo none /// small /// medium /// *large"
64125 >second: accepted option
64125 <second:
64125 <second: # from engine: option randomness type combo var none var small var medium var large default none
64125 <second: feature option="randomness -combo *none /// small /// medium /// large"
64125 >second: accepted option
64125 <second:
64125 <second: # from engine: option newgame type button
64125 <second: feature option="newgame -button"
64125 >second: accepted option
64125 <second:
64125 <second: # from engine: ucciok
64125 <second: feature myname="ElephantEye 3.1 (UCCI2WB)"
64125 >second: accepted myname
64141 <second:
64141 <second: feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1
64141 >second: accepted variants
64141 >second: accepted setboard
64141 >second: accepted debug
64141 >second: accepted reuse
64141 >second: accepted memory
64141 <second: feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 done=1
64141 >second: accepted usermove
64141 >second: accepted sigint
64141 >second: accepted sigterm
64141 >second: accepted colors
64141 >second: accepted pause
64141 >second: accepted done
64157 >second: memory 132
64157 >second: new
random
64157 >second: variant xiangqi
64157 >second: level 40 10 0
64157 >second: post
64157 >second: hard
64157 >second: easy
Impossible move , type = 0
64172 >second: force
64172 <second: # to engine  : setoption hashsize 132
64172 <second: # to engine  : setoption newgame
New game (0): Deep Ultimate Fight of Xiangqi 0.18 (UCCI2WB)-ElephantEye 3.1 (UCCI2WB) (w)
64204 >first : computer
64204 >second: computer
Reset Clocks: full string=:40/600
Reset Clocks: w=600000, b=600000
64204 >first : time 60000
64204 >first : otim 60000
book hit = (NULL)
64204 >first : go
nps: w=-1, b=-1
64219 <first : # to engine  : position fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR w - - 0 1
64219 <first : # to engine  : go time 599900 movestogo 40
64235 <first : # from engine: bestmove g3g4
64235 <first : move g3g4
64235 >second: time 60000
64235 >second: otim 59996
book hit = (NULL)
64235 >second: usermove 64235 >second: g3g4
64235 >second: go
silence
64375 <second: # to engine  : position fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR w - - 0 1 moves g3g4
64375 <second: # to engine  : go time 599900 movestogo 40
64563 <second: # from engine: info depth 0 score 149 pv h7g7
64563 <second: # from engine: info depth 0 score 57 pv c6c5
64563 <second: # from engine: info depth 0 score 50 pv b9c7
cnchang
 
Posts: 49
Joined: 03 Dec 2012, 09:08

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 17 Dec 2012, 17:35

cnchang wrote:The above command is similar to what I used to generate the what you called GUI-adapter debug log. The only difference is I added a "-debug" argument at the end.
i.e., "UCI2WB debug Shiga.exe ../Shijia" -debug

You can see that this is not the case; the winboard.debug file also shows the commands that started the engines, and they were:
Code: Select all
StartChildProcess (dir=".") UCI2WB Shiga.exe ..\Shijia
StartChildProcess (dir="..\Anita") UCI2WB cyclone.exe ..\cyclone2011

So the 'debug' argument to UCI2WB that I highlighted in quoting you above was obviously not given, and this is the reason UCI2WB does not report on engine->adapter traffic. You also can set UCI2WB to debug mode through the Engine Settings dialog, but you are too late then to capture the handshaking.

Now, to see the engine-adapter dialog, I tried your command with "-debug" removed, but no winboard.debug or any other obvious log file got created.

That is correct. You need to add -debug to cause WB to create a winboard.debug file. But WB can only report on what it sees, and it is only connected to UCI2WB, and not to the UCI engine. So you also have to make UCI2WB report on what goes on between it and the engine.

This is the command I used before, and it generated a GUI-adapter log file without adapter-engine side:
"Shijia" -fcp "UCI2WB debug Shiga.exe ..\Shijia" -debug /variant=xiangqi

This is the command I put in Edit Engine List to gather UCI engine debug info but it ends up getting no log file:
"Shijia" -fcp "UCI2WB debug Shiga.exe ..\Shijia" /variant=xiangqi

Then, I tried something different:
"Shijia" -fcp "UCI2WB -debug Shiga.exe ..\Shijia" -debug /variant=xiangqi

No, that doesn't work. UCI2WB needs plain 'debug' and wouldnot recognize '-debug'. (I suppose this means you cannot use itto run a UCI engine called 'debug'...)

Code: Select all
recognized 'xiangqi' (-1) as variant xiangqi
Parse TC: tc=10
Parse TC: full string = :40/600
recognized 'xiangqi' (-1) as variant xiangqi
WinBoard master-20121209 + UCI2WB
Reset(1, 0) from gameMode 0
recognized 'xiangqi' (-1) as variant xiangqi
GameEnds(0, (null), 2)
shuffleOpenings = 0
Reset Clocks: full string=:40/600
Reset Clocks: w=600000, b=600000
StartChildProcess (dir=".") UCI2WB -debug Shiga.exe ..\Shijia

Well, you can see that here it indeed used the '-debug' on UCI2WB, but unfortunately this is not what UCI2WB needs. In your earlier debug log there was no 'debug' argument to UCI2WB at all, however. So something must have gone wrong, and you were not executing the engine line you intended to execute.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 17 Dec 2012, 18:25

cnchang wrote:I chose Bugcchess to play with Elephant Eye with both debug mode turned on, and I tried to set 256MB/4cores via WBGUI.
As a result, Bugcchess stays ~40MB/1core, and Elephant Eye turns into 260MB/1core.
Here is the debug log. I noticed <second: # to engine : setoption hashsize 260 just appeared once, and it seems only Elephant Eye engine received this command, but not Bugcchess.
I think the reason it only sent to Elephant Eye is because UCCI adapter received this from EleEye a while ago.
<second: # from engine: option hashsize type spin min 16 max 1024 default 16

Exactly. That is how the handshaking works. UCCI2WB scans the 'option' commands it receives from the engine for a Hash or hashsize option, and if it finds either of these, it uses it to set the hash size through a 'setoption'. If it does not receive any of these two from the engine, it does not know what command the engine would accept (if, indeed, it would accept any at all), so it does not send anything.

Code: Select all
1500 <first : # to engine  : ucci
1500 <first : # from engine: alloc material table for thread 0
1500 <first : # from engine: id name bgc 1.0a-11-02-18         
1500 <first : # from engine: id version 1.0a-11-02-18             
1500 <first : # from engine: id author BugCChess team
1500 <first : # from engine: id copyright 2011 BugCChess team
1500 <first : # from engine: option usemillisec type check default true
1500 <first : # from engine: ucciok
1516 <first : feature myname="bgc 1.0a-11-02-18         1.0a-11-02-18               (UCCI2WB)"
1516 >first : accepted myname
1516 <first :
1516 <first : feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1

You see that BugCChess is great on announcing names, versions and copyrights, but announces only one option: usemillisec. UCCI2WB concatenates the id-name and id-version command to create a name that it can send to the GUI as 'myname' feature. (There must be trailing spaces or tabs in the 'id' commands; it might be a good idea to let UCCI2WB strip those...)

Code: Select all
185579 <second: # to engine  : ucci
185579 <second: # from engine: id name ElephantEye 3.1
185579 <second: # from engine: id copyright 2004-2007 www.elephantbase.net
185579 <second: # from engine: id author Morning Yellow
185579 <second: # from engine: id user ElephantEye Test Team
185579 <second: # from engine: option usemillisec type check default true
185579 <second: # from engine: option promotion type check default false
185579 <second: feature option="promotion -check 0"
185579 >second: accepted option

You see that UCCI2WB does immediately relay the announced 'option promotion' to WB as an 'option feature', which is the way for engines to define non-standard options in WB protocol. It does not do this for 'usemillisec', as this is a standard UCCI options that affects the way times are sent between adapter and engine,and which does not concern the GUI. (In WB protocol times are always sent in centi-sec.)

Code: Select all
185579 <second:
185579 <second: # from engine: option batch type check default false
185579 <second: feature option="batch -check 0"
185579 >second: accepted option
185579 <second:
185579 <second: # from engine: option debug type check default false
185579 <second: feature option="debug -check 0"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option ponder type check default false
185594 <second: feature option="ponder -check 0"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option usebook type check default true
185594 <second: feature option="usebook -check 1"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option bookfiles type string default D:\cchess\WinBoardPortable\App\WinBoard\EleEye\BOOK.DAT
185594 <second: feature option="bookfiles -string D:\cchess\WinBoardPortable\App\WinBoard\EleEye\BOOK.DAT"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option evalapi type string default D:\cchess\WinBoardPortable\App\WinBoard\EleEye\EVALUATE.DLL
185594 <second: feature option="evalapi -string D:\cchess\WinBoardPortable\App\WinBoard\EleEye\EVALUATE.DLL"
185594 >second: accepted option
185594 <second:
185594 <second: # from engine: option hashsize type spin min 16 max 1024 default 16

Here we see the announcement of the 'hashsize' option. Note that it is not relayed to the GUI as option feature, but used later to translate WB 'memory' commands.
Code: Select all
185594 <second: # from engine: option idle type combo var none var small var medium var large default none
185610 <second: feature option="idle -combo *none /// small /// medium /// large"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: option pruning type combo var none var small var medium var large default large
185610 <second: feature option="pruning -combo none /// small /// medium /// *large"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: option knowledge type combo var none var small var medium var large default large
185610 <second: feature option="knowledge -combo none /// small /// medium /// *large"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: option randomness type combo var none var small var medium var large default none
185610 <second: feature option="randomness -combo *none /// small /// medium /// large"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: option newgame type button
185610 <second: feature option="newgame -button"
185610 >second: accepted option
185610 <second:
185610 <second: # from engine: ucciok
185625 <second: feature myname="ElephantEye 3.1 (UCCI2WB)"
185625 >second: accepted myname
185625 <second:
185625 <second: feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1
....
185625 <second: feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 done=1

So after lots of options, all relayed to the GUI as option features, Elephant Eye finlly announces it is done by sending 'ucciok'. UCCI2WB continues then 'configuring' the GUI through other feature commands, concluding with done=1.

Code: Select all
185672 >second: memory 260
185672 >second: new
...
185704 <second: # to engine  : setoption hashsize 260
185704 <second: # to engine  : setoption newgame
185719 <first : # to engine  : position fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR w - - 0 1
185719 <first : # to engine  : go time 599900 movestogo 40

Here the 'memory 260' reeived from the GUI is relayed as 'setoption hashsize', because UCCI2WB now knows that the engine uses 'hashsize' for this. (Some other UCCI engine use Hash in stead.)

** But, I can't seem to find the portion of the log to show adapter sent "# to engine :setoption threads 2" or "# to engine :setoption threads 4". Would you help?

This is correct. I did not add any code in UCCI2WB yet to intercept 'threads' and similar options to connect them to the WB 'cores' command, so that the thread# cannot be centrally controlled from Common Engine yet. But because 'threads' is not recognized as special, it will be relayed to the GUI as engine-specific option like any other, and appear in the Engine Settings dialo. So to set the number of threads for UCCI engines, it should be done from Engine Settings.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby cnchang » 18 Dec 2012, 07:29

This is correct. I did not add any code in UCCI2WB yet to intercept 'threads' and similar options to connect them to the WB 'cores' command, so that the thread# cannot be centrally controlled from Common Engine yet. But because 'threads' is not recognized as special, it will be relayed to the GUI as engine-specific option like any other, and appear in the Engine Settings dialo. So to set the number of threads for UCCI engines, it should be done from Engine Settings.

Got something going on UFX Threads#, but it is still not quite correct.
The default threads#: 0
In Engine Settings,
(1) set it to 1 -> it uses 1 core (25%)
Code: Select all
2137 <first : # to engine  : setoption hashsize 260
2137 <first : # to engine  : setoption newgame
[x] usedualtime               
[x] ponder                                  threads [    +/-]
20046 >first : option threads=1
20062 <first : # to engine  : setoption threads 1
26645 >first : force

(2) set it to 2 -> it uses 3 cores (75%)
Code: Select all
[x] usedualtime               
[x] ponder                                  threads [    +/-]
9812 >first : option threads=2
9828 <first : # to engine  : setoption threads 2
13728 >first : force

(3) set it to 3 -> it uses 4 cores (100%)
Code: Select all
2106 <first : # to engine  : setoption hashsize 260
2106 <first : # to engine  : setoption newgame
[x] usedualtime               
[x] ponder                                  threads [    +/-]
8424 >first : option threads=3
8439 <first : # to engine  : setoption threads 3
11497 >first : force


Is there any UCCI engine fully compatible with WBGUI/UCCI2WB on hashsize and threads# settings? I'm not sure how to set up a tourney when Common Engine is not working. For example, when a new engine is loaded for a new match, will this new engine#1 use previous match engine#1's settings?
cnchang
 
Posts: 49
Joined: 03 Dec 2012, 09:08

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 18 Dec 2012, 09:28

cnchang wrote:Got something going on UFX Threads#, but it is still not quite correct.
The default threads#: 0

Yes, this is weird. But from your earlier post one can see that it is indeed what the engine said:
Code: Select all
1094 <first : # from engine: option threads type spin min 0 max 64 default 0

Of course it would not be possible to run without using CPU, so one would presume the '0' is an invalid value, used to indicate something like 'use all available cores'. I don't know if there is any UCCI standard for this. There exist no UCCI specs that I can read, or even subject to mechanical translation.

(1) set it to 1 -> it uses 1 core (25%)

That, at least, sounds normal.

(2) set it to 2 -> it uses 3 cores (75%)
Code: Select all
[x] usedualtime               
[x] ponder                                  threads [    +/-]
9812 >first : option threads=2
9828 <first : # to engine  : setoption threads 2
13728 >first : force


This is weird again. But WB & UCCI2WB are not to blame; eventually the engine does receive a 'setoption' request for 2 threads. Why it then starts using 3 is anybodies guess. This is what I meant when I said that UCCI engines are in general a buggy and non-compliant bunch. Apparently, as soon as you ask for more threads than the engine process is born with, it starts to create new ones, and creates as many new ones as you asked for, forgetting that it already has one running, and thus ending up with one too many.

Is there any UCCI engine fully compatible with WBGUI/UCCI2WB on hashsize and threads# settings? I'm not sure how to set up a tourney when Common Engine is not working. For example, when a new engine is loaded for a new match, will this new engine#1 use previous match engine#1's settings?


Indeed, newly loaded engines would normally start with their defaults, except for the centrally controlled hash and thread#, which WB automatically sends through the 'memory' and 'core' commands. (But 'cores' is not yet translated by UCCI2WB, so that is not mucch help.) But WinBoard can be instructed to automatically change the default. This can be done by adding the WinBoard option /firstOptions="..." to the engine line (using the 'Edit Engine List' menu item). The text string then can contain option name=value pairs separated by commas. E.g. with UFX you could do

"Ultimate Fight (4 core)" -fcp "UFX.exe" -fd "../UFX221" -fUCCI -firstOptions="threads=3"
"Ultimate Fight (4 core)" -fcp "UCI2WB -noini ../UFX221/UFX.exe" -fUCCI -firstOptions="threads=3"

to make it play with 4 threads. WB would then send 'option threads=3' to UCCI2WB each time it started UFX, and UCCI2WB would translate this to 'setoption threads 3' before relaying it to UFX. This is cumbersome, because you would have to change it in all installed engines when you decide to run a tourney with different settings for the number of cores (which is the rationale for having it centrally controlled). It has the advantage, though, that you can alter the setting and the option name on a per-engine basis, which is good for curing non-compliancies such as UFX' core use: you would install UFX with threads=3, and the others with threads=4 (or maxthreads=4, or cpus=4, or whatever they need).

Ideally there would be a 'Save' button in the Engine Settings dialog that would add such a -firstOptions option to the engine line, containing all options that are not at their default. Then it would just be a matter of altering the setting of 'threads' in the Engine Settings, and pressing 'Save' to make that the new effective default. An alternative would be to make UCCI2WB support a Save option towards WB, and maintain an INI file for the engine settings. Which it would read at statup to set the engine options, and which would be written on receiving the Save command from the GUI. This is the solution that Polyglot (the UCI adapter that can only handle Chess) uses.

As to your first question, I don't really know. Upto two months ago I only had a dual, and I never tried to run any SMP tournies. I have not been running any Xiangqi games for the past two years, as I did not work on HaQiKi D in this period. Last time I did run tournies only few engines were SMP, and they all could be controlled through ini files, like Shiga. Rarely were they set for using more that 1 core by default, and in that case there was no reason for me to attempt setting the thread# at all. Some engines had problems, to the point where I could not run them at all in my tourney. E.g. there was one that used 60-80% CPU (on a dual, so that is 1.2-1.6 core) when set to 1 thread.

To improve the situation, it would be necessary to know if there is a standard option that most engines react to (which could be different for UCI and UCCI engines, but that is no problem, as either protocol has its own adapter). I could then program UCCI2WB and UCI2WB to translate the WB 'cores' command to this option. Perhaps there are also other UCCI engines that use 'threads'. UFX at least announces it does, even though it then seems to err in applying it.

Btw, to see what options engines announce there is no need to make debug files; the simplest way is just double-click the engine .exe, and type 'ucci' in the window that appears. It then prints all options in this window. This works for almost every engine I tried.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 18 Dec 2012, 14:17

Since it seems that 'threads' is sort of standard amongst UCCI engines (beside UFX also XQSpirit announces this. Not sure about Kou; this refuses to run from the command prompt) I now let UCCI2WB translate the WB 'cores' command to 'setoption threads' (for engines that announce this option). I also made it possible to use a DefectiveEngineOptions.ini file with UCCI2WB. I uploaded the new version to

http://hgm.nubati.net/ucci2wb.exe

[Edit] Note that UCCI2WB has always had the possibility to read a file UCCI2QH.ini at startup, and for any line "Option=xxx" on it, it would send "xxx" to the engine. Before I implemented relaying the handshaking to the GUI back and forth, this was the only way to set engine options. (And they could not be set interactively.) Initially UCCI2WB was always looking for this UCCI2QH.ini in its own folder, forcing you to make copies of UCCI2WB.exe in each engine folder if they needed to use different UCCI2QH.ini files. But this latest version changes directory to the engine folder, so that you could put a UCCI2QH.ini there specific to the engine, to cause some unconditional adapter -> engine commands at startup. But 'setoption' commands send this way are completely static, and will never react to any GUI settings, as the GUI will be completely oblivious of the fact they have been set at all. This is why it is better to fake some engine -> adapter commands, to evoke the required 'setoption' commands from the GUI.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby cnchang » 19 Dec 2012, 04:31

Downloaded and tested your new ucci2wb beta on a two-core system.
(1)UFX can be configured successfully with new Hash and Threads settings through Common Engine.
(2)With defectiveEngineOptions.ini installed, Bugcchess can also be configured successfully on Hashsize and Threads.
(3)My Xqspirit, 2008 edition, doesn't announce threads option and Hashsize option, defectiveEngineOptions.ini can only help WB configure Hashsize. Engine itself seems to be the problem using only 1 core, just like my Elephant Eye.
Do you know where I can download a newer version as yours to do some tests?

You have made significant progress on UCCI GUI.
I will test extensively on more engines on a four-core system.
cnchang
 
Posts: 49
Joined: 03 Dec 2012, 09:08

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 19 Dec 2012, 08:36

Indeed, I never payed much attention to the cores command, as I never used SMP myself, and it seeemed hardly any engine had an option for it anyway. With a dual, even if I wanted to us both cores, I would play ponder games rather than 2-core ponder-off. And I figured the option would appear in the Engine Settings dialog anyway. But now that you tell me that BHGUI can set the thread# of most engines, it must mean there is some de-facto standard for it. Even though most engines hide it well, apparently taking for granted that the GUI will send it.

IIRC I downloaded it as attahment to the elephantbase.com forum, which was losed down in 2010 because of an impending crackdown of the Chinese government on illegal forums. It was posted there by the author himself. (Which unfortunately did not speak any English at all.) So it is a public version. (Although in theory only registered forum members could download it, anyone with an e-mail address could register...)

I will check if I can upload the version I have somewhere. Although I am sure that there must exist much newer versions than the one I have, by now. But I haven't visited any Chinese computer-XQ forums lately.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby cnchang » 19 Dec 2012, 16:26

From Xqbase, http://www.xqbase.com/league/xqspirit.htm,this is the 2008 version that I have, which can only use 1 core.
I also found a Traditional Oriental board introduced here - http://home.hccnet.nl/h.g.muller/XQwinboard.html
But, I can't seem to download the FONT or BOARD by following the links on that page.
I thought it may have already integrated into Winboard, but all I see from my current Winboard [View > Board Themes ... > Select from Theme list] there is only one theme - "Native", a western chess style board.
Is it because I am using a portable Winboard? Do I need to Download WinBoard 4.6.2 installer (2.3MB) to get this Traditional Oriental board?
cnchang
 
Posts: 49
Joined: 03 Dec 2012, 09:08

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 19 Dec 2012, 16:51

I just uploaded XQ Spirit 2010.05.12, which is the latest one I have. I was wrong: it does not announce a 'threads' option. I confused it with BHWS engine, which does. This XQ Spirit is SMP, though: it comes with an INI file, where the thread# is set with the option 'nThreads'.

Themes are a new feature in this WinBoard beta, for which I do not supply a fully-configured installer package yet. This is why you only see the default (compiled-in) themes list, which only contains the Native theme, which switches the use of all external resources off. Other themes would only work if you have the resources for the (fonts and bitmap files). When I officially release WB 4.7.0 it will come fully equiped, configured with several themes.

The portable version is indeed a highly stripped-down version of the standard install, lacking all optional stuff (which includes XQ and Shogi stuff).

WinBoard 4.6.2 already comes with bitmaps of a Xiangqi board and the XIANGQI font, when you select the optional Xiangqi components during install. (I also have a special WinBoard XQ distribution, where WB is configured for oriental-style XQ by default, but this contains an even older WB version. It can be downloaded from my WB home page.) When you have one of these full packages installed, all you have to do to create an Oriental XQ theme is to use the Themes dialog to browse for the XQ board in the 'WinBoard\textures' folder of it, and select it for both light and dark-square texture. And use the Font dialog to select the font named XIANGQI, which the installer installed. That way (after playing a bit with the piece colors) you should be able to reproduce the images on my website, and the save it as a new Theme by specifying a name for it.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby cnchang » 20 Dec 2012, 10:45

OK, UCCI engines mostly work with your beta and defectiveEngineOptions.ini. UFX's not quite following the order of WBGUI proves to be engines' own problem because the same sympton showed up in BHGUI.

With that confidence building up, I wonder if we can revisit UCI's GUI problem.
I did some tests and collected some info here:
1. WBGUI, with the help of defectiveEngineOptions.ini, can mostly control UCI engines' Hash(e.g., Shiga and Cyclone 6.2 will follow GUI's Common Engine instruction, but ggChess not fully following GUI's order on Hash), but WBGUI can't control Threads# on all GUI engines.
2. BHGUI can control all UCI engines(e.g., Shiga, Cyclone 6.2, ggChess, and Apo i.e., BHWS engine's new name) on Hash and Threads#.

I used spy.exe to replace cyclone62 to collect the BHGUI commands while setting 512/4 there.
Code: Select all
out: max threads set to 2
out: XQMS 3.26_10_19. By  Ⅲ穸+塘鏙++?
in:  uci
out: id name XQMS 3.26_10_19
out: id author Ⅲ穸+塘鏙++?

out: uciok

out: XQMS Use uci[ucci] protocol
in:  isready
out: readyok
in:  setoption name OwnBook value false
in:  setoption name Threads value 4
in:  setoption name Hash value 512


Here is WinBoard GUI log on 512/4.
Code: Select all
0. cyclone62.exe
out: max threads set to 2
out: XQMS 3.26_10_19. By  Ⅲ穸+塘鏙++?
in:  uci
out: id name XQMS 3.26_10_19
out: id author Ⅲ穸+塘鏙++?

out: uciok

out: XQMS Use uci[ucci] protocol
in:  setoption name Hash value 516
in:  isready
out: readyok
in:  ucinewgame
in:  isready
out: readyok


This is cyclone62's initial handshaking messages.
Code: Select all
engine init...
init OK
uci
id name Cyclone v6.2 [develop 091218]
id author Chency
option name Hash type spin default 64 min 4 max 1024
option name Threads type spin default 1 min 1 max 16
option name Ponder type check default false
option name OwnBook type check default true
option name Clear Hash type check default false
uciok
cnchang
 
Posts: 49
Joined: 03 Dec 2012, 09:08

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 20 Dec 2012, 11:34

It seems from this that Cyclone 6.2 is completely compliant with the UCI standard: it announces the options Threads, Hash and OwnBook as it should. BHGUI does set these options without them being announced however: spy.exe was a Shiga simulator, and thus, like Shiga, did not announce any options. Yet BHGUI does send the 'setoption' commands for them.

At this stage we cannot know whether BHGUI does send these options unconditionally, or because we really fooled it into thinking that spy.exe is Shiga, (e.g. by scanning the initial output for XQMS), and it has special code to cater to the non-compliancy of Shiga. It could also be that BHGUI has special code to recognize engines by filename, and therefore thinks that spy.exe is Cyclone, and therefore sends the options it knows are good for Cyclone.

Can you run spy.exe under BHGUI again after renaming it to Shiga.exe, to see if BHGUI persists in using Hash and Threads? We already know that Shiga responds to whatever BHGUI sends it. If that is Threads, then a line "option name Threads type spin default 2 min 1 max 8" in the DefectiveEngineOptions.ini should work for Shiga, in the sense that it should make the option appear in the Engine Settings dialog, and respond to its setting there. Note that with the current UCI2WB nothing will ever respond to the Max CPUs setting in Common Engine, as UCI2WB does not translate the WB 'cores' command. It seems I should translate it to 'Threads'.

But I thought you already tried 'threats' in the DefectiveEngineOptions.ini, and that that did not work. It could be that the leading capital T in the option name is critical, although officially UCI is supposed to be case-insensitive.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby cnchang » 20 Dec 2012, 13:48

BHGUI did it unconditionally as I suggested before. For example, ggChess(i.e., id name: ggChess-UCI-4U) never announces threads option in handshaking, but BHGUI simple sends the same commands to activate the hidden threads feature. It won't hurt the engines even if those engines don't recognize the options, engines will just ignore the setoption commands at most. I think that is why BHGUI doesn't need any custom made defectiveEngineOptions.ini installed for any engine, and it doesn't care if engines ever announce options in the handshaking. I have seen this many times. It is hard for users to tailor defectiveEngineOptions.ini by trying Hash or Hashsize for UCCI/UCI engines. But in reality, 99% UCCI engine knows Hashsize and 99% UCI knows Hash. Simple is good.

BTW, is Winboard an open source project like Xboard?
cnchang
 
Posts: 49
Joined: 03 Dec 2012, 09:08

Re: How to suspend a Winboard tournament?

Postby H.G.Muller » 20 Dec 2012, 14:39

Well, for example the version of Anita I have announces the option Hash, rather than hashsize. I don't remember anymore if it actually worked. But if it truly responds to Hash, and not to hashsize, sending hashsize always would leave you with a non-working Anita. This is why it is better to ion out these non-compliancies in an engine-dependent way. It is much easier for most users to edit an ini file than to change and recompile the GUI...

If almost all engines respond to Hash and Threads, there is no need for the user to do any experimenting with options at all. He can just use a standard version of DefectiveEngineOptions.ini, copy it to the engine folder, and it would work in the 99% of the cases you mention. Only for engines where it does not wok would he have to experiment. But then at least it might be possible to get it working. Which would not be possible when the 'standard work-around' was hard-coded in the GUI, while another work-around was needed.

WinBoard is indeed open-source, like XBoard. In fact it is the same open-source project; they share ~70% of the source code (the so-called 'back-end'), and the remaining 30% is the front-end that is dedicated to performing platform-dependent tasks. The WinBoard source code is included in the XBoard souce tar balls you an find at GNU and in my own on-line source repository. The WB front-end is located in the sub-directory 'winboard', and you would have to change to that directory to built WinBoard.

[Edit] I uploaded a new http://hgm.nubati.net/UCI2WB.exe , which intercepts the option Threads and connects it to the WB cores command. So UCI engines that announce it, (like Cyclone 6.2 and my version of ggChess) should automatically respond to the Common Engine settings. Shiga will need a DefectiveEngineOptions.ini with "option name Threads default 2 min 1 max 8" for this.
User avatar
H.G.Muller
 
Posts: 3376
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: How to suspend a Winboard tournament?

Postby cnchang » 20 Dec 2012, 16:21

For Anita, not sure about yours, mine is 2006 edition, it doesn't work with either Winboard or BHGUI on Hash/Threads. I think BHGUI just sent out the same commands. But, Anita is not operable even though it announced Hash option in the handshaking. If you want to verify it, you can make another spy_ucci.exe so I can capture a trace on BHGUI for you.

My tests so far show most engines, as long as they are operable on UCI/UCCI settings, will take general UCI/UCCI commands. If you still worry about some anomalies, why not hard code two-way commands? For example, send "setoption name Hash value 512" command followed by "setoption name Hashsize value 512" command, thus at least one will work and the other ignored. If an engine claims to be UCI or UCCI compliant, then at least it must be conformant to some extent. Only then, Common Engine can be used to force all engines, within their powers, to follow the same rules without much alteration.
cnchang
 
Posts: 49
Joined: 03 Dec 2012, 09:08

PreviousNext

Return to Winboard and related Topics

Who is online

Users browsing this forum: No registered users and 10 guests