gtp August 2001

gtp@lists.lysator.liu.se

20 participants
58 discussions

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 20 Aug '01

20 Aug '01

Well, I think that we may need commands where the machines can announce to each other what command sets they support. Once that is done, each machine will announce what command sets they intend to use for that session. Maybe something like: begin_command_sets_available tournament player_to_player end_command_sets_available begin_command_sets_used tournament end_command_sets_used or: begin_command_sets_available tournament player_to_player end_command_sets_available session_rejected if the machine does not wish to continue. Alan > -----Original Message----- > From: Gunnar Farnebäck [mailto:gunnar@lysator.liu.se] > Sent: Monday, August 20, 2001 4:39 PM > To: gtp(a)lists.lysator.liu.se > Subject: Re: [gtp] GTP Specification-Draft > > > Alan wrote: > > I was wondering if there's a clear consensus on command > sets. What I mean > > by that is, has everyone bought in on the idea of having > named command sets > > that are accepted or rejected during an initial command negotiation? > > Initial command negotiation? > > > If it's felt to be not a good idea, fine; I feel that both Don and I > > have said our piece. However, if you like it, then I have some > > comments on the draft. > > I think it will be necessary to partition the command set into a > number of subsets for different application areas. While tournament > and server play has about the same needs, regression testing and gui > applications are quite different. To take the popular example of undo > this is marginally important in the first case, mostly pointless in > the second case, and quite important in the last case. > > /Gunnar > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp >

2 1

End-of-line
by Phil 20 Aug '01

20 Aug '01

In the specification, the end-of-line will be either a linefeed or carriage return. Empty lines are to be disregard and no output will be sent back. Phil

4 4

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 20 Aug '01

20 Aug '01

I was wondering if there's a clear consensus on command sets. What I mean by that is, has everyone bought in on the idea of having named command sets that are accepted or rejected during an initial command negotiation? If it's felt to be not a good idea, fine; I feel that both Don and I have said our piece. However, if you like it, then I have some comments on the draft. Regards, Alan > I think it's a good idea to have a mechanism for extensions which is > smart enough to allow a standard "not implemented" response.

2 1

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

20 Aug '01

Pierce Wetter <pierce(a)twinforces.com> writes: > Perl on Windows outputs CRLF for \n. Just read this last night in the > Perl Cookbook. So if we want twogtp to work on Windows, the gtp protocol > has to deal with CRLF at the minimum. Mac perl probably spits out a CR, > so the same goes there, except on Mac OS X, which is really unix... > But in perl you can just set the filehandle to binmode and then it should just send/recv exactly what you tell it to... > Someone could write a quick C program to find out what Windows does in > C with \n for sure on that platform. > One question is, how would a dos/windows program be speaking to the other end of a gtp channel ? Possibly not through the stdio library, in which case this may not matter. If it sprintf's to a string and then calls a win32 api to send the data along a named pipe, for example, then there should be no conversions taking place. Similarly, if using sockets, send() and recv() operate on buffers of data, and the \n reinterpretation shouldn't be happening here. ISTR it is difficult to use stdio from a windows gui program : we tried in gnuplot, but it just doesn't seem to have the concept of stdin. > > > > "A newline is a indicated by a single LF. Possible occurences of CR > > should be discarded on input." > > > > would be difficult to handle. This is in any case the newline > > convention I would prefer for GTP. > > > > > > > Then it won't work on CR platforms... > > There are three cases: CR, LF, CRLF. There exist platforms which use CR, LF and CRLF for terminating lines in local text files. This doesn't really need to have any bearing on what the gtp protocol does. Some care needs to taken when sending data, but avoiding \n and text mode on files removes these issues. I don't know how macos does pipes and things, so I don't really know whether stdio would be involved. dd > > If we want to handle all three, we need an or clause to deal with the > CR vs LF case. It seems to me our choices are: > > 1. Handle LF. > 2. Handle CRLF by ignoring CRs. > 3. Handle all three by looking for CR | LF and ignoring any extra LF. > > I think #2 is worse, because it will mysteriously not work on some > platforms. YMMV. > > #3 doesn't really seem much more difficult then #2 but it does mean we > can't use things like fgets. > > > Pierce -- dave.denholm(a)insignia.com http://www.insignia.com

1 0

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

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