Page 1 of 1

Polyglot 1.4.54b

PostPosted: 30 Nov 2009, 15:26
by Michel
See here

http://alpha.uhasselt.be/Research/Algeb ... ot-release


(*) The EngineCommand's are now passed through wordexp on Linux instead of being naively chopped up according to the spaces they contain. This makes it possible to use (appropriately quoted) spaces in an EngineCommand in Linux (windows executables usually have spaces in them).

(*) If an engine exits unexpectedly (i.e. without being instructed to do so first) then PG will detect this and inform xboard with the
appropriate tellusererror command. This pops up an error dialog (which is currently obscured immediately with a bunch of
xboard error dialogs).

(*) I changed the quoting mechanism. It turned out that stripping off a pair of outer quotes (if present) from the values in the inifile
interferes with the use of double quotes in EngineCommand's in windows.

I have now implemented a different quoting mechanism. Characters that have a special meaning to PG (that is: ;#=[]) should
be quoted with \ when used as literal characters (e.g. in NalimovPath where ; is used as a separator).

For other characters the backslash has no effect. In particular this should not interfere with the use of \ as a path separator in windows.

Unfortunately this version was not tested with Winboard as my harddisk crashed and I lost my windows virtual machine for the
moment. I did test it with xboard under wine though.

Re: Polyglot 1.4.54b

PostPosted: 30 Nov 2009, 17:10
by H.G.Muller
Not sure if I understand your third point. If the ini file contains

EngineCommand = "super engine" --iomode uci

I would expect it to do the same as when (from the shell command line) I type

polyglot -ec '"super engine" --io-mode uci'

because the shell would strip off the outer (single) quotes. Under Windows there is no shell, but any C program implements this fnction of the shell in its startup routine. So even if I call Polyglot from WinBoard, it acts as if a shell had procesed the line in between. In XBoard I now have implemented a simplified form of thi kind of procesing: it handles the quoting, but there is no escaping between the quotes. So

polyglot -ec "\"super engine\" --io-mode uci"

would not work as -fcp argument in XBoard, although it would work from the shell. (At least, if Polyglot would handle the quoting.)

Re: Polyglot 1.4.54b

PostPosted: 30 Nov 2009, 19:30
by Michel
polyglot -noini -ec "\"super engine\" --io-mode uci"


This works indeed on my computer.

It does indeed not work as an argument of -fcp. The error message seems to indicate that xboard
calls polyglot with argv[1] equal to "\"super.

On the other hand

/usr/games/xboard -fcp '"super engine" --io-mode uci' -fUCI


seems to work as expected.

A polyglot.ini file containing

EngineCommand="super engine" --io-mode uci


also works.

Re: Polyglot 1.4.54b

PostPosted: 30 Nov 2009, 19:46
by Michel
The stripping of outer quotes was something that Fonzy added in one of his last
versions and I did the same for compatibility/

The reason why I undid it is that it leads to unexpected behaviour on Windows.

Assume your current directory contains

Rybka.exe
Rybka Human.exe

If you have

EngineCommand="Rybka Human.exe"

then after stripping outer quotes Polyglot would invoke CreateProcess with Rybka Human.exe
which then silently invokes Rybka.exe instead of Rybka Human.exe.

With the current version Polyglot will invoke CreateProcess again with "Rybka Human.exe"
which does the right thing.

Re: Polyglot 1.4.54b

PostPosted: 30 Nov 2009, 22:15
by H.G.Muller
OK, I see what you mean now. And I think I agree with the underlying philosophy:

polyglot -ec "Rybka Human.exe"

should do the same thing as when you have

EngineCommand = Rybka Human.exe

in the ini file, as the shell (or in the windows case the shell emulator in the stratup routine) strips off the quotes, so to the Polyglot code the argument is simply

Rybka3 Human.exe

which is also what it reads from the ini file. Stripping quotes on the ini-file values would be illogical if you did not do it on every element of argv[] representing an option value as well. And that would serve no purpose.

Re: Polyglot 1.4.54b

PostPosted: 02 Dec 2009, 04:38
by Michel
Ok I posted 1.4.55b. I suppressed a few error dialogs and inserted a small delay between sending a fatal error message and actually quitting.
Combined with the latest development version of xboard this should provide a better user experience when the engine fails to start up.

Re: Polyglot 1.4.54b

PostPosted: 29 Dec 2009, 11:10
by Michel
I posted PG 1.4.56b. No changes on Windows.

On Linux there should now normally precisely one error message in case of a fatal error (no more ugly cascade of dialog boxes).

This needed a bit of thought since if the engine fails to start then the error message comes from a forked process. So this message
must be communicated to the parent process. Furthermore the forked process must stay alive until the parent allows it to quit to avoid broken pipe errors.

Re: Polyglot 1.4.54b

PostPosted: 28 Apr 2010, 05:43
by K Inuen
Hi Michel. Hello all.

I am having problems using Polyglot 1.4.50b to current version, 1.4.58b. When I play off-line engine-engine match or on-line computer chess, polyglot 1.4.50b - 1.4.58b exits giving me this error message:

POLYGLOT: write_integer(): fputc():Bad file descriptor


and also this, especially when doing offline engine-engine games:

POLYGLOT: learn() unknown side


And then, even if I ignore this error message and start next game, it freezes and engine won't move! This problem does not happen with Polyglot version 1.4.30b - 1.4.46b. Michel, any idea why I'm getting these error messages, specifically with polyglot 1.4.50b to 1.4.58b? Any help is appreciated.

My OS is Phenom II X4 965
Windows 7 64-bit
Winboard Seek Graph Feb25 & 28 (CCT12 and other WB versions)


I have uploaded my winboard.ini, polyglot.ini, engine log files, and .ini files for both engines. This message happens also with other engines I use.
Edit: Link to log files deleted.

Thanks in advance.

Re: Polyglot 1.4.54b

PostPosted: 28 Apr 2010, 09:46
by Michel
Hmm this does not look good:-(

Just a wild guess. Have you enabled learning? I have never looked at that code as the learning information is
not used by any program that I know of. Maybe I messed up something where introducing the option BookDepth
(this happened in 37b).

For now I would recommend setting BookLearn=false (the default).

I am quite busy now but will look at it in the next couple of days.

EDIT: I looked at your log files (thanks!). BookLearn seems to be indeed enabled.
If you disable that then the problems should go away. I will try to find the bug
though,

Re: Polyglot 1.4.54b

PostPosted: 29 Apr 2010, 01:41
by K Inuen
Michel,

Thanks for the help. The BookLearn=false fixed it. No more error messages after 1 game, subsequently requiring me to either close Winboard and restart it (if it's off-line engine-engine games) or log-off and re-log back in(if it's on-line games).

Still, it would be nice to have these BookLearn actually shift learn-weights (based on previous games) and have direct influence on polyglot .bin books - similar to the learn-weight function of .ctg books in Chessbase / Fritz GUI.

Re: Polyglot 1.4.54b

PostPosted: 30 Apr 2010, 04:37
by matematiko
Hi,

I am going to cast my opinion at the risk of being wrong, but here are my two cents.

Book learning capabilities are there for a GUI developer to take advantage and implement them, not for polyglot to implement them. A move can not be weighted as its been played because we do not know yet if it was a move that will led to a win, draw or lose, therefor polyglot will have to remember every move made in a game, evaluate the result, implement a book learning algorithm and then change the book accordingly. I think this is well beyond polyglot's goals. Even if this is ever implemented by a GUI, a move can not be judged as a bad or good move based in the result, example: The move is good but we end up loosing the game in middle and end game to a superior hardware; or the other way around: the move is bad but we won the game due to superior hardware in our end.

Book learning is a nice tool if use wisely(toggle on and off as needed), but it should never substitute manual book tuning, for that we can use SCID.

Best regards,

matematiko