gtp August 2001

gtp@lists.lysator.liu.se

20 participants
58 discussions

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 21 Aug '01

21 Aug '01

> From: William M. Shubert [mailto:wms@igoweb.org] > > Yes, this will be irritating. But that's why, if you choose not to > implement every GTP command, you should run a few tests when > you first > attach your engine to a new GTP system to ensure that you support all > the commands needed. Then you do the "real" work with it. Well here's where we get to the crux of my point. I'm not wedded to that particular protocol snippet, I just have a feeling that we're glossing over an important, albeit boring, aspect of this protocol. When you say "you should run a few tests when you first attach your engine to a new GTP system to ensure that you support all the commands needed", I say fine, but the devil is in the details and I want to know how exactly this gets done. > I see your point, I just think that the handshaking you proposed will > add a significant complexity and will probably be just as > error-prone as > the "try it and see" system I recommend...I know that were I to > implement this system, I'd probably find my bugs in the > "main" GTP part > pretty quick, but it would be easy to screw up the > protocol-checking and > never notice since it wouldn't get exercised in as many different > situations. I don't see where it's more error prone, at least no more so than any other command; we're not talking TCP/IP here. All you have to do is exchange the hand full of command set names and move on. Now let me first state this, not everyone is going to implement the full porotocol; that much is clear from what I've been reading here. To me this implies that I have a valid concern here. With that said, let me go over a use case. If the case isn't relevant, please chime up. We hook up, I run through a all of commands that I want to use to see which ones you support. Now through dumb luck, I happen to run through a valid sequence one quarter of the way through when I present a command that you don't support. You return a "not implemented". By the time we're done, I have to keep track of all those little commands that you don't support; this is quite a complex endevor. Your machine and my machine are in a wacky state, because of the testing. You may have even succeeded in crashing my machine by sending in that one non-sensical sequence required to put me into a bad state. Now what if we just exchanged the two or three command set names? In my GTP implementation, I'm asumming my protocol, there would be two or three command handler classes, one for each command set. If there's a command set that you don't handle, I de-register that command set handler. Now someone may say, "My gift to the computer go community shall be a GTP implementation that will handle all these minor points." I would reply, at some point, my engine will still need to keep track of what commands and features it can use/support and which ones it can't. Using named command sets simplifies this tracking. So my point is that for every non-tournement hookup, almost everyone will *have* to do this to see what commands they can use. It's a grey area that I think needs to be cleared up with me being partial to my proposal. Alan

2 1

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 21 Aug '01

21 Aug '01

