Gothmog 0.4.8 Winboard protocol problem

[Robert Allgeuer]

Geschrieben von:/Posted by: Robert Allgeuer at 06 June 2004 13:08:04:

In the past I have failed to run Gothmog on my machine, because of the feature done=0 problem (posted here at the time). I have now retried version 0.4.8 on my machine (Winboard 4.2.7, Win2k, Athlon TB 1.2GHz) and encounter still a problem, the symptoms are identical, although the exact mechanisms may not: this time Gothmog appears to not take into account the move of the white side, thinks itself is white and makes the move e2e4. The problem is reproducable. It is a pity because I would love to run Gothmog ...
The problem manifests itself when Gothmog is black and only the first time, that is when Gothmog intialises. After one "reset game" it works. But as I want to run Gothmog with WBTM, it is the first time that is important for me.
Debug file is here:

recognized 'normal' (-1) as variant normal
WinBoard 4.2.7 + Ruffian
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
StartChildProcess (dir="f:\chess\ruffian") Ruffian
601 >first : xboard
protover 2
631 <first : Ruffian 1.0.1
631 <first : feature done=0
631 >first : accepted done
631 <first : Loading configuration: ruffian.cfg
631 <first : Warning: RESIGN changed, default=700, newvalue=900
631 <first : Warning: HASH changed, default=33554432, newvalue=67108864
631 <first : Warning: EGTB_HASH_SIZE changed, default=1048576, newvalue=6291456
631 <first : Logfile: Sun Jun 06 12:50:01 2004
631 <first : Total hash size 64M
631 <first : Open book: ruffian.bok
631 <first : Book version 0.3 created Sun Sep 29 02:01:08 2002
631 <first : 59116 book moves, depth=60
631 <first : ruffian: [xboard]
6579 <first : feature setboard=1
6579 >first : accepted setboard
6579 <first : feature analyze=1
6579 >first : accepted analyze
6579 <first : feature setboard=1
6579 >first : accepted setboard
6579 <first : feature myname="Ruffian 1.0.1"
6579 >first : accepted myname
6579 <first : feature done=1
6579 >first : accepted done
6579 <first : feature ping=1
6579 >first : accepted ping
6589 >first : new
random
6589 >first : level 0 5 2
6589 >first : post
6589 >first : hard
6589 >first : easy
6589 >first : ping 1
6589 <first : pong 1
16724 >first : force
StartChildProcess (dir="f:\chess\gothmog_0.4.8") Gothmog
17235 >second: xboard
protover 2
27239 >second: new
random
27239 >second: level 0 5 2
27239 >second: post
27239 >second: hard
27239 >second: easy
27239 >second: force
27239 >first : computer
27239 >second: computer
27239 >first : black
27239 >first : time 30000
otim 30000
27239 >first : white
27239 >first : go
27249 <first : move g1f3
27249 >second: time 30000
otim 30199
27249 >second: g1f3
27249 >second: black
27249 >second: go
39417 <second: feature done=0
Interrupting second
39417 >second: accepted done
39417 <second: feature ping=1
39417 >second: accepted ping
39417 <second: feature setboard=1
39417 >second: accepted setboard
39417 <second: feature san=0
39417 >second: accepted san
39417 <second: feature usermove=1
39417 >second: accepted usermove
39417 <second: feature time=1
39417 >second: accepted time
39417 <second: feature sigint=0
39417 >second: accepted sigint
39417 <second: feature sigterm=0
39417 >second: accepted sigterm
39417 <second: feature reuse=1
39427 >second: accepted reuse
39427 <second: feature analyze=1
39437 >second: accepted analyze
39437 <second: feature ics=1
39437 >second: accepted ics
39437 <second: feature colors=0
39437 >second: accepted colors
39437 <second: feature myname="Gothmog 0.4.8"
39437 >second: accepted myname
39437 <second: feature done=1
39437 >second: accepted done
39437 <second: 0 0 0 0 (e2e4 d2d4 )
39447 <second: move e2e4
Interrupting first
39447 >first : time 30199
otim 28980
39447 >first : e2e4
39537 <first : Illegal move: e2e4
Reset(1, 1) from gameMode 5
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
58665 >first : force
58665 >first : ping 2
58665 >second: force
58665 >second: ping 1
58665 >first : new
random
58665 >first : level 0 5 2
58665 >first : post
58675 >first : hard
58675 >first : easy
58675 >first : ping 3
58675 <first : pong 2
58675 <first : pong 3
58675 <second: pong 1
GameEnds(0, (null), 2)
60688 >first : force
60688 >first : ping 4
60688 >first : quit
60688 >second: quit


