How to suspend a Winboard tournament?

[H.G.Muller]

My policy is to stick to the standard. Relaxing standards is malicious, and usually does incredible damage. Because people it will encourage more people to deviate from the standard, and before you know it, there is complete chaos. Giving an inch will soon be not enough, and turn in a foot, then a yard, etc. The only responsible thing is not to budge at all.

[cnchang]

It depends on what adhering to UCI/UCCI protocol means. For Anita, it adheres to protocol by announcing options, but no GUI can utilize any of its announced options via standard methods. Maybe its options can still be invoked in some strange way. But, who cares. No one is willing to do the guess work for it, not a bit.

For some UCI/UCCI engines, maybe they think announcing "max threads#" means nothing much because the real max threads# depends on the system limitation. For example, announcing max threads# 32 means nothing on a 4 cores system. On the other hand, if it hard codes and announces the max threads# is 4 or 6 due to their test results but later finds out it's working well on the newly released 8 or 12 cores systems, do they have to recompile another one? Therefore, maybe the simple and the best way is not to announce something they are not sure about but to allow GUIs to use standard setoption commands to invoke options. To be honest, I don't see how much they deviate from the UCI/UCCI protocols on not willing to announce something that they are not sure about. For Shiga, its ini outweighs GUI settings is somewhat unique and deviated, but once you know the trick this property can be used for different purposes as mentioned before.

