Gothmog 0.4.7 winboard protocol problem?

[Robert Allgeuer]

Geschrieben von:/Posted by: Robert Allgeuer at 28 March 2004 12:41:12:

The Gothmog version playing black moves as if it were playing white, which is rejected by the Gothmog version playing white. The second Gothmog version does get a "black" command, but moves as if it were white.
This happens only the first time I launch Winboard, if after the rejection of the move I start a new game it works fine, but for every first game after I start Winboard the problem occurs.
What is happening?
Robert
Debug file:

recognized 'normal' (-1) as variant normal
WinBoard 4.2.7 + Gothmog
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
StartChildProcess (dir="f:\chess\gothmog_0.4.7sel4") Gothmog
600 >first : xboard
protover 2
10605 >first : new
random
10605 >first : level 0 5 2
10605 >first : post
10605 >first : hard
10605 >first : easy
17405 >first : force
StartChildProcess (dir="f:\chess\gothmog_0.4.7sel6") Gothmog
17916 >second: xboard
protover 2
22983 first : accepted ping
22983 first : accepted setboard
22983 first : accepted san
22983 first : accepted usermove
22983 first : accepted time
22983 first : accepted sigint
22983 first : accepted sigterm
23003 first : accepted reuse
23003 first : accepted analyze
23003 first : accepted ics
23003 first : accepted colors
23003 first : accepted myname
23003 first : accepted done
27920 >second: new
random
27920 >second: level 0 5 2
27920 >second: post
27920 >second: hard
27920 >second: easy
27920 >second: force
27920 >first : computer
27920 >second: computer
27920 >first : time 30000
otim 30000
27920 >first : go
27920 second: e2e4
27930 >second: black
27930 >second: go
41159 second: accepted ping
41159 second: accepted setboard
41159 second: accepted san
41159 second: accepted usermove
41159 second: accepted time
41159 second: accepted sigint
41159 second: accepted sigterm
41159 second: accepted reuse
41159 second: accepted analyze
41159 second: accepted ics
41159 second: accepted colors
41169 second: accepted myname
41169 second: accepted done
41169 first : usermove 41169 >first : c2c4
41259

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 12:51:56:
Als Antwort auf:/In reply to: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Robert Allgeuer at 28 March 2004 12:41:12:

The Gothmog version playing black moves as if it were playing white, which is rejected by the Gothmog version playing white. The second Gothmog version does get a "black" command, but moves as if it were white.
This happens only the first time I launch Winboard, if after the rejection of the move I start a new game it works fine, but for every first game after I start Winboard the problem occurs.
What is happening?
Robert
Debug file:

23003 23003 >first : accepted colors
...
27930 >second: e2e4
27930 >second: black
27930 >second: go
...
41159 41159 >second: accepted colors

I think an unfortunate order of commands happened here.
Gothmog 0.4.5 had a bug when receiving the black/white commands.
The new Gothmogs ask WinBoard not to send them anymore (they are obsolete anyway).
Unfortunately as you can see "black" was sent to engine 2 before receiving the corresponding feature ...
Tord will have to fix the colour bug for good I am afraid.
My advice is to only take "white" (resp. "black") into account when white (resp. black) is on move.
Also, plenty of outdated software still use protover 1 and will send colours no matter what ...
Fabien.

[Tord Romstad]

Geschrieben von:/Posted by: Tord Romstad at 29 March 2004 14:06:53:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 12:51:56:

The Gothmog version playing black moves as if it were playing white, which is rejected by the Gothmog version playing white. The second Gothmog version does get a "black" command, but moves as if it were white.
This happens only the first time I launch Winboard, if after the rejection of the move I start a new game it works fine, but for every first game after I start Winboard the problem occurs.
What is happening?
Robert
Debug file:

23003 >23003 >first : accepted colors
...
27930 >second: e2e4
27930 >second: black
27930 >second: go
...
41159 >41159 >second: accepted colors

I think an unfortunate order of commands happened here.
Gothmog 0.4.5 had a bug when receiving the black/white commands.
The new Gothmogs ask WinBoard not to send them anymore (they are obsolete anyway).
Unfortunately as you can see "black" was sent to engine 2 before receiving the corresponding feature ...
Tord will have to fix the colour bug for good I am afraid.
My advice is to only take "white" (resp. "black") into account when white (resp. black) is on move.
Also, plenty of outdated software still use protover 1 and will send colours no matter what ...
Fabien.