Robert

[Tord Romstad]

Geschrieben von:/Posted by: Tord Romstad at 06 June 2004 15:31:27:
Als Antwort auf:/In reply to: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Robert Allgeuer at 06 June 2004 13:08:04:

In the past I have failed to run Gothmog on my machine, because of the feature done=0 problem (posted here at the time). I have now retried version 0.4.8 on my machine (Winboard 4.2.7, Win2k, Athlon TB 1.2GHz) and encounter still a problem, the symptoms are identical, although the exact mechanisms may not: this time Gothmog appears to not take into account the move of the white side, thinks itself is white and makes the move e2e4. The problem is reproducable. It is a pity because I would love to run Gothmog ...
The problem manifests itself when Gothmog is black and only the first time, that is when Gothmog intialises. After one "reset game" it works. But as I want to run Gothmog with WBTM, it is the first time that is important for me.
Debug file is here:

Hi Robert,
I regard this as a Winboard bug rather than a Gothmog bug. The problem
is the same as before, Winboard sends Ruffian's first move to Gothmog
without waiting for Gothmog's feature list, which includes the 'usermove'
feature. I've quoted the relevant parts of the debug file below:

>StartChildProcess (dir="f:\chess\gothmog_0.4.8") Gothmog
>17235 >second: xboard
>protover 2
>27239 >second: new
>random
>27239 >second: level 0 5 2
>27239 >second: post
>27239 >second: hard
>27239 >second: easy
>27239 >second: force
>27249 >second: time 30000
>otim 30199
>27249 >second: g1f3
>27249 >second: black
>27249 >second: go
>39417 <second: feature done=0
>Interrupting second
>39417 <second: feature usermove=1
>39417 >second: accepted usermove
>39437 <second: feature colors=0
>39437 >second: accepted colors
>39437 <second: feature myname="Gothmog 0.4.8"
>39437 >second: accepted myname
>39437 <second: feature done=1
>39437 >second: accepted done
>39437 <second: 0 0 0 0 (e2e4 d2d4 )
>39447 <second: move e2e4

As you can see above, Winboard sends Gothmog the 'black' command
and Ruffian's first move without the 'usermove' prefix. Only
afterwards does it listen to Gothmog's feature list, which contains
'usermove=1' and 'colors=0'. In version 0.4.7 and earlier you
could to some extent blame Gothmog for the problem, because it didn't
use 'feature done=0' at the beginning of the feature list. This is
no longer the case in 0.4.8.
I'll see if I can find some workaround for the next public version.
Meanwhile, have you tried running Gothmog in UCI mode with the
PolyGlot adapter? I can send you a polyglot.ini file if you want.
Tord

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 06 June 2004 15:54:37:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tord Romstad at 06 June 2004 15:31:27:

In the past I have failed to run Gothmog on my machine, because of the feature done=0 problem (posted here at the time). I have now retried version 0.4.8 on my machine (Winboard 4.2.7, Win2k, Athlon TB 1.2GHz) and encounter still a problem, the symptoms are identical, although the exact mechanisms may not: this time Gothmog appears to not take into account the move of the white side, thinks itself is white and makes the move e2e4. The problem is reproducable. It is a pity because I would love to run Gothmog ...
The problem manifests itself when Gothmog is black and only the first time, that is when Gothmog intialises. After one "reset game" it works. But as I want to run Gothmog with WBTM, it is the first time that is important for me.
Debug file is here:
StartChildProcess (dir="f:\chess\gothmog_0.4.8") Gothmog
17235 >second: xboard
protover 2
27239 >second: new
random
27239 >second: level 0 5 2
27239 >second: post
27239 >second: hard
27239 >second: easy
27239 >second: force
27249 >second: time 30000
otim 30199
27249 >second: g1f3
27249 >second: black
27249 >second: go
39417 first : xboard

Hi Robert,
I regard this as a Winboard bug rather than a Gothmog bug. The problem
is the same as before, Winboard sends Ruffian's first move to Gothmog
without waiting for Gothmog's feature list, which includes the 'usermove'
feature. I've quoted the relevant parts of the debug file below:

protover 2
591

[Tom Likens]

Geschrieben von:/Posted by: Tom Likens at 06 June 2004 16:34:58:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Uri Blass at 06 June 2004 15:54:37:

In the past I have failed to run Gothmog on my machine, because of the feature done=0 problem (posted here at the time). I have now retried version 0.4.8 on my machine (Winboard 4.2.7, Win2k, Athlon TB 1.2GHz) and encounter still a problem, the symptoms are identical, although the exact mechanisms may not: this time Gothmog appears to not take into account the move of the white side, thinks itself is white and makes the move e2e4. The problem is reproducable. It is a pity because I would love to run Gothmog ...
The problem manifests itself when Gothmog is black and only the first time, that is when Gothmog intialises. After one "reset game" it works. But as I want to run Gothmog with WBTM, it is the first time that is important for me.
Debug file is here:
StartChildProcess (dir="f:\chess\gothmog_0.4.8") Gothmog
17235 >second: xboard
protover 2
27239 >second: new
random
27239 >second: level 0 5 2
27239 >second: post
27239 >second: hard
27239 >second: easy
27239 >second: force
27249 >second: time 30000
otim 30199
27249 >second: g1f3
27249 >second: black
27249 >second: go
39417 It seems that it takes a long time for gotmog to send feature done=1(12 seconds

Hi Robert,
I regard this as a Winboard bug rather than a Gothmog bug. The problem
is the same as before, Winboard sends Ruffian's first move to Gothmog
without waiting for Gothmog's feature list, which includes the 'usermove'
feature. I've quoted the relevant parts of the debug file below:

if I understand the output correctly)
I do not understand why so much time and what is the problem with
sending feature done=0 immediatly after getting the go command.
Here is for comparison movei debug:
581 >first : xboard
protover 2
591 591
You can see some things about movei:
1)Movei responds immediately to xboard by feature done=1
2)Movei does not have feature done=0
3)Movei needs 0.01 seconds to respond
In my code I have only:
Print("feature setboard=1 draw=0 analyze=1 ping=1 done=1\n");
Uri

Actually, it's okay to send the "feature done=0" even earlier. The relevant quote from Tim's
documentation:
" To increase the timeout, if needed, set the feature "done=0" before your first feature command
and "done=1" at the end. If needed, it is okay for your engine to set done=0 soon as it starts, even
before it receives the xboard and protover commands."
--tom

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 06 June 2004 17:23:55:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tom Likens at 06 June 2004 16:34:58:

In the past I have failed to run Gothmog on my machine, because of the feature done=0 problem (posted here at the time). I have now retried version 0.4.8 on my machine (Winboard 4.2.7, Win2k, Athlon TB 1.2GHz) and encounter still a problem, the symptoms are identical, although the exact mechanisms may not: this time Gothmog appears to not take into account the move of the white side, thinks itself is white and makes the move e2e4. The problem is reproducable. It is a pity because I would love to run Gothmog ...
The problem manifests itself when Gothmog is black and only the first time, that is when Gothmog intialises. After one "reset game" it works. But as I want to run Gothmog with WBTM, it is the first time that is important for me.
Debug file is here:
StartChildProcess (dir="f:\chess\gothmog_0.4.8") Gothmog
17235 >second: xboard
protover 2
27239 >second: new
random
27239 >second: level 0 5 2
27239 >second: post
27239 >second: hard
27239 >second: easy
27239 >second: force
27249 >second: time 30000
otim 30199
27249 >second: g1f3
27249 >second: black
27249 >second: go
39417 >It seems that it takes a long time for gotmog to send feature done=1(12 seconds

Hi Robert,
I regard this as a Winboard bug rather than a Gothmog bug. The problem
is the same as before, Winboard sends Ruffian's first move to Gothmog
without waiting for Gothmog's feature list, which includes the 'usermove'
feature. I've quoted the relevant parts of the debug file below:

if I understand the output correctly)
I do not understand why so much time and what is the problem with
sending feature done=0 immediatly after getting the go command.
Here is for comparison movei debug:
581 >first : xboard
protover 2
591 >591 >
You can see some things about movei:
1)Movei responds immediately to xboard by feature done=1
2)Movei does not have feature done=0
3)Movei needs 0.01 seconds to respond
In my code I have only:
Print("feature setboard=1 draw=0 analyze=1 ping=1 done=1\n");
Uri

