gtp August 2001

gtp@lists.lysator.liu.se

20 participants
58 discussions

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

17 Aug '01

Yes. I think we understand that. -----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Thursday, August 16, 2001 7:52 PM To: adc(a)multex.com Cc: wms(a)igoweb.org; gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3 Alan, > What I'm proposing is to have several non-overlapping standards that > do different things. Good, that's one proposal. My proposal is to have a single standard GTP command set. Don From: "Cabrera, Alan" <adc(a)multex.com> Your conclusion "the odds that any particular program uses any particular set gets sharply reduced" does not necessarily follow from your assertion that "If you fragment [GTP] to several standards". Also, if a particular set of commands does fall into disuse then it's because no one thought it was important enough to support. I would argue that if, and I use a little bit of hyperbole to make my point, there is a single giant standard, people will be discouraged from implementing it or, worse, not completely and/or correctly implement it. X windows comes to mind and, Christ, how long did it take everyone to get that protocol pig right? Please understand that what I'm proposing is NOT several different standards. This implies that there are several different ways of doing the same thing; which is NOT the case here. What I'm proposing is to have several non-overlapping standards that do different things. Now here is why we do this. An implementer does not have to pay for feature sets that he does not want or need and others are free to innovate previously un-thought of features. It would also allow feature sets that are not popular to fall by the wayside and not hang on like useless DNA. Why do i have to implement TCP when UDP will do for my particular application? It's that simple. Alan -----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Thursday, August 16, 2001 4:29 PM To: adc(a)multex.com Cc: wms(a)igoweb.org; gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3 From: "Cabrera, Alan" <adc(a)multex.com> Did we reject the idea of multiple GTP command sets? How, exactly, would it would serve to discourage the adaptation of a standard? If you fragment this to several standards, then the odds that any particular program uses any particular set gets sharply reduced. That means that all those standards are (unintentionally) discouraged. If we create and promote a single standard, everyone benefits because ANY (gtp standard) engine will work with ANY gtp tool. Now that is something that benefits everyone! By having a single standard instead of 5 different ones, we are keeping things simple and implicity encourage people to implement the whole thing, not just some little piece. But go ahead and make up as many different standards as you want to. If you actually believe this will bring everyone together, I'm all for it. Don Alan -----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Thursday, August 16, 2001 2:51 PM To: wms(a)igoweb.org Cc: gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3 From: "William M. Shubert" <wms(a)igoweb.org> Don, your comments are making less and less sense. I am merely putting out the point that since we plan on using GTP for several purposes, and some commands will be used for only some of these purposes, then it makes sense to break out the commands used for each purpose (eg tournaments) so that a programmer can implement only the commands they plan on using. What is so hard to understand about that? My fault, I read that email in a big hurry. I thought we had earlier rejected the idea of multiple GTP command sets? It's just my opinion, but I think this would serve to discourage the adaptation of a standard. William, I don't mean to be contentious about these issues, but I know that I am currently building a GOOD user interface and I will be making it available for EVERYONE to use. It will support "undo" and you will be able to set up positions from scratch and load problems. So I'm speaking from a real NEEDS point of view, not a hypothetical "what kind of things might someone want to build" perspective. I also know that one of two things will happen when I am done: 1. The new GTP standard will be powerful enough to support my UI. 2. The new GTP standard will need some extensions in order for OTHER programs to work with it. I'm still going to build my interface in either case, but I will use my own extensions reluctantly, only if I have to. The extension I use will either be adapted anyone by others so they can use my interface, or someone else will build a more popular interface and have to build their own extensions. Don Why do you insist on anwsering my messages with bizarre tangents (like having to make up your own commands) that have nothing at all to do with what I was saying? Don Dailey wrote: >> I don't see why we need to force a person who just wants to participate in >> GTP tournaments to implement the commands for these other purposes. >> > >Who is it you are trying to be fair to? What about other users, they >don't matter? > >I'm not going to fight this battle any longer if others don't care >either. I'll make up the commands if I have to and other programmers >will have to conform to use my tools. It really isn't the way I want >to do it, but I'm not going to write a user interface without the >"position setup" feature or "undo" command just to name a couple. > >Don > -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/> _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