Fine. I have a tendency to over engineer things at times. But lets say that we're half way through a game and I need a command, one that we haven't encounted in our exchange, that I think is critical. When you return a "not implemented" to that command, my program quits and closes the connection. Wouldn't that be a terribly irritating experience? Maybe this scenario would be seldom encountered. Thoughts? > -----Original Message----- > From: William M. Shubert [mailto:wms@igoweb.org] > Sent: Monday, August 20, 2001 10:28 PM > To: GTP Mailing List > Subject: Re: [gtp] GTP Specification-Draft > > > I agree with Gunnar, this seems needlessly complex. If I write GTP > program, I'll provide a README telling users what commands > they need. If > they return "not implemented" to one of those commands, my > program will > either a) ignore this (if the command isn't terribly imporant) or b) > quit and close the connection (if the command was critical). I'm > definitely not going to spend my time writing my code to try > to figure > out whether or not the engine is "good enough" beforehand. > > The only set of features that we need completely defined IMHO is the > tournament features, because we want to be sure that > everybody can play > in the tournament before they get there. Otherwise, we can design > commands with a use in mind (such as the "load SGF file" > command used by > a test system), but if somebody writes a test system that doesn't use > the "load SGF file" command that's fine, and people who use that test > system can just skip doing that command in their engines. > > Alan wrote: > >/ Well, I think that we may need commands where the machines can > />/ announce to each other what command sets they support. > Once that is > />/ done, each machine will announce what command sets they intend to > />/ use for that session. Maybe something like: > / > I don't see the need for this. > > >/ begin_command_sets_available > />/ tournament > />/ player_to_player > />/ end_command_sets_available > />/ begin_command_sets_used > />/ tournament > />/ end_command_sets_used > />/ > />/ or: > />/ > />/ begin_command_sets_available > />/ tournament > />/ player_to_player > />/ end_command_sets_available > />/ session_rejected > />/ > />/ if the machine does not wish to continue/ > And this is just plain ugly. > > /Gunnar > > > -- > > Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> > http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/> > > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp >

2 1

Re: [gtp] Re: VC regression failures
by Dave Denholm 21 Aug '01

21 Aug '01

Daniel Bump <bump(a)match.Stanford.EDU> writes: > I'm cc'ing both the GNU Go list and the GTP list because this is > a protocol issue. > > To summarize, Trevor Morris reports that the GNU Go regressions are broke on > Visual C. The reason is that apparently printf on VC++ interprets \n as CRLF > instead of just LF. AFAIK VC is doing the correct thing : \n is defined to expand to whatever line ending is appropriate for the platform. [ I would be inclined to blame the awk for not understanding CRLF when reading in text on a dos-like machine. Possibly a feature of cygwin tools, since someone at work here had similar problems which turned out to be do with the tools not processing CR as I would have expected them to. ] I think I did mention this feature of \n | \r, and pointed out that any portable implementations of GTP code should use \012 explicitly if they mean a LF character. > > I think this is an issue which was discussed in the protocol list > but I do not remember whether any conclusions were reached. > > Trevor Morris wrote: > > > >Do you mean that the gtp output > > >is getting spurious CR's added by the DOS version of the > > >program? > > > > Yes, this is the problem. Spurious CR added by the DOS version of the > > program. An appropriate sed script to strip out the offending ^M > > characters should do it. > > > > Perhaps the GTP needs to explicitly define what the end-of-line character(s) > > should be? > > We can simulate this problem on Linux by replacing all occurrences > of \n by \r\n in gtp.c. I just did that and found that regress.sh > is broke but twogtp is not. That wouldn't help since on windows that would (may) give CRCRLF And on mac, \n is CR \012 is probably safest if you really mean a LF character > > One difference between the two is that regress.sh is awkward where twogtp is > perlward. Perhaps we should reimplement regress.sh in perl. FWIW, the regress script doesn't work properly with /usr/bin/awk on solaris. Need to use nawk instead. perl is probably slightly better defined, and therefore more portable. dd -- dave.denholm(a)insignia.com http://www.insignia.com

6 7

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 21 Aug '01

21 Aug '01

So what's the point in partitioning the commands into all these sets? Why not just have two buckets, required and optional? > -----Original Message----- > From: Phil Garcia [mailto:PhilippGarcia@Home.com] > Sent: Monday, August 20, 2001 8:46 PM > To: gtp(a)lists.lysator.liu.se > Subject: Re: [gtp] GTP Specification-Draft > > > The help command will return a list of implemented commands. > > ----- Original Message ----- > From: "Cabrera, Alan" <adc(a)multex.com> > To: "'Gunnar Farnebäck'" <gunnar(a)lysator.liu.se>; > <gtp(a)lists.lysator.liu.se> > Sent: Monday, August 20, 2001 5:22 PM > Subject: RE: [gtp] GTP Specification-Draft > > > > From: Gunnar Farnebäck [mailto:gunnar@lysator.liu.se] > > > > Alan wrote: > > > Well, I think that we may need commands where the machines can > > > announce to each other what command sets they support. > Once that is > > > done, each machine will announce what command sets they intend to > > > use for that session. Maybe something like: > > > > I don't see the need for this. > > So when do two programs discover when a command set is not supported? > > > > begin_command_sets_available > > > tournament > > > player_to_player > > > end_command_sets_available > > > begin_command_sets_used > > > tournament > > > end_command_sets_used > > > > > > or: > > > > > > begin_command_sets_available > > > tournament > > > player_to_player > > > end_command_sets_available > > > session_rejected > > > > > > if the machine does not wish to continue. > > > > And this is just plain ugly. > > Ugly in what way? The actual commands or the idea itself? > > > Alan > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp > > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp >

2 1

GTP Goals, ver. 3
by William M. Shubert 21 Aug '01

21 Aug '01

OK, Dan Dailey has convinced me. I will no longer speak in any way of a "minimal command set". Version 3 of my goals document instead calls it a "tournament command set", the plan being that if you want to use GTP for tournaments, you *must* implement all these commands, but all others are optional for tournament play. Do other people see this as a good change? It seems that most people who spoke of a minimal command set really meant "a command set if you just want to set up games and play them", but that seems still too vague, so I think "tournament command set" is a better way to put it. Dan, are you satisfied with this change? Or do you still have issues with having a subset of the commands being given different priority in this way? Any thought or comments on this name change (or anything else in the goals document) are welcome. ******************** GTP Goals version 3 Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform. 1. Usable to play games vs. other programs head to head. If the protocol requires some kind of arbiter, that's OK, but see III.1. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. 4. Usable to write full featured interfaces. Part II - Implementation Goals. Constraints that we must follow when designing the exact command list. 1. Simple to implement, debug and understand; all commands are ASCII, all human text (comments etc.) is UTF-8, exactly one line per command, each command gets an exactly one line response. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs in tournaments. Note that GTP and GMP will not necessarily have the same feature set - just the possibility of playing against each other is necessary. 3. There must be a "tournament command set" that is designed to be a small enough set of commands to be extremely easy to implement but complete enough to make go program tournaments efficient to operate. All commands needed only for regression tests, server play, or "full featured" front ends are optional extensions that programmers need not implement if they plan on using GTP only for tournaments. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features when using GTP to communicate with other programs that have not implemented quite the same feature set. Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source. 1. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game? 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other. Part IV - Additional Programs. These are programs that are not necessary for us to call GTP "done" but would be useful to have publicly available. 1. A sample GTP program that understands all of the commands. 2. GTP bridges for various servers. 3. GUIs and other human-usable front ends so that programmers who write GTP programs can automatically play against their programs, query their programs as to evaluations, etc. 4. A GTP test system/test library to determine whether or not a program is emitting legal GTP. ******************** -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

5 11

Re: [gtp] GTP Specification-Draft
by William M. Shubert 21 Aug '01

21 Aug '01

I agree with Gunnar, this seems needlessly complex. If I write GTP program, I'll provide a README telling users what commands they need. If they return "not implemented" to one of those commands, my program will either a) ignore this (if the command isn't terribly imporant) or b) quit and close the connection (if the command was critical). I'm definitely not going to spend my time writing my code to try to figure out whether or not the engine is "good enough" beforehand. The only set of features that we need completely defined IMHO is the tournament features, because we want to be sure that everybody can play in the tournament before they get there. Otherwise, we can design commands with a use in mind (such as the "load SGF file" command used by a test system), but if somebody writes a test system that doesn't use the "load SGF file" command that's fine, and people who use that test system can just skip doing that command in their engines. Alan wrote: >/ Well, I think that we may need commands where the machines can />/ announce to each other what command sets they support. Once that is />/ done, each machine will announce what command sets they intend to />/ use for that session. Maybe something like: / I don't see the need for this. >/ begin_command_sets_available />/ tournament />/ player_to_player />/ end_command_sets_available />/ begin_command_sets_used />/ tournament />/ end_command_sets_used />/ />/ or: />/ />/ begin_command_sets_available />/ tournament />/ player_to_player />/ end_command_sets_available />/ session_rejected />/ />/ if the machine does not wish to continue/ And this is just plain ugly. /Gunnar -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