Winboard can still apply strict protocol and not to show unannounced options boxes in the [Engine #1(or #2) Settings...] configuration screen. But in [Common Engine...] configuration screen, which is so important for a tourney or two-machine match, GUI should not budge at all. It should send all user selected options to the engines regardless if engines are limited by their restraints, because these options are considered "common". When set to use 4 cores, BHGUI sends "setoption name Threads value 4" to the engines right away, but WBGUI doesn't send anything to the engines even after I tried to use this DefectiveEngineOptions.ini workaround method. Isn't that a little discouraging? All BHGUI did was using standard methods to faithfully invoke all options set by users via its GUI.

For UCI engines, the standard method to set Hash and Threads is --

Code: Select all

setoption name Threads value x
setoption name Hash value yyy

For UCCI engines, the standard method to set Hash and Threads is --

Code: Select all

setoption name Threads value x
setoption name Hashsize value yyy

We has seen this in UCI engines. If you want to verify the case for UCCI engines, you can make a spy4ucci.exe and I can operate the Chinese BHGUI to capture a trace for examining. Perhaps I may try to modify your original spy.exe source code to make a UCCI edition like this:

Code: Select all

#include <stdio.h>

void
out(FILE *f, char *s)
{
  printf(s); // to GUI
  fprintf(f, "out: %s", s); // on log file
  fflush(f);
}

int
main(int argc, char **argv)
{
  FILE *f = fopen("log.txt", "w");
  int j;

  for(j=0; j<argc; j++) fprintf(f, "%d. %s\n", j, argv[j]), fflush(f); // command line to log file

  out(f, "max threads set to 2\n");     //may I remove this line?
  out(f, "XQMS 3.26_10_19. By  ¢»Í¥├¶íóı┼├÷.\n");

  while(1) {
   int i=0, x;
   char line[1000], command[100];

   fflush(stdout);
   while((line[i] = x = getchar()) != EOF && line[i] != '\n') i++;
   line[++i] = 0;
   fprintf(f, "in:  %s", line); fflush(f);
   sscanf(line, "%s", command);
   if(!strcmp(command, "quit")) return 1;
   else if(!strcmp(command, "ucci")) {
      out(f, "id name XQMS 3.26_10_19\n");
      out(f, "id author ¢»Í¥├¶íóı┼├÷.\n\n");
      out(f, "ucciok\n\n");
      out(f, "XQMS Use ucci[uci] protocol\n");
   }
   else if(!strcmp(command, "isready")) out(f, "readyok\n");
  }
}

Does this spy4ucci source code look OK with the line I marked removed? Is your spy.exe compiled by C# or C++?

[H.G.Muller]

It depends on what adhering to UCI/UCCI protocol means. For Anita, it adheres to protocol by announcing options, but no GUI can utilize any of its announced options via standard methods. Maybe its options can still be invoked in some strange way. But, who cares. No one is willing to do the guess work for it, not a bit.

Announcing options that are in fact not supported should be considered one of the worst forms of non-compliancy. Like I said, I did not remember if Anita would actually respond to using this option; in general I noticed that there are very many UCCI engines that announce options they don't have, or options they do have with the wrong default setting, or use UCI syntax to announce UCCI options, etc. But the main point is that I, a GUI author, am first in line of the queue of people that are not willing to do the guess work for it. If engines do not announce their options, it is an engine problem. Sending them 'threads' in that case is nothing else than a blind first guess.

For some UCI/UCCI engines, maybe they think announcing "max threads#" means nothing much because the real max threads# depends on the system limitation. For example, announcing max threads# 32 means nothing on a 4 cores system.

Not really. Most SMP engines faithfully obey the number of threads, and would use 32 threads on a 4-core system if ordered to do so. That this is rather detrimental to performance, because 8 threads will be competing for a single core, is the user's own fault. It is up to the user to determine what works best on his hardware. Especially now that there is Hyper Threading it is not so obvious whether you should use 4 or 8 threads on a quad like the Intel i7. Compare this with hash size; also there it is possible to ask for a larger hash table than the amount of physical RAM in your system, with an even more dramatic drop in performance when the engine starts to use disk for storing it.

On the other hand, if it hard codes and announces the max threads# is 4 or 6 due to their test results but later finds out it's working well on the newly released 8 or 12 cores systems, do they have to recompile another one? Therefore, maybe the simple and the best way is not to announce something they are not sure about but to allow GUIs to use standard setoption commands to invoke options.

The problem is that maximum number of threads is usually a property of the program, because it reserves tables of a fixed size to store information about the threads. So then there is indeed no other way to increase the number of threads over the maximum other than enlarging the tables in the source code, and recompile. The max parameter on the option command is supposed to reflect this tablesize. A sloppily written engine might crash if you ak for more threads than the max it specified, because it would oveflow the tables. This should be considered the GUIs fault. (Not that I test that in UCCI2WB, now...) Test results should really only be used to determine the default value of the parameter. And when the Threads option was still appearing in Engine Settings (as, btw, it would for most other GUIs, such as Shredder or Arena), the default value is of importance, as in general WB only sends setoption commands for options that it thinks you have changed.

When set to use 4 cores, BHGUI sends "setoption name Threads value 4" to the engines right away, but WBGUI doesn't send anything to the engines even after I tried to use this DefectiveEngineOptions.ini workaround method. Isn't that a little discouraging? All BHGUI did was using standard methods to faithfully invoke all options set by users via its GUI.

Those are several questions at once. For one, it is very bad, almost criminal, that BHGUI does this. Whoever decided to do that carries most of the responsibility for there being so many crappy UCCI engines today. Second point: yes, it is discouraging if WB does not send anything even with the DefectiveEngineOptions.ini work-around, because it was designed to do so. If things do not work as designed, this really doesn't say anything about the design though. Other designs that do not work as designed will not necessary perform better or even different. Because in the end the only thing that matters is how it works, not how it was designed.

I am a bit surprised that you say it does not work, though: for me it works without problems.

For UCI engines, the standard method to set Hash and Threads is --

Code: Select all

setoption name Threads value x
setoption name Hash value yyy

Well, I only know 3 Xiangqi UCI engines (Cyclone, ggChess and Shiga). where Cyclone and ggChess seem fully compliant (and so would automatically get those commands on a GUI that implements the protocol correctly), and only Shiga needs a work-around (which in any case would include removing its Shiga.ini file). The 100-or-so UCI Chess engines, however, in general do not use 'Threads', mut many different other options (maxcpus, maxthreads, nthreads, searchthreads...).

For UCCI engines, the standard method to set Hash and Threads is --

Code: Select all

setoption name Threads value x
setoption name Hashsize value yyy

We has seen this in UCI engines. If you want to verify the case for UCCI engines, you can make a spy4ucci.exe and I can operate the Chinese BHGUI to capture a trace for examining. Perhaps I may try to modify your original spy.exe source code to make a UCCI edition like this:
....
Does this spy4ucci source code look OK with the line I marked removed? Is your spy.exe compiled by C# or C++?

Indeed, this looks OK. I will make an UCCIspy.exe later, as this is virtually no work. Note, however, that the most urgent problem is to understand why WinBoard/UCCI2WB configured by the DefectiveEngineOptions.ini to do so would NOT send these very same commands to the engine as as BHGUI does. As for me the winboard.debug clearly shows that it does:

recognized 'xiangqi' (-1) as variant xiangqi
recognized 'xiangqi' (-1) as variant xiangqi
WinBoard 4.7.20121129 + ANITA
Reset(1, 0) from gameMode 0
recognized 'xiangqi' (-1) as variant xiangqi
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir=".") UCCI2WB -noini "C:\cygwin\home\xq\engines\anita\ANITA.EXE"
nice engine proc to 10
751 >first : xboard
protover 2
801 <first : UCCI2WB 1.8 by Morning Yellow and H.G.Muller
801 <first : # to engine : ucci
801 <first : # from engine: option Threads default 1 min 1 max 4
801 <first :
801 <first : # from engine: protocol UCCI
801 <first : # from engine: id name anita 0.2
801 <first : # from engine: id copyright 2006 - 2006
801 <first : # from engine: id author ÌÕÉÆÎÄ
801 <first : # from engine: id user Unknown User
801 <first : # from engine: id birth Jun 15 2006 10:27:00
801 <first : # from engine: copyprotection OK
801 <first : # from engine: ucciok
801 <first : # from engine: option name Hash type spin default 16 min 4 max 1024
801 <first : # from engine: option name Ponder type check default false
811 <first : # from engine: option name BookFile type string default book.dat
811 <first : # from engine: option name NullMove Reduction type spin default 2 min 1 max 3
811 <first : # from engine: option name History Pruning type check default true
821 <first : feature myname="anita 0.2 (UCCI2WB)"
821 >first : accepted myname
821 <first :
821 <first : feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1 smp=1
821 >first : accepted variants
821 >first : accepted setboard
821 >first : accepted debug
821 >first : accepted reuse
821 >first : accepted memory
821 >first : accepted smp
821 <first : feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 done=1
821 >first : accepted usermove
821 >first : accepted sigint
821 >first : accepted sigterm
821 >first : accepted colors
821 >first : accepted pause
821 >first : accepted done
831 >first : memory 68
831 >first : cores 1
831 >first : new
random
831 >first : variant xiangqi
831 >first : level 40 5 0
831 >first : post
831 >first : hard
Impossible move , type = 0
841 <first : # to engine : setoption threads 1
841 <first : # to engine : setoption newgame
15122 >first : cores 2
Reset(1, 1) from gameMode 0
recognized 'xiangqi' (-1) as variant xiangqi
GameEnds(0, (null), 2)
15132 >first : quit
shuffleOpenings = 0
StartChildProcess (dir=".") UCCI2WB -noini "C:\cygwin\home\xq\engines\anita\ANITA.EXE"
nice engine proc to 10
15673 >first : xboard
protover 2
15673 >first : memory 68
15673 >first : cores 2
15673 >first : new
random
15673 >first : variant xiangqi
15673 >first : level 40 5 0
15673 >first : post
15673 >first : hard
Impossible move , type = 0
15703 <first : UCCI2WB 1.8 by Morning Yellow and H.G.Muller
15703 <first : # to engine : ucci
15703 <first : # from engine: option Threads default 1 min 1 max 4
15703 <first :
15703 <first : # from engine: protocol UCCI
15703 <first : # from engine: id name anita 0.2
15703 <first : # from engine: id copyright 2006 - 2006
15703 <first : # from engine: id author ÌÕÉÆÎÄ
15703 <first : # from engine: id user Unknown User
15703 <first : # from engine: id birth Jun 15 2006 10:27:00
15703 <first : # from engine: copyprotection OK
15703 <first : # from engine: ucciok
15703 <first : # from engine: option name Hash type spin default 16 min 4 max 1024
15703 <first : # from engine: option name Ponder type check default false
15703 <first : # from engine: option name BookFile type string default book.dat
15703 <first : # from engine: option name NullMove Reduction type spin default 2 min 1 max 3
15703 <first : # from engine: option name History Pruning type check default true
15733 <first : feature myname="anita 0.2 (UCCI2WB)"
15733 >first : accepted myname
15743 <first :
15743 <first : feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1 smp=1
15743 >first : accepted variants
15743 >first : accepted setboard
15743 >first : accepted debug
15743 >first : accepted reuse
15743 >first : accepted memory
15743 >first : accepted smp
15743 <first : feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 done=1
15743 >first : accepted usermove
15743 >first : accepted sigint
15743 >first : accepted sigterm
15743 >first : accepted colors
15743 >first : accepted pause
15743 >first : accepted done
15743 <first : # to engine : setoption threads 2
15743 <first : # to engine : setoption newgame
nps: w=-1, b=-1
nps: w=-1, b=-1
19228 >first : time 30000
19228 >first : otim 30000
book hit = (NULL)
19228 >first : usermove 19228 >first : e3e4
19328 <first : # to engine : position fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR w - - 0 1 moves e3e4
19328 <first : # to engine : go time 299 movestogo 40
19348 <first : # from engine: info searching openbook...
19348 <first : # from engine: info depth 0
19568 <first : # from engine: info load move from book book.dat fail
20129 <first : # from engine: easy search time is 561
20129 <first : # from engine: info depth 1
20129 <first : # from engine: info depth 1 seldepth 14 score 4 time 561 nodes 495540 pv b7e7
20129 <first : 1 4 56 495540 b7e7
20129 <first : # from engine: info depth 1 seldepth 14 score 8 time 561 nodes 495547 pv b9c7
20129 <first : 1 8 56 495547 b9c7
20139 <first : # from engine: info seldepth 14 time 561 nodes 495594 nps 0
20139 <first : # from engine:
20139 <first : # from engine: info depth 2
20139 <first : # from engine: info depth 2 seldepth 14 score -1 time 561 nodes 495676 pv b9c7 b0c2
20139 <first : 2 -1 56 495676 b9c7 b0c2
20139 <first : # from engine: info depth 2 seldepth 14 score 0 time 561 nodes 495991 pv b7e7 b2e2
20139 <first : 2 0 56 495991 b7e7 b2e2
...
20870 <first : # from engine: info seldepth 16 time 1302 nodes 1041845 nps 800188
20880 <first : # from engine:
20880 <first : # from engine: info depth 9
20880 <first : # from engine: info currmove h7e7 currmovenumber 1
21681 <first : # from engine: info time 2003 nodes 1700000 nps 848727 cpuload 1000
GameEnds(28, xboard exit, 2)
21681 >first : result * {xboard exit}
21681 >first : quit

