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 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
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp