Debugging a Program Designed For WinBoard

[beneficii]

How does one go about debugging a program designed for WinBoard, where you are trying to test the clock, the interface with the GUI, and the interaction of the interface and the engine itself? I'm not sure how to go about this. I tried putting the input in the pipe myself, but that didn't work.

[Dann Corbit]

How does one go about debugging a program designed for WinBoard, where you are trying to test the clock, the interface with the GUI, and the interaction of the interface and the engine itself? I'm not sure how to go about this. I tried putting the input in the pipe myself, but that didn't work.

Why didn't it work when you put the input into the pipe yourself?
There is no reason why you should not be able to create unit tests in this way.
Out of curiosity, have you definitely turned buffering off for both standards input and standard output?

[beneficii]

How does one go about debugging a program designed for WinBoard, where you are trying to test the clock, the interface with the GUI, and the interaction of the interface and the engine itself? I'm not sure how to go about this. I tried putting the input in the pipe myself, but that didn't work.

Why didn't it work when you put the input into the pipe yourself?
There is no reason why you should not be able to create unit tests in this way.
Out of curiosity, have you definitely turned buffering off for both standards input and standard output?

For output I use setvbuf to set no buffer, and for input I always use PeekNamedPipe to see if there is input, and then use ReadFile to obtain it. When I open the EXE directly it never lets me type anything in. When I open it in WinBoard, it takes a few seconds to start the engine, but the engine never moves. The engine crashes when I close WinBoard.

EDIT: BTW, when I open up the Fruit EXE directly, it does let me type input in, but it never sends anything back to me. Why is this? I start off typing, "xboard\n" and then "protover 2\n" to it, but it never does anything.

[H.G.Muller]

I think PeekNamedPipe() does not work if the input is a terminal, rather than a pipe. In my engines I check for input using PeekNamedPipe() only when the engine is pondering (or analysing, which is a form of pondering), and in other cases just use blocking input. That makes it easy to test the engine from the command line with ponder off. With ponder on, it just comes out of ponder imemdiately, because it thinks there is input when there actually is not, and then blocks in the attempt to read it.

Windows is a pain...

[beneficii]

So you would use a function that would just stop execution until it receives input, right, when you're not analyzing/pondering? Would that just be an fread from stdin?

[H.G.Muller]

I use getchar() for all input, but I guess that amounts to the same thing. And during the search I would periodically peek the pipe (when analyzing / pondering) or read the clock (while thinking) to see if I have to abort the search.

[beneficii]

I use getchar() for all input, but I guess that amounts to the same thing. And during the search I would periodically peek the pipe (when analyzing / pondering) or read the clock (while thinking) to see if I have to abort the search.

So you would basically just sit there with something like:

int get;
while((get = getchar()) != EOF)
str += get;

[beneficii]

Opening my chess engine's EXE directly, I get the same thing I get when I open the Fruit EXE directly, I can type stuff in, but I never seen any response on the console window, even after typing "xboard" and "protover 2"

[beneficii]

