gtp

gtp@lists.lysator.liu.se

164 discussions

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

20 Aug '01

Gunnar Farnebäck <gunnar(a)lysator.liu.se> writes: > Dave wrote: > > AFAIK VC is doing the correct thing : \n is defined to expand to whatever > > line ending is appropriate for the platform. > > > > [...] > > > > I think I did mention this feature of \n | \r, and pointed out that > > any portable implementations of GTP code should use \012 explicitly > > if they mean a LF character. > > > > [...] > > > > And on mac, \n is CR > > > > \012 is probably safest if you really mean a LF character > > I'm almost, but not completely, certain that you are somewhat wrong > here. What follows is my understanding, which also could be > wrong. It's correct that the C standard doesn't say what numerical > value '\n' should have, although ascii LF is a common choice, at least > on unix platforms. I'm pretty certain that '\n' does NOT expand to > anything like CRLF on dos/windows platforms simply because that is not > a single character. It's possible that '\n' has the value ascii CR on > MacOS, but that is more than I know about. > > The missing step here is that what actually is written to the output > is decided by the C library. What in particular is important is > whether the FILE being written to has been opened in text mode or in > binary mode. On unix systems I don't think this ever makes a > difference, but on other platforms it may. On dos/windows platforms, > this is where \n (however it is represented) is converted to the CRLF > sequence, but only in text mode. Please correct me if I'm wrong about > this. Apologies. You are quite correct, it's the library that's doing the conversion, and therefore \n and \012 are likely to be treated the same. [I'm sure I saw using \012 instead of \n recommended somewhere. Can't think where that was now. Ah : must have been a mac thing, where \n is a CR. ] dd -- dave.denholm(a)insignia.com http://www.insignia.com

1 0

RE: [gtp] Re: VC regression failures
by Cabrera, Alan 20 Aug '01

20 Aug '01

CR = <US-ASCII CR, carriage return (13)> LF = <US-ASCII LF, linefeed (10)> HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7. 19.3 Tolerant Applications The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR. -----Original Message----- From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] Sent: Monday, August 20, 2001 11:08 AM To: pierce(a)twinforces.com Cc: bump(a)match.stanford.edu; gtp(a)lists.lysator.liu.se; gnugo(a)gnu.org; dave.denholm(a)insignia.com Subject: Re: [gtp] Re: VC regression failures When is this really an issue? It's only when you are doing things over a network between platforms, never when you are using "native" software tools. Is there already a defined convention for doing this? I know these platforms work together all the time over the internet, but I have never taken the time to understand what the low level issues are. Web pages can be constructed and loaded on all platforms, how are web browsers designed to cope with these issues? I don't know the answer, but I suggest we find out, and do the same. Don Date: Mon, 20 Aug 2001 07:35:10 -0700 On Sunday, August 19, 2001, at 08:18 PM, Daniel Bump wrote: > > David Denholm wrote: > >> My inclination would be to define that GTP uses LF for end of line, and >> treats CR as a whitespace character. Provided the protocol also >> defines that >> trailing whitespace will be ignored (which impacts things like sending >> filenames as parameters, since they could end in spaces). >> in space, for example) So then either CRLF or LF will work fine. > > A disadvantage of this scheme is that printf("gtp response\n") > would be broken on Macintosh, since CR is the Macintosh newline. > Mac C compilers output \r in place of \n. PC C compliers output CRLF. Easier to just execute when either a CR or LF is received, and allow the "null" command that lies between CRLF. Pierce _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

2 1

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

20 Aug '01