[cnchang]

Indeed, this looks OK. I will make an UCCIspy.exe later, as this is virtually no work. Note, however, that the most urgent problem is to understand why WinBoard/UCCI2WB configured by the DefectiveEngineOptions.ini to do so would NOT send these very same commands to the engine as as BHGUI does. As for me the winboard.debug clearly shows that it does

No, my spy4ucci is not working. Actually, it won't even compile:

Code: Select all

Turbo C++ Version 3.00 Copyright (c) 1992 Borland International
spy4ucci.cpp:
Error spy4ucci.cpp 31: Function 'strcmp' should have a prototype in function main(int,char * *)
Warning spy4ucci.cpp 39: 'x' is assigned a value that is never used in function main(int,char * *)
*** 1 errors in Compile ***

until I add this:

Code: Select all

#include <string.h>

Then, it compiled and generated an executable. However, this spy4ucci.exe got rejected by BHGUI, saying this UCCI engine not valid.
For a comparison, I went back to compile your spy.exe from the source you posted on page#2. Again, I needed to add "string.h" to compile it, but it also failed to act and accepted by BHGUI as an UCI engine this time. Are you sure the source you posted there is not an older version?

I suppose your winboard.debug shows what is going on between GUI and adapter. To see if the setoption command really passed to engines, why not use spy log?