1 0

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

17 Aug '01

Your conclusion "the odds that any particular program uses any particular set gets sharply reduced" does not necessarily follow from your assertion that "If you fragment [GTP] to several standards". Also, if a particular set of commands does fall into disuse then it's because no one thought it was important enough to support. I would argue that if, and I use a little bit of hyperbole to make my point, there is a single giant standard, people will be discouraged from implementing it or, worse, not completely and/or correctly implement it. X windows comes to mind and, Christ, how long did it take everyone to get that protocol pig right? Please understand that what I'm proposing is NOT several different standards. This implies that there are several different ways of doing the same thing; which is NOT the case here. What I'm proposing is to have several non-overlapping standards that do different things. Now here is why we do this. An implementer does not have to pay for feature sets that he does not want or need and others are free to innovate previously un-thought of features. It would also allow feature sets that are not popular to fall by the wayside and not hang on like useless DNA. Why do i have to implement TCP when UDP will do for my particular application? It's that simple. Alan -----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Thursday, August 16, 2001 4:29 PM To: adc(a)multex.com Cc: wms(a)igoweb.org; gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3 From: "Cabrera, Alan" <adc(a)multex.com> Did we reject the idea of multiple GTP command sets? How, exactly, would it would serve to discourage the adaptation of a standard? If you fragment this to several standards, then the odds that any particular program uses any particular set gets sharply reduced. That means that all those standards are (unintentionally) discouraged. If we create and promote a single standard, everyone benefits because ANY (gtp standard) engine will work with ANY gtp tool. Now that is something that benefits everyone! By having a single standard instead of 5 different ones, we are keeping things simple and implicity encourage people to implement the whole thing, not just some little piece. But go ahead and make up as many different standards as you want to. If you actually believe this will bring everyone together, I'm all for it. Don Alan -----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Thursday, August 16, 2001 2:51 PM To: wms(a)igoweb.org Cc: gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3 From: "William M. Shubert" <wms(a)igoweb.org> Don, your comments are making less and less sense. I am merely putting out the point that since we plan on using GTP for several purposes, and some commands will be used for only some of these purposes, then it makes sense to break out the commands used for each purpose (eg tournaments) so that a programmer can implement only the commands they plan on using. What is so hard to understand about that? My fault, I read that email in a big hurry. I thought we had earlier rejected the idea of multiple GTP command sets? It's just my opinion, but I think this would serve to discourage the adaptation of a standard. William, I don't mean to be contentious about these issues, but I know that I am currently building a GOOD user interface and I will be making it available for EVERYONE to use. It will support "undo" and you will be able to set up positions from scratch and load problems. So I'm speaking from a real NEEDS point of view, not a hypothetical "what kind of things might someone want to build" perspective. I also know that one of two things will happen when I am done: 1. The new GTP standard will be powerful enough to support my UI. 2. The new GTP standard will need some extensions in order for OTHER programs to work with it. I'm still going to build my interface in either case, but I will use my own extensions reluctantly, only if I have to. The extension I use will either be adapted anyone by others so they can use my interface, or someone else will build a more popular interface and have to build their own extensions. Don Why do you insist on anwsering my messages with bizarre tangents (like having to make up your own commands) that have nothing at all to do with what I was saying? Don Dailey wrote: >> I don't see why we need to force a person who just wants to participate in >> GTP tournaments to implement the commands for these other purposes. >> > >Who is it you are trying to be fair to? What about other users, they >don't matter? > >I'm not going to fight this battle any longer if others don't care >either. I'll make up the commands if I have to and other programmers >will have to conform to use my tools. It really isn't the way I want >to do it, but I'm not going to write a user interface without the >"position setup" feature or "undo" command just to name a couple. > >Don > -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/> _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

2 1

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

16 Aug '01

