UCI protocol in winboard

[Engin]

wow, i dont expect that the thread now be so long!

anyway, the main wish was simply to implement the UCI protocol directly to winboard, because a little lag between the engine, adapter and GUI.

the other problem is the cumbersome to install Winboard engines with they unstandard (worse) ini files, and configuration by hand, and this is not easy for non-experts.

by UCI engines this is no problem, because the GUI tell the engine, "wich option are you have?" , the engine answer this "i have this options....", the GUI tell the user this options and the user can select what he will do, the GUI tell then the option wich user is selected to the engine, now the engine knows witch options are use, eg. where the path of nalimove egtbs or book is.

i will say that UCI engines are more USER friendly then the winboard engines are is, but that can not the GUI solve only, there must be a communication between GUI and winboard engines wich options the engine have that tell the GUI.

its need to add to the WB protocol the options wich the engines have without a INI file.

[Teemu Pudas]

its need to add to the WB protocol the options wich the engines have without a INI file.

Already done (see "feature option=NAME").

[H.G.Muller]

.Once I got Rybka running, I noticed it was using only one CPU. Engine #1 Settings... doesn't have the expected Max CPUs parameter - the only place where I found one was in Global Settings.

Indeed the max number of CPUs is a global setting in WinBoard. IMO this is preferable over having to set them individual. Your point is noted that a global value needed for tournaments is likely to be different from one desirable for analysis. But even then the price you pay for this, namely having to change the setting back to the the tournament value when you start the tournament seems very small compared to the need to set 30 individual values when you change from a ponder-on to a ponder-off tournament, or a single-CPU versus SMP tournament. And the recommended use of WinBoard would be such that as game analyzer you would run it through a shortcut that would specify this value, and would suppress saving the settings on exit. SO you could specify the max-CPUs parameter there to a value suitable for analysis.

You do have a point, though. There's a bunch of options that masquerade as commands and/or "features": memory, variant, hard/easy, egtpath, post/nopost, nps, computer, rating, name, sd, st, ics, reuse. Adding a normal option to my engine is one line of code (plus whatever non-default handler function I may need to write). Adding a "feature <name>" option already requires supporting a different syntax.

It seems like "feature option=NAME" is intended for 'unsupported' options; all the others have some sort of special handling from Winboard. From an engine's perspective, though, they are all just options. UCI makes this distinction (for the most part. sigh) by prefixing option names with UCI_, which is infinitely better IMO.

Well, WinBoard protocol is burdoned with legacy commands, there is little that can be done about that. I don't see the ínfinitely better' thing, though. UCI prefixes standard options with "UCI_". WinBoard prefixes non-standard options with "option ". Seems exactly the same thing to me.

[H.G.Muller]

anyway, the main wish was simply to implement the UCI protocol directly to winboard, because a little lag between the engine, adapter and GUI.

Well, I don't believe a significant lag exists. Saving a few micro-seconds per games does not justify a major redesign effort. Of course I would not do it anyway, because I don't even know UCI, and don't intend to learn it.

the other problem is the cumbersome to install Winboard engines with they unstandard (worse) ini files, and configuration by hand, and this is not easy for non-experts.

This is indeed an unrelated problem, and it can only be solved by the engine authors. When they all use WinBoard option commnds to set the engine parameters, the problem will have disappeared.

by UCI engines this is no problem, because the GUI tell the engine, "wich option are you have?" , the engine answer this "i have this options....", the GUI tell the user this options and the user can select what he will do, the GUI tell then the option wich user is selected to the engine, now the engine knows witch options are use, eg. where the path of nalimove egtbs or book is.

Well, in UCI engines that do not tell the GUI which options they have, but take the settings from an INI file in stead, it would be exactly as much of a problem. The question is not what the protocol offers, but how well the engine uses the protocol.

ill say that UCI engines are more USER friendly then the winboard engines are is, but that can not the GUI solve only, there must be a communication between GUI and winboard engines wich options the engine have that tell the GUI.

its need to add to the WB protocol the options wich the engines have without a INI file.

[Teemu Pudas]

Well, WinBoard protocol is burdoned with legacy commands, there is little that can be done about that. I don't see the ínfinitely better' thing, though. UCI prefixes standard options with "UCI_". WinBoard prefixes non-standard options with "option ". Seems exactly the same thing to me.

My gripe is that it uses a different syntax for them (e.g. option NAME[=VALUE] vs. NAME [VALUE]). The command for setting a standard option isn't always even the same as the name of the feature (egt->egtpath)!

[H.G.Muller]

I guess the syntax matter should be blamed on Michel, who one-sidedly added a delimiter to the option format in Polyglot. I am to blame for the fancy naming of the other features. But ths realy starts to become a bit like nitpicking. Who cares if it takes one or three lines of code to add an option. As long as they are trivial to add.