Those are several questions at once. For one, it is very bad, almost criminal, that BHGUI does this. Whoever decided to do that carries most of the responsibility for there being so many crappy UCCI engines today. Second point: yes, it is discouraging if WB does not send anything even with the DefectiveEngineOptions.ini work-around, because it was designed to do so. If things do not work as designed, this really doesn't say anything about the design though. Other designs that do not work as designed will not necessary perform better or even different. Because in the end the only thing that matters is how it works, not how it was designed.

I am a bit surprised that you say it does not work, though: for me it works without problems.

I have never encountered BHGUI crashing any engine when it just sends user's settings regardless if there are defined max Hash size or max Thread# to take care of. Engine simply won't allow BHGUI to bring it down. Any example to show your worried impact has ever happened?
When you said it(i.e., the pair of WinBoard and DefectiveEngineOptions.ini) works without problems, which UCI engine did you test to successfully set Threads#?

Regarding adhering to the design standard, I'd really like to discuss with UCI charter members on:
(1)why it is mandantory for engines to announce all options? BHGUI proves it is not necessary, and sometime, like setting up a tourney, it is better put the control back to users and GUI and let engines to accommodate with the game rule as best as it can.
(2)Why GUI can arbitrarily decide whether to send user's GUI game settings but not let engine decide whether it can cooperate to certain extent?
(3)With multi-core systems getting so common today, why not patch their standard for this SMP consideration?
But, you said that UCI project is pretty much "dead". Therefore, no one is responsible for answering those questions.

[H.G.Muller]

Note that the Spy program was plain C, not C++. This probably causes the compile errors.

Unlike UCI2WB, UCCI2WB relays everything that is sent to or received from the engine also to the GUI (as "# from engine" and "# to engine" lines), so it should in principle provide us with the same info as spy.exe could. The latter ius only important to spy on a GUIthat does not provide this info, such as BHGUI or ShigaGUI.

[Edit] I uploaded a http://hgm.nubati.net/UCCIspy.exe , where I replaced uci with ucci everywhere. I had to delete the Chinese author name, as it somehow coalesced with the following linefeed, causing the next output to appear on the same line. Anyway, this should now simulate a UCCI engine which does not annoounce any option at all, not even 'usemillisec'.

[cnchang]

Just downloaded UCCISpy, and it failed to load in BHGUI. May I know your C compiler?
Even if your C compiler doesn't need to explicitly include <string.h> in the main, but why am I getting another warning message like this:

Code: Select all

Warning spy4ucci.cpp 39: 'x' is assigned a value that is never used in function main(int,char * *)

Do you have a compile log to compare with my compilation warning?

I posted the fake cyclone62's spy log yesterday to show you setoption command never sent by WBGUI to engines for Threads#, can you show me if any faked UCI engine has ever received WBGUI's "setoption name Threads ..." in your spy log?

[H.G.Muller]

Regarding adhering to the design standard, I'd really like to discuss with UCI charter members

Well, there isn't any such thing as a UCI charter. UCI is a take-it-or-leave-it deal by one commercial author, (of the Shredder engine and GUI), designed to fit his needs. He made the formal specs of the protocol he uses public, but that is about all.
I can tell you what I would answer to your questions, however...

on:
(1)why it is mandantory for engines to announce all options? BHGUI proves it is not necessary, and sometime, like setting up a tourney, it is better put the control back to users and GUI and let engines to accommodate with the game rule as best as it can.