Don Dailey <drd(a)supertech.lcs.mit.edu> writes: > > I wonder if it is possible to come to a consensus about > > newline policy in the gtp before we release 3.0.0. > > I wonder that too. > > My suggestion is: For writing data, use the line ending convention of > the platform your software runs on. For reading data, make sure your > software can read either convention. Use of 'either' suggests you have two in mind, which presmably means LF and CRLF. But different platforms could appear in the future, using some other convention for \n. So as I have said, I don't think \n can safely by used in any portable libraries written for GTP. (BTW, correct me if I am wrong, but my understanding is that in java, println will send the appropriate line-ending characters, but \n means exactly LF. In c, \n expands to the platform specific sequence. > > This is not difficult to do on either platform. Other than DOS and > UNIX, are their other line ending conventions in common use? What do > MAC's do? I believe macs use CR only, though much software will cope with LF and CRLF My inclination would be to define that GTP uses LF for end of line, and treats CR as a whitespace character. Provided the protocol also defines that trailing whitespace will be ignored (which impacts things like sending filenames as parameters, since they could end in spaces). in space, for example) So then either CRLF or LF will work fine. dd > > Don > > > > > From: Daniel Bump <bump(a)match.stanford.edu> > Cc: gnugo(a)gnu.org, gtp(a)lists.lysator.liu.se > References: <3.0.3.32.20010818210823.00fb5b48(a)mail.codebus.com> <3.0.3.32.20010818210823.00fb5b48(a)mail.codebus.com> <3.0.3.32.20010819082308.00f49f40(a)mail.codebus.com> <200108191549.IAA31169(a)match.Stanford.EDU> <kmelq8vvw0.fsf(a)insignia.com> > Sender: gtp-admin(a)lists.lysator.liu.se > Errors-To: gtp-admin(a)lists.lysator.liu.se > X-BeenThere: gtp(a)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: Sun, 19 Aug 2001 10:01:36 -0700 > Content-Type: text > Content-Length: 826 > > > David Denholm wrote: > > > > We can simulate this problem on Linux by replacing all occurrences > > > of \n by \r\n in gtp.c. I just did that and found that regress.sh > > > is broke but twogtp is not. > > > > That wouldn't help since on windows that would (may) give CRCRLF > > The purpose of that change to gtp.c wasn't to fix anything but to > break it. I wanted to see what the problem was. So I hacked in > carriage returns to gtp.c, in order to see where they should be > stripped in regress.awk. > > > And on mac, \n is CR > > > > \012 is probably safest if you really mean a LF character > > I wonder if it is possible to come to a consensus about > newline policy in the gtp before we release 3.0.0. > > Dan > > _______________________________________________ > 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] GTP Specification-Draft
by Dave Denholm 20 Aug '01

20 Aug '01

"Phil Garcia" <PhilippGarcia(a)Home.com> writes: > Thanks Anders for all the comments and questions. > > From: "Anders Kierulf" <anders(a)smartgo.com> > To: <gtp(a)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. We could do what the existing internet protocols do (smtp, nntp, ...), and have both a 3-digit error code, followed by explanatory text. dd -- dave.denholm(a)insignia.com http://www.insignia.com

3 2

Re: [gtp] GTP Specification-Draft
by Phil 20 Aug '01

20 Aug '01

From: "Daniel Bump" <bump(a)match.Stanford.EDU> > > Does the link work? I get a http 404 (file not found) error. > > Dan > I got this same message from a few people. I could use some help here - I rechecked all the links with both Netscape 6.1 and Internet Explorer 6.0 and I did not find a single problem. Frontpage does not report any broken links either. I'm stumped. Any ideas? Phil

1 0

Re: VC regression failures
by Daniel Bump 19 Aug '01

19 Aug '01

I'm cc'ing both the GNU Go list and the GTP list because this is a protocol issue. To summarize, Trevor Morris reports that the GNU Go regressions are broke on Visual C. The reason is that apparently printf on VC++ interprets \n as CRLF instead of just LF. I think this is an issue which was discussed in the protocol list but I do not remember whether any conclusions were reached. Trevor Morris wrote: > >Do you mean that the gtp output > >is getting spurious CR's added by the DOS version of the > >program? > > Yes, this is the problem. Spurious CR added by the DOS version of the > program. An appropriate sed script to strip out the offending ^M > characters should do it. > > Perhaps the GTP needs to explicitly define what the end-of-line character(s) > should be? We can simulate this problem on Linux by replacing all occurrences of \n by \r\n in gtp.c. I just did that and found that regress.sh is broke but twogtp is not. One difference between the two is that regress.sh is awkward where twogtp is perlward. Perhaps we should reimplement regress.sh in perl. But without going so far, the patch at the end of this message should fix the problem. At least it fixes the broke version I made by adding \r's in gtp.c. Trevor, could you try this? Dan diff -u -N -r -x *.info* -x *Makefile* ./regression/regress.awk ../gnugo-2.7.252/gnugo-2.7.251/regression/regress.awk --- ./regression/regress.awk Thu Apr 26 00:45:53 2001 +++ ../gnugo-2.7.252/gnugo-2.7.251/regression/regress.awk Sun Aug 19 15:12:50 2001 @@ -15,6 +15,7 @@ } /^[=?][0-9]+ /{ + sub(/\r/, ""); sub(/^[=?]/, ""); num = $1; sub(/^[0-9]+ */, "");

2 2

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 16 Aug '01

16 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

Jump to page:

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