Gunnar wrote:
Adriaan wrote:
GTP. I am writing a nngs <--> gtp interface (unix: pipe+fork+exec)
I assume you are aware that there already exists two go server to GTP bridges, gnugoclient by me and gtpclient.c by Tristan Cazenave. How does your program differ? Will it be publically available?
Yes, I know. Have not checked Tristan's out though. There are mixed reasons for this, some personal or coincidental:
1) The last two years, I have done some hacking into NNGS, together with Nils Lohner. At the moment, this line of NNGS is more or less unused. It has become incredible stable though (I did perform replay of thousands of sgf-files via an automated testclient, without crash or resourceleaks. I hope Nils will soon releas this 1.1.14 version) I think a some_nngsclient<->NNGS<->some_bridge<->some_go_engine is a useable architecture for go programming. I don't like to do (G)UI stuff, so letting the nngs-client do that for me is just laziness. NNGS can be used as a independant middleman, maintaining the board(s), in a automated game or tournament. 2) I failed(for various reasons) in getting your pike-client up and running. 3) For my own project, I decided to use GTP as one of the interfaces. I did not want to complicate the program by adding a separate interface for command && control, add select/poll or threading. Now the protocolconvertor takes care of this. I have added some "bypass" functionality to manually send commands to the engine, via tell or yell. The bridge directs the responses back to tells or channel yells. (I'm planning on some Elisa functionality, too :-)) This is more or less independent of the normal game machinery. 4) chronic case of Not Invented Here - syndrome :-)
I might release the source GPL. At first, it should be useable. At the moment, it accepts and plays a game, but does not know how to end. It does not respond well yet to crashes at either side of the connection.
This is addressed in my new specification draft. The relevant section
| Engines are allowed to use private extensions without a dash in the | name, but then they do it at their own risk and must be prepared to
Good.
- gnugo should *not* pollute the existing namespace with redundant commands. eg: genmove_black is equivalent to "genmove b". this is protocolbloat to avoid.
There is no "genmove" command in GNU Go. You may be thinking of
Exactly. Instead of the gtp version 1 command "genmove" *four* extentions to the commandset were implemented. For perfectly valid reasons, of course.
In version two of the protocol genmove_black and genmove_white will be replaced by a single genmove command. There will also be a command reg_genmove for regression purposes.
Good. I don't object to extensions. But basic functions should be mapped to the standard command set, IMHO.
- gnugo extends the error messages with descriptive text, eg: out_of_range: point d33 is outside the board.
I'd like a concrete (and real) example to comment on that.
I could not get a runnable version og gnugo here at work. Just some visual inspection of the source(3.2 play_gtp.[ch] ): gtp_failure(id, "komi not a float"); gtp_failure(id, "handicap not an integer"); Should have been "invalid_argument" ?
there are more of these.
I know this seems like nitpicking. But bloat in the responses will make it increasingly hard for the driverprograms. A two level message ala "404: not gound", or "invalid_argument : some extra text" would combine the best of both worlds.
- some features still seem to bi missing : the equivalents of sgf MN, PL , some timecontrol.
How would MN be useful? PL follows implicitly from the issued genmove commands. Time control commands are included in the new draft.
At the moment they both represent invisible state in the engine. Someone may want to evaluate territory or the status of groups without generating a move. Evaluation is impossible without PL. Currently, the only way to influence the PL variable is by adding the correct player last. That is not exactly an elegant solution. I dont know if MN could play any role in evaluation. It could be necessary for debugging purposes.
- at the moment, the protocol is practically stateless. Maybe a "game" or "session" layer should be added in a
To solve what problems?
/Gunnar
Not yet. I agree, we should not design a "paper" protocol for future use only. But, in the future an engine might want to perform it's own passing, scoring, removal of dead stones, etc. Just like doing it's own timecontrol. Or, at least: be aware of it.
I realise it is hard to maintain an "independent" protocol, with gnugo beiing virtually the only user. A design-by-committee- approach is not wanted. What is needed is stability: the basic commandset should work, regardless of version or age. Extensions are fine, and very useful for development. But they should not replace standard commands. Esperanto does not need dialects.
BTW, in the standard definition paper, it is very hard for me (as a non-native reader) to determine the "sign" of the "prisoners" response. Are black prisoners "taken by black", or "colored black" (taken by white) ?
Happy hacking, AvK
Adriaan wrote:
There is no "genmove" command in GNU Go. You may be thinking of
Exactly. Instead of the gtp version 1 command "genmove" *four* extentions to the commandset were implemented. For perfectly valid reasons, of course.
In version two of the protocol genmove_black and genmove_white will be replaced by a single genmove command. There will also be a command reg_genmove for regression purposes.
Good. I don't object to extensions. But basic functions should be mapped to the standard command set, IMHO. [...] BTW, in the standard definition paper, it is very hard for me
Um, there seems to be some misunderstanding here. GTP version 1 has no written specification. It only has a reference implementation, which is GNU Go 3.0.0. Since it implements genmove_black and genmove_white, those are the standard commands. In fact there is no command called just genmove in GTP version 1.
Maybe you have been confused by the old draft for GTP version 2.
I could not get a runnable version og gnugo here at work. Just some visual inspection of the source(3.2 play_gtp.[ch] ): gtp_failure(id, "komi not a float"); gtp_failure(id, "handicap not an integer"); Should have been "invalid_argument" ?
there are more of these.
I know this seems like nitpicking. But bloat in the responses will make it increasingly hard for the driverprograms. A two level message ala "404: not gound", or "invalid_argument : some extra text" would combine the best of both worlds.
I'd generally prefer to specify as little as possible about the error messages. The examples you show above can only occur if there is a bug in the controller and it wouldn't be meaningful to include code trying to handle them.
There are a couple of error messages which the controller does need to deal with, though, which certainly need to be standardized. This part is not finished in the new draft. I'll think about your proposal.
/Gunnar
-
A van Kessel -
Gunnar Farneb�ck