The system BHGUI uses in deviation of the standard is inferior, because it leaves the GUI unaware of the limits of the standard options. So the user can never be warned if he tries to start a game with a hash size or thread number that is not supported by one of the engines, but is nby the other, so that he might be playing biased games without knowing it.
For non-standard options the BHGUI system would not work at all, as it could never guess what commands the engine can respond to.
Engines typically have dozens of non-standard options, so announcing one or more standard options in addition can hardly be considered a burdon on the engine programmer. In fact treating standard and engine-specific options on the same basis highly simplifies his task. UCI engines typically handle options through a table-driven parser, so that the only thing needed to add fully compliant handling of a new option to the engine is mentioning its name, type and the internal variable which it should set in the table of options. This would then automatically cause both announcing of the option, as well as recognizing and processing the corresponding setoption command. It would require extra code to have different handling of standard and engine-specific options, which means extra work for both engine and GUI author.

(2)Why GUI can arbitrarily decide whether to send user's GUI game settings but not let engine decide whether it can cooperate to certain extent?

Not sure what you are asking here, or if the question does not spring from a misconception. What do you mean by 'not letting the engine dicide whether it can cooperate'? Isn't this exactly what standard UCI does, 'letting the engine decide'? The engine determines which options the GUI is allowed to send, and which the valid ranges for their values are. SO compliant GUIs would not 'arbitrarily' send any settings at all. It is BHGUI that arbitrarily sends hashsize and threads commands to engines that might not even support them or support the requested value.

(3)With multi-core systems getting so common today, why not add their standard for this SMP consideration?

This I actually asked to the Shredder author, and he replied that he did not think this very useful, m as users could set the number of threads from the Engine Settings dialog of Shredder GUI, where they had to set all the other options anyway. There the user would see the name of the option no matter what it was, and probably engine authors would pick a name that was intuitively clear. Shredder GUI does not have something similar to the WB Cmmon Engine dialog. He thought it an advantage that you could set the number of threads for each engine separately. When I pointed out that this was very inconvenient when you wanted to have a large engine tourney using 2 CPUs when last time you had set all the participants to 4 CPUs, he sort of shrugged, and said that almost none of the Shredder users wanted to do such things.

[H.G.Muller]

Just downloaded UCCISpy, and it failed to load in BHGUI. May I know your C compiler?

I am using gcc under Cygwin.

I posted the fake cyclone62's spy log yesterday to show you setoption command never sent by WBGUI to engines for Threads#, can you show me if any faked UCI engine has ever received WBGUI's "setoption name Threads ..." in your spy log?

I think this is because at that time you were still using a version of UCI2WB that did not connect the WB cores option to any particular UCI option, and thus referred the Threads option to the Engine Settings dialog, like Shredder GUI does. And you probably did not try to set the number of threads from that dialog, so WB did not have any reason to send a 'setoption Threads' command. I am pretty sure that when you would use the UCI2WB that I uploaded in reaction to you figuring out Cyclone uses Threads, you would see the setoption for Threads in response to the Common Engine setting.

For me it works with spy.exe as Shiga simulator (using DefectiveEngineOptions.ini to fake it sends 'option name Threads ...'):

Code: Select all

0. Shiga.exe
out: max threads set to 2
out: XQMS 3.26_10_19. By  ¢»Í¥+¶íói++÷.
in:  uci
out: id name XQMS 3.26_10_19
out: id author ¢»Í¥+¶íói++÷.

out: uciok

out: XQMS Use uci[ucci] protocol
in:  setoption name Threads value 2
in:  setoption name Hash value 68
in:  isready
out: readyok
in:  ucinewgame
in:  isready
out: readyok
in:  fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR r moves e3e4
in:  go btime 300000 wtime 300000 movestogo 40
in:  fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR r moves e3e4
in:  go btime 300000 wtime 300000 movestogo 40
in:  quit


and the same run seen from the winboard.debug file, where I used a specially adapted version of the latest UCI2WB that tells the GUI when it sets the Threads option (which it normally would not report, even in debug mode; UCI2WB reports only what it receives from the engine).

Code: Select all

1893 <first : # fake engine input
1893 <first : # engine said: option name Hash type spin default 512 min 16 max 512
1893 <first : # engine said: option name Threads type spin default 1 min 1 max 8
1893 <first : # end fake
1943 <first : feature variants="normal,xiangqi" setboard=1 usermove=1 debug=1 ping=1 reuse=0 exclude=1 pause=1 done=0
1943 >first : accepted variants
1943 >first : accepted setboard
1943 >first : accepted usermove
1943 >first : accepted debug
1943 >first : accepted ping
1953 >first : accepted reuse
1953 >first : accepted exclude
1953 >first : accepted pause
1953 >first : accepted done
1953 <first : feature option="UCI2WB debug output -check 1"
1953 >first : accepted option
1953 <first : # engine said: max threads set to 2
1963 <first : # engine said: XQMS 3.26_10_19. By  ¢»Í¥+¶íói++÷.
1963 <first : # engine said: id name XQMS 3.26_10_19
1963 <first : feature myname="XQMS 3.26_10_19 (UCI2WB)"
1963 >first : accepted myname
1963 <first : # engine said: id author ¢»Í¥+¶íói++÷.
1963 <first : # engine said:
1973 <first : # engine said: uciok
1973 <first : feature smp=1 memory=1 done=1
1973 >first : accepted smp
1973 >first : accepted memory
1973 >first : accepted done
1973 <first : # engine said:
1973 <first : # engine said: XQMS Use uci[ucci] protocol
1983 >first : memory 68
1983 >first : cores 2
1983 >first : new
random
1983 >first : variant xiangqi
1983 >first : level 40 5 0
1983 >first : post
1983 >first : hard
1983 >first : ping 1
Impossible move , type = 0
2003 <first : # setoption name Threads value 2
2003 <first : # engine said: readyok
2003 <first : # engine said: readyok
2003 <first : pong 1
nps: w=-1, b=-1
nps: w=-1, b=-1
3916 >first : time 30000
3916 >first : otim 30000
book hit = (NULL)
3916 >first : usermove 3916 >first : e3e4
4006 <first : # start search
4006 <first : # fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR r moves e3e4
4006 <first : # go btime 300000 wtime 300000 movestogo 40


