Don Dailey drd@supertech.lcs.mit.edu writes:
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."
Yes, but a client-side library can do this stuff once, rather than requiring every interface builder to do it themselves.
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?)
Does gmp allow stones to be placed explicitly ?
dd
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 likeif ( 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
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
I would like to propose a new GTP command: command_list. It that returns a list of all implemented commands (space delimited). For example:
< command_list
boardsize name protocol_version version black white genmove_black
genmove_white undo
This way the client can determine what GTP commands are available without having to attempt them.
This would be a useful command but the idea is to have a single standard (I think.) There is a lot of resistance to any kind of convienence feature, so I doubt this will go over well, even though I personally like it. It would be an easy way for a GTP based tool to quickly find out if the client implemented the standard set or at least enough for the tool to function.
Don
From: "Phil" PhilippGarcia@home.com
I would like to propose a new GTP command: command_list. It that returns a list of all implemented commands (space delimited). For example:
< command_list
boardsize name protocol_version version black white genmove_black
genmove_white undo
This way the client can determine what GTP commands are available without having to attempt them.
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
From: Dave Denholm dave.denholm@insignia.com
Don Dailey drd@supertech.lcs.mit.edu writes:
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."
Yes, but a client-side library can do this stuff once, rather than requiring every interface builder to do it themselves.
But you still have to go through an elaborate configuration phase for each and every program in order to use the library. In fact, you might as well ignore GTP if you have to do this, because you are now operating in the mode where you configure each program separately based on how the program works, not GTP. Do you really think that should be the goal of the GTP standard?
Also, these "workarounds" have to be considered ugly kludges. I am a champion of ugly kludges when it's not possible to implement a more elegant solution, but that is hardly the case here. To illustrate how broken this is, if I implemented "undo" by killing and restarting the program, how long will the user wait just to undo a single move? My program uses large hash tables and there is a noticable startup time delay while these initialize. Not only that, but my program would also be crippled because I benefit from state kept from searches done recently. This would all go away just because we were forced to do it the wrong way (or wanted to isolate the programmer from having to implement the daunting "undo" command.
By the way, your idea of a library is a very good one. But having a broken GTP standard would hurt a library too, in exactly the same way it would cripple any GTP tool. It does not change or re-define the problem. Also, I will point out that a library is one thing GTP makes possible, it's part of the rationale for standardizing the low level protocol.
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?)
Does gmp allow stones to be placed explicitly ?
dd
Well, GTP does allows you to place stones out of turn, but they are considered moves, not just placements.
After thinking about this a little bit more, I think that you could implement position setup (if the position is legal of course) by simply "moving" all the stones explicitly, because I am not aware of any placement strategy that can cause a capture to happen once you have a legal position in mind. Does anyone see anything wrong with this reasoning?
However, this is an example of where a simple GTP command would do the job better, and would be trivial to implement in an engine. The normal mechanism would require a great deal of back and forth communication and I would suggest a command to allow placing a group of stones with no validation. You should be able to do something like "place_black j3 a4 b5 ..." etc.
Again, none of this is unreasable stuff and I'm not looking for a highly complex command set that no one will be interested in implementing. A programmer, in the development stage doesn't need to implement every command as long as s/he returns "not_implemented", and would get most of the functionality of good interfaces right away and could clean up later after he gets the basics right.
Don
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 likeif ( 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
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
-- dave.denholm@insignia.com http://www.insignia.com
After thinking about this a little bit more, I think that you could implement position setup (if the position is legal of course) by simply "moving" all the stones explicitly, because I am not aware of any placement strategy that can cause a capture to happen once you have a legal position in mind. Does anyone see anything wrong with this reasoning?
Don
Yes, the position could be set up that way, but the history of the game would depend on the sequence in which stones are added, which could possibly make some future moves illegal (due to not repeating previous board positions). Thus I think Setup has to be one of the basic commands.
Anders Kierulf www.smartgo.com
-
Anders Kierulf -
Dave Denholm -
Don Dailey -
Phil