Did we reject the idea of multiple GTP command sets? How, exactly, would it would serve to discourage the adaptation of a standard? Alan -----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Thursday, August 16, 2001 2:51 PM To: wms(a)igoweb.org Cc: gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3 From: "William M. Shubert" <wms(a)igoweb.org> Don, your comments are making less and less sense. I am merely putting out the point that since we plan on using GTP for several purposes, and some commands will be used for only some of these purposes, then it makes sense to break out the commands used for each purpose (eg tournaments) so that a programmer can implement only the commands they plan on using. What is so hard to understand about that? My fault, I read that email in a big hurry. I thought we had earlier rejected the idea of multiple GTP command sets? It's just my opinion, but I think this would serve to discourage the adaptation of a standard. William, I don't mean to be contentious about these issues, but I know that I am currently building a GOOD user interface and I will be making it available for EVERYONE to use. It will support "undo" and you will be able to set up positions from scratch and load problems. So I'm speaking from a real NEEDS point of view, not a hypothetical "what kind of things might someone want to build" perspective. I also know that one of two things will happen when I am done: 1. The new GTP standard will be powerful enough to support my UI. 2. The new GTP standard will need some extensions in order for OTHER programs to work with it. I'm still going to build my interface in either case, but I will use my own extensions reluctantly, only if I have to. The extension I use will either be adapted anyone by others so they can use my interface, or someone else will build a more popular interface and have to build their own extensions. Don Why do you insist on anwsering my messages with bizarre tangents (like having to make up your own commands) that have nothing at all to do with what I was saying? Don Dailey wrote: >> I don't see why we need to force a person who just wants to participate in >> GTP tournaments to implement the commands for these other purposes. >> > >Who is it you are trying to be fair to? What about other users, they >don't matter? > >I'm not going to fight this battle any longer if others don't care >either. I'll make up the commands if I have to and other programmers >will have to conform to use my tools. It really isn't the way I want >to do it, but I'm not going to write a user interface without the >"position setup" feature or "undo" command just to name a couple. > >Don > -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/> _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

2 1

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

16 Aug '01