1 0

GTP Goals ver. 4
by William M. Shubert 21 Aug '01

21 Aug '01

OK here's draft 4. Mostly this is the changes Gunnar recommended, plus one more thing that I realized Must be possible for programs to implement their own extensions to GTP in a clean manner". I've heard lots of people talk about this, I don't think it will cause much dissent - obviously if GTP is good, most programs won't /need /to implement their own extensions, but we know that some will have to. ******************** GTP Goals version 4 Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform. 1. Usable to play games vs. other programs head to head. If the protocol requires some kind of arbiter, that's OK, but see III.2. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. 4. Usable to write a GUI or control program for a go playing engine. 5. Must be possible for programs to implement their own extensions to GTP in a clean manner. Part II - Implementation Goals. Constraints that we must follow when designing the exact command list. 1. Simple to implement, debug and understand; all commands are ASCII, all human text (comments etc.) is UTF-8, exactly one line per command, each command gets an easily delimited block of text in return. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs in tournaments. Note that GTP and GMP will not necessarily have the same feature set - just the possibility of playing against each other is necessary. 3. There must be a "tournament command set" that is designed to be a small enough set of commands to be extremely easy to implement but complete enough to make go program tournaments efficient to operate. All commands needed only for regression tests, server play, or "full featured" front ends are optional extensions that programmers need not implement if they plan on using GTP only for tournaments. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features. Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source. 1. An example program that implements the tournament GTP command set properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other. Part IV - Additional Programs. These are programs that are not necessary for us to call GTP "done" but would be useful to have publicly available. 1. A sample GTP program that understands all of the commands. 2. GTP bridges for various servers. 3. GUIs and other human-usable front ends so that programmers who write GTP programs can automatically play against their programs, query their programs as to evaluations, etc. 4. A GTP test system/test library to determine whether or not a program is emitting legal GTP. -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

