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
Hellwig wrote:
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.
Ok, here it is: URL:http://hera.mni.fh-giessen.de/~hg53/gtpparser.tar.gz If you experience any difficulties with this link, please let me know.
To compile it, you will need flex and bison, and, of course, gcc. (Lex and Yacc should do, but I didn't check this.) A Makefile is included. After 'make' you will end up having an executable named 'gtpparser'. When run, it expects GTP commands from stdin and displays responses on stdout. The program also outputs some debugging information which is preceded by <DEBUG> in the output; you can disable this feature by setting the variable 'debug' in cmds.c to 0.
Please give it a try; any critique is always welcome.
The formal specification relevant for the definition of GTP can be found in gtp.l (lexical spec) and gtp.y (grammar spec).
While writing the software, I stumbled upon another bunch of questions:
1. Does the engine have to have the notion of a "current player"? I remember having read in the archives that Gunnar objects.
2. If there is a "current player", why is white the default? Shouln't it be black?
3. Is "fixed_handicap 0" a legal command? (It should be.)
4. The fixed_handicap command description should contain a statement that on success, the handicap stones are placed onto the board. If indeed present, should the current player then change to white?
5. Are the coordinates which constitute the response to a fixed_handicap command output in separate lines?
6. The 'state defaults' section should contain the statement "The board is empty".
7. Case insensitivity in color specification, how far goes this? Is "wHiTE" really ok? Or can a more restrictive set be specified, such as e.g. "one of 'w', 'white', 'W', or 'WHITE'"?
8. If a move command is successfully completed, the spec does not say anything about a) current move number (updated?) b) current player (toggled?)
9. Is "pass" a legal 'coordinate' everywhere (e.g. in setup)?
10. In a response in which the engine gives a move, does case matter?
11. The current specification does not give the engine the possibility to include any comments into responses. This is of course not really necessary, but would have allowed, e.g., the debugging output of my protocol exerciser to be put into the responses. This feature would not in my opinion complicate response analysis unduly. What's your opinion?
Hellwig wrote:
- Does the engine have to have the notion of a "current
player"? I remember having read in the archives that Gunnar objects.
No, the protocol should allow moves by either player at any time. For tournament use the moves would always be alternating of course. An engine which is written in a way which can't cope with moves out of turn should keep track of color to play and return error if requested to make a move it can't handle.
- If there is a "current player", why is white the default?
Shouln't it be black?
Black usually starts, so if there had been a current player it should have been black to start with.
- Is "fixed_handicap 0" a legal command? (It should be.)
Yes, letting "fixed_handicap 0" leave the board empty is no problem. What's worse is "fixed_handicap 1". This is quite a bit degenerated. Current GNU Go doesn't accept it.
- The fixed_handicap command description should contain
a statement that on success, the handicap stones are placed onto the board.
Agreed. The specification should also tell exactly where the handicap stones should go. (I don't know if this is controversial. I believe at least GMP, IGS, NNGS, and GNU Go have compatible placement.)
If indeed present, should the current player then change to white?
No current player, but had there been one it should have changed to white for handicap>0.
- Are the coordinates which constitute the response to a
fixed_handicap command output in separate lines?
No, only one line with space between each move.
- The 'state defaults' section should contain the statement
"The board is empty".
This and "no captured stones" are incidentally the only defaults needed in the specification. If the controller has any specific opinions on boardsize, komi, and so on, it should tell the engines explicitly.
- Case insensitivity in color specification, how far goes this?
Is "wHiTE" really ok? Or can a more restrictive set be specified, such as e.g. "one of 'w', 'white', 'W', or 'WHITE'"?
In terms of implementation the straightforward solution is to change the whole string to lower case and then do the comparison, so then also the sillycapsed versions would be accepted. For serious use "w", "W", "white", "WHITE", and possibly "White" should suffice. Would this simplify the formal specification?
- If a move command is successfully completed, the spec does
not say anything about a) current move number (updated?) b) current player (toggled?)
Neither state needs to be specified in the protocol.
- Is "pass" a legal 'coordinate' everywhere (e.g. in setup)?
It doesn't seem useful there. I don't think it should be legal. (Btw, does SGF allow an "AB[]" property? It's not clear to me from a quick look at the spec.)
- In a response in which the engine gives a move, does case
matter?
No, either case should be okay.
- The current specification does not give the engine the
possibility to include any comments into responses. This is of course not really necessary, but would have allowed, e.g., the debugging output of my protocol exerciser to be put into the responses. This feature would not in my opinion complicate response analysis unduly. What's your opinion?
I must admit I haven't even considered this possibility. It certainly wouldn't be a big problem to filter out comments at the controller end of the link.
/Gunnar
Thanks Hellwig,
I look forward to reviewing the lex/yacc grammar! Most of your questions/comments will be addressed in the next working draft. Give me a few days to compile everything.
Phil
-
Gunnar Farneb�ck -
Hellwig Geisse -
Phil Garcia