Is it time for a new and improved UCI2WB adapter?

[Günther Simon]

Geschrieben von: / Posted by: Günther Simon at 12 March 2004 13:35:03:

The old one is nearly 3 years old now and the bugs and flaws
were collected here several times.
Also it allows only to set four UCI options:
hash, tablebase path, tablebase cache and style if available,
moreover setting up a log file is possible.
This is an example of how it looks for those who never
fiddled around with it:
#############################
#
# Adapter Resource Control
#
#############################
#
# Exe-Name
Name=Fruit 0.98b
exe=Fruit098b
#
# Directory
dir=C:\Winboard\Fruit_098b
#
# Hashtable size in MB (*not* for UCI)
Hash=128
# Tablebase Path (*not* for UCI)
# tbpath=D:\program files\shredder5\tb
tbpath=D:\sicherheit\chess\tbs
#
# Tablebase Cache in MB (*not* for UCI)
tbcache=8
#
# Style: Aggressive, Active, Normal, Solid
#Style=Active
#
logfile=yes
#
Additionally to the known bugs, it always starts the
move counter from zero, even if you use BookThinker
in front of it for the opening.
I think a lot of people would welcome a new and improved
UCI2WB adapter now. At least it would be a very nice to
have to.
If Fabien or perhaps Odd Gunnar have some time
and interest in accomplishing that task it would
be great IMHO.
What do you think?
Regards,
Günther

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 12 March 2004 13:41:30:
Als Antwort auf: / In reply to: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Günther Simon at 12 March 2004 13:35:03:

The old one is nearly 3 years old now and the bugs and flaws
were collected here several times.
Also it allows only to set four UCI options:
hash, tablebase path, tablebase cache and style if available,
moreover setting up a log file is possible.
This is an example of how it looks for those who never
fiddled around with it:
...
Additionally to the known bugs, it always starts the
move counter from zero, even if you use BookThinker
in front of it for the opening.
I think a lot of people would welcome a new and improved
UCI2WB adapter now. At least it would be a very nice to
have to.
If Fabien or perhaps Odd Gunnar have some time
and interest in accomplishing that task it would
be great IMHO.
What do you think?
Regards,
Günther

