Don Dailey drd@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@match.stanford.edu Cc: gnugo@gnu.org, gtp@lists.lysator.liu.se References: 3.0.3.32.20010818210823.00fb5b48@mail.codebus.com 3.0.3.32.20010818210823.00fb5b48@mail.codebus.com 3.0.3.32.20010819082308.00f49f40@mail.codebus.com 200108191549.IAA31169@match.Stanford.EDU kmelq8vvw0.fsf@insignia.com Sender: gtp-admin@lists.lysator.liu.se Errors-To: gtp-admin@lists.lysator.liu.se X-BeenThere: gtp@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@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
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.
Dan
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
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
Cc: bump@match.stanford.edu, dave.denholm@insignia.com, gnugo@gnu.org, gtp@lists.lysator.liu.se From: Dave Denholm dave.denholm@insignia.com Date: 19 Aug 2001 20:34:31 +0100
Don Dailey drd@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.
Yes, I had 2 platforms in mind, Dos and Unix.
Your suggestion is pretty workable and I would second it. My GTP parser uses whitespace as the token delimiter, so I couldn't see a filename with spaces in it anyway. As far as I know this is the GTP convention and there is no provision for whitespace within token names, but I haven't done a really careful reading of the notes on it either.
I would suggest the following way to put spaces in a token. Use the '%hh' convention where '%' is an escape character and hh is 2 hex digits which represent an ascii character code. The character '%' itself would be escaped with %25 (it could also be '%%' but that makes the parsers somewhat more complicated.) I believe that only spaces and percentages inside of tokens would ever use this code.
'%' <percent> = %25 ' ' <space> = %20
It's brain dead simple to parse this. Scan the string, when you see a '%' character convert it (and next 2 characters) to a single ascii code. If the next 2 digits are not hex digits, assume the software is broken and let the '%' represent itself.
dd (don dailey)
(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@match.stanford.edu Cc: gnugo@gnu.org, gtp@lists.lysator.liu.se References: 3.0.3.32.20010818210823.00fb5b48@mail.codebus.com 3.0.3.32.20010818210823.00fb5b48@mail.codebus.com 3.0.3.32.20010819082308.00f49f40@mail.codebus.com 200108191549.IAA31169@match.Stanford.EDU kmelq8vvw0.fsf@insignia.com Sender: gtp-admin@lists.lysator.liu.se Errors-To: gtp-admin@lists.lysator.liu.se X-BeenThere: gtp@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@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
-- dave.denholm@insignia.com http://www.insignia.com
-
Daniel Bump -
Dave Denholm -
Don Dailey -
Pierce Wetter