Gunnar wrote:
A newline is a indicated by a single LF. Possible occurences of CR should be discarded on input.
and:
Yes, more or less. Protocol version 1 will be whatever is implemented in GNU Go 3.0.0 when this is released and should only be used by other programs which wish to experiment with the gnugoclient 2.0 or twogtp programs. The first fully specified protocol will be version 2. I expect this to be followed by a version 3 and possibly more when it becomes clear what is missing or done wrong in the protocol. This means I definitely don't expect version 2 to be final and complete but I do expect it to be finished in a not too far future.
I am hoping that GNU Go 3.0.0 will be released by the end of this week and that there will be no substantial changes in the engine. We've achieved clean builds on Unix and GNU/Linux as well as Windows with VC++ or Cygwin. If all is well, 2.7.253 should also build cleanly on Mac OS X and pass the regressions though I have not been informed if that is the case.
So it is worth reviewing how GNU Go 2.7.253 handles the newlines in the GTP.
Newlines are written in gtp.c and play_gtp.c with the standard C function printf(" ... \n"). On Unix this makes a LF=\012. On DOS it makes CRLF. David stated that on Macintosh it makes just a Carriage return but we believe this is not true with OS X. If it were, things would be worse broke than they are now.
(Does anyone know?)
We are aiming at good compatibility with Mac OS X and may be close to achieving it, thanks to help from Pierce Wetter and others. I'm less optimistic that we will have full compatibility with Mac classic though I'll change the names of two files as Alan Crossman suggested.
I have to interpret Gunnar's statement as meaning that writing an LF is mandated and CRLF is acceptable.
Dan