[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnugo-devel] GTP sometimes fails

From: Darren Cook
Subject: [gnugo-devel] GTP sometimes fails
Date: Fri, 18 Mar 2005 13:30:25 +0900
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

I'm connecting to gnugo 3.6 using GTP: using pipes from C++. When
running my unit tests, they sometimes work fine, but sometimes they
fail. If it fails it seems to be on the first command I send after
successfully connecting.

I was originally using lower-level file descriptors, but after having
lots of problems, I looked at gnugo's oracle.c code and switched to
using two FILE*. So my code is now basically the same as oracle.c
(except I use fwrite instead of fprintf). Does anyone have similar
problems with that code?

My send_command() is shown below.

I'm wondering if when fgets() returns NULL if it means Gnugo is still
processing? Should I just do a continue to have it try again? Perhaps
combined with sleeping for a millisecond or something. Or should fgets()
wait forever until the remote program sends a carriage-return?


P.S. This is on linux, with gnugo running on the same single-CPU machine.

const char *send_command(const char *command)const{
size_t sz=strlen(command);
size_t bytes=fwrite(command,1,sz,fp_out);
        std::cerr<<"write to pipe failed: sent "<<sz<<" bytes, but only
"<<bytes<<" bytes written apparently\n"<<std::flush;;
        return NULL;

const int MAX_BUFFER=2048;

static char readbuf[MAX_BUFFER];

size_t ix=0;    //Where in readbuf we're up to
    char buf[256];  //Max line length assumed to be 256
    char *p=fgets(buf,255,fp_in);
        std::cerr<<"Failed to read from gtp stream\n"<<std::flush;;
        return NULL;
    size_t len=strlen(p);
        if(ix==0)continue;  //gnugo always returns at least "=", so I think
            //this means it has not replied yet.
        break;  //Blank line indicates end of reply

        std::cerr<<"Sending "<<command<<" returned this
        return NULL;

return readbuf;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]