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?