Actually, it's okay to send the "feature done=0" even earlier. The relevant quote from Tim's
documentation:
" To increase the timeout, if needed, set the feature "done=0" before your first feature command
and "done=1" at the end. If needed, it is okay for your engine to set done=0 soon as it starts, even
before it receives the xboard and protover commands."
--tom

Movei does it immediately after it reads the protever command(I did not think about setting feature done=0 before getting the protover command because I thought that winboard is not going to read it).
Does winboard read information that the engine sent before winboard sent the xboard command?
The only delay that movei can have is because of initializing hash tables and some internal array so it is not ready to read winboard commands when winboard send them but this delay is a small delay and based on my memory there may be a problem only in case of delay of more than 2 seconds.
Uri

[Dan Honeycutt]

Geschrieben von:/Posted by: Dan Honeycutt at 06 June 2004 17:53:43:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Uri Blass at 06 June 2004 17:23:55:

In the past I have failed to run Gothmog on my machine, because of the feature done=0 problem (posted here at the time). I have now retried version 0.4.8 on my machine (Winboard 4.2.7, Win2k, Athlon TB 1.2GHz) and encounter still a problem, the symptoms are identical, although the exact mechanisms may not: this time Gothmog appears to not take into account the move of the white side, thinks itself is white and makes the move e2e4. The problem is reproducable. It is a pity because I would love to run Gothmog ...
The problem manifests itself when Gothmog is black and only the first time, that is when Gothmog intialises. After one "reset game" it works. But as I want to run Gothmog with WBTM, it is the first time that is important for me.
Debug file is here:
StartChildProcess (dir="f:\chess\gothmog_0.4.8") Gothmog
17235 >second: xboard
protover 2
27239 >second: new
random
27239 >second: level 0 5 2
27239 >second: post
27239 >second: hard
27239 >second: easy
27239 >second: force
27249 >second: time 30000
otim 30199
27249 >second: g1f3
27249 >second: black
27249 >second: go
39417 >>It seems that it takes a long time for gotmog to send feature done=1(12 seconds

Hi Robert,
I regard this as a Winboard bug rather than a Gothmog bug. The problem
is the same as before, Winboard sends Ruffian's first move to Gothmog
without waiting for Gothmog's feature list, which includes the 'usermove'
feature. I've quoted the relevant parts of the debug file below:

if I understand the output correctly)
I do not understand why so much time and what is the problem with
sending feature done=0 immediatly after getting the go command.
Here is for comparison movei debug:
581 >first : xboard
protover 2
591 >>591 >>
You can see some things about movei:
1)Movei responds immediately to xboard by feature done=1
2)Movei does not have feature done=0
3)Movei needs 0.01 seconds to respond
In my code I have only:
Print("feature setboard=1 draw=0 analyze=1 ping=1 done=1\n");
Uri

Actually, it's okay to send the "feature done=0" even earlier. The relevant quote from Tim's
documentation:
" To increase the timeout, if needed, set the feature "done=0" before your first feature command
and "done=1" at the end. If needed, it is okay for your engine to set done=0 soon as it starts, even
before it receives the xboard and protover commands."
--tom

Movei does it immediately after it reads the protever command(I did not think about setting feature done=0 before getting the protover command because I thought that winboard is not going to read it).
Does winboard read information that the engine sent before winboard sent the xboard command?
The only delay that movei can have is because of initializing hash tables and some internal array so it is not ready to read winboard commands when winboard send them but this delay is a small delay and based on my memory there may be a problem only in case of delay of more than 2 seconds.
Uri

Uri:
Where does the 2 seconds come from - is that Movei or a winboard limit?
In Gerbil Bruce Moreland inits the engine between sending done=0 and done=1. He says he does that so if the engine takes a little while to init winboard won't time out and think its protover 1. Bruja takes maybe 3/4 sec to init, most of that time filling a table I use for SEE. I follow Bruce's scheme since I don't support protover 1 but if I have 2 seconds I might simplify it.
Dan H.

[Tom Likens]

Geschrieben von:/Posted by: Tom Likens at 06 June 2004 17:56:11:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Uri Blass at 06 June 2004 17:23:55:

In the past I have failed to run Gothmog on my machine, because of the feature done=0 problem (posted here at the time). I have now retried version 0.4.8 on my machine (Winboard 4.2.7, Win2k, Athlon TB 1.2GHz) and encounter still a problem, the symptoms are identical, although the exact mechanisms may not: this time Gothmog appears to not take into account the move of the white side, thinks itself is white and makes the move e2e4. The problem is reproducable. It is a pity because I would love to run Gothmog ...
The problem manifests itself when Gothmog is black and only the first time, that is when Gothmog intialises. After one "reset game" it works. But as I want to run Gothmog with WBTM, it is the first time that is important for me.
Debug file is here:
StartChildProcess (dir="f:\chess\gothmog_0.4.8") Gothmog
17235 >second: xboard
protover 2
27239 >second: new
random
27239 >second: level 0 5 2
27239 >second: post
27239 >second: hard
27239 >second: easy
27239 >second: force
27249 >second: time 30000
otim 30199
27249 >second: g1f3
27249 >second: black
27249 >second: go
39417 >>It seems that it takes a long time for gotmog to send feature done=1(12 seconds

Hi Robert,
I regard this as a Winboard bug rather than a Gothmog bug. The problem
is the same as before, Winboard sends Ruffian's first move to Gothmog
without waiting for Gothmog's feature list, which includes the 'usermove'
feature. I've quoted the relevant parts of the debug file below:

if I understand the output correctly)
I do not understand why so much time and what is the problem with
sending feature done=0 immediatly after getting the go command.
Here is for comparison movei debug:
581 >first : xboard
protover 2
591 >>591 >>
You can see some things about movei:
1)Movei responds immediately to xboard by feature done=1
2)Movei does not have feature done=0
3)Movei needs 0.01 seconds to respond
In my code I have only:
Print("feature setboard=1 draw=0 analyze=1 ping=1 done=1\n");
Uri

Actually, it's okay to send the "feature done=0" even earlier. The relevant quote from Tim's
documentation:
" To increase the timeout, if needed, set the feature "done=0" before your first feature command
and "done=1" at the end. If needed, it is okay for your engine to set done=0 soon as it starts, even
before it receives the xboard and protover commands."
--tom

Movei does it immediately after it reads the protever command(I did not think about setting feature done=0 before getting the protover command because I thought that winboard is not going to read it).
Does winboard read information that the engine sent before winboard sent the xboard command?
The only delay that movei can have is because of initializing hash tables and some internal array so it is not ready to read winboard commands when winboard send them but this delay is a small delay and based on my memory there may be a problem only in case of delay of more than 2 seconds.
Uri

My engine performs a roughly one second CPU calibration test when it first starts, which can
cause problems with some Winboard compatible GUIs. So to avoid these type of problems,
which people usually consider a bug, the program sends the "done=0" feature immediately
upon initialization, basically before doing anything else. All the versions of Winboard/xboard
that I've tried, which support protocol 2, seem to work just fine. But as I mentioned, this really
helps with other GUIs.
--tom

[Tom Likens]

Geschrieben von:/Posted by: Tom Likens at 06 June 2004 18:03:04:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Dan Honeycutt at 06 June 2004 17:53:43:

In the past I have failed to run Gothmog on my machine, because of the feature done=0 problem (posted here at the time). I have now retried version 0.4.8 on my machine (Winboard 4.2.7, Win2k, Athlon TB 1.2GHz) and encounter still a problem, the symptoms are identical, although the exact mechanisms may not: this time Gothmog appears to not take into account the move of the white side, thinks itself is white and makes the move e2e4. The problem is reproducable. It is a pity because I would love to run Gothmog ...
The problem manifests itself when Gothmog is black and only the first time, that is when Gothmog intialises. After one "reset game" it works. But as I want to run Gothmog with WBTM, it is the first time that is important for me.
Debug file is here:
StartChildProcess (dir="f:\chess\gothmog_0.4.8") Gothmog
17235 >second: xboard
protover 2
27239 >second: new
random
27239 >second: level 0 5 2
27239 >second: post
27239 >second: hard
27239 >second: easy
27239 >second: force
27249 >second: time 30000
otim 30199
27249 >second: g1f3
27249 >second: black
27249 >second: go
39417 >>>It seems that it takes a long time for gotmog to send feature done=1(12 seconds

Hi Robert,
I regard this as a Winboard bug rather than a Gothmog bug. The problem
is the same as before, Winboard sends Ruffian's first move to Gothmog
without waiting for Gothmog's feature list, which includes the 'usermove'
feature. I've quoted the relevant parts of the debug file below:

if I understand the output correctly)
I do not understand why so much time and what is the problem with
sending feature done=0 immediatly after getting the go command.
Here is for comparison movei debug:
581 >first : xboard
protover 2
591 >>>591 >>>
You can see some things about movei:
1)Movei responds immediately to xboard by feature done=1
2)Movei does not have feature done=0
3)Movei needs 0.01 seconds to respond
In my code I have only:
Print("feature setboard=1 draw=0 analyze=1 ping=1 done=1\n");
Uri