I'm not sure that you understood what I said; I am confused as to why you include a scenario where commands are to be simulated since I am not suggesting that at all. Let me run through a sample scenario. It is not meant to be complete but is merely for expository purposes. I also want to add that we should have a common set of use cases that we agree on. Reading the archives of this group leads me to believe that we may not have a consensus on use cases. The GTP group has sanctioned two official command sets. First, we start with a core feature set labeled "core". It will contain genmove_white, gen_move_black, white and black. Second, we have the feature set labeled "player_to_player". It will contain newgame, takeback, version, Level, and Setup. Now your program supports core and player_to_player. My program only supports core. When we hook up to play we exchange supported sets and discover that we can only communicate via the core set. You've written a fancy interface telling the user that such and such commands are not available and ask if he/she wants to continue. The user does not wish to setup the board by hand and refuses the game. Now, there's a guy named Joey who has a program who's engine only supports core but is very impressed by your program's interface and wants to support player_to_player like functionality. So, he simulates the player_to_player functionality, with the set core of commands, in his interface. Joey does this because he's stolen the engine from someone and is unable to modify it. :) (Is this what your talking about?) Now, a guy named Bill comes up with six super-duper commands that has waiting rooms and allows chatting and mp3 files to be exchanged. He goes to the GTP group to have a new standardize set approved. The group gives his set the name "player_to_server". Now you may want to upgrade your program to include this new set. Since I'm only writing a tournament machine, I will not. Joey, would like to include the player_to_server set of commands in his program but has yet to add an mp3 player to his set of warez; he chooses to not support it. The critical key here is that we have GTP sanctioned sets. You may say, Don, "Yes, yes, yes, we've discussed this before". However, anytime someone discusses leaving out a command that's near and dear to you, you bring up arguments that have no validity if we accept the above paradigm. Regards, Alan -----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Wednesday, August 15, 2001 9:22 AM To: adc(a)multex.com Cc: gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3 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(a)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(a)insignia.com Cc: gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 3 Hi Dave, Rather than making each user-interface add the composite commands, we could provide a separate (free) client-side library which implements high level commands out of the minimal commands provided by the protocol. But this is not really possible unless GTP has enough primitives to support it. If there is no "setup" command, as an example, how do you set up a position? I absolutely agree with you however, we SHOULD be able to do these things. You need a few basic primitives to do all the cool things. I am in favor of making sure we get them in a standardized set. If we don't, people (like me) will end up creating our own GTP extensions, and whoever builds the most popular user interface (or library like you are suggesting) will be the one actually defining the standard, in a defacto manner. My user interface will actually have incredibly advanced features like the ability to set up a position or "take back" a move!!! I know how amazing that may seem to some, but I have this fear that I may have to create a non-standard GTP command to do these simple things. Since I will want other programmers to benefit from this, I'll have to communicate my extensions to the world, and the GTP "standard" itself will not really be treated as a standard or gain any respect. You will get conversations like this: Q "Hey, I want to implement the standard GTP protocol so I can use this super cool user interface I found on the web with my own program." A "No, don't use the GTP standard, you can't really do anything very useful with it except push moves back and forth between 2 programs. The best set is the 'John Doe' set which most everyone else uses." Q "But I heard the Bill Johnson set is better?" A "Well, they are basically the same, but 'undo' is called 'takeback' and the Johnson set doesn't let you set levels except by editing the 'program invocation' box and adding the proper command line arugments." Q "I just tried the John Doe set like you suggested, but it does't work." A "Which user interface are you using?" Q "I'm using the 'SuperGo tools' gui package." A "Ok, that's a good one, but doesn't really work with the Doe set, I guess you have to use the Johnson set. By the way, there is a patch that let's you set levels by storing a library of different program invocation strings in a buffer and pressing the F7 function key to cycle through them." ... etc. Don From: Dave Denholm <dave.denholm(a)insignia.com> Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > I would like to also point out that we CAN have a very complete set > without it being "big" and involved or difficult to implement. A set > was already sketched out that is very small, but makes it possible to > design a full featured user interface. > > By "full featured" I mean just all the basics, saving and loading > games, positions, setting levels, taking back moves etc. Almost any > highly advanced features can be composed by a user interface if we > have the minimal support that I am asking for. Also, I don't want to > be forced to add my own non-standard commands just to be able to do > something really as basic and simple as taking back moves. How lame > is that? > Haven't really been keeping up, but... Rather than making each user-interface add the composite commands, we could provide a separate (free) client-side library which implements high level commands out of the minimal commands provided by the protocol. In fact, it could even do things like if ( gtp_do_this_thing() == NOT_IMPLEMENTED ) { gtp_do_that_first_simple_thing(); gtp_do_that_second_simple_thing(); ... } Eg if loading an sgf file is not implemented, the library can load it and send down lots of addstone commands. (I'm not suggestinging this as part of a gtp interface library, but as a value-added separate layer...) dd -- dave.denholm(a)insignia.com http://www.insignia.com _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

1 0

Undo on Servers
by Magnus Persson 16 Aug '01

16 Aug '01

