gtp September 2001

gtp@lists.lysator.liu.se

6 participants
6 discussions

GTP web page
by Gunnar Farneb�ck 17 Sep '01

17 Sep '01

I've put up a web page for the GTP at http://www.lysator.liu.se/~gunnar/gtp This contains working documents, sample implementations and all other relevant information. There are probably still some missing items, so please alert me to errors and omissions on the page. Suggestions for general improvements are of course also welcome. /Gunnar

1 0

Re: [gtp] GTP Specification-Draft
by Hellwig Geisse 17 Sep '01

17 Sep '01

Phil, I am currently preparing a formal specification of the grammar (based on your draft) which can be fed into flex/bison to generate a GTP command parser. I will integrate this in a very simple application so that one can get a feeling for the behaviour of the protocol by manually feeding it commands and observe the answers. Actually this is already half way done (error recovery is missing yet); I will make it available ASAP. The formal spec perhaps can help to cleanup syntax issues in the GTP docs as well. Hellwig

3 3

GTP Specification-Draft
by Hellwig Geisse 15 Sep '01

15 Sep '01

Hi folks, I joined this mailing list only very recently, so please be patient with me if I missed one point or another in the preceding discussions. I am interested in implementing the Go Text Protocol (GTP) Version 2, for which I downloaded the draft spec revision 9. I assume this to be the most recent published one, right? First of all, thanks for the hard work which already went into this document. But during my implementation work I ran into some questions which I want to discuss here. 1. What kind of return (success or failure) does the engine have to return if it does not implement the command which was requested? The spec says "..should return 'not_implemented'", but does not specify the return type (by the way, there is a typo in the section on failure: it must read "Here the '?' character..." instead of "Here the '=' character ..."). Only much later, in the section on error messages, one can guess that this return must be a failure return. I propose to phrase this sentence something like that: "Commands that are not recognized by the engine should return 'not_implemented' in a failure return." 2. The grammar as specified cannot be used to parse commands because it is ambiguous in several places. Let me give an example: 'command-arguments' can be a 'command-argument' which in turn can be 'text'. 'text' consists of 'printable' characters. The hash "#" is a 'SYM' and therefore a 'printable' character. This is in conflict with its use as the character which starts a comment. By the way, the 'text' "a1" may as well be a 'coordinate' in a command argument and thus has two different derivations also. I see two possible solutions: a) Cleanup the specification so that a parser for commands and responses can be generated by tools (e.g. flex & bison). I could do that, in case this is really wanted. This requires some extra work and I am not sure if it is worth the effort. b) Drop the attempt to formally specify the protocol. Use explanations in plain English instead. This is not as bad as it sounds, and it is used already in some places in the current spec (e.g., response-message = { depends on the ... }). 3. A few other grammar curiosities: a) Where is 'WS' (white space) used? b) "date-time = date | date time" is missing an 'SP' between date and time. By the way: does 'SP' really mean a single space character? So one cannot, for example, separate two arguments with two spaces. Frequently, horizontal tabs ('\t') are also considered "white space". c) A comment following a command argument must not be preceded by an 'SP'. Is this really intended? d) A command which solely consists of a command name may not be followed by a comment. Really? 4. Another typo: "The core command set consists of the following eleven (14) commands:" 5. The error messages specified for various commands sometimes include 'not_implemented' and sometimes they don't. What is the reason? This has apparently nothing to do with the different command sets: gen_move is in the core set and nevertheless may be answered with 'not_implemented'. By the way: is it spelled "gen_move" or "genmove"? 6.What is the exact format of the answer to 'help'? Specifically, is the first command returned on the same line as the '=' or on the next one? 7. It is explicitly stated that coordinates and colors are case insensitive. This does not hold for "yes"/"no" arguments in a suicide command, for example, nor for the argument of the 'scoring_system' command. What is the reason? (One can define this at will, of course, but IMHO consistency is a desirable goal.) 8. To write a competitive engine, the concept of time has to be incorporated. Then the human opponent (or an arbiter in case of a computer tournament) has to fix the timing system. How should this be communicated to the engine? (Perhaps this goes under the "Tournament Command Set", or you have discussed it already; please enlighten me on this subject. The communication through command-line arguments during engine start-up is IMHO a non-solution because you open up a second way to transmit information to the program: the very next question is 'why not send <insert, e.g., boardsize here> in this way?'.) Please don't get me wrong: I do not want to exercise fault-finding on your specification draft. I only tried to implement things and I think that my experience could help to improve an already well- written document. Regards, Hellwig

5 4

linefeed and carriage return (was Re: [gtp] Re: VC regression failures)
by Dave Denholm 07 Sep '01

07 Sep '01