Actually, it's okay to send the "feature done=0" even earlier. The relevant quote from Tim's
documentation:
" To increase the timeout, if needed, set the feature "done=0" before your first feature command
and "done=1" at the end. If needed, it is okay for your engine to set done=0 soon as it starts, even
before it receives the xboard and protover commands."
--tom

Movei does it immediately after it reads the protever command(I did not think about setting feature done=0 before getting the protover command because I thought that winboard is not going to read it).
Does winboard read information that the engine sent before winboard sent the xboard command?
The only delay that movei can have is because of initializing hash tables and some internal array so it is not ready to read winboard commands when winboard send them but this delay is a small delay and based on my memory there may be a problem only in case of delay of more than 2 seconds.
Uri

Uri:
Where does the 2 seconds come from - is that Movei or a winboard limit?
In Gerbil Bruce Moreland inits the engine between sending done=0 and done=1. He says he does that so if the engine takes a little while to init winboard won't time out and think its protover 1. Bruja takes maybe 3/4 sec to init, most of that time filling a table I use for SEE. I follow Bruce's scheme since I don't support protover 1 but if I have 2 seconds I might simplify it.
Dan H.

It's set by xboard, more from the redoubtable Mr. Mann:
"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."
Chances are good an hour will be more than enough.
--tom

[Robert Allgeuer]

Geschrieben von:/Posted by: Robert Allgeuer at 06 June 2004 18:05:23:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tord Romstad at 06 June 2004 15:31:27:

Hi Robert,
I regard this as a Winboard bug rather than a Gothmog bug. The problem
is the same as before, Winboard sends Ruffian's first move to Gothmog
without waiting for Gothmog's feature list, which includes the 'usermove'
feature. I've quoted the relevant parts of the debug file below:

As you can see above, Winboard sends Gothmog the 'black' command
and Ruffian's first move without the 'usermove' prefix. Only
afterwards does it listen to Gothmog's feature list, which contains
'usermove=1' and 'colors=0'. In version 0.4.7 and earlier you
could to some extent blame Gothmog for the problem, because it didn't
use 'feature done=0' at the beginning of the feature list. This is
no longer the case in 0.4.8.
I'll see if I can find some workaround for the next public version.
Meanwhile, have you tried running Gothmog in UCI mode with the
PolyGlot adapter? I can send you a polyglot.ini file if you want.
Tord

I am not sure about that; the way I interpret the log:
Winboard gives Gothmog 10 seconds time to respond to the xboard command (e.g. with feature; this is probably an undocumented timeout value), so I guess that after these 10 seconds Winboard assumes the lowest demonitor in terms of WB protocol and continues in that spirit. Gothmog then does send the feature done=0, but too late, in fact it takes it some 20 seconds or so. (Does Gothmog initialise tablebases etc. before sending the feature command, which takes that amount of time?)
I believe the feature done=0 command should be sent immediately, even when the rest of the features are only sent much later, e.g. Ruffian does it that way.
Essentially the problem is still the same, in the past feature done=0 was not sent at all and Winboard continued after 10 seconds, now feature done=0 is sent, but too late, and Winboard continues after 10 seconds.
I should also add that Gothmog is the only engine that has such problems in my setup (which is nothing special at all), and I have >100 engines installed.
No I have not tried Polyglot, would also not be too happy if this were the only way to get Gothmog to run, because it appears as a kind of overhead. But I would nevertheless be interested in the ini file, as a kind of last resort. My mail address is rwa at pt dot lu.
Thanks
Robert
>>StartChildProcess (dir="f:\chess\gothmog_0.4.8") Gothmog
>>17235 >second: xboard
>>protover 2
>>27239 >second: new
>>random
>>27239 >second: level 0 5 2
>>27239 >second: post
>>27239 >second: hard
>>27239 >second: easy
>>27239 >second: force
>>27249 >second: time 30000
>>otim 30199
>>27249 >second: g1f3
>>27249 >second: black
>>27249 >second: go
>>39417 <second: feature done=0
>>Interrupting second
>>39417 <second: feature usermove=1
>>39417 >second: accepted usermove
>>39437 <second: feature colors=0
>>39437 >second: accepted colors
>>39437 <second: feature myname="Gothmog 0.4.8"
>>39437 >second: accepted myname
>>39437 <second: feature done=1
>>39437 >second: accepted done
>>39437 <second: 0 0 0 0 (e2e4 d2d4 )
>>39447 <second: move e2e4
>