1 0

RE: [gtp] GTP Goals, ver. 3
by Cabrera, Alan 21 Aug '01

21 Aug '01

Couldn't there be a bare bones standard with a set of standardized extensions? Each set of extensions could be standardized by this same group that is working on GTP. During the initial protocol negotiation, the set of extensions that each machine supports could be exchanged. Each machine would gracefully degrade in features available to the user, depending on what both machines were capable of. Alan -----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Tuesday, August 14, 2001 5:02 PM To: dave.denholm(a)insignia.com Cc: gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3 Hi Dave, Rather than making each user-interface add the composite commands, we could provide a separate (free) client-side library which implements high level commands out of the minimal commands provided by the protocol. But this is not really possible unless GTP has enough primitives to support it. If there is no "setup" command, as an example, how do you set up a position? I absolutely agree with you however, we SHOULD be able to do these things. You need a few basic primitives to do all the cool things. I am in favor of making sure we get them in a standardized set. If we don't, people (like me) will end up creating our own GTP extensions, and whoever builds the most popular user interface (or library like you are suggesting) will be the one actually defining the standard, in a defacto manner. My user interface will actually have incredibly advanced features like the ability to set up a position or "take back" a move!!! I know how amazing that may seem to some, but I have this fear that I may have to create a non-standard GTP command to do these simple things. Since I will want other programmers to benefit from this, I'll have to communicate my extensions to the world, and the GTP "standard" itself will not really be treated as a standard or gain any respect. You will get conversations like this: Q "Hey, I want to implement the standard GTP protocol so I can use this super cool user interface I found on the web with my own program." A "No, don't use the GTP standard, you can't really do anything very useful with it except push moves back and forth between 2 programs. The best set is the 'John Doe' set which most everyone else uses." Q "But I heard the Bill Johnson set is better?" A "Well, they are basically the same, but 'undo' is called 'takeback' and the Johnson set doesn't let you set levels except by editing the 'program invocation' box and adding the proper command line arugments." Q "I just tried the John Doe set like you suggested, but it does't work." A "Which user interface are you using?" Q "I'm using the 'SuperGo tools' gui package." A "Ok, that's a good one, but doesn't really work with the Doe set, I guess you have to use the Johnson set. By the way, there is a patch that let's you set levels by storing a library of different program invocation strings in a buffer and pressing the F7 function key to cycle through them." ... etc. Don From: Dave Denholm <dave.denholm(a)insignia.com> Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > I would like to also point out that we CAN have a very complete set > without it being "big" and involved or difficult to implement. A set > was already sketched out that is very small, but makes it possible to > design a full featured user interface. > > By "full featured" I mean just all the basics, saving and loading > games, positions, setting levels, taking back moves etc. Almost any > highly advanced features can be composed by a user interface if we > have the minimal support that I am asking for. Also, I don't want to > be forced to add my own non-standard commands just to be able to do > something really as basic and simple as taking back moves. How lame > is that? > Haven't really been keeping up, but... Rather than making each user-interface add the composite commands, we could provide a separate (free) client-side library which implements high level commands out of the minimal commands provided by the protocol. In fact, it could even do things like if ( gtp_do_this_thing() == NOT_IMPLEMENTED ) { gtp_do_that_first_simple_thing(); gtp_do_that_second_simple_thing(); ... } Eg if loading an sgf file is not implemented, the library can load it and send down lots of addstone commands. (I'm not suggestinging this as part of a gtp interface library, but as a value-added separate layer...) dd -- dave.denholm(a)insignia.com http://www.insignia.com _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

