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@insignia.com Cc: gtp@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@insignia.com
Don Dailey drd@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@insignia.com http://www.insignia.com _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
Yes, this has been talked about much. Here is the general conclusion, although it's unclear if all agree:
. 2 standards are more complicated than 1, creates confusion.
. We already have GMP, we don't need a clone unless it's actually better somehow.
. We can still keep things very "minimal" and simple and have one complete standard.
We are not talking about hundreds of complicated commands, only about 12 or so, and they are trivial to implement. Probably the most complicated command I would like to see is "undo" (which apparantly many programmers find hard to do.)
Don
From: "Cabrera, Alan" adc@multex.com
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@insignia.com Cc: gtp@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@insignia.com
Don Dailey drd@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@insignia.com http://www.insignia.com _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
On Wed, Aug 15, 2001 at 08:41:49AM -0400, Don Dailey wrote:
We are not talking about hundreds of complicated commands, only about 12 or so, and they are trivial to implement. Probably the most complicated command I would like to see is "undo" (which apparantly many programmers find hard to do.)
My program -- 12th out of 12 at the 21st century cup -- implemented "undo" very early, so that it could analyze variations. So I should be all set, I guess.
"It was another fine day on the Full Featured Go Server. I was playing Chinese rules with situational superko, free placement of three handicap stones, 15 minutes basic time plus 10 minutes byoyomi, plus Ing-style buying time, 90 seconds per point. I was 7 minutes and 1 move into my first byo-yomi period and my opponent had bought 270 seconds of time and used 206 of them when the server told me to undo my last move because my opponent had changed his mind. Fortunately, I've never found undo hard to do."
But if we could get a consensus here that feature creep won't be a problem, maybe I'd be more enthusiastic.:-)
In my (admittedly limited) experience, undo is not a core feature for portable communication between a Go-playing program and its opponent. I was expecting GTP to replace GMP, mostly, and secondarily to replace IGS protocol for computers playing on IGS-style servers. GMP seems to be used almost entirely in tournaments, where undo isn't allowed. The computers that I'm familiar with play on Internet servers in part to establish their ratings, and as far as I know no one has a good scheme for judiciously allowing undo without being taken advantage of by the usual emboldened-by-anonymity Internet twit.
Both GMP and IGS protocol support undo. How many programs actually use it?
Both GMP and IGS protocol support undo. How many programs actually use it?
What user interface is complete without undo?
Don
-- William Harold Newman william.newman@airmail.net "Three hours a day will produce as much as a man ought to write." -- Anthony Trollope PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
On Wed, Aug 15, 2001 at 05:44:17PM -0400, Don Dailey wrote:
Both GMP and IGS protocol support undo. How many programs actually use it?
What user interface is complete without undo?
Which is more important, to standardize a protocol which implements a complete user interface, or to standardize a protocol which does a good job on the features that programs actually use when interfacing to other programs (including servers and multitool-things like cgoban)?
Of course, I still don't know the answer to my first question. Maybe the number of programs which use the existing 'undo' command is much larger than I realize..
From: William Harold Newman william.newman@airmail.net References: 20010815145635.A5952@rootless 200108152144.RAA04457@silk.supertech
On Wed, Aug 15, 2001 at 05:44:17PM -0400, Don Dailey wrote:
Both GMP and IGS protocol support undo. How many programs actually use it?
What user interface is complete without undo?
Which is more important, to standardize a protocol which implements a complete user interface, or to standardize a protocol which does a good job on the features that programs actually use when interfacing to other programs (including servers and multitool-things like cgoban)?
The answer? BOTH! I say this out of my own needs. I want to build a really cool interface that everyone can use. Can't do it with GMP.
I also maintain that this is still a very small set of commands, we might as well not get stingy and be sorry later.
Don
Of course, I still don't know the answer to my first question. Maybe the number of programs which use the existing 'undo' command is much larger than I realize..
-- William Harold Newman william.newman@airmail.net "Three hours a day will produce as much as a man ought to write." -- Anthony Trollope PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
On Wed, Aug 15, 2001 at 10:21:14PM -0400, Don Dailey wrote:
From: William Harold Newman william.newman@airmail.net References: 20010815145635.A5952@rootless 200108152144.RAA04457@silk.supertech
On Wed, Aug 15, 2001 at 05:44:17PM -0400, Don Dailey wrote:
Both GMP and IGS protocol support undo. How many programs actually use it?
What user interface is complete without undo?
Which is more important, to standardize a protocol which implements a complete user interface, or to standardize a protocol which does a good job on the features that programs actually use when interfacing to other programs (including servers and multitool-things like cgoban)?
The answer? BOTH! I say this out of my own needs. I want to build a really cool interface that everyone can use. Can't do it with GMP.
Last night as I was driving to the Dallas Go Club, I got to wondering..
Why do you want a go-playing engine to use text commands to interface to your really cool interface? Isn't it more normal, and convenient, for a user interface to talk to a program through a set of functions callable from C or Java or whatever?
If you want a protocol that lets lots of different combinations of computers play Go against each other, then TCP looks natural, and then text commands make sense.
If you want an engine to be able to present a GUI, why mess with TCP?
Are you thinking of an interface to an IGS-style server, as opposed to an interface to a Go-playing engine?
I also have spent a GREAT DEAL of time thinking about all of these issues.
My main goal was to build something that would benefit the whole computer Go community, a really usable Go interface that would work with ANY go engine.
I still want to do this, but I feel like I'm asking for something this group is not willing support. It's not my intention to force this on anyone, I just wanted to do something I thought was really cool and would benefit all of us.
Here is what I have decided to do. I will write a set of various tools including a user interface that I will contribute. All of these tools will use GTP extensions that I have defined. In order to make sure there are at least a few go engine choices, I will also provide "shell wrappers" for any text based go engine I have access to which will make them act as if they have implemented my protocol. Think of the go engines as devices and my wrappers as device drivers to get the general idea. I'll stay as close as possible to whatever minimal protocol we come up with as a group.
If a GTP standard ever gets defined and the protocol is complete enough to support those basic features end users want, I'll conform by making my tools use this protocol. I will also provide documentation on my extensions so that others can benefit if they choose.
Whether these tools are popular or not, I think the effort will benefit everyone. Maybe this will spur someone else on to do something better, and I am interested in seeing how the issues of inconsistent interfaces is dealt with by others.
Can anyone help me compile a list of freely available TEXT based go programs?
Don
From: William Harold Newman william.newman@airmail.net
On Wed, Aug 15, 2001 at 10:21:14PM -0400, Don Dailey wrote:
From: William Harold Newman william.newman@airmail.net References: 20010815145635.A5952@rootless 200108152144.RAA04457@silk.supertech
On Wed, Aug 15, 2001 at 05:44:17PM -0400, Don Dailey wrote:
Both GMP and IGS protocol support undo. How many programs actually use it?
What user interface is complete without undo?
Which is more important, to standardize a protocol which implements a complete user interface, or to standardize a protocol which does a good job on the features that programs actually use when interfacing to other programs (including servers and multitool-things like cgoban)?
The answer? BOTH! I say this out of my own needs. I want to build a really cool interface that everyone can use. Can't do it with GMP.
Last night as I was driving to the Dallas Go Club, I got to wondering..
Why do you want a go-playing engine to use text commands to interface to your really cool interface? Isn't it more normal, and convenient, for a user interface to talk to a program through a set of functions callable from C or Java or whatever?
The answer is that I don't want to write this interface just for myself, I want to contribute it to the whole computer go community. It seems too much to ask everyone to rewrite their code and link in my libraries just to be able to use my interface. What if 3 other people did the same thing? Then we have 3 sets of libraries floating around and lots of tools that won't work unless you picked the right one.
Now GTP could end up being a standard everyone uses. If so, then we would instantly have a pool of go engines that would "just work" without asking any questions. Additionally, we could write all kinds of tools that also will work with ANY Go engine. Of course these won't work either if we partition the GTP standard into many groups.
It is my feeling that we have lacked imagination here. Having the ability to communicate directly with ANY engine makes software possible that apparently no one has even thought about. The only thing I keep hearing over and over is "why do I need 'setup' to just play a match with another engine", as if that is the only possible use.
The library idea is good too, but it is essentially a different thing with a different goal. Since I would build GTP support into any engine I design, I would probably either build GTP into the library or make the
The idea of writing a library is of course a more specific answer, and less likely to get used by the whole how I would do it if all I wanted was to interface to
I have come to the conclusion that I just have to focus on these issues on my own, define my own protocol and write the software that no one is interested in for myself as a first pass. When someone I have discovered that peoples imagination is often stimulated when they actually see something work
If you want a protocol that lets lots of different combinations of computers play Go against each other, then TCP looks natural, and then text commands make sense.
If you want an engine to be able to present a GUI, why mess with TCP?
Are you thinking of an interface to an IGS-style server, as opposed to an interface to a Go-playing engine?
-- William Harold Newman william.newman@airmail.net "Three hours a day will produce as much as a man ought to write." -- Anthony Trollope PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
You can find my working version of the GTP Specification at www.tgiphil.com (click Computer Go and GTP Specification on the menu bar). Nothing fancy yet, mostly focusing on documenting the "standard" GTP command set. I will eventually add diagrams, clean up the TODO comments, and get it edited.
Please provided feedback and input... (but do not shoot the volunteer).
Phil
Thanks to Phil for getting this written up, it's good place to start from. Below are various comments and suggestions, and lots of questions.
(1) Optional id --------------- What's the purpose of these optional id numbers? As I understand it, the engine is simply echoing them, it can't base any of its decisions on these numbers. So how are they helping the controller program? How are these numbers used in GNU Go, and what would the protocol lose if these were removed from the standard?
(2) Error messages ------------------ Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
(3) Command sets ---------------- In my opinion, the tournament command set should be the core set. Every Go program should at least implement the commands necessary to play in a computer-computer tournament. We need to keep that command set simple enough that this is not a burden, but I don't see a benefit in splitting up the tournament and the core command set.
(4) Missing commands -------------------- - Need a way to set up a position (as discussed previously, playing moves is not a substitute). - Need to know under what rules the game is being played. - Need a way to know how much time to spend on a move or on the whole game, and how much time is left. - Query position: There should be a way for the controller to get the current board position from the engine. (Not necessarily a core command, but would help a lot with debugging and verifying engines.)
(5) Argument definitions ------------------------ - For coordinates, both lowercase and uppercase coordinates should be acceptable. The standard coordinates are most often given in uppercase, and GTP shouldn't require people to change coordinate notation. (I know, I made that mistake in SGF.)
- Real: No need for everybody to deal with numbers like 1.7E308. Real numbers will only be used for things like komi, score, and time left, so a simpler definition will do.
- Date: Why not use the standard YYYY-MM-DD format that's used in SGF? (Doesn't seem to be used by any commands yet, though.)
(6) What to do on failure ------------------------- The GTP standard should clearly state that anytime failure is returned, the state of the Go program must remain unchanged. That simplifies the description of the "On Failure" section for each command, that section simply needs to list the standard error messages that can be returned.
(7) Specific commands --------------------- - 'boardsize': The Notes section is clearly part of the definition of this command, and should thus be moved to the On Success section.
- 'fixed_handicap': What if this command is not sent at the beginning of the game? Is the only purpose of this command to get the coordinates of fixed handicap stones, or does it also play them on the board? Why include this in the core set of commands, why not put the responsibility for figuring out where to put handicap stones in the controller?
- 'komi': I don't think the standard should specify a default komi. Why 5.5 and not 6.5 or 7.5? The komi should be zero unless specified. I think it will be easier to get all the controllers to always send a komi command than to make sure they remember to set the komi to zero (or 0.5) for handicap games.
- 'is_legal': I like this command, but why does it specify color and coordinate while other commands use separate commands for each color? Why not have 'genmove' and 'move' commands rather than 'genmove_black', 'genmove_white', 'black', and 'white'?
- 'all_legal': Instead of providing a command that returns a huge number of legal points to play, we should define a command (e.g. 'illegal_points') to return the empty points that are illegal to play on. This will just be a few points, much more manageable.
(8) State changes ----------------- The specification is vague on some points, for example: - Does 'loadsgf' change boardsize and komi? Does it reset the number of prisoners? - 'boardsize' probably resets the number of prisoners?
I think explicitly specifying the state maintained by each engine would make it clearer, and would make it easier to implement GTP correctly. For example, board_size, komi, and (optional) number_of_prisoners are clearly part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's a different matter). Every command affecting this state should specify that.
(9) Timeouts ------------ What happens when the controller sends a genmove_black command and then waits for a reply, and waits, and waits, and waits? Should there be a way to query the engine whether it's still thinking?
Enough for now. This should get some discussions started. :-)
Anders Kierulf www.smartgo.com
Thanks Anders for all the comments and questions.
From: "Anders Kierulf" anders@smartgo.com To: gtp@lists.lysator.liu.se Sent: Sunday, August 19, 2001 9:55 PM Subject: RE: [gtp] GTP Specification-Draft
Thanks to Phil for getting this written up, it's good place to start from. Below are various comments and suggestions, and lots of questions.
(1) Optional id
What's the purpose of these optional id numbers? As I understand it, the engine is simply echoing them, it can't base any of its decisions on these numbers. So how are they helping the controller program? How are these numbers used in GNU Go, and what would the protocol lose if these were removed from the standard?
I agree, these numbers seem to be useless in a requst/response type of protocol. Unless there is a really good reason for keeping them, I'm all for removing them. Existing GTP developers please speak up.
(2) Error messages
Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
Great idea! I suggested something similar, using error code numbers, but your suggestion is much better. I will add this to the GTP specification.
(3) Command sets
In my opinion, the tournament command set should be the core set. Every Go program should at least implement the commands necessary to play in a computer-computer tournament. We need to keep that command set simple enough that this is not a burden, but I don't see a benefit in splitting up the tournament and the core command set.
I need help here. How do we see a tournament being formed?
It does allow commands to be sent out of order. Imagine we have the following gtp commands:
genmove_black heartbeat show_thinking
A problem tester piece of software sents up a postion and then sends "genmove_black"
The engine goes into a long think cycle. Suppose the tester software wants to know if the engine is thinking or has died (or the connection is broken.) It can send the 'heartbeat' command and the engine should respond as soon as possible to this commands (even if it is still in the middle of a very long think cycle.)
The engine keeps thinking, but still can send a response to the heartbeat query.
Don
From: "Phil Garcia" PhilippGarcia@home.com
Thanks Anders for all the comments and questions.
From: "Anders Kierulf" anders@smartgo.com To: gtp@lists.lysator.liu.se Sent: Sunday, August 19, 2001 9:55 PM Subject: RE: [gtp] GTP Specification-Draft
Thanks to Phil for getting this written up, it's good place to start from. Below are various comments and suggestions, and lots of questions.
(1) Optional id
What's the purpose of these optional id numbers? As I understand it, the engine is simply echoing them, it can't base any of its decisions on these numbers. So how are they helping the controller program? How are these numbers used in GNU Go, and what would the protocol lose if these were removed from the standard?
I agree, these numbers seem to be useless in a requst/response type of protocol. Unless there is a really good reason for keeping them, I'm all for removing them. Existing GTP developers please speak up.
(2) Error messages
Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
Great idea! I suggested something similar, using error code numbers, but your suggestion is much better. I will add this to the GTP specification.
(3) Command sets
In my opinion, the tournament command set should be the core set. Every Go program should at least implement the commands necessary to play in a computer-computer tournament. We need to keep that command set simple enough that this is not a burden, but I don't see a benefit in splitting up the tournament and the core command set.
I need help here. How do we see a tournament being formed?
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
It seems like the list has been busy while I've been on vacation. I'll add my comments as I find time, starting with one of the recent messages. Unfortunately I can't reach Phil's page, getting a 404 like some other people seem to, so I can only comment on the comments to his specification draft.
Anders wrote:
(1) Optional id
What's the purpose of these optional id numbers? As I understand it, the engine is simply echoing them, it can't base any of its decisions on these numbers. So how are they helping the controller program? How are these numbers used in GNU Go, and what would the protocol lose if these were removed from the standard?
Correct, the engine can't and shouldn't try to do anything with those numbers. For the controller they are very useful. I'll give two examples:
1. Regression testing. A regression test suite in GNU Go may look like this:
| loadsgf games/strategy1.sgf | 1 genmove_white | #? [Q13] | | loadsgf games/strategy2.sgf 5 | 2 gg_genmove black | #? [!G2|D2] | | loadsgf games/strategy2.sgf 9 | 3 gg_genmove black | #? [!H1|H2]
This is fed in its entirety (all at once) as GTP input to GNU Go, which gives the response:
| = white | | =1 Q13 | | = black | | =2 C7 | | = black | | =3 F8
Thanks to the id numbers, the regression script can easily identify which responses correspond to which queries. (The lines starting with '#?' are GTP comments which gives information about accepted results to the regression script.)
2. gnugoclient The gnugoclient program has a multithreaded architecture with among others double threads for communication with the go engine, one for reading and one for writing. When some event on the server, e.g. the opponent making a move, prompts a call to the engine, this is handled like this: * Another thread invokes the method SendCommand(command, callback). * A new id number is generated. * The callback is stored in a mapping indexed by the id number. * The id number is prepended to the command and placed in a queue. * The GTP writing thread picks up the request from the queue and sends it to the engine * Sometime later the GTP reading thread picks up the response from the engine. * The id number is extracted from the response. * The callback is retrieved from the mapping where it was stored through the id number. * The callback is invoked with the response from the engine (with id stripped) as argument.
(2) Error messages
Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
I doubt the controllers can do very much with other error messages than "unknown command" (this is what GNU Go has always responded and I see no compelling reason to change this to "not implemented") but there is no reason not to standardize the common ones. Would it really simplify matters to use underscore rather than space in the error messages?
(4) Missing commands
- Need a way to set up a position (as discussed previously, playing
moves is not a substitute).
For GNU Go playing moves has worked quite well but I agree we also want a setup command.
- Need to know under what rules the game is being played.
Unless someone has a very good suggestion for precisely how this should be implemented, I'd rather postpone it. For tournament and server use it's no big burden to have to specify this by e.g. command line parameters.
- Need a way to know how much time to spend on a move or on the whole
game, and how much time is left.
Agreed, this is important to include.
- Query position: There should be a way for the controller to get the
current board position from the engine. (Not necessarily a core command, but would help a lot with debugging and verifying engines.)
GNU Go has the color and showboard commands for this purpose.
(5) Argument definitions
- For coordinates, both lowercase and uppercase coordinates should be
acceptable. The standard coordinates are most often given in uppercase, and GTP shouldn't require people to change coordinate notation. (I know, I made that mistake in SGF.)
Absolutely.
- Real: No need for everybody to deal with numbers like 1.7E308. Real
numbers will only be used for things like komi, score, and time left, so a simpler definition will do.
Agreed.
- Date: Why not use the standard YYYY-MM-DD format that's used in SGF?
(Doesn't seem to be used by any commands yet, though.)
I don't know why date should be needed but if there is a need it should absolutely use the YYYY-MM-DD format.
(6) What to do on failure
The GTP standard should clearly state that anytime failure is returned, the state of the Go program must remain unchanged. That simplifies the description of the "On Failure" section for each command, that section simply needs to list the standard error messages that can be returned.
Agreed.
(7) Specific commands
- 'fixed_handicap': What if this command is not sent at the beginning of
the game?
GNU Go currently resets the board before executing the command. It may be better to specify this command to be illegal unless the board is empty.
Is the only purpose of this command to get the coordinates of fixed handicap stones, or does it also play them on the board?
It also plays them on the board.
Why include this in the core set of commands, why not put the responsibility for figuring out where to put handicap stones in the controller?
I think both alternatives are reasonable. The main reason for having this in the engine is that it allows simpler controllers (see e.g. the twogtp program in the GNU Go distribution) and the engine probably needs to know how to place fixed handicap stones anyway if it has some more interface to the world than GTP.
- 'komi': I don't think the standard should specify a default komi. Why
5.5 and not 6.5 or 7.5? The komi should be zero unless specified. I think it will be easier to get all the controllers to always send a komi command than to make sure they remember to set the komi to zero (or 0.5) for handicap games.
In my opinion the GTP standard shouldn't prescribe any default values at all. If the controller expects the engine to play on any specific boardsize or with any specific komi it should tell them.
- 'is_legal': I like this command, but why does it specify color and
coordinate while other commands use separate commands for each color? Why not have 'genmove' and 'move' commands rather than 'genmove_black', 'genmove_white', 'black', and 'white'?
This is only because I happened to implement the 'genmove_*', 'black', and 'white' commands in GNU Go like that a little more than a year ago. As I indicated in an early message to this list I now think this was a mistake and it would be better to have a 'genmove' and 'play' command taking color and color + coordinate as arguments respectively.
(8) State changes
The specification is vague on some points, for example:
- Does 'loadsgf' change boardsize and komi? Does it reset the number of
prisoners?
It should.
- 'boardsize' probably resets the number of prisoners?
This too.
I think explicitly specifying the state maintained by each engine would make it clearer, and would make it easier to implement GTP correctly. For example, board_size, komi, and (optional) number_of_prisoners are clearly part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's a different matter). Every command affecting this state should specify that.
Agreed, except the comment about current player. Not to include a current player is very intentional to avoid unnecessary limitations on the protocol.
(9) Timeouts
What happens when the controller sends a genmove_black command and then waits for a reply, and waits, and waits, and waits? Should there be a way to query the engine whether it's still thinking?
No. This would be more pain to implement than it's worth. When e.g. GNU Go is thinking about a move it has no mechanism to scan through future GTP commands coming along to check for any possible status queries.
If the controller becomes fed up with the engine's seeming inactivity it should send a 'quit' command and close down the communication.
/Gunnar
The link in the introduction page points to http://www.tgiphil.com/GTPSpecification.htm
going to
http://www.tgiphil.com/ComputerGo/GTPSpecification.htm
does work.
Joan
"Gunnar Farnebäck" wrote:
It seems like the list has been busy while I've been on vacation. I'll add my comments as I find time, starting with one of the recent messages. Unfortunately I can't reach Phil's page, getting a 404 like some other people seem to, so I can only comment on the comments to his specification draft.
Joan wrote:
The link in the introduction page points to http://www.tgiphil.com/GTPSpecification.htm
going to
http://www.tgiphil.com/ComputerGo/GTPSpecification.htm
does work.
Thanks.
But this leads to a zip file, containing a doc file, which I can't read. How great.
/Gunnar
"Gunnar Farnebäck" wrote:
Joan wrote:
The link in the introduction page points to http://www.tgiphil.com/GTPSpecification.htm
going to
http://www.tgiphil.com/ComputerGo/GTPSpecification.htm
does work.
Thanks.
But this leads to a zip file, containing a doc file, which I can't read. How great.
I have the same problem. Is the format of this doc-file an open standard or is it possible to convert it to pdf or something similar?
/Nicklas
I'm using Microsoft Word right now, but I'll also create a PDF version shortly.
----- Original Message ----- From: "Nicklas Ekstrand" nicklas@ekstrand.org To: "Gunnar Farnebäck" gunnar@lysator.liu.se; gtp@lists.lysator.liu.se Sent: Monday, August 20, 2001 1:23 PM Subject: Re: [gtp] GTP Specification-Draft
"Gunnar Farnebäck" wrote:
Joan wrote:
The link in the introduction page points to http://www.tgiphil.com/GTPSpecification.htm
going to
http://www.tgiphil.com/ComputerGo/GTPSpecification.htm
does work.
Thanks.
But this leads to a zip file, containing a doc file, which I can't read. How great.
I have the same problem. Is the format of this doc-file an open standard or is it possible to convert it to pdf or something similar?
/Nicklas
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
If the doc is more or less normal you still can edit it with a normal ascii editor, skip the garbage and found the contents inside ...
Considering that MSword has an option to output what you are editing as html format is indeed strange to find a .zip of a .doc and not a .html page that your favourite browser would display.
Joan
"Gunnar Farnebäck" wrote:
Joan wrote:
The link in the introduction page points to http://www.tgiphil.com/GTPSpecification.htm
going to
http://www.tgiphil.com/ComputerGo/GTPSpecification.htm
does work.
Thanks.
But this leads to a zip file, containing a doc file, which I can't read. How great.
/Gunnar _______________________________________________
... are part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's a different matter). ...
Agreed, except the comment about current player. Not to include a current player is very intentional to avoid unnecessary limitations on the protocol.
/Gunnar
How would this limit the protocol? In my mind, if there was a 'genmove' and a 'move' command, the color would be an optional parameter (same with 'is_legal'). In most cases, you want to know the best move for the current player, but you always have the option to specify the player to move.
I'd even argue that it may be a greater burden to require programs to support consecutive moves of the same color, while every program must be able to handle alternating moves and keep track of whose turn it is to play. So assuming there's a 'setup' command, the core standard might not even require handling the optional color parameter.
Anders Kierulf www.smartgo.com
From: "Anders Kierulf" anders@smartgo.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: gtp-admin@lists.lysator.liu.se Errors-To: gtp-admin@lists.lysator.liu.se X-BeenThere: gtp@lists.lysator.liu.se X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: mailto:gtp-request@lists.lysator.liu.se?subject=help List-Post: mailto:gtp@lists.lysator.liu.se List-Subscribe: http://lists.lysator.liu.se/mailman/listinfo/gtp, mailto:gtp-request@lists.lysator.liu.se?subject=subscribe List-Id: Discussion about the computer-go protocol GTP. <gtp.lists.lysator.liu.se> List-Unsubscribe: http://lists.lysator.liu.se/mailman/listinfo/gtp, mailto:gtp-request@lists.lysator.liu.se?subject=unsubscribe List-Archive: http://lists.lysator.liu.se/pipermail/gtp/ Date: Mon, 20 Aug 2001 10:30:12 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1149
... are part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's a different matter). ...
Agreed, except the comment about current player. Not to include a current player is very intentional to avoid unnecessary limitations on the protocol.
/Gunnar
How would this limit the protocol? In my mind, if there was a 'genmove' and a 'move' command, the color would be an optional parameter (same with 'is_legal'). In most cases, you want to know the best move for the current player, but you always have the option to specify the player to move.
I'd even argue that it may be a greater burden to require programs to support consecutive moves of the same color, while every program must be able to handle alternating moves and keep track of whose turn it is to play. So assuming there's a 'setup' command, the core standard might not even require handling the optional color parameter.
Yes, the 'white' and 'black' commands seem to require moves that are actually "legal" in some sense, and yet is it permissable to send 2 white moves in a row? Isn't this illegal?
Anders Kierulf www.smartgo.com
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
In the specification, the commands "white" and "black" will be superceeded by a new command, "move" which takes the "white" or "black' as parameter in addition to the coordinate. Also commands "genmove_black" and "genmove_white" change similarily to "genmove". This also reduces the number of standard commands.
I recommend for backwards compatibility, in the short-term, that the Engine continue to support the old commands. However, they will not be in the final specification.
A "setup" command is also being added to support setting up freely placed handicap positions. The "setup" command is only valid before the first "move" or "genmove" is issued. This is similar to SGF.
A final note, the protocol_version of this specification will be "2" - to distinguish itself from the previous implementations.
Phil
----- Original Message ----- From: "Don Dailey" drd@supertech.lcs.mit.edu
From: "Anders Kierulf" anders@smartgo.com
... are part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's
a
different matter). ...
Agreed, except the comment about current player. Not to include a current player is very intentional to avoid unnecessary limitations
on
the protocol.
/Gunnar
How would this limit the protocol? In my mind, if there was a 'genmove' and a 'move' command, the color would be an optional parameter (same with 'is_legal'). In most cases, you want to know the best move for the current player, but you always have the option to specify the player to move.
I'd even argue that it may be a greater burden to require programs to support consecutive moves of the same color, while every program must
be
able to handle alternating moves and keep track of whose turn it is to play. So assuming there's a 'setup' command, the core standard might
not
even require handling the optional color parameter.
Yes, the 'white' and 'black' commands seem to require moves that are actually "legal" in some sense, and yet is it permissable to send 2 white moves in a row? Isn't this illegal?
From: "Phil Garcia" PhilippGarcia@home.com
In the specification, the commands "white" and "black" will be superceeded by a new command, "move" which takes the "white" or "black' as parameter in addition to the coordinate. Also commands "genmove_black" and "genmove_white" change similarily to "genmove". This also reduces the number of standard commands.
I recommend for backwards compatibility, in the short-term, that the Engine continue to support the old commands. However, they will not be in the final specification.
A "setup" command is also being added to support setting up freely placed handicap positions. The "setup" command is only valid before the first "move" or "genmove" is issued. This is similar to SGF.
Yippee!!! This protocol might actually be usuable!
A final note, the protocol_version of this specification will be "2" - to distinguish itself from the previous implementations.
Phil
----- Original Message ----- From: "Don Dailey" drd@supertech.lcs.mit.edu
From: "Anders Kierulf" anders@smartgo.com
... are part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's
a
different matter). ...
Agreed, except the comment about current player. Not to include a current player is very intentional to avoid unnecessary limitations
on
the protocol.
/Gunnar
How would this limit the protocol? In my mind, if there was a 'genmove' and a 'move' command, the color would be an optional parameter (same with 'is_legal'). In most cases, you want to know the best move for the current player, but you always have the option to specify the player to move.
I'd even argue that it may be a greater burden to require programs to support consecutive moves of the same color, while every program must
be
able to handle alternating moves and keep track of whose turn it is to play. So assuming there's a 'setup' command, the core standard might
not
even require handling the optional color parameter.
Yes, the 'white' and 'black' commands seem to require moves that are actually "legal" in some sense, and yet is it permissable to send 2 white moves in a row? Isn't this illegal?
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
Illegal but sometimes practical. Of course you can always throw in a 'pass' for the missing move.
If a program receives what it considers an illegal/unfeasible move it will have to complain anyhow ... or crash!
Joan
Don Dailey wrote:
... are part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's a different matter). ...
Agreed, except the comment about current player. Not to include a current player is very intentional to avoid unnecessary limitations on the protocol.
/Gunnar
How would this limit the protocol? In my mind, if there was a 'genmove' and a 'move' command, the color would be an optional parameter (same with 'is_legal'). In most cases, you want to know the best move for the current player, but you always have the option to specify the player to move.
I'd even argue that it may be a greater burden to require programs to support consecutive moves of the same color, while every program must be able to handle alternating moves and keep track of whose turn it is to play. So assuming there's a 'setup' command, the core standard might not even require handling the optional color parameter.
Yes, the 'white' and 'black' commands seem to require moves that are actually "legal" in some sense, and yet is it permissable to send 2 white moves in a row? Isn't this illegal?
Anders Kierulf www.smartgo.com
From: Joan Pons i Semelis joan@host1.webarna.es
Illegal but sometimes practical. Of course you can always throw in a 'pass' for the missing move.
If a program receives what it considers an illegal/unfeasible move it will have to complain anyhow ... or crash!
Joan
Yes, I agree. The standard seems to be headed towards cleaning this up though and I think it's probably best. If you used the "feature" of moving out of order you would spoil the game record a program might keep, might as well just use setup!
Don
Don Dailey wrote:
... are part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's a different matter). ...
Agreed, except the comment about current player. Not to include a current player is very intentional to avoid unnecessary limitations on the protocol.
/Gunnar
How would this limit the protocol? In my mind, if there was a 'genmove' and a 'move' command, the color would be an optional parameter (same with 'is_legal'). In most cases, you want to know the best move for the current player, but you always have the option to specify the player to move.
I'd even argue that it may be a greater burden to require programs to support consecutive moves of the same color, while every program must be able to handle alternating moves and keep track of whose turn it is to play. So assuming there's a 'setup' command, the core standard might not even require handling the optional color parameter.
Yes, the 'white' and 'black' commands seem to require moves that are actually "legal" in some sense, and yet is it permissable to send 2 white moves in a row? Isn't this illegal?
Anders Kierulf www.smartgo.com
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
Anders wrote:
How would this limit the protocol? In my mind, if there was a 'genmove' and a 'move' command, the color would be an optional parameter (same with 'is_legal'). In most cases, you want to know the best move for the current player, but you always have the option to specify the player to move.
A single "genmove" command which could only be used to generate a move for the color in turn to move would be limiting. I don't see how a "genmove" command with an optional color would be simplifying the protocol.
I'd even argue that it may be a greater burden to require programs to support consecutive moves of the same color, while every program must be able to handle alternating moves and keep track of whose turn it is to play.
No, they don't. E.g. the GTP implementation in GNU Go has no concept of alternating play. I'm aware that existing programs may be written in a way which would make consecutive moves by the same color infeasible to deal with, so a tournament program should only issue "play" and "genmove" commands in an alternating fashion.
/Gunnar
----- Original Message ----- From: "Anders Kierulf" anders@smartgo.com To: gtp@lists.lysator.liu.se Sent: Sunday, August 19, 2001 9:55 PM Subject: RE: [gtp] GTP Specification-Draft
- Need to know under what rules the game is being played.
(6) What to do on failure
The GTP standard should clearly state that anytime failure is returned, the state of the Go program must remain unchanged. That simplifies the description of the "On Failure" section for each command, that section simply needs to list the standard error messages that can be returned.
- 'komi': I don't think the standard should specify a default komi. Why
5.5 and not 6.5 or 7.5? The komi should be zero unless specified. I think it will be easier to get all the controllers to always send a komi command than to make sure they remember to set the komi to zero (or 0.5) for handicap games.
- 'boardsize' probably resets the number of prisoners?
I think explicitly specifying the state maintained by each engine would make it clearer, and would make it easier to implement GTP correctly. For example, board_size, komi, and (optional) number_of_prisoners are clearly part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's a different matter). Every command affecting this state should specify that.
I've incorporated most of these comments about state into the specification.
You also point out a current gap in GTP, there is no way to set the rules for scoring, suicide, KO, etc.
So I offer two proposals to solution:
(1) Set the rule set for the game, like so: rule_set {chinese|Japanese|ing|new_zealand|igs|tromp_taylor}
(2) Or set each rule seperately, like so: scoring {territory|area, ko {simple|no_repeats}, suicide_allowed {yes|no}
We also need to define the default rule set or rules, when not specified by the Controller. We can work this out later.
So which is it to be? Or does someone have a better idea?
Phil
You also point out a current gap in GTP, there is no way to set the
rules
for scoring, suicide, KO, etc.
So I offer two proposals to solution:
(1) Set the rule set for the game, like so: rule_set {chinese|Japanese|ing|new_zealand|igs|tromp_taylor}
(2) Or set each rule seperately, like so: scoring {territory|area, ko {simple|no_repeats}, suicide_allowed {yes|no}
We also need to define the default rule set or rules, when not
specified
by the Controller. We can work this out later.
So which is it to be? Or does someone have a better idea?
Phil
I favor (2), setting scoring, ko, and self-capture settings separately rather than specifying the rule-set. This makes it very clear exactly what the engine has to implement.
Defaults: To make sure that all programs can play each other, I think area scoring and no repeated board positions should be the defaults, and every program that wants to play in computer Go tournaments should implement that. The controller may request territory scoring or simple ko, but the program may not support it. I don't have a strong opinion on what the self-capture default should be, but as with scoring and ko, there should be one setting that all programs are expected to understand.
Anders Kierulf www.smartgo.com
I favor 2 also. Did we change our minds somewhere along the line about using commands that are not absolutely needed to set up a match manually?
Don
From: "Anders Kierulf" anders@smartgo.com
You also point out a current gap in GTP, there is no way to set the
rules
for scoring, suicide, KO, etc.
So I offer two proposals to solution:
(1) Set the rule set for the game, like so: rule_set {chinese|Japanese|ing|new_zealand|igs|tromp_taylor}
(2) Or set each rule seperately, like so: scoring {territory|area, ko {simple|no_repeats}, suicide_allowed {yes|no}
We also need to define the default rule set or rules, when not
specified
by the Controller. We can work this out later.
So which is it to be? Or does someone have a better idea?
Phil
I favor (2), setting scoring, ko, and self-capture settings separately rather than specifying the rule-set. This makes it very clear exactly what the engine has to implement.
Defaults: To make sure that all programs can play each other, I think area scoring and no repeated board positions should be the defaults, and every program that wants to play in computer Go tournaments should implement that. The controller may request territory scoring or simple ko, but the program may not support it. I don't have a strong opinion on what the self-capture default should be, but as with scoring and ko, there should be one setting that all programs are expected to understand.
Anders Kierulf www.smartgo.com
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
I agree about choosing (2) and area for the default, but maybe simple ko would be a better alternative as it looks easier to detetect and encourages new participants. Suicide it's an obvious no because a default is what's to be expected, but I'm personally for a yes, although that can extend the number of moves of a game by an enormous amount in programs that yet trying to learn the rules.
Joan
Anders Kierulf wrote:
You also point out a current gap in GTP, there is no way to set the
rules
for scoring, suicide, KO, etc.
So I offer two proposals to solution:
(1) Set the rule set for the game, like so: rule_set {chinese|Japanese|ing|new_zealand|igs|tromp_taylor}
(2) Or set each rule seperately, like so: scoring {territory|area, ko {simple|no_repeats}, suicide_allowed {yes|no}
We also need to define the default rule set or rules, when not
specified
by the Controller. We can work this out later.
So which is it to be? Or does someone have a better idea?
Phil
I favor (2), setting scoring, ko, and self-capture settings separately rather than specifying the rule-set. This makes it very clear exactly what the engine has to implement.
Defaults: To make sure that all programs can play each other, I think area scoring and no repeated board positions should be the defaults, and every program that wants to play in computer Go tournaments should implement that. The controller may request territory scoring or simple ko, but the program may not support it. I don't have a strong opinion on what the self-capture default should be, but as with scoring and ko, there should be one setting that all programs are expected to understand.
Anders Kierulf www.smartgo.com
Aren't we making a mountain out of a mole hill here.
For GTP to be successful, it needs to be better than both GMP and IGS protocol. We do this by keeping it simple _and_ complete. I already think GTP is simple - it's in text base, request/response protocol, and sits on a reliable connection. Now to make it complete, we need to at least implementing everything that GMP has to offer - that includes undo. And implement enough that would make GUI clients useful to users.
I agree with William (and Alan), that we should define which commands need to be implement for each purpose (eg. Engine, Tournament Server). So a developer only has to implement what is necessary for his goal or purpose. This will keep the GTP command set from become to unwheeldly.
Anyway, right now I've been focusing on documenting the GTP command set. I hope to have it available in a few days for review.
Phil
----- Original Message ----- From: "William Harold Newman" william.newman@airmail.net To: gtp@lists.lysator.liu.se Sent: Wednesday, August 15, 2001 4:12 PM Subject: Re: [gtp] GTP Goals, ver. 3
On Wed, Aug 15, 2001 at 05:44:17PM -0400, Don Dailey wrote:
Both GMP and IGS protocol support undo. How many programs actually
use
it?
What user interface is complete without undo?
Which is more important, to standardize a protocol which implements a complete user interface, or to standardize a protocol which does a good job on the features that programs actually use when interfacing to other programs (including servers and multitool-things like cgoban)?
Of course, I still don't know the answer to my first question. Maybe the number of programs which use the existing 'undo' command is much larger than I realize..
--
Another footnote:
I suggested at one time that we just do a complete (but small) set and to let all commands be considered optional. This is pretty much the same idea. There are only 4 commands that you cannot manage to play a game with, genmove_white, gen_move_black, white and black.
Some other stuff can be faked with great effort by the interface builder, by carefully studying everything you can about each program you are building an interface for. Assuming we have only the 4 commands I mentioned, let's consider how we might do certain things:
newgame - kill the engine and restart.
takeback - kill the engine and feed back in all the game history.
version - build a configuration file that contains the programs with the version names.
Level - Have a configuration that understands the apropriate commands line arguments for setting various levels for various programs. If level is set during a game, kill the engine, reinvoke it with the correct command line arguments, feed back in the move to catch up to current position.
Setup - I'm not sure how easy this is to fake. You can place stones on the board to set up a position from a book or problem set, but you cannot be too arbitrary about the order you put the stones in, or you might accidently make an illegal move. You would probably end up with a program that could set up most positions, but people would notice that there were certain ones that cause it to crash, hang or simply reject.
Doesn't it seem silly that the interface builder should go through such superhuman efforts to build an interface everyone can use? If a new go engine comes along, the user must tediously create and careful test a large set of configuration options that are specific to the program being "interfaced."
In fact, why bother with GTP to do this? If GTP itself can't handle this why would I waste my time using GTP?
I don't need GTP to learn how each program works, wrap it up in my own shell and tediously configure a list of programs to work with it. GUI oriented programs will be harder but even this is doable, I used to do it with commercial chess programs so that I could autotest them against each other unsupervised. In involves trapping mouse or keyboard events, "reading" the screen in graphics mode etc.
So GTP is either a communication protocol or it isn't, and if it can't communicate then it's really a "could have been" thing, and people will stick with GMP (why would they change?)
Don
From: "Cabrera, Alan" adc@multex.com
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@insignia.com Cc: gtp@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@insignia.com
Don Dailey drd@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@insignia.com http://www.insignia.com _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
-
Anders Kierulf -
Cabrera, Alan -
Don Dailey -
Gunnar Farneb�ck -
Joan Pons i Semelis -
Nicklas Ekstrand -
Phil -
Phil Garcia
-
William Harold Newman