[gnugo-devel] Strange error in self-compiled GNU Go 3.5.x for Win32 using gtp-mode (patch included)

[aquarius]

Hi all,

recently I started to build up my own MinGW/Msys environment for compiling
development and interim versions of GNU Go for Win32 on my WinXP Home box.

It all went painless so far - I am using the current stable versions of
MingW/Msys: MinGW-3.1.0-1 (plus runtime-3.2 upgrade), MSYS-1.0.9 and 
msysDTK-1.0.1.

PROBLEM:
Unfortunately MingW/Msys cannot cope with the change in STDOUT-buffering
introduced in the 3.5.x versions: The following line in play_gtp.c:

setvbuf(stdout, (char *)NULL, _IOLBF, 0);

has no effect sometimes (depending on the environment that GNU Go runs in).
When running in the Msys-command-shell: "rxvt.exe" or when connected through
pipes (as in a Java environment - e. g. GoGui: http://gogui.sf.net)
effectively FULL BUFFERING is used unless one forces _IONBF (no buffering).
(Thus line buffering is not achievable at all in this situation in MingW/Msys)
So all output can only be seen after the buffer is flushed automatically
when the program finishes. But in this way no communication can be established.

NOTES: This error CAN'T be reproduced using cmd.exe or command.com ...
       both behave well ;-0

       I have no idea if this is also a problem with visual c++ for Win32
       and i cannot check this myself - sorry ...

       See the end of this message for links to some (unsatisfying)
       discussion of the problem in the MingW Users Newsgroup.

SOLUTION:
Instead of choosing unbuffered gtp output (as in the 3.4 version and before)
I opted for leaving play_gtp.c unchanged and live with the line buffered or
full buffered output depending on the situation:

The following patch adds one single fflush(STDOUT) into the gtp
main loop. This way the buffer is flushed at least after every response.

It may be questionable if this is too infrequent (how long can a gtp response
be?) ... or if - instead - full buffering and flushing manually could become
the standard handling of gtp output  ... for now it is shielded by #ifdef 
__MINGW32__

I know that the first fflush in the program run is unneeded and that the extra
flushing may be completely unneeded in a sane environment or with a sane MingW.
But I think having the buffering is better - what do you think? And it's elegant
in that it's only one line of code (when terminating, flushing is done by the 
OS)
and in that MingW binaries will benefit from line buffering at almost no cost
without the need for another immediate code change as soon as MingW behaves 
well.

Feel free to use this patch for GNU Go :-))
*********************************************************************

--- gtp.c.orig  Wed Oct 22 15:05:18 2003
+++ gtp.c.flushfix      Wed Nov  5 15:50:00 2003
@@ -80,6 +80,10 @@
   int status = GTP_OK;

   while (status == GTP_OK) {
+#ifdef __MINGW32__
+    /* flush buffer to overcome an error when compiling with mingw gcc */
+    fflush(stdout);
+#endif
     /* Read a line from gtp_input. */
     if (!fgets(line, GTP_BUFSIZE, gtp_input))
       break; /* EOF or some error */

*********************************************************************

Happy GO - ing
      aquarius

P.S.: Many thanx to Paul Pogonyshev for pointing me to the executable
      packer upx (http://upx.sf.net). My sizes for Win32 binaries are:
      GNU Go 3.5.2-pre-1 with debug symbols: 6.307.768 Bytes
      GNU Go 3.5.2-pre-1 stripped and upx'd:   583.168 Bytes

      I am thinking about making a web page and offering Win32 binaries of
      dev. versions in a regular manner plus (3.4 and current) doku in HTML.
      You can see a preliminary HTML version of the GNU Go Manual at:
      http://www.goban.net/gnugo/doc/
      (only 3.4 by now ... "current" will follow soon after rel. 3.5.2)
      Is that appreciated? If so, feel free to add a link on the GNU Go page.
      Any tipps on improving the generated HTML are very welcome.

P.P.S: He, He, rather long babble about my first line of code for Gnu Go ;-)
_____________________________

These are the links to the MingW Users Newsgroup discussions:

http://news.gmane.org/onethread.php?group=gmane.comp.gnu.mingw.user&root=%3C200310132032.h9DKWD006986%40cicada4.pcs.mot.com%3E

http://news.gmane.org/onethread.php?group=gmane.comp.gnu.mingw.user&root=%3COFD6894437.E8412F0B-ON80256D9D.003B884D-80256D9D.0044EF54%40LocalDomain%3E

The underlying reason seems to be that MinW/Msys's isatty() is
clueless sometimes about the nature of the communication partner.

Perhaps someone with a profound C knowledge should file this up again
at the MingW folks.