[cnchang]

I tested Spy.exe playing as Shiga.exe in Winboard with DefectiveEngineOptions.ini content like this:

Code: Select all

option name Hash type spin default 64 min 16 max 512
option name threads type spin default 2 min 1 max 8
option name Ponder type check default true

I am using the latest beta uci2wb.exe. SHA256#: 64f7ceae718c1a905e89e5aca3797d7b07e304eff55aec809c4e0032bed5ef0f
My spy.exe, and later renamed to Shiga.exe, is SHA256#: 6677c1435ef564f0f5d095245e79298f6b0397069ad50f63b3dcf9db6db63106
This is the log.txt collected by spy.exe when I set the faking Shiga to use 256/2.
In this captured trace, there is no Threads# settings sent out from GUI. Not sure why your spy trace captured from Winboard has that. Can you tell me what I missed?

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:  setoption name Hash value 260
in:  isready
out: readyok
in:  ucinewgame
in:  isready
out: readyok
in:  quit

Why do you put "max threads set to 2" in your spy.exe, as you can see the first line outcome in the trace, to hinder yourself from testing 4 threads?

This is what spy.exe captured in BHGUI when I set the faking Shiga spy to use 512/4. You can see BHGUI sent out GUI settings on both Hash and Threads.

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
in:  setoption usebook false
in:  setoption useegtb false
in:  setoption threads 4
in:  setoption hashsize 512

This is what spy.exe captured in Shijia's own GUI, ShiGaGui.exe.
As you can see Shiga's own GUI is not sending any setoption commands.
This version's Shiga GUI is designed to use Shiga.ini only, even though it may be applicable in another version.

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:  setoption name Ponder value true
in:  isready
out: readyok

Let's put the design philosophy aside, there are two major issues remaining:
1. the latest UCCIspy.exe doesn't work in BHGUI -> Thus, we can't confirm that BHGUI unilaterally send out setoption commands to engines per user's preferences regardless what engines announced.
* I am still trying to install Cygwin with gcc. Even though there is a chance this gcc compiler doesn't need to explicitly include <string.h>, but I wonder it will eliminate my TurboC's warning "spy4ucci.cpp 39: 'x' is assigned a value that is never used in function main(int,char * *)".
2. You and I have experienced totally different WBGUI behaviors on setting up UCI's Threads#. I just don't see this line in my spy generated trace:

Code: Select all

in:  setoption name Threads value 2

[H.G.Muller]

I guess the problem is that in the DefectiveEngineOptions.ini 'threads' is not spelled with a captital T. Perhaps UCI2WB should really use a case-insensitive compare routine to test if an announced option is 'Threads', because officially UCI is case insensitive. There is no guarantee, however, that non-compliant engines would be compliant in this respect. As BHGUI seems to send 'Threads' with a capital T, it is thus safer to force the user to specify a capital T in DefectiveEngineOptions.ini as well. Because UCI2WB will use exactly the same string to set options as it received in the announcement. So recognizing both 'threads' and 'Threats' as an option to set the thread# could be asking for trouble. Both Cyclone 6.2 and ggChess announce 'Threads' with a capital, so there seemed no need to recognize anything else.

As to the "max threads set to 2":
spy.exe says this because Shiga says this, and spy.exe was originally an exact Shiga simulator. This is not UCI, however, just a non-compliant exclamation by the engine, which normally would be ignored by any GUI. Like the "QMS 3.26_10_19 by ...", which also has no meaning. One presumes that Shiga prints such things, rather than relying on the compliant "id name", "id author" commands that follow, because it can also run in an own, native protocol which would never send the latter commands.

UCI2WB will certainly ignore the "max threads set to 2" thing, as it does not recognize a valid UCI keyword at the beginning. So the fact that spy.exe prints this should not do any damage. It is an indication that "option name Threads type spin default 2 ..." would be the correct option to fake, however. Which would be important to GUIs that put the Threads option in the Engine Settings, and might not send a 'setoption' to the engine when the user sets it to 1 while the GUI was made to believe it already was 1 (while in fact it stated as 2).