Thanks for Robert for pointing out the problem, and to Fabien for explaining
what really happens. But isn't xboard supposed to wait until the engine
sends "feature done=1" before it starts sending commands to the engine?
Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 14:12:27:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Tord Romstad at 29 March 2004 14:06:53:

The Gothmog version playing black moves as if it were playing white, which is rejected by the Gothmog version playing white. The second Gothmog version does get a "black" command, but moves as if it were white.
This happens only the first time I launch Winboard, if after the rejection of the move I start a new game it works fine, but for every first game after I start Winboard the problem occurs.
What is happening?
Robert
Debug file:

23003 >>23003 >first : accepted colors
...
27930 >second: e2e4
27930 >second: black
27930 >second: go
...
41159 >>41159 >second: accepted colors

I think an unfortunate order of commands happened here.
Gothmog 0.4.5 had a bug when receiving the black/white commands.
The new Gothmogs ask WinBoard not to send them anymore (they are obsolete anyway).
Unfortunately as you can see "black" was sent to engine 2 before receiving the corresponding feature ...
Tord will have to fix the colour bug for good I am afraid.
My advice is to only take "white" (resp. "black") into account when white (resp. black) is on move.
Also, plenty of outdated software still use protover 1 and will send colours no matter what ...
Fabien.

Thanks for Robert for pointing out the problem, and to Fabien for explaining
what really happens. But isn't xboard supposed to wait until the engine
sends "feature done=1" before it starts sending commands to the engine?
Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.
Of course "engine 2" is at a big disadvantage, as it might lag a lot while "engine 1" is initialising ...
My message is don't expect anything to work with the xboard protocol; you have to be ready for the worst, and it *will* happen at some point. I speak of experience.
Fabien.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 14:16:55:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Tord Romstad at 29 March 2004 14:06:53:

The Gothmog version playing black moves as if it were playing white, which is rejected by the Gothmog version playing white. The second Gothmog version does get a "black" command, but moves as if it were white.
This happens only the first time I launch Winboard, if after the rejection of the move I start a new game it works fine, but for every first game after I start Winboard the problem occurs.
What is happening?
Robert
Debug file:

23003 >>23003 >first : accepted colors
...
27930 >second: e2e4
27930 >second: black
27930 >second: go
...
41159 >>41159 >second: accepted colors

I think an unfortunate order of commands happened here.
Gothmog 0.4.5 had a bug when receiving the black/white commands.
The new Gothmogs ask WinBoard not to send them anymore (they are obsolete anyway).
Unfortunately as you can see "black" was sent to engine 2 before receiving the corresponding feature ...
Tord will have to fix the colour bug for good I am afraid.
My advice is to only take "white" (resp. "black") into account when white (resp. black) is on move.
Also, plenty of outdated software still use protover 1 and will send colours no matter what ...
Fabien.

Thanks for Robert for pointing out the problem, and to Fabien for explaining
what really happens. But isn't xboard supposed to wait until the engine
sends "feature done=1" before it starts sending commands to the engine?
Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

In my software I only have something like 10 extra lines of code to support a subset of "protover 1". Maybe it's not as much work as you think. Of course I never support "edit".
Maybe you want to reconsider it?
Fabien.

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 14:33:50:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 14:12:27:

Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.
Of course "engine 2" is at a big disadvantage, as it might lag a lot while "engine 1" is initialising ...
My message is don't expect anything to work with the xboard protocol; you have to be ready for the worst, and it *will* happen at some point. I speak of experience.
Fabien.

Same here it's just obsolete with WBII.
I decided to support the very ugly WBI way of passing moves, without
the "usermove", it's kind of convient when typing stuff from the console.
No not if you send "feature done=0":
"done (integer, no default)
If you set done=1 during the initial two-second timeout after xboard sends you
the "xboard" command, the timeout will end and xboard will not look for any
more feature commands before starting normal operation. If you set done=0, the
initial timeout is increased to one hour; in this case, you must set done=1
before xboard will enter normal operation. "
http://www.tim-mann.org/xboard/engine-intf.html
btw, it would be nice to have a link to this page, Volker?
It's a big problem with TBs, they can't be initialized in less than 2 seconds,
so with TBs done=0 is needed.
Yeah that must be why there is only 200+ winboard engines, nothing works!
-S.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 14:46:03:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 14:33:50:

Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.
Of course "engine 2" is at a big disadvantage, as it might lag a lot while "engine 1" is initialising ...
My message is don't expect anything to work with the xboard protocol; you have to be ready for the worst, and it *will* happen at some point. I speak of experience.
Fabien.