OK, I got the program to respond with the features (though I can't ever seem to get Fruit to do that, which is strange). Nevertheless, when I play around in the Console window it never does anything more, but now WinBoard can't initialize it, because it crashes. So in the Console window it doesn't crash, but in WinBoard it does not.

What is a full list of commands that are sent to the engine when WinBoard initializes, so that I can test them?

EDIT: I'm able to get FairyMax to respond.

[H.G.Muller]

Fruit is not a WinBoard engine. It only responds when it receives the command "uci".

To see what exactly WinBoard sends, best run it with Fairy-Max and the extra option /debug. You can then see in the winboard.debug file everything that WB sends to the engine. (And what the engine sends back.)

[Dann Corbit]

OK, I got the program to respond with the features (though I can't ever seem to get Fruit to do that, which is strange). Nevertheless, when I play around in the Console window it never does anything more, but now WinBoard can't initialize it, because it crashes. So in the Console window it doesn't crash, but in WinBoard it does not.

What is a full list of commands that are sent to the engine when WinBoard initializes, so that I can test them?

EDIT: I'm able to get FairyMax to respond.

Can you post your I/O routines?

[beneficii]

OK, I got the program to respond with the features (though I can't ever seem to get Fruit to do that, which is strange). Nevertheless, when I play around in the Console window it never does anything more, but now WinBoard can't initialize it, because it crashes. So in the Console window it doesn't crash, but in WinBoard it does not.

What is a full list of commands that are sent to the engine when WinBoard initializes, so that I can test them?

EDIT: I'm able to get FairyMax to respond.

Can you post your I/O routines?

// checks for input

bool xboard::input_available() {
return PeekNamedPipe(ipipe, NULL, 0, NULL, NULL, NULL);
}

// used during the search to check for input

std::string xboard::get_input() {
char buffer[max_bytes+1];
DWORD num_read;
std::string ret;

while(input_available()) {
ReadFile(ipipe, buffer, max_bytes, &num_read, NULL);
ret.append(buffer, buffer+num_read);
}

return ret;
}

// used to wait for input outside of a search

std::string xboard::wait_input() {
int get;
std::string ret;

while((get = getchar()) != EOF) {
ret += static_cast<char>(get);
if(get == '\n' || get == '\r')
break;
}

return ret;
}

// used to write output

void xboard::write_output(std::string out, ...) {
va_list ap;

va_start(ap, out);
vfprintf(stdout, out.c_str(), ap);
fflush(stdout);
va_end(ap);
}

One problem I notice that I'm having is that the engine never makes a move when opened with WinBoard, but when I use the exact same set of commands I see in the winboard.debug when I open the EXE directly, the engine does work and makes a move.

[beneficii]

To clarify, looking at the WB debug output, WB never receives the move command from the engine, as the move command doesn't appear anywhere. When I open up the engine EXE directly, however, the move command does appear on the console. I use the same set of commands I saw sent by WB in that debug and the result is different.

[Dann Corbit]

How do you open ipipe?

[beneficii]

How do you open ipipe?

I'm sorry. They're initialized like so in the initialization list (and left that way for the duration of the program):

ipipe(GetStdHandle(STD_INPUT_HANDLE)), opipe(GetStdHandle(STD_OUTPUT_HANDLE)),

I ended up not using opipe, but it has been in there too.

[beneficii]

OK, I've done some modifications: When I've opened the engine in WinBoard, it still doesn't do anything. Checking the debug file, WB does not receive either the engine output or the move sent by the engine. I have a "# searching\n" comment that gets sent whenever the search begins, and that DOES appear in the debug file, but nothing else from the engine between the "go" command and the "result" command when I quit xboard. But, when I open the EXE directly, and go through the exact same set of commands as WB's Machine White, it DOES display the engine output and does display a move, after a good amount of time (that matches the time control settings well).

I'm formatting the engine output correctly and the move output correctly, but even if they were incorrect they'd still be displayed in the debug file, right? I tried turning off ping, but still no can do, so it's not ping. I use the write_output() function for all output to the engine, so what is still the matter?

[H.G.Muller]

It sounds like your output is buffered, after all. Anything you print that starts with a recogided keyword or '#' should appear in the debug file under any circumstances. should appear in the debug file. For non-compliant output, it could depend on the setting of /engineDebugOutput, but the default for that (=1) is also that everything the engine says would always be printed in the debug file. I see you do fflush(stdout); , but it doesn't seem to be working... Are you sure this rutine write_out is indeed used for ptinting thinking output and move?

[beneficii]

(duplicate post)

[beneficii]

It should not be buffered. When the interface initializes, it calls setvbuf() to set the stdout buffer to 0, which actually should make fflush() unncessary.

Regarding the engine, I send the engine output (showing number of nodes searched, principle variation, etc.) like the WinBoard protocol says. The protocol doesn't say anything about putting a command in front of the output. Is there a command that should go before the engine output?

EDIT: Either way, it should not matter whether there is a command. I tested it by turning off the engine output, but nothing changed with WB.

My engine sends the move using the "move xxxx" command.

[H.G.Muller]

If it starts with 4 integers, WB considers it thinking output. And if /engineDebugOutput=1, anything the engine sends, no matter how incompliant, should be copied to the debug file. So if it is not there, it means WB did not receive it, which must mean the engine did not actually send it.

Either the engine somehow hangs in the input loop, or the output is not flushed...

In my engines the test for input is like this, however:

Code: Select all

int unbuffered_input(int init)
{
    static int pipe;
    static HANDLE inp;
    DWORD cnt;

    if(init)
    {   inp = GetStdHandle(STD_INPUT_HANDLE);
    } else
    {   if(!PeekNamedPipe(inp, NULL, 0, NULL, &cnt, NULL)) return 1;
        return cnt;
    }
}