Gunther (UK keyboard here, no umlaut),
Yes I think too many bugs/limitations in existing ones (for instance I think Roland does not maintain a chess board so his adapter can't detect draws).
Right now I am busy giving Fruit the finishing touches (UCI support). I already use my own adapter on Linux (xboard Fruit). This very week-end I am going to add more UCI and xboard support to it, and test it with the few linux UCI engines I have got.
Next week, I will see with others (Dann?) how we can port it to windows and see how it does. It might be very primitive at first, we will see later.
I will start a thread next week about feature requests. For now it does not have .INI files (actually the engine name is hardcoded into the source code).
So I am thinking about Winboard/xboard users (I am one of them, no choice on Linux)!
Let's hope for the best,
Fabien.

[Günther Simon]

Geschrieben von: / Posted by: Günther Simon at 12 March 2004 14:08:21:
Als Antwort auf: / In reply to: Re: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Fabien Letouzey at 12 March 2004 13:41:30:

...

I think a lot of people would welcome a new and improved
UCI2WB adapter now. At least it would be a very nice to
have to.
If Fabien or perhaps Odd Gunnar have some time
and interest in accomplishing that task it would
be great IMHO.
What do you think?
Regards,
Günther

Gunther (UK keyboard here, no umlaut),
Yes I think too many bugs/limitations in existing ones (for instance I think Roland does not maintain a chess board so his adapter can't detect draws).
Right now I am busy giving Fruit the finishing touches (UCI support). I already use my own adapter on Linux (xboard Fruit). This very week-end I am going to add more UCI and xboard support to it, and test it with the few linux UCI engines I have got.
Next week, I will see with others (Dann?) how we can port it to windows and see how it does. It might be very primitive at first, we will see later.
I will start a thread next week about feature requests. For now it does not have .INI files (actually the engine name is hardcoded into the source code).
So I am thinking about Winboard/xboard users (I am one of them, no choice on Linux)!
Let's hope for the best,
Fabien.

I hope the best too and wish you good luck for your program also!
Of course I understand that 'Fruit' comes first
Regards,
Günther

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 12 March 2004 14:24:02:
Als Antwort auf: / In reply to: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Günther Simon at 12 March 2004 13:35:03:

#############################
#
# Adapter Resource Control
#
#############################
#
# Exe-Name
Name=Fruit 0.98b
exe=Fruit098b
#
# Directory
dir=C:\Winboard\Fruit_098b
#
# Hashtable size in MB (*not* for UCI)
Hash=128
# Tablebase Path (*not* for UCI)
# tbpath=D:\program files\shredder5\tb
tbpath=D:\sicherheit\chess\tbs
#
# Tablebase Cache in MB (*not* for UCI)
tbcache=8
#
# Style: Aggressive, Active, Normal, Solid
#Style=Active
#
logfile=yes
#

BTW, I think you want "log=true" and "logfile=..." (file name)
Fruit 1.0 will have search options as well.
Fabien.

[Norm Pollock]

Geschrieben von: / Posted by: Norm Pollock at 12 March 2004 14:37:52:
Als Antwort auf: / In reply to: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Günther Simon at 12 March 2004 13:35:03:

My complaint about uci2wb concerns memory problems. I have noticed that SOS 3 & 4, and Dragon-uci (with all versions of uci2wb) stayed in memory after being checkmated, and they would not resign prior to being checkmated. This stopped the tournament and required expert intervention to resume the tournament. Could it be the adapter? Perhaps yes, perhaps no, but it is suspicious.
A top adapter will also be good for winboard popularity.

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 12 March 2004 14:46:44:
Als Antwort auf: / In reply to: IT IS time for a new and improved UCI2WB adapter! geschrieben von: / posted by: Norm Pollock at 12 March 2004 14:37:52:

My complaint about uci2wb concerns memory problems. I have noticed that SOS 3 & 4, and Dragon-uci (with all versions of uci2wb) stayed in memory after being checkmated, and they would not resign prior to being checkmated. This stopped the tournament and required expert intervention to resume the tournament. Could it be the adapter? Perhaps yes, perhaps no, but it is suspicious.
A top adapter will also be good for winboard popularity.

This *could* be a bug in the engines.
TO ALL PROGRAMMERS: make sure your engine quits gracefully when EOF (end-of-file) is reached on stdin; if you use fgets() please check for NULL!
This would help GUI/interface/adapter authors enormously, and probably helps in case of say GUI crashes as well (the GUI or whatever interface does not have the time to send a "quit").
I find many engines (on Linux) that have this problem, also this should not affect "normal" usage.
Fabien.

[Dann Corbit]

Geschrieben von: / Posted by: Dann Corbit at 12 March 2004 22:26:57:
Als Antwort auf: / In reply to: Re: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Fabien Letouzey at 12 March 2004 14:24:02:

#############################
#
# Adapter Resource Control
#
#############################
#
# Exe-Name
Name=Fruit 0.98b
exe=Fruit098b
#
# Directory
dir=C:\Winboard\Fruit_098b
#
# Hashtable size in MB (*not* for UCI)
Hash=128
# Tablebase Path (*not* for UCI)
# tbpath=D:\program files\shredder5\tb
tbpath=D:\sicherheit\chess\tbs
#
# Tablebase Cache in MB (*not* for UCI)
tbcache=8
#
# Style: Aggressive, Active, Normal, Solid
#Style=Active
#
logfile=yes
#

BTW, I think you want "log=true" and "logfile=..." (file name)
Fruit 1.0 will have search options as well.
Fabien.

These ini file things are an awful inconvenience. Imagine 100 engines or more.
A database will be much, much better.



my ftp site {remove http:// unless you like error messages}

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 13 March 2004 01:12:04:
Als Antwort auf: / In reply to: Re: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Dann Corbit at 12 March 2004 22:26:57:

#############################
#
# Adapter Resource Control
#
#############################
#
# Exe-Name
Name=Fruit 0.98b
exe=Fruit098b
#
# Directory
dir=C:\Winboard\Fruit_098b
#
# Hashtable size in MB (*not* for UCI)
Hash=128
# Tablebase Path (*not* for UCI)
# tbpath=D:\program files\shredder5\tb
tbpath=D:\sicherheit\chess\tbs
#
# Tablebase Cache in MB (*not* for UCI)
tbcache=8
#
# Style: Aggressive, Active, Normal, Solid
#Style=Active
#
logfile=yes
#

BTW, I think you want "log=true" and "logfile=..." (file name)
Fruit 1.0 will have search options as well.
Fabien.

These ini file things are an awful inconvenience. Imagine 100 engines or more.
A database will be much, much better.

What sort of database, how should that work?
I imagine a new extended winboard protocol would be a better way to approach this.
It should not be very hard to add features for hash, tbpath, logfile and such.
I still want my inifile for playing in the console though
-S.

[Dann Corbit]

Geschrieben von: / Posted by: Dann Corbit at 13 March 2004 01:20:38:
Als Antwort auf: / In reply to: Re: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Sune Fischer at 13 March 2004 01:12:04:

[snip]

These ini file things are an awful inconvenience. Imagine 100 engines or more.
A database will be much, much better.

What sort of database, how should that work?
I imagine a new extended winboard protocol would be a better way to approach this.
It should not be very hard to add features for hash, tbpath, logfile and such.
I still want my inifile for playing in the console though

SQL. Using ODBC, JDBC and/or OLEDB. Any standards based access. As long as you make it standards based, it does not really matter what the database is. It could be MySQL or SQLite or MS Access or Foxpro or Oracle or whatever.
Indeed. What Winboard is completely missing and what is implemented as command passing in UCI really belongs in a database.
Why, if you already would be using standard database access code?
Might seem overkill for your single engine, but if it plays against several others the merit becomes instantly obvious.



my ftp site {remove http:// unless you like error messages}

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 13 March 2004 01:51:40:
Als Antwort auf: / In reply to: Re: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Dann Corbit at 13 March 2004 01:20:38:

[snip]

These ini file things are an awful inconvenience. Imagine 100 engines or more.
A database will be much, much better.

What sort of database, how should that work?
I imagine a new extended winboard protocol would be a better way to approach this.
It should not be very hard to add features for hash, tbpath, logfile and such.
I still want my inifile for playing in the console though

SQL. Using ODBC, JDBC and/or OLEDB. Any standards based access. As long as you make it standards based, it does not really matter what the database is. It could be MySQL or SQLite or MS Access or Foxpro or Oracle or whatever.
Indeed. What Winboard is completely missing and what is implemented as command passing in UCI really belongs in a database.
Why, if you already would be using standard database access code?
Might seem overkill for your single engine, but if it plays against several others the merit becomes instantly obvious.

Well I've never used any of these databases, do I just include a library of some sort?
Do I then call upon some library functions to get the ini-settings?
Can the engine write back to the database, or would this access be restricted to the GUI?
(I have a ton of questions like this:).
I usually prefer the simplest of two solutions, so if winboard could
save the settings to its own inifile, is a database not a bit overkill?
I assume you want the same setting for all engines of course, might be problematic if you want to give e.g. individual hash settings.
-S.

[Dann Corbit]

Geschrieben von: / Posted by: Dann Corbit at 13 March 2004 01:57:15:
Als Antwort auf: / In reply to: Re: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Sune Fischer at 13 March 2004 01:51:40:

[snip]

These ini file things are an awful inconvenience. Imagine 100 engines or more.
A database will be much, much better.

What sort of database, how should that work?
I imagine a new extended winboard protocol would be a better way to approach this.
It should not be very hard to add features for hash, tbpath, logfile and such.
I still want my inifile for playing in the console though

SQL. Using ODBC, JDBC and/or OLEDB. Any standards based access. As long as you make it standards based, it does not really matter what the database is. It could be MySQL or SQLite or MS Access or Foxpro or Oracle or whatever.
Indeed. What Winboard is completely missing and what is implemented as command passing in UCI really belongs in a database.
Why, if you already would be using standard database access code?
Might seem overkill for your single engine, but if it plays against several others the merit becomes instantly obvious.

Well I've never used any of these databases, do I just include a library of some sort?
Do I then call upon some library functions to get the ini-settings?
Can the engine write back to the database, or would this access be restricted to the GUI?
(I have a ton of questions like this:).
I usually prefer the simplest of two solutions, so if winboard could
save the settings to its own inifile, is a database not a bit overkill?
I assume you want the same setting for all engines of course, might be problematic if you want to give e.g. individual hash settings.

You link against the appropriate library. Source code would be provided, so all you would have to do is use it.
Depending on how much exposure to the raw internals was wanted, it would be something like:
unsigned hash = GetHashSize("EngineName", "EngineVersion");
or something of that ilk.
There would also be Set() functions.
Either.
Will Winboard want to be able to save and restore a thousand different settings?
It does not sound like a Winboard task to me, but maybe it could be added into Winboard or any other GUI.
Nope. It would be the same as UCI handles it right now, but it would be stored in a database instead of ping-pong between UCI GUI and Engine.



my ftp site {remove http:// unless you like error messages}

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 13 March 2004 02:15:59:
Als Antwort auf: / In reply to: Re: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Dann Corbit at 13 March 2004 01:57:15:

Do I then call upon some library functions to get the ini-settings?
Can the engine write back to the database, or would this access be restricted to the GUI?
(I have a ton of questions like this:).
I usually prefer the simplest of two solutions, so if winboard could
save the settings to its own inifile, is a database not a bit overkill?
I assume you want the same setting for all engines of course, might be problematic if you want to give e.g. individual hash settings.

Depending on how much exposure to the raw internals was wanted, it would be something like:
unsigned hash = GetHashSize("EngineName", "EngineVersion");
or something of that ilk.
There would also be Set() functions.
Either.
Will Winboard want to be able to save and restore a thousand different settings?
It does not sound like a Winboard task to me, but maybe it could be added into Winboard or any other GUI.
Nope. It would be the same as UCI handles it right now, but it would be stored in a database instead of ping-pong between UCI GUI and Engine.

How would the engine know what to Set() if it played in winboard and
had no inifile input?
How would winboard know what to Set() as default in the database if it
wasn't told by the user?
It seems you need to change winboard in any case.
I think the main idea behind these UCI settings is to have a large bunch of
common settings, like the hash and tbpaths.
This way the user doesn't have to configure the same thing over and over
for each engine.
It is possible for the engine to ignore these common settings
and invent its own settings.
I don't see any engine doing that though. I don't think it would be of much
practical use either, except if one wants the ability to play a sort of
handicap match setup.
I think I would be happy enough if winboard could handle just one set
of settings common to all engines.
-S.

[Dann Corbit]

Geschrieben von: / Posted by: Dann Corbit at 13 March 2004 03:27:47:
Als Antwort auf: / In reply to: Re: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Sune Fischer at 13 March 2004 02:15:59:

Do I then call upon some library functions to get the ini-settings?
Can the engine write back to the database, or would this access be restricted to the GUI?
(I have a ton of questions like this:).
I usually prefer the simplest of two solutions, so if winboard could
save the settings to its own inifile, is a database not a bit overkill?
I assume you want the same setting for all engines of course, might be problematic if you want to give e.g. individual hash settings.

Depending on how much exposure to the raw internals was wanted, it would be something like:
unsigned hash = GetHashSize("EngineName", "EngineVersion");
or something of that ilk.
There would also be Set() functions.
Either.
Will Winboard want to be able to save and restore a thousand different settings?
It does not sound like a Winboard task to me, but maybe it could be added into Winboard or any other GUI.
Nope. It would be the same as UCI handles it right now, but it would be stored in a database instead of ping-pong between UCI GUI and Engine.

How would the engine know what to Set() if it played in winboard and
had no inifile input?
How would winboard know what to Set() as default in the database if it
wasn't told by the user?
It seems you need to change winboard in any case.
I think the main idea behind these UCI settings is to have a large bunch of
common settings, like the hash and tbpaths.
This way the user doesn't have to configure the same thing over and over
for each engine.
It is possible for the engine to ignore these common settings
and invent its own settings.
I don't see any engine doing that though. I don't think it would be of much
practical use either, except if one wants the ability to play a sort of
handicap match setup.
I think I would be happy enough if winboard could handle just one set
of settings common to all engines.
-S.

What I envision is another tool, like Winboard or Arena but separate.
It is a GUI to administer the chess programs database.
The chess engine reads from the database to know where to find Nalimov/Edwards/whatever tablebase files
The chess engine reads from the database to know how much hash to use
The chess engine reads from the database to know what you want the king safety value to be set to...
Etc.
Then tools like Winboard and Arena (and otherwise) could also inquire and set the database using either the GUI or their own direct connections.



my ftp site {remove http:// unless you like error messages}

[Fabien Letouzey]

Geschrieben von: / Posted by: Fabien Letouzey at 15 March 2004 13:28:23:
Als Antwort auf: / In reply to: Re: Is it time for a new and improved UCI2WB adapter? geschrieben von: / posted by: Fabien Letouzey at 12 March 2004 14:24:02:

#############################
#
# Adapter Resource Control
#
#############################
#
# Exe-Name
Name=Fruit 0.98b
exe=Fruit098b
#
# Directory
dir=C:\Winboard\Fruit_098b
#
# Hashtable size in MB (*not* for UCI)
Hash=128
# Tablebase Path (*not* for UCI)
# tbpath=D:\program files\shredder5\tb
tbpath=D:\sicherheit\chess\tbs
#
# Tablebase Cache in MB (*not* for UCI)
tbcache=8
#
# Style: Aggressive, Active, Normal, Solid
#Style=Active
#
logfile=yes
#

BTW, I think you want "log=true" and "logfile=..." (file name)
Fruit 1.0 will have search options as well.
Fabien.

I was wrong again.
All the options in this file are *internal* to WB2UCI.
Quite unfortunate that there are UCI options with the same name (including in Fruit).
There is a different syntax to set the engine UCI options, right?
Fabien.