Same here it's just obsolete with WBII.
I decided to support the very ugly WBI way of passing moves, without
the "usermove", it's kind of convient when typing stuff from the console.
No not if you send "feature done=0":
"done (integer, no default)
If you set done=1 during the initial two-second timeout after xboard sends you
the "xboard" command, the timeout will end and xboard will not look for any
more feature commands before starting normal operation. If you set done=0, the
initial timeout is increased to one hour; in this case, you must set done=1
before xboard will enter normal operation. "
http://www.tim-mann.org/xboard/engine-intf.html
btw, it would be nice to have a link to this page, Volker?
It's a big problem with TBs, they can't be initialized in less than 2 seconds,
so with TBs done=0 is needed.
Yeah that must be why there is only 200+ winboard engines, nothing works!
-S.

Each of the 200 has work-around code to support the protocol ...
Fruit will not be added to the list.
Fabien.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 14:52:13:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 14:33:50:

Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.

Same here it's just obsolete with WBII.
I decided to support the very ugly WBI way of passing moves, without
the "usermove", it's kind of convient when typing stuff from the console.
No not if you send "feature done=0":
"done (integer, no default)

What I was pointing out is that the lag might prevent WinBoard from receiving anything from "engine 2" in time, including "feature done=0". Perhaps this is due to how Windows multitasking works, I do not know.
Now it seems like Tord does not send it anyway, I did not even consider that possibility ...
Fabien.

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 14:53:28:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 14:46:03:

Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.
Of course "engine 2" is at a big disadvantage, as it might lag a lot while "engine 1" is initialising ...
My message is don't expect anything to work with the xboard protocol; you have to be ready for the worst, and it *will* happen at some point. I speak of experience.
Fabien.

Same here it's just obsolete with WBII.
I decided to support the very ugly WBI way of passing moves, without
the "usermove", it's kind of convient when typing stuff from the console.
No not if you send "feature done=0":
"done (integer, no default)
If you set done=1 during the initial two-second timeout after xboard sends you
the "xboard" command, the timeout will end and xboard will not look for any
more feature commands before starting normal operation. If you set done=0, the
initial timeout is increased to one hour; in this case, you must set done=1
before xboard will enter normal operation. "
http://www.tim-mann.org/xboard/engine-intf.html
btw, it would be nice to have a link to this page, Volker?
It's a big problem with TBs, they can't be initialized in less than 2 seconds,
so with TBs done=0 is needed.
Yeah that must be why there is only 200+ winboard engines, nothing works!
-S.

Each of the 200 has work-around code to support the protocol ...
Fruit will not be added to the list.
Fabien.

What work around code?
UCI is a lot worse, it's is not even a chess game protocol, it is a fixed position analysis protocol.
In order to get it to play a chess game without clearing hash at every move
you have to do lots of tricks that is directly against the nature of the
protocol.
Choose your poison.
Well you've made that nice uci2wb tool, so in a sense...
-S.

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 14:58:05:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 14:52:13:

Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.

Same here it's just obsolete with WBII.
I decided to support the very ugly WBI way of passing moves, without
the "usermove", it's kind of convient when typing stuff from the console.
No not if you send "feature done=0":
"done (integer, no default)

What I was pointing out is that the lag might prevent WinBoard from receiving anything from "engine 2" in time, including "feature done=0". Perhaps this is due to how Windows multitasking works, I do not know.
Now it seems like Tord does not send it anyway, I did not even consider that possibility ...
Fabien.

Not sure if this is a problem, I don't think winboard initializes more than
one engine at a time. Hard to say, usually they initialize so fast I have not
noticed.
Adding the done feature is a good idea in any case.
-S.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 15:00:01:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 14:53:28:

Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.
Of course "engine 2" is at a big disadvantage, as it might lag a lot while "engine 1" is initialising ...
My message is don't expect anything to work with the xboard protocol; you have to be ready for the worst, and it *will* happen at some point. I speak of experience.
Fabien.

Same here it's just obsolete with WBII.
I decided to support the very ugly WBI way of passing moves, without
the "usermove", it's kind of convient when typing stuff from the console.
No not if you send "feature done=0":
"done (integer, no default)
If you set done=1 during the initial two-second timeout after xboard sends you
the "xboard" command, the timeout will end and xboard will not look for any
more feature commands before starting normal operation. If you set done=0, the
initial timeout is increased to one hour; in this case, you must set done=1
before xboard will enter normal operation. "
http://www.tim-mann.org/xboard/engine-intf.html
btw, it would be nice to have a link to this page, Volker?
It's a big problem with TBs, they can't be initialized in less than 2 seconds,
so with TBs done=0 is needed.
Yeah that must be why there is only 200+ winboard engines, nothing works!
-S.