> 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? > > -- > William Harold Newman <william.newman(a)airmail.net> My program Viking plays on NNGS and do not allow undo. As a matter of fact my program are able to make "undo" easily sinc the abstract base class of my Go Engine defines TakeBack, I realized that if i did not implement that from the very beginning (that was a random player) I would regret it later. So what is my point? I think undo in GTP for is a good thing. But a server that uses GTP should allow the user (the computer programs) to refuse undo. Most conveniently would be to have a flag for this in the server. That is: the programs should handle undo but the server would never allow the human player (the usual emboldened-by-anonymity Internet twit) to issue the command. My implementation of Undo on NNGS is like this: if the opponent try an undo the program will hang and the user has to manually adjourn and then reload that painful position. The idea is that emotional distress will punish this undisired behaviour. ;-) *About Position setup* The protocol as far as I understand it (I have not gone into any details yet), make a difference between proposing a move and actually playing it in the game. This is good (my program works this way :-) ). There is a catch though: if we want to load a position, (Such as "reload" on NNGS which has to be implemented, but is not fun at all because of the IGS-style protocol) there is a danger in using the usual game playing commands for this. The reason is that playing a move in a game might induce a lot of overhead in a game playing program. My program makes a full rematch of all patterns on the board which is quite slow (up to one second). If an endgame position is loaded it could take minutes to do so. I once had a bug that caused exactly this problem for a while and I thought my program was too slow and that I had to abondon my approach of wait for 100 GHZ computers) Thus I think setup has to be separated from ordinary playing commands. (If your program is fast there is no pain involved implementing this because you just use the same code for both playing and setup). Conclusion: undo is good for all (programmers should adapt) and setup has to be separate (gtp cannot expect playing moves take no time) and the nice thing is that if you can implement fast setup undo follows conveniently. It is just a matter of good design. And the protocol should encourage that. Best Wishes Magnus Persson -- Magnus Persson Department of psychology, Uppsala University Box 1225, SE-751 42, Sweden 018-471 2141 (work), 018-460264 (home) 070-2987879 (cellular) MAILTO: magnus.persson(a)psyk.uu.se URL: http://www.docs.uu.se/~magnuspe

2 1

Re: [gtp] GTP Goals, ver. 3
by Dave Denholm 15 Aug '01

15 Aug '01

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

4 4

Re: [gtp] New Command: command_list
by Dave Denholm 15 Aug '01

15 Aug '01

Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > 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. Well, there is the precedent that, even though protocols like smtp or nntp are intended for program<->program, they provide help : $ telnet localhost smtp Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. 220 honda.isltd.insignia.com ESMTP Sendmail 8.9.3/8.9.3; Wed, 15 Aug 2001 18:36:18 +0100 help 214-This is Sendmail version 8.9.3 214-Topics: 214- HELO EHLO MAIL RCPT DATA 214- RSET NOOP QUIT HELP VRFY 214- EXPN VERB ETRN DSN 214-For more info use "HELP <topic>". 214-To report bugs in the implementation send email to 214- sendmail-bugs(a)sendmail.org. 214-For local information send email to Postmaster at your site. 214 End of HELP info help mail 214-MAIL FROM: <sender> [ <parameters> ] 214- Specifies the sender. Parameters are ESMTP extensions. 214- See "HELP DSN" for details. 214 End of HELP info quit 221 honda.isltd.insignia.com closing connection Connection closed by foreign host. So given that gtp might be used interactively, list of commands could double up as help. Feels kind of wrong to standardise the format of the help output, though ! But would a gtp version number would be a better indicator of level of standard support ? Possibly worth tracking separately the comms protocol and the command set. > > Don > > > From: "Phil" <PhilippGarcia(a)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. > Maybe one per line rather than space-separated list ? (Is there a maximum line length defined by the lowlevel part of the protocol ?) dd -- dave.denholm(a)insignia.com http://www.insignia.com

1 0

Re: [gtp] GTP Goals, ver. 3
by Dave Denholm 14 Aug '01