Daniel Bump <bump(a)match.Stanford.EDU> writes: > > So it is worth reviewing how GNU Go 2.7.253 handles the newlines > in the GTP. > > Newlines are written in gtp.c and play_gtp.c with the standard > C function printf(" ... \n"). On Unix this makes a LF=\012. > On DOS it makes CRLF. David stated that on Macintosh it makes > just a Carriage return but we believe this is not true with > OS X. If it were, things would be worse broke than they are now. > > (Does anyone know?) FWIW... just discovered that the perlport man page has some discussion on this : ISSUES Newlines In most operating systems, lines in files are terminated by newlines. Just what is used as a newline may vary from OS to OS. Unix traditionally uses \012, one kind of Windows I/O uses \015\012, and Mac OS uses \015. Perl uses \n to represent the "logical" newline, where what is logical may depend on the platform in use. In MacPerl, \n always means \015. In DOSish perls, \n usually means \012, but when accessing a file in "text" mode, STDIO translates it to (or from) \015\012. Due to the "text" mode translation, DOSish perls have limitations of using seek and tell when a file is being accessed in "text" mode. Specifically, if you stick to seek-ing to locations you got from tell (and no others), you are usually free to use seek and tell even in "text" mode. In general, using seek or tell or other file operations that count bytes instead of characters, without considering the length of \n, may be non-portable. If you use binmode on a file, however, you can usually use seek and tell with arbitrary values quite safely. A common misconception in socket programming is that \n eq \012 everywhere. When using protocols such as common Internet protocols, \012 and \015 are called for specifically, and the values of the logical \n and \r (carriage return) are not reliable. print SOCKET "Hi there, client!\r\n"; # WRONG print SOCKET "Hi there, client!\015\012"; # RIGHT [NOTE: this does not necessarily apply to communications that are filtered by another program or module before sending to the socket; the the most popular EBCDIC webserver, for instance, accepts \r\n, which translates those characters, along with all other characters in text streams, from EBCDIC to ASCII.] However, using \015\012 (or \cM\cJ, or \x0D\x0A) can be tedious and unsightly, as well as confusing to those maintaining the code. As such, the Socket module supplies the Right Thing for those who want it. use Socket qw(:DEFAULT :crlf); print SOCKET "Hi there, client!$CRLF" # RIGHT When reading from a socket, remember that the default input record separator ($/) is \n, but code like this should recognize $/ as \012 or \015\012: while (<SOCKET>) { # ... } Better: use Socket qw(:DEFAULT :crlf); local($/) = LF; # not needed if $/ is already \012 while (<SOCKET>) { s/$CR?$LF/\n/; # not sure if socket uses LF or CRLF, OK # s/\015?\012/\n/; # same thing } And this example is actually better than the previous one even for Unix platforms, because now any \015's (\cM's) are stripped out (and there was much rejoicing). An important thing to remember is that functions that return data should translate newlines when appropriate. Often one line of code will suffice: $data =~ s/\015?\012/\n/g; return $data; dd -- dave.denholm(a)insignia.com http://www.insignia.com

1 0

Getting the boardsize
by Daniel Bump 05 Sep '01

05 Sep '01

Currently, at least with GNU Go there doesn't seem to be any way to get the engine's opinion about boardsize, komi, etc. Normally the gtp controller will know these before the engine does but there is an exception after the command loadsgf is executed. Because of this exception, there should be a way of getting the boardsize from the engine. Actually there should be a way of getting the whole position from the engine but for my purposes just getting the boardsize will be enough. There seem to be two obvious ways of doing this: (1) allow the command 'boardsize' without arguments. The gtp response is to return the boardsize without setting it. (2) a new command query_boardsize with obvious functionality: loadsgf games/nicklas/nicklas9.sgf = black query_boardsize = 9 I've patched GNU Go 3.1.2 to add this command (because I need it) but I wonder if this is something that is likely to become part of the protocol or not. Dan

2 2

Server Commands
by William M. Shubert 05 Sep '01

05 Sep '01

Well things have been quiet lately, so I think I'll put out a set of commands for server play to think about. I've been going from Phil's straw man version of the spec; Phil, you can plug these into the next revision if you want. It seems that only 5 more commands are needed. The trickiest thing is setting up games; and the related problem of specifying the server game exactly when somebody challenges the program. To do things well, we need to be able to tell the engine exactly what the time system is. Engines can choose to ignore this of course. Having written a client for IGS/NNGS/etc. and for KGS, I'm pretty sure that these five commands will give us the functionality we need for all these servers. If anybody has information on dashn, cyberkiwon, etc., and thinks this will have to be changed for them, that's no problem. ********************************************************************** GTP commands for go servers ---------------------------------------------------------------------- Command: play_mode This is the bridge's attempt to find out whether the go engine is looking for games, or if it intends to play a particular game vs. a particular opponent. Engine Responses: If the engine is in general looking for games: any If the engine is looking to play a particular opponent, with particular settings: <color> <user> <handicap> <handicap fixed?> <ko setting> <suicide> <scoring system> <time system> Time system format: <style>[,<main_time>[,<byo-yomi time>,(<stones>|<# of periods>)]] <style> is one of "none", "absolute", "canadian", "byoyomi" ---------------------------------------------------------------------- Command: game_ok <color> <user> <handicap> <handicap fixed?> <ko setting> <suicide> <scoring system> <time> This is the bridge's query to the engine, as to whether a particular game is acceptable. Note that the arguments are exactly the same as the response to "play_mode". Engine Responses: "y" or "n" "y" will probably be followed soon by a serios of "komi", "board_size", etc. commands then finally a "new_game". ---------------------------------------------------------------------- Command: undo_ok Here the bridge is saying that the opponent wants an undo. The engine can allow or disallow. Responses: "y" or "n" ---------------------------------------------------------------------- Command: query_dead The game is over. The brige is asking the engine what stones it thinks are dead. If the engine does not know, then it answering with a not implemented error is OK...in this case, it will be up to the opponent to decide which stones are dead. responses: List all locations on the board that contain dead stones. ---------------------------------------------------------------------- Command: time_left <color> <seconds left in period> [<stones left>] The server is telling the engine how much time is left on the clocks for the color specified. The time reported should be the server's idea of how much time is left, so if there is netlag the engine's clock will not drift from the server's. ---------------------------------------------------------------------- Command: comment The server is telling you that somebody is trying to talk to the engine. Any text in the response will be sent back to the user who was talking. ********************************************************************** -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

gtp September 2001