Each of the 200 has work-around code to support the protocol ...
Fruit will not be added to the list.

What work around code?
UCI is a lot worse, it's is not even a chess game protocol, it is a fixed position analysis protocol.
In order to get it to play a chess game without clearing hash at every move
you have to do lots of tricks that is directly against the nature of the
protocol.
Choose your poison.
Well you've made that nice uci2wb tool, so in a sense...

I don't like UCI either, but as an ASCII I/O to a single search function, it's not too badly designed.
BTW, why would you need to clear the hash table?
The full point of PolyGlot is that the work-around code is outside of the engine. Also other engines can share that code if they want to.
Fabien.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 15:01:29:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 14:58:05:

Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.

Same here it's just obsolete with WBII.
I decided to support the very ugly WBI way of passing moves, without
the "usermove", it's kind of convient when typing stuff from the console.
No not if you send "feature done=0":
"done (integer, no default)

What I was pointing out is that the lag might prevent WinBoard from receiving anything from "engine 2" in time, including "feature done=0". Perhaps this is due to how Windows multitasking works, I do not know.
Now it seems like Tord does not send it anyway, I did not even consider that possibility ...
Fabien.

Not sure if this is a problem, I don't think winboard initializes more than
one engine at a time. Hard to say, usually they initialize so fast I have not
noticed.
Adding the done feature is a good idea in any case.
-S.

IME "engine 2" is initialised "in a hurry" when a game starts.
I have had problems related to that in the past.
Of course, I never considered Tord might not be sending it.
Fabien.

[Tord Romstad]

Geschrieben von:/Posted by: Tord Romstad at 29 March 2004 15:05:22:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 14:33:50:

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.

No not if you send "feature done=0":
"done (integer, no default)

Aha! You tell me I should send "done=0" first? I thought it was enough to
just send "done=1" at the end. Thanks for the tip!
Looks like I will have to release yet another 0.4.x version of Gothmog.
Quite annoying, I would really like to let this thing die. Its tortured
existence has continued far too long already.
Tord

[Tord Romstad]

Geschrieben von:/Posted by: Tord Romstad at 29 March 2004 15:08:48:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 15:00:01:

BTW, why would you need to clear the hash table?

Precisely what I was about to ask. I don't see how UCI differs from xboard in
this respect. I never clear the hash tables in either protocol.
Tord

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 15:12:20:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 15:00:01:

Gothmog doesn't work at all in protocol version 1, for a number of reasons.
At the moment I have no plans of supporting it.
Tord

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.
Of course "engine 2" is at a big disadvantage, as it might lag a lot while "engine 1" is initialising ...
My message is don't expect anything to work with the xboard protocol; you have to be ready for the worst, and it *will* happen at some point. I speak of experience.
Fabien.

Same here it's just obsolete with WBII.
I decided to support the very ugly WBI way of passing moves, without
the "usermove", it's kind of convient when typing stuff from the console.
No not if you send "feature done=0":
"done (integer, no default)
If you set done=1 during the initial two-second timeout after xboard sends you
the "xboard" command, the timeout will end and xboard will not look for any
more feature commands before starting normal operation. If you set done=0, the
initial timeout is increased to one hour; in this case, you must set done=1
before xboard will enter normal operation. "
http://www.tim-mann.org/xboard/engine-intf.html
btw, it would be nice to have a link to this page, Volker?
It's a big problem with TBs, they can't be initialized in less than 2 seconds,
so with TBs done=0 is needed.
Yeah that must be why there is only 200+ winboard engines, nothing works!
-S.

Each of the 200 has work-around code to support the protocol ...

What work around code?
UCI is a lot worse, it's is not even a chess game protocol, it is a fixed position analysis protocol.
In order to get it to play a chess game without clearing hash at every move
you have to do lots of tricks that is directly against the nature of the
protocol.
Choose your poison.
Well you've made that nice uci2wb tool, so in a sense...

I don't like UCI either, but as an ASCII I/O to a single search function, it's not too badly designed.
BTW, why would you need to clear the hash table?
The full point of PolyGlot is that the work-around code is outside of the engine. Also other engines can share that code if they want to.
Fabien.