Remember the syntax is not optimized for developing an engine with a huge number of options from scratch, but to easily add the most necessary options to existing engines. Things like smp=1 or memory=1 are easily added in existing feature strings, next to all the other legacy options that are already there. to recognize a new command in most WinBoard engines only requires a single line like

Code: Select all

if(!strcmp(command, "cores")) sscanf(inputLine, "cores %d", &maxCPUs); else


I don't think it is worth fussing about how this could be done even simpler. Non-standard options could typically be parsed as

Code: Select all

if(!strcmp(command, "option")) {
    if(sscanf(inputLine, "option XXX=%d", &valueXXX) == 1) continue;
    if(sscanf(inputLine, "option YYY=%d", &valueYYY) == 1) continue;
    ...
}


Which also requires one line to print the feature command and one line to handle options to set parameters. If that is not totally trivial, I don't know what is...

[Teemu Pudas]

Code: Select all

const int &MyOption = make_option("MyOption", DEFAULT, MIN, MAX, &non_default_handler);

Obviously, this will only work if there's a consistent way to report and set options.

[Michel]

Michel, who one-sidedly added a delimiter to the option format in Polyglot.

Well at that time it wasn't clear what the syntax should be. Names and values of options can contain spaces so some extra characters are needed
to separate them. A single = sign seemed most economical. It matches the standard ini file syntax.

I brought up this issue at one point but I don't think we really discussed it.

[Daniel Mehrmann]

wow, i dont expect that the thread now be so long!
anyway, the main wish was simply to implement the UCI protocol directly to winboard, because a little lag between the engine, adapter and GUI.

I understand your view of point. I think programmers here missed a simple point:

Keep it simple as possible to avoid possible errors

Every professional programmer learn this in a company. Why is that so importent ?
Well, the uci-adapter is just an object which could produce error or more complications.
Fabien developed it because he wasn't familiar with the X-/Winboard code, otherwhise
we'll have native UCI support in winboard already

However, from a abstract view, every professional developer will tell you
that you should avoid any stuff of adaptation.

On the other side this is just hobby stuff.
So what, keep the people working....
I had/have my fun while reading this thread. :-P

Have-fun-with-crazy-new-winboard-stuff-greetings
Daniel

[H.G.Muller]

Well, Keep-it-simple = do-not-use-UCI...

[rigao]

Are winboard and polyglot both released under GPL license?

I guess winboard is, but is polyglot GPL too?

If it is so, then ppl complaining about the split, just need to make a fork to winboard which includes polyglot (or a fork of polyglot which includes winboard !?) . It wont be much difficult, if even just the two programs hidden under the same binary, as it is in gold pack in winboard...

Not that using it as it is presents us with much difficulties either, but who knows...

When the winboard package is updated in the ubuntu repositories, it would be advisable to ask for polyglot as an optional package, so ppl installing it w/o knowing anything will be adviced to install polyglot too, and after that, a simple help file under winboard is more than enough to explain how to use uci under winboard, maybe a couple of examples in the polyglot or winboard packages would be good. And some optional dependency with an UCI engine which would work out of the box, would be simply perfect. Dreaming is free, isn't it?

Oh, and please, don't forget the default engine as at least optional package, because it is really annoying that xboard hangs because it doesn't find the engine. It is a very newbie unfriendly behavior.

[Miguel A. Ballicora]

Are winboard and polyglot both released under GPL license?

I guess winboard is, but is polyglot GPL too?

If it is so, then ppl complaining about the split, just need to make a fork to winboard which includes polyglot (or a fork of polyglot which includes winboard !?) . It wont be much difficult, if even just the two programs hidden under the same binary, as it is in gold pack in winboard...

Not that using it as it is presents us with much difficulties either, but who knows...

When the winboard package is updated in the ubuntu repositories, it would be advisable to ask for polyglot as an optional package, so ppl installing it w/o knowing anything will be adviced to install polyglot too, and after that, a simple help file under winboard is more than enough to explain how to use uci under winboard, maybe a couple of examples in the polyglot or winboard packages would be good. And some optional dependency with an UCI engine which would work out of the box, would be simply perfect. Dreaming is free, isn't it?

Oh, and please, don't forget the default engine as at least optional package, because it is really annoying that xboard hangs because it doesn't find the engine. It is a very newbie unfriendly behavior.

I think xboard -ncp should be the default behavior if no engine is assigned.

Miguel

[H.G.Muller]

Well, the problem is that currently there is no way out of -ncp mode if you do want to use an engine, other than exit. And most of the time people do want to use an engine when they explicitly fire up XBoard, and do not specify ICS mode. If they merely want to view games they usually click the PGN, which then will invoke a batch file with the proper option settings.

If the only thing people can do to eventually get what they want is quit XBoard, we might as well have it do that automatically for them...

After we implemented loading engines from the regular menu, rather than only at startup, we will change the default behavior to -ncp.