From you post it seems BHGUI sends a whole lot of other unsollicited setoption stuff. It even sends UCCI commands to UCI engines. Very bad practice... An UCCI engine that supports an option 'name' would get its name altered to 'Hash'!


It is indeed remarkable that ShigaGUI doesn't make an attempt to set the threads. Pehaps it waits with this until you actually set the engine searching. Or perhaps it did notes the "max threads set to 2" remark, and wants to run the engine with 2 cores by coincidence (or perhaps always tries to run the engine at its default settings by default), so that it does not feel the need to set anything. This is exactly what Shredder GUI would do, and WinBoard when the Threads option was still defered to the Engine Settings: the GUI would initially be set to the engine default, because it has no pior concept of what the engine options mean, and thus no preference by itself for any value. Only when the user changes the value through the dialog, the GUI would feel the need to send a 'setoption' command.

Have you tried altering the number of threads in the Shiga GUI after loading spy.exe, but before starting a game? Does the tue Shiga engine react to such changes (in absence of Shiga.ini)? Or does the Shiga GUI not allow the user to change this setting interactively at all? That could also be an explanation: perhaps ShigaGUI is not a GUI that supports SMP. (And that this is why Shiga engine relies on a Shiga.ini file for its settings.)

[H.G.Muller]

Let's put the design philosophy aside, there are two major issues remaining:
1. the latest UCCIspy.exe doesn't work in BHGUI -> Thus, we can't confirm that BHGUI unilaterally send out setoption commands to engines per user's preferences regardless what engines announced.

Well, I can make an UCCIspy.exe that exactly simulates Anita's output. I suppose Anita does work in BHGUI...

* I am still trying to install Cygwin with gcc. Even though there is a chance this gcc compiler doesn't need to explicitly include <string.h>, but I wonder it will eliminate my TurboC's warning "spy4ucci.cpp 39: 'x' is assigned a value that is never used in function main(int,char * *)".

The main problem could be that you use a .cpp suffix on a C file, rather than .c, making the compiler think it is a C++ program, and use C++ headers and libraries rather than the regular C headers. The problem might go away in your current compiler if you rename the file to spy4ucci.c. I don't know C++, so I cannot say whether <sting.h> is a standard header file there.

2. You and I have experienced totally different WBGUI behaviors on setting up UCI's Threads#. I just don't see this line in my spy generated trace:

Code: Select all

in:  setoption name Threads value 2

Well, our postings seem to be crossing. Have you already tried capitalizing it?

[cnchang]

You nailed one. It is the "Threads" not "threads" that will trigger WinBoard GUI to send setoption name Threads ...
Oddly enough, I don't recall why I put that lower case "threads" together with other capitalized options; I checked my USB drive for the original version DefectiveEngineOptions.ini. It is shown as Threads there.
But, If name Threads must start with capital T, why many UCCI engines spell out "option threads type spin ..." once received "ucci" command? Why lower case here?

[H.G.Muller]

Oh sorry, my mistake!

I forgot to use the option -mno-cygwin when compiling UCCIspy.c. So I got and upload an exe that can only run in presence of the Cygwin1.dll library, which for me was no problem, as I tested it under Cygwin. I have uploaded a new one now, that should un on a bare Windows. It does simulate Anita.

Btw, I noticed that Anita's output is also quite non-compliant: it writes 'ucciok' BEFORE sending all these 'option' commands!

[H.G.Muller]

You nailed one. It is the "Threads" not "threads" that will trigger WinBoard GUI to send setoption name Threads ...
Oddly enough, I don't recall why I put that lower case "threads" together with other capitalized options; I checked my USB drive for the original version DefectiveEngineOptions.ini. It is shown as Threads there.
But, If name Threads must start with capital T, why many UCCI engines spell out "option threads type spin ..." once received "ucci" command? Why lower case here?

Since all UCCI engines seemed to respond to 'threads', I saw no reason to echo it the option as it receives it, and just hard-coded 'threads' in the printf towards the engine. Furthermore, UCCI2WB defines its own StrEqvSkip comparison routine, which does seem to be case insensitive. (It must be defined somewhere in the Elephant Eye sources, which are partly linked to UCCI2WB.)

In UCI2WB this is different. Remember that UCI2WB also has to work for all Chess and Shogi engines, which use a wide variaty of option names for setting thread#.

[cnchang]

After changed spy.cpp to spy.c and removed " include <string.h>" then compiled it with tcc (TurboC), no error reported this time but warning persists.

Code: Select all

 'x' is assigned a value that is never used in function main

I believe it refers to this part of the spy source code:

Code: Select all