It's not the design as such, it's the limitations imposed by the design I don't like.
E.g. how do you implement learning?
How do you know if you're playing a human or computer?
How do you know the rating of your opponent compared to your own rating?
This information is need IMO.
I'm actually surprised that UCI sends you the
time of your opponent, seems redundant from the design POV.
When setting up a new position it is better to clear the hash and reset
all the age flags etc., for efficiency.
In UCI you have to make a work around to see when the position is completely
new, or just evolved one move.
Good thinking
In general it is quite nice if the modules are seperate and can be pieced
together independently.
I'm just too lazy, I put everything in one binary, "the complete chess tool"
-S.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 15:12:40:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Tord Romstad at 29 March 2004 15:08:48:

BTW, why would you need to clear the hash table?

Precisely what I was about to ask. I don't see how UCI differs from xboard in
this respect. I never clear the hash tables in either protocol.
Tord

Apparently, Tim did not expect engines to clear them after "new" either. There is that "reset" function in the (now dead) CB adapter that was considered as an addition to "protover 3". I don't think the discussions are still ongoing though.
So in short clearing them after "new" is a personal choice and not a recommendation.
Fabien.

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 15:17:35:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 15:01:29:

Not sure if this is a problem, I don't think winboard initializes more than
one engine at a time. Hard to say, usually they initialize so fast I have not
noticed.

IME "engine 2" is initialised "in a hurry" when a game starts.
I have had problems related to that in the past.

If they do get initialized simultaniously they should get about 50% cpu each.
I would think this should be sufficient for winboard to recieve the done command.
-S.

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 15:22:11:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Tord Romstad at 29 March 2004 15:05:22:

As you know, after some timeout (is it 2 or 5 seconds?) xboard "decides" that an engine does not support "protover 2" and carries on with "protover 1" commands.

No not if you send "feature done=0":
"done (integer, no default)

Aha! You tell me I should send "done=0" first? I thought it was enough to
just send "done=1" at the end. Thanks for the tip!
Looks like I will have to release yet another 0.4.x version of Gothmog.
Quite annoying, I would really like to let this thing die. Its tortured
existence has continued far too long already.
Tord

Feel free to do so, as long as it isn't stronger
-S.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 15:26:13:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 15:12:20:

I don't like UCI either, but as an ASCII I/O to a single search function, it's not too badly designed.
BTW, why would you need to clear the hash table?
The full point of PolyGlot is that the work-around code is outside of the engine. Also other engines can share that code if they want to.

It's not the design as such, it's the limitations imposed by the design I don't like.
E.g. how do you implement learning?
How do you know if you're playing a human or computer?
How do you know the rating of your opponent compared to your own rating?
This information is need IMO.
I'm actually surprised that UCI sends you the
time of your opponent, seems redundant from the design POV.
When setting up a new position it is better to clear the hash and reset
all the age flags etc., for efficiency.
In UCI you have to make a work around to see when the position is completely
new, or just evolved one move.
Good thinking
In general it is quite nice if the modules are seperate and can be pieced
together independently.
I'm just too lazy, I put everything in one binary, "the complete chess tool"

I agree with this as well, if I want any of those the code would be outside the engine module. I am considering a two-staged protocol with game level (xboard like) and position level (UCI like).
Absolutely. Also the requirement to never stop the search in infinite or ponder mode makes the engine more complex than necessary; this should be a "GUI" problem.
I try to think about long searches only, so I always assume saturated tables. For short time controls, smaller tables should be used anyway.
Clearly you want a game-level protocol, and indeed UCI is not suitable for you then.
Note that I have written xboard-compatible engines in the past, so I really enjoy the difference in code complexity.
engines and GUIs are already separated in different executables; why not push the idea further ...
I intend to add EPD testing into PolyGlot in the near future for instance. If I want book learning, I can put the code there as well. And yes it could still be an UCI engine, PolyGlot would "just" have to learn how to talk to a UCI GUI ...
Fabien.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 15:29:12:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 15:17:35:

Not sure if this is a problem, I don't think winboard initializes more than
one engine at a time. Hard to say, usually they initialize so fast I have not
noticed.

IME "engine 2" is initialised "in a hurry" when a game starts.
I have had problems related to that in the past.

If they do get initialized simultaniously they should get about 50% cpu each.
I would think this should be sufficient for winboard to recieve the done command.
-S.

The point again is that it is a race condition. You can never be 100% sure that Winboard is going to receive any feature in time. Therefore each engine should be "protover 1"-compatible as well.
Fabien.