[Robert Allgeuer]

Geschrieben von:/Posted by: Robert Allgeuer at 06 June 2004 18:08:05:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tom Likens at 06 June 2004 18:03:04:

...

It's set by xboard, more from the redoubtable Mr. Mann:
"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."
Chances are good an hour will be more than enough.
--tom

And based on the log I think in practice those 2 seconds are 10 seconds.

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 06 June 2004 18:20:59:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Robert Allgeuer at 06 June 2004 18:08:05:

...

It's set by xboard, more from the redoubtable Mr. Mann:
"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."
Chances are good an hour will be more than enough.
--tom

And based on the log I think in practice those 2 seconds are 10 seconds.

Yes and it takes gothmog more than 22 seconds to respond to the protever command by feature done=0(here is the relevant part of the debug again)
I looked previously only at the time between the go command and the feature done=0
17235 >second: xboard
protover 2
27239 >second: new
random
27239 >second: level 0 5 2
27239 >second: post
27239 >second: hard
27239 >second: easy
27239 >second: force
27239 >first : computer
27239 >second: computer
27239 >first : black
27239 >first : time 30000
otim 30000
27239 >first : white
27239 >first : go
27249 second: time 30000
otim 30199
27249 >second: g1f3
27249 >second: black
27249 >second: go
39417

[Dan Honeycutt]

Geschrieben von:/Posted by: Dan Honeycutt at 06 June 2004 23:08:54:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tom Likens at 06 June 2004 18:03:04:

Thanks Tom. Based on your and other comments I'll leave my init alone.
Dan H.

[Tord Romstad]

Geschrieben von:/Posted by: Tord Romstad at 06 June 2004 23:10:58:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Robert Allgeuer at 06 June 2004 18:05:23:

Winboard gives Gothmog 10 seconds time to respond to the xboard command (e.g. with feature; this is probably an undocumented timeout value), so I guess that after these 10 seconds Winboard assumes the lowest demonitor in terms of WB protocol and continues in that spirit. Gothmog then does send the feature done=0, but too late, in fact it takes it some 20 seconds or so. (Does Gothmog initialise tablebases etc. before sending the feature command, which takes that amount of time?)
I should also add that Gothmog is the only engine that has such problems in my setup (which is nothing special at all), and I have >100 engines installed.
No I have not tried Polyglot, would also not be too happy if this were the only way to get Gothmog to run, because it appears as a kind of overhead. But I would nevertheless be interested in the ini file, as a kind of last resort. My mail address is rwa at pt dot lu.

Yes, Gothmog does all initialization immediately when it starts up, it doesn't wait for the
xboard command. Remember that it is not only an xboard engine, it is supposed to work
even if you never enter xboard mode at all. I'll try to make it send the 'feature done=0'
command before receiving any input from xboard, and see whether that helps.
The long delay is really strange. Gothmog seems to finish its initialization almost
instantly on all computers I have tried.
And you are the only person among hundreds of users who have reported this problem.
There is some kind of mysterious problem which causes Gothmog to spend very long
time during intialization on your computer, but I have no idea what it could be.
Please don't spend a lot of effort trying to make Gothmog work in your setup. It is
essentially a dead engine, and not a very interesting one to test. There are many other
engines you could try, which are still not on your list.
Still, I will mail you a polyglot init file, and try to send "feature 0" immediately at
startup in the next (and hopefully last) public version of Gothmog.
Tord

[Tord Romstad]

Geschrieben von:/Posted by: Tord Romstad at 06 June 2004 23:14:01:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tom Likens at 06 June 2004 16:34:58:

Actually, it's okay to send the "feature done=0" even earlier. The relevant quote from Tim's
documentation:
" To increase the timeout, if needed, set the feature "done=0" before your first feature command
and "done=1" at the end. If needed, it is okay for your engine to set done=0 soon as it starts, even
before it receives the xboard and protover commands."

Thanks for the tip, Tom! I had no idea xboard even listened to the engine output
before the 'xboard' command was sent. I'll try to put a printf("feature done=0\n")
at the beginning of my main() function.
Tord

[Robert Allgeuer]

Geschrieben von:/Posted by: Robert Allgeuer at 06 June 2004 23:34:27:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tord Romstad at 06 June 2004 23:10:58:

[Tom Likens]

Geschrieben von:/Posted by: Tom Likens at 07 June 2004 05:09:10:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tord Romstad at 06 June 2004 23:14:01:

Actually, it's okay to send the "feature done=0" even earlier. The relevant quote from Tim's
documentation:
" To increase the timeout, if needed, set the feature "done=0" before your first feature command
and "done=1" at the end. If needed, it is okay for your engine to set done=0 soon as it starts, even
before it receives the xboard and protover commands."

Thanks for the tip, Tom! I had no idea xboard even listened to the engine output
before the 'xboard' command was sent. I'll try to put a printf("feature done=0\n")
at the beginning of my main() function.
Tord

Hey Tord,
It's the least I can do for all the help and good suggestions you've
contributed over the last few months.
--tom

[Robert Allgeuer]

Geschrieben von:/Posted by: Robert Allgeuer at 07 June 2004 11:51:18:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tord Romstad at 06 June 2004 23:10:58:

Please don't spend a lot of effort trying to make Gothmog work in your setup. It is
essentially a dead engine, and not a very interesting one to test. There are many other
engines you could try, which are still not on your list.
Still, I will mail you a polyglot init file, and try to send "feature 0" immediately at
startup in the next (and hopefully last) public version of Gothmog.
Tord

Forgot to respond to this: in fact I do consider Gothmog one of the most interesting engines out there, with interesting playing style, as one can conclude from various games and posts, and interesting techniques. So it is a pity that up to now I cannot run it ...
Robert

[Tord Romstad]

Geschrieben von:/Posted by: Tord Romstad at 07 June 2004 12:43:59:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Robert Allgeuer at 07 June 2004 11:51:18:

Please don't spend a lot of effort trying to make Gothmog work in your setup. It is
essentially a dead engine, and not a very interesting one to test. There are many other
engines you could try, which are still not on your list.

Forgot to respond to this: in fact I do consider Gothmog one of the most interesting engines out there, with interesting playing style, as one can conclude from various games and posts, and interesting techniques.
So it is a pity that up to now I cannot run it ...

I wish I could agree. By now I hate Gothmog more than any other piece of
software. It is rotten to the core, and has been kept alive artificially
far too long.
Yes, even if it is the last thing I ever do with Gothmog, I will try to make
it work for you before I stop working on the program.
Tord

[Robert Allgeuer]

Geschrieben von:/Posted by: Robert Allgeuer at 07 June 2004 13:30:18:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.8 Winboard protocol problem geschrieben von:/posted by: Tord Romstad at 07 June 2004 12:43:59:

Please don't spend a lot of effort trying to make Gothmog work in your setup. It is
essentially a dead engine, and not a very interesting one to test. There are many other
engines you could try, which are still not on your list.

Forgot to respond to this: in fact I do consider Gothmog one of the most interesting engines out there, with interesting playing style, as one can conclude from various games and posts, and interesting techniques.
So it is a pity that up to now I cannot run it ...

I wish I could agree. By now I hate Gothmog more than any other piece of
software. It is rotten to the core, and has been kept alive artificially
far too long.
Yes, even if it is the last thing I ever do with Gothmog, I will try to make
it work for you before I stop working on the program.
Tord

Thanks very much, hope your new program will pick-up where Gothmog stopped.
Robert
PS.: I have no clue why my installation should be slow during installation ...