while(1) {
   int i=0, x;
   char line[1000], command[100];

   fflush(stdout);
   while((line[i] = x = getchar()) != EOF && line[i] != '\n') i++;
   line[++i] = 0;

In addition to the warning, my recompiled spy.exe, from your posted source code, simply won't work. It won't make GUI believe it as a UCI engine.

I will try your new UCCIspy Saturday afternoon.

[H.G.Muller]

Well, I guess the warning is correct, but pretty harmless. I sort copied that code from UCI2WB, and there the vaiable x, which remembered the latest input, is later tested for end-of-file to break out of the surrounding loop:

Code: Select all

   i = 0; while((x = getchar()) != EOF && (line[i] = x) != '\n') i++;
   line[++i] = 0; if(x == EOF) { printf("# EOF\n"); exit(-1); }
   sscanf(line, "%s", command);


Spy.exe usually terminates because it is send a quit command from the GUI, though. It could be that it doesn't stop now when the GUI crashes, getting stuck in a loop where it reads EOF for ever, without giving output (which would make it die if the GUI is no longer there to receive the output), running as a rogue background program.

It is difficult to guess why BHGUI would not recognize my Shiga-like UCCIspy.

[cnchang]

Would there be any difference between the original sort-of-copied-from-uci2wb source code and this one(i.e., taking "x" out of the equation):

Code: Select all

while(1) {
   int i=0;
   char line[1000], command[100];

   fflush(stdout);
   while((line[i] = getchar()) != EOF && line[i] != '\n') i++;
   line[++i] = 0;

[H.G.Muller]

That would be the same, but if you want to fundamentally repair it, it would be better to add the line

if(x == EOF) exit(0);

rather than delete the x. That should also get rid of the warning, and then the program would not hang eating CPU when a GUI fails to send 'quit' before exiting.

[cnchang]

Tested UCCIspy sitting in for Anita and XQspirit. It proves BHGUI just sends out setoption commands unconditionally to UCI/UCCI engines after spy.exe and UCCIspy.exe tests.

Code: Select all

out: protocol UCCI
in:  ucci
out: id name anita 0.2
out: id copyright 2006 - 2006
out: id author 夷+?-
out: id user Unknown User
out: id birth Jun 15 2006 10:27:00
out: copyprotection OK
out: ucciok
out: option name Hash type spin default 16 min 4 max 1024
out: option name Ponder type check default false
out: option name BookFile type string default book.dat
out: option name NullMove Reduction type spin default 2 min 1 max 3
out: option name History Pruning type check default true
in:  isready
out: readyok
in:  setoption usemillisec true
in:  setoption repetition asianrule
in:  setoption drawmoves 100
in:  setoption usebook false
in:  setoption useegtb false
in:  setoption threads 4
in:  setoption hashsize 512
in:  setoption usebook false
in:  setoption useegtb false
in:  setoption threads 4
in:  setoption hashsize 512

I may consider adding your recommended extra lines for a fundamental fix later.
But, to keep things simple and to make as little change as possible from your original codes, I just removed the "x" factor from the equation, and it went thru compilation without warnings and errors.

Code: Select all

Turbo C++ Version 3.00 Copyright (c) 1992 Borland International
spy.c:
Turbo Link  Version 5.0 Copyright (c) 1992 Borland International
        Available memory 4091888

But this successfully compiled executable is still not accepted by BHGUI or WBGUI as a valid UCI engine.
It seems like cygwin will be my next stop.
I assume gcc is contained in the default minimal base Cygwin packages install.

[H.G.Muller]

Indeed, BHGUI seems to send a lot of unsollicited stuff. Some of it in duplicate. Did you press New Game or anything like that, that might have triggered it to send the threads/hash/bookstuff again? The usemillisec / repetition rule is only sent once. And the UCI Hash and Threads options are not send at all, now. So it must have some sort of an idea that it is dealing with a UCCI engine now, and alte its behavior accordingly. In paticular, it starts sending 'ucci' rather than 'uci', which it did towards Cyclone 6.2. The only thing it has seen at that time from 'Anita' is the line "potocol UCCI". So it seems that it uses this line as if it wee some sort of 'meta-potocol' command from the combined UCI/UCCI potocol, to identify the protocol. I don't think every UCCI engine sends this line, though. Perhaps it has special code built in to recogize the initial non-compliant utterances of all known engines, and act according to that.

Installing Cygwin is a bit of a pain. Gcc is NOT included in the base install. When you run the Cygwin Setup.exe, you should explicitly select it (and binutils) in the "devel" section.

It seems it is only the Turbo C compile that BHGUI rejects. Can you run this compile from the command prompt? And can you run it from the command prompt when you are in a different directory? It could be that executables made with Turbo C are dependent on a DLL with library functions, which it cannot find when run from BHGUI, because it is not installed system-wide. The same happens in Cygwin gcc, when you forget to add the compiler flag -mno-cygwin. It will then need the file Cygwin1.dll in the same directory, or it will exit with the complaint it cannot find it. With -mno-cygwin it will use the MicroSoft msvcrts.dll (the run-time system of MicroSoft Visual C), which is available system-wide in a standard Windows install. (But alas, is not compatible with Cygwin1.dll, as it provides Windows API rather than a Linux-like API. As long as you stick to standard functions as fprintf, this is no problem, though.)