14 Aug '01

Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > I would like to also point out that we CAN have a very complete set > without it being "big" and involved or difficult to implement. A set > was already sketched out that is very small, but makes it possible to > design a full featured user interface. > > By "full featured" I mean just all the basics, saving and loading > games, positions, setting levels, taking back moves etc. Almost any > highly advanced features can be composed by a user interface if we > have the minimal support that I am asking for. Also, I don't want to > be forced to add my own non-standard commands just to be able to do > something really as basic and simple as taking back moves. How lame > is that? > Haven't really been keeping up, but... Rather than making each user-interface add the composite commands, we could provide a separate (free) client-side library which implements high level commands out of the minimal commands provided by the protocol. In fact, it could even do things like if ( gtp_do_this_thing() == NOT_IMPLEMENTED ) { gtp_do_that_first_simple_thing(); gtp_do_that_second_simple_thing(); ... } Eg if loading an sgf file is not implemented, the library can load it and send down lots of addstone commands. (I'm not suggestinging this as part of a gtp interface library, but as a value-added separate layer...) dd -- dave.denholm(a)insignia.com http://www.insignia.com

2 1

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

13 Aug '01

Two good points. Thanks for the quick response. My response would be that for every platform, there usually is an XML/SAX/DOM library so, lexing, parsing, character encoding, would automatically be taken care of. These libraries are quite easy to use; have you ever tried to read someone else's lexer/parser, much less debug it? Using XML would encourage implementations across the many OS/language platforms while also supporting internationalization. Extensions could be handled with namespaces. You don't have to worry about issues such as newlines/CR. I think that many implementation issues would be solved using XML. Regards, Alan -----Original Message----- From: William M. Shubert [mailto:wms@igoweb.org] Sent: Sunday, August 12, 2001 12:02 PM To: Cabrera, Alan; GTP Mailing List Subject: Re: [gtp] GTP Goals, ver. 2 For UTF-8 vs. ascii, the beauty of it is that ASCII is a subset of UTF-8 and all non-ascii characters show up as strings of bytes >127 in UTF-8. That means that having the base command set in ASCII but comments in UTF-8 lets people write 100% ASCII lexers if they want, and they only need to worry about UTF-8 if they have non-ascii comments coming in. If they don't care about non-ascii comments looking garbled, then they can write a purely ascii parser and everything works fine. For XML, my question to you is: how would XML be better than what people are talking about now? XML has a few definite drawbacks (XML is much more complex than what has been discussed here so far, so you would need to use an XML library to parse GTP, and integrating another library into your program always requires more time and work). Usually XML's benefit is that you can deduce the structure of your communication without knowing anything about the content, but in the case of GTP, how would that make our lives any easier? Cabrera, Alan wrote: >What was wrong with my idea of using UTF-8 instead of ASCII? Also, what >about XML? Do you have any thoughts on this or am I way out in left field? > > >Regards, >Alan > >-----Original Message----- >From: William M. Shubert [mailto:wms@igoweb.org] >Sent: Sunday, August 12, 2001 2:15 AM >To: GTP Mailing List >Subject: [gtp] GTP Goals, ver. 2 > > >OK, there were some good suggestions, here's take 2 on the GTP goals. My >thoughts... > > * I think a minimal command set is absolutely necessary, but I > clarified the bullet for what most people seem to think is the > need: tournaments. If we leave all things optional, I can see one > programmer saying "Hmm, I don't ever do undos, I can leave that > command out", then if in a tournament an undo is needed (due to > operator error entering a move or some such), one of the programs > is totally screwed. We 100% need to say "you MUST implement these > commands to play in GTP tournaments." > * I clarified many of the points to say more precisely what they mean. > * I added "additional programs that would be nice but aren't > necessary for GTP to be usable" because lots of people were > suggesting programs they wanted to see written. > * I left in the requirement for GMP vs. GTP tournaments. I also see > this as necessary, because we don't want to force all old programs > to get GTP front ends, and we want to let GMP and GTP programs > participate in tournaments together. > * A few items added that people recommended, such as have GMP be > able to do general interfaces. (Seems like a really good idea, > that way one front end can be used by several programs, letting > programmers spend more time on their algorithm and less on front > end programming.) > * Some people were bringing up commands that they wanted, I left all > them out of this document. That belongs in the spec, not in the > goals document...I want the goals to be just what we want to do > with GTP and what we need to do to be successful, not include info > on how GTP will work. > >Well that's enough babbling. Here's the next version of the goals >document. Again, all comments are welcome! >************************ >GTP Goals version 2 > >Part I - Functional Requirements. These are the actions that our command >list must allow go programs to perform. > > 1. Usable to play games vs. other programs head to head. If the protocol > requires some kind of arbiter, that's OK, but see III.1. > 2. Usable for regression tests on programs. > 3. Usable for playing go on a server. > 4. Usable to write full featured interfaces. > >Part II - Implementation Goals. Constraints that we must follow when >designing the exact command list. > > 1. Simple to implement, debug and understand; all commands are ASCII, > all human text (comments etc.) is UTF-8, exactly one line per > command, each command gets an exactly one line response. > 2. Possible to create bridges that let GMP programs play head to head > vs. GTP programs in tournaments. Note that GTP and GMP will not > necessarily have the same feature set - just the possibility of > playing against each other is necessary. > 3. There must be a minimal command set that is exactly enough > commands to play head to head tournament games, no more no less! > All commands required for regression tests or server play should > be optional extensions that programmers need not implement. > 4. It should be possible to design software that gracefully deals > with unimplemented GTP commands/features. > >Part III - Necessary Auxiliary Programs. These are programs that we (the >GTP designers) must write for GTP to be successful. All must be open source. > > 1. An example program that implements the minimal GTP command set > properly and can play a legal game (similar to the goDummy program > for GMP). > 2. An arbiter to be used in head-to-head games, communicating to both > programs, judging legal/illegal rules, etc. Should the arbiter > know how to score a game? > 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play > against each other. > >Part IV - Additional Programs. These are programs that are not necessary >for us to call GTP "done" but would be useful to have publicly available. > > 1. A sample GTP program that understands all of the commands. > 2. GTP bridges for various servers. > 3. GUIs and other human-usable front ends so that programmers who > write GTP programs can automatically play against their programs, > query their programs as to evaluations, etc. > 4. A GTP test system/test library to determine whether or not a > program is emitting legal GTP. > >************************ > -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

3 2

GTP Goals, ver. 2
by William M. Shubert 13 Aug '01

13 Aug '01

OK, there were some good suggestions, here's take 2 on the GTP goals. My thoughts... * I think a minimal command set is absolutely necessary, but I clarified the bullet for what most people seem to think is the need: tournaments. If we leave all things optional, I can see one programmer saying "Hmm, I don't ever do undos, I can leave that command out", then if in a tournament an undo is needed (due to operator error entering a move or some such), one of the programs is totally screwed. We 100% need to say "you MUST implement these commands to play in GTP tournaments." * I clarified many of the points to say more precisely what they mean. * I added "additional programs that would be nice but aren't necessary for GTP to be usable" because lots of people were suggesting programs they wanted to see written. * I left in the requirement for GMP vs. GTP tournaments. I also see this as necessary, because we don't want to force all old programs to get GTP front ends, and we want to let GMP and GTP programs participate in tournaments together. * A few items added that people recommended, such as have GMP be able to do general interfaces. (Seems like a really good idea, that way one front end can be used by several programs, letting programmers spend more time on their algorithm and less on front end programming.) * Some people were bringing up commands that they wanted, I left all them out of this document. That belongs in the spec, not in the goals document...I want the goals to be just what we want to do with GTP and what we need to do to be successful, not include info on how GTP will work. Well that's enough babbling. Here's the next version of the goals document. Again, all comments are welcome! ************************ GTP Goals version 2 Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform. 1. Usable to play games vs. other programs head to head. If the protocol requires some kind of arbiter, that's OK, but see III.1. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. 4. Usable to write full featured interfaces. Part II - Implementation Goals. Constraints that we must follow when designing the exact command list. 1. Simple to implement, debug and understand; all commands are ASCII, all human text (comments etc.) is UTF-8, exactly one line per command, each command gets an exactly one line response. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs in tournaments. Note that GTP and GMP will not necessarily have the same feature set - just the possibility of playing against each other is necessary. 3. There must be a minimal command set that is exactly enough commands to play head to head tournament games, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features. Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source. 1. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game? 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other. Part IV - Additional Programs. These are programs that are not necessary for us to call GTP "done" but would be useful to have publicly available. 1. A sample GTP program that understands all of the commands. 2. GTP bridges for various servers. 3. GUIs and other human-usable front ends so that programmers who write GTP programs can automatically play against their programs, query their programs as to evaluations, etc. 4. A GTP test system/test library to determine whether or not a program is emitting legal GTP. ************************ -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

gtp August 2001