Re: patch - was: Re: [gnugo-devel] temporary development web page

[Gunnar Farneback]

Aquarius wrote:
> Yes, setbuf(stdout, NULL) works - i've tested it both with the "rxvt.exe"
> of MinGW/Msys and with the java-based "GoGui" that connects through pipes.
> All on Win-XP home with MinGW-3.1.0, gcc 3.2.3 mingw special, java 1.4.2
 
Fine let's use that then.

> B.t.w:
> setvbuf(stdout, (char *)NULL, _IONBF, 0) works also. (isn't setbuf 
> deprecated?)

Not that I know of. My Linux man page says

  The setbuf function is exactly equivalent to the call
  
                setvbuf(stream, buf, buf ? _IOFBF : _IONBF, BUFSIZ);

and

  CONFORMING TO
         The setbuf and setvbuf functions conform to  ANSI  X3.159-1989  (``ANSI
         C'').

There's also a note that setbuf() uses a suboptimal buffer size but
that should be irrelevant when unbuffering. Personally I prefer the
simpler call.

> and:
> in combination with my patch enabled for all platforms even
> setvbuf(stdout, (char *)NULL, _IOFBF, 0) would work (I've tested it) - 
> resulting
> in full buffering of gtp-mode and flushing after each response. Would that be
> against the specs of the gtp protocol?

No, the GTP spec only says that no assumptions should be made about
the timing of the individual characters in the response. It's only
necessary to make sure that the controller has a chance to get the
full response at all, otherwise the communication obviously breaks
down.

> How long can a gtp-response be? (I do not know of all the debug-commands ...)

No limitation. Hmm, this seems to be missing in the spec.

/Gunnar