9 30

Re: [gtp] GTP Specification-Draft
by Dave Denholm 21 Aug '01

21 Aug '01

Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > > However, I'm not sure whether error messages need to be standardized. > > I agree 100% with this. > > By the way, "not_implemented" is not an error message, it's a > legitimate response that does NOT indicated an error. It's a way of > saying, "I have not implemented that command." > > There has been a tremendous amount of resistance to adding even very > simple commands, the main argument being that it's extra work to > implement more than the very most basic 4 or 5 commands. Having a set > of standardized error codes for each command is certainly not very > compatible with this philosophy. It may not just be that it seems to be too much work. Another problem is that requiring that engines implement apparently simple commands is that they may constrain the engine to work in certain ways. Implementing lots of commands just because they are trivial in some implementations does not necessarily mean they will be easy in all possible implementations. As I think I've mentioned before, it was a long, long time before gnugo implemented undo. The priority was on getting a strong go-playing engine rather than making a good user experience. Of course, it's different now... It's not impossible to imagine an engine with so much complex state and cache information that undo is simply not possible, other than by going back and regenerating the moves from scratch. Incidentally, I can't remember the current state of things, but IIRC, there were proposals to separate the commands to generate a move from committing that move. So the contoller would ask the engine for its move, then tell the engine later to place a move, which would usually be the move the engine asked for. ISTR that one objection to *not* having undo was that it could destroy an engine's incremental state by clearing the board and playing all the previous moves. However, could it not be argued that asking for the engine to make a move without allowing it to update its state has just the same effect ? Apologies if you've all moved on from here... And FWIW, one nice feature of the smtp/http response scheme is that you can distinguish success/temporary failure / permanent failure without needing to understand the text of the message. Just the first digit is enough. If we are using plain text responses, perhaps we should use a standard textual prefix (OK, WARN, ERROR, ...) in a similar way. So then even if the exact text of the response is not understood, the controller knows if the engine is reporting an error or not. dd -- dave.denholm(a)insignia.com http://www.insignia.com

3 3

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 21 Aug '01

21 Aug '01

> From: Gunnar Farnebäck [mailto:gunnar@lysator.liu.se] > > Alan wrote: > > Well, I think that we may need commands where the machines can > > announce to each other what command sets they support. Once that is > > done, each machine will announce what command sets they intend to > > use for that session. Maybe something like: > > I don't see the need for this. So when do two programs discover when a command set is not supported? > > begin_command_sets_available > > tournament > > player_to_player > > end_command_sets_available > > begin_command_sets_used > > tournament > > end_command_sets_used > > > > or: > > > > begin_command_sets_available > > tournament > > player_to_player > > end_command_sets_available > > session_rejected > > > > if the machine does not wish to continue. > > And this is just plain ugly. Ugly in what way? The actual commands or the idea itself? Alan

2 1

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 August 2001