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
It's in the very early draft stages. Gunnar sent me a list of changes today.
----- Original Message ----- From: "Hellwig Geisse" Hellwig.Geisse@mni.fh-giessen.de To: gtp@lists.lysator.liu.se Sent: Thursday, September 13, 2001 11:56 AM Subject: [gtp] GTP Specification-Draft
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.
- 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."
- 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 ... }).
- 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?
- Another typo:
"The core command set consists of the following eleven (14) commands:"
- 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?
- 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.)
- 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 _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
In addition to Phil's draft specification, some GTP doc may be found in the GNU Go texinfo. There is also some code in GNU Go (two files gtp.c and gtp.h) which has a more liberal license than the GPL allowing use in proprietary software.
The protocol was developed mostly by Gunnar Farneback in GNU Go 2.7.xxx culminating in GNU Go 3.0. There have been a few minor changes in GNU Go's implementation post-3.0. There are some discrepancies between Phil's draft and GNU Go's implementation and both are likely to change in the future. But in cases of doubt the safest course might be to copy GNU Go's behavior, and to be prepared to make changes in the future as the protocol evolves. Hopefully by the time GNU Go 3.2 exists (or even long before) the specification will be complete. In any case you should read the documentation in the GNU Go Texinfo.
- 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
Presumably this is a failure so assuming this proposal is adopted the full response would be:
? not_implemented
This is not currently GNU Go's behavior. GNU Go does this:
extemporize ? unknown command: 'extemporize'
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:
You should be aware that the protocol is asymmetrical so the command syntax could overlap harmlessly with the response syntax.
By the way: is it spelled "gen_move" or "genmove"?
"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?
In GNU Go the first command is on the same line as '='.
Dan
Hellwig wrote:
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?
It's the most recent one but expect quite a few significant changes to the next one. To be perfectly honest it's a little early to do an implementation based on it yet.
- 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."
Yes, it should definitely be a failure.
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 ... }).
You're very welcome to help cleanup the grammar if you feel like it. I agree that an informal definition is preferrable to an inconsistent formal one.
- 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".
It's probably asking for trouble not to allow multiple spaces and horizontal tabs, but I'm not certain about this.
c) A comment following a command argument must not be preceded by an 'SP'. Is this really intended?
No.
d) A command which solely consists of a command name may not be followed by a comment. Really?
No.
The idea is that everything from (inclusive) a hash sign to (exclusive) the following newline should be discarded on input, together with any occurence of CR.
By the way: is it spelled "gen_move" or "genmove"?
It should be 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?
It's returned on the same line.
- 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.)
The suicide and scoring_system commands still need review. In the GNU Go implementation of GTP version 1 the case sensitivity only is important in the loadsgf command, since file names tend to be case sensitive.
- 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?
Yes, this is important and missing. There has been some discussion about it on the list.
(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?'.)
I don't agree about this. While there should be provisions to communicate all important information through the protocol, I see no major problems with additional channels for setting up parameters. If some program has to be recompiled to switch between boardsizes that shouldn't disqualify it from being used in contexts where the boardsize is being known beforehand, e.g. a 13x13 tournament. For use on a server, on the other hand, such a limitation would be more problematic.
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.
Your input is appreciated.
/Gunnar
- 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?
Yes, this is important and missing. There has been some discussion about it on the list.
The Generic Game Server URL:http://www.neci.nec.com/homepages/igord/gsa-ggs.htm has a pretty advanced notion of time. I cite here from the description of time settings for games URL:http://www.neci.nec.com/homepages/igord/service-clock.txt:
GGS clock can be specified in the following way:
[ini[,[N]m1]]/[inc[,[N]m2]]/[ext[,[N]m3]]
where ini, inc and ext are times specified in [[HH:]MM:]SS format.
Clock parameters have following meaning:
Initial time (ini) is the initial time on the players clock. Player has to complete m1 moves - or if m1 is 0 to finish the whole game before clock goes to zero. Parameter N specifies what happens if the clock goes to 0 and player does not complete game or m1 moves. If N is not present, clock goes into soft-timeout loss[1]. If N (read NOT loss) is present, clock goes into overtime (extension time) mode. Completion of m1 moves causes clock to go to overtime mode too.
In overtime mode, player has to make m3 moves (or finish the game if m3 is 0) before clock reaches 0. Parameter N specifies how is overtime added to the clock. If N is not present, overtime is additive, i.e. it is added to the remaining time. if N (read NOT add) is present, clock is (re)set to overtime every m3 moves and any unused time is lost. If player does not complete game or m3 moves during overtime clock goes into hard-timeout[2].
Increment time (inc) is the time that will be added to players clock every m2 moves (m2 >= 1). Parameter N specifies how is increment time added to the clock. If N is not present, increment time is additive, i.e. it is added to the clock. If N (read NOT additive) is present, min( spent_time, increment_time ) is added to the clock.
See formula page to see how to access clock parameters in a formula.
Footnotes:
[1] Some games, like Othello have soft-timeout, it ensures minimal loss, but player is allowed extension time to complete the game. The actual score is min( minimal_loss, board_score ). Other (mostly win/draw/loss) games treat soft-timeout as hard-timeout.
[2] Hard-timeout results in maximal loss.
Here are few examples that ilustrate clock specifications:
Chess tournament clock: 2 hours for 40 minutes, if the game is not finished, players receive additional 30 minutes to complete the game: 2:00:00,40//30:00,0
Blitz chess, Fisher clock: 2 minutes plus 12 seconds per move: 2:00,0/12/0
Blitz chess, Bronstein clock: 2 minutes, at most 12 seconds per move: 2:00,0/12,N1/0
Othello tournament clock: 30 minutes to complete the game, 2 minutes to complete the lost game in the case of timeout: 30:00,0//2:00,0
Go tournament clock: 30 minute to complete the game, if the game is not finished, player receives 5 minutes overtime for 10 moves: 30:00,N0//5:00,N10
5.Oct.2000 (c) Igor Durdanovic, igord@research.nj.nec.com
-Inge
-
Daniel Bump -
Gunnar Farneb�ck -
Hellwig Geisse -
Inge Wallin -
Phil Garcia