Heikki wrote:
When changing this, could we add human-readable comments to the codes? Something like = 1 B8 (Can live) = 2 B8 (kill with good ko)
GNU Go sends most gtp responses to stout but showboard writes to stderr. Perhaps responses intended for human consumption should go to stderr and should not be part of the specification.
I see Phil's draft specification is now up on the web in a form I can read (html). It states:
The end-of-line is defined as either CR or LF: EOL = CR or LF
I know Gunnar didn't like this. The GNU Go 3.0.0 doc says this:
Newlines are implemented differently on different operating systems. On Unix, a newline is just a line feed LF (ascii \012). On DOS/Windows it is CRLF (\013\012). Thus whether GNU Go sends a carriage return with the line feed depends on which platform it is compiled for. The arbiter should silently discard carriage returns.
Perhaps the doc should say that EOL is defined as LF and that an optional CR will be silently discarded by the arbiter.
Dan
I will change the draft specification to match Gunnar's defination of end-of-line; including that empty lines or lines with just white spaces are to be completely ignored by the Engine and Controller. Gunnar, please let me know if I get this right in the next revision.
I see Phil's draft specification is now up on the web in a form I can read (html). It states:
The end-of-line is defined as either CR or LF: EOL = CR or LF
I know Gunnar didn't like this. The GNU Go 3.0.0 doc says this:
Newlines are implemented differently on different operating systems. On Unix, a newline is just a line feed LF (ascii \012). On DOS/Windows it is CRLF (\013\012). Thus whether GNU Go sends a carriage return with the line feed depends on which platform it is compiled for. The arbiter should silently discard carriage returns.
Perhaps the doc should say that EOL is defined as LF and that an optional CR will be silently discarded by the arbiter.
Dan
-
Daniel Bump -
Phil Garcia