mainGNU Go - Support: sr #105877, non-conforming to GTP in...

 
 

sr #105877: non-conforming to GTP in gtp_final_status_list()

Submitter:  Serge Batalov <uncle_serge>
Submitted:  Tue 29 May 2007 09:53:50 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 17 Oct 2007 11:34:41 AM UTC, comment #6: 

A string is a string not a string. I am not sure if Serge understand that string in 4.3 is probably not referring to string in 3.2.1. That is why Gunnar say the GTP spec is unclear and need to add some text to clarify this.

But still Serge say that the dead stones come more then one on the same line only separated by a space. And if that is true then something is wrong. I tried yesterday, and it was only one stone per line.

Could it be that the KGS GTP adapter does not follow 2.4 as what is a line. Is it expecting CRLF when GNU Go only output LF. This sounds like it could be the case. And then it is a KGS GTP adapter error.

Jens Yllman <jpyllman>
Wed 17 Oct 2007 10:20:52 AM UTC, comment #5: 

Since May, I've actually lost most of the steam, but you'd be interested to know that at KGS they find it silly when GNU robots give up completely won positions by not being able to negotiate via the KGS protocol (I've spoken with a few KGS admins, quote: "GNU bots are full of bugs" is what they've said). The opponents simply abuse this feature. Maybe it is the bug in the KGS JAR adapter, maybe not.

I don't really care. Someone who actually wants to run the KGS robots may care. I run 10 different robot kinds on another server (Go being one of the robots, the others are chess, losers, gomoku, reversi, and different flavors of backgammon), but since they play Go games till the end - I don't (currently) care. Their server is in its infancy in Go, there's no arbitration, hence - there're no bugs. :-)

P.S. The anonymous author in comment #3 was not me.

Serge Batalov <uncle_serge>
Sun 14 Oct 2007 08:15:24 AM UTC, comment #4: 

I'm fairly certain I did not propose to change anything. I was only trying to explain a misunderstanding.

Gunnar Farnebäck <gf>
Group administrator
Sat 13 Oct 2007 02:42:33 AM UTC, comment #3: 

You cannot be serious with that closing comment. The concept of a GNU Go worm is totally undefined in the GTP spec and it would be silly to use it in the specification instead of the simple and clear concept of a string as a set of stones connected by direct adjacency.

Anonymous
Thu 11 Oct 2007 07:40:36 PM UTC, comment #2: 

It's a bit of a confusion of terminology in the GTP spec, in that context string refers to the concept of a connected set of stones (also called worm in GNU Go sources). It's also the reason why it suffices to communicate only one stone, the rest are uniquely determined for any application which has an internal representation of the board state.

Anyway, this is not a problem with GNU Go, so I'm closing this issue.

Gunnar Farnebäck <gf>
Group administrator
Wed 30 May 2007 11:33:44 PM UTC, comment #1: 

On a second thought, it is the format description which is self-inconsistent: http://www.lysator.liu.se/~gunnar/gtp/
The GTP page says in paragraph 6.3.4:

"final_status_list
arguments status
  string status - Requested status.
effects none
output stones
  *vertex**& stones - Stones with the requested status.
comments See section 4.3 for details."

...and section 4.3 states "The second command, final_status_list, is used to query an engine about the status of the stones. This command takes a string argument which may be one of alive, seki, and dead. The result is reported by listing all stones having the requested status. The list is organized with one string per line."
According to 3.2.1 "A string is a sequence of printable, non-whitespace characters. Strings are case sensitive. "

The kgsGtp adapter implements section 4.3 and 3.2.1 literally! The GNU Go code implements 6.3.4 +verbatim+" vertex*& "-verbatim-.

Theres's a disconnect here between implementations because of a self-contradicting GTP description.

Suggestions?

Serge Batalov <uncle_serge>
Tue 29 May 2007 09:53:50 PM UTC, original submission:  

GTP states that the list returned by this function (e.g. "dead") should contain one string per line. However, the existing code outputs space-separated group string lists per line. This is convenient to read, but non-conforming to GTP description.

A GTP adapter (e.g. to KGS) simplemindedly sends only one (the first) stone per group to the server during arbitration. This is probably because it expects everything after the first string on the line to be comments (as per GTP description).

This is true for all OSs (there's no such choice, so I chose None). Affected files: interface/play_gtp.c interface/gtp.c and the regression tests.

Serge Batalov <uncle_serge>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jpyllman (Posted a comment)
  • -email is unavailable- added by gf (Posted a comment)
  • -email is unavailable- added by uncle_serge (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-10-11 gf StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code