It is always difficult to go against the grain of the estblished logic of a program. The 'interface->Do Something' tasks are all just printing of simple messages; in XBoard protocol this would be a move, PV info ('thinking output'), a 'ping' response, a draw offer, a result claim or an error message. The move, draw offer and PVs are produced by the search, the result claim could also be the consequence of an input move.
The example driver is in pseudo-code, so there is little danger for plagiarising anything. It was more intended as an unambiguous definition of the meaning of the commands. The hardest part is always to make the program receptive to input during a search, as is necessary for implementing pondering and analysis.
Interfacing with a GUI
-
H.G.Muller
- Posts: 190
- Joined: Sun Jul 14, 2013 10:00 am
- Real Name: H.G. Muller
Re: Interfacing with a GUI
Hey,
Managed today to actually get meaningful responses from xboard!! Can actually play games, so I'm very pleased! Only a bare minimum of functionality though, but at least I have a grasp now on how it works -- ish.
One thing I had a problem with is when xboard sends the command 'xboard\n' and then immediately after sends "protover 2". So I had an if statement that says if (command=="xboard") do stuff, but it was picking up the "\nprotover 2" part, and not responding. So I have written a kind of FIFO buffer, so when it receives "xboard\nprotover 2" it gives me xboard, and then protover 2. That probably makes no sense, but it seems to work -- as I say, I am no programmer!
Another thing is that what I have managed to cobble together so far works ok in xboard, but the knights GUI -- which I personally prefer -- seems to randomly fail to accept moves from the engine. Not too bothered about that though.
Thanks for all the help
Adam
Managed today to actually get meaningful responses from xboard!! Can actually play games, so I'm very pleased! Only a bare minimum of functionality though, but at least I have a grasp now on how it works -- ish.
One thing I had a problem with is when xboard sends the command 'xboard\n' and then immediately after sends "protover 2". So I had an if statement that says if (command=="xboard") do stuff, but it was picking up the "\nprotover 2" part, and not responding. So I have written a kind of FIFO buffer, so when it receives "xboard\nprotover 2" it gives me xboard, and then protover 2. That probably makes no sense, but it seems to work -- as I say, I am no programmer!
Another thing is that what I have managed to cobble together so far works ok in xboard, but the knights GUI -- which I personally prefer -- seems to randomly fail to accept moves from the engine. Not too bothered about that though.
Thanks for all the help
Adam
-
H.G.Muller
- Posts: 190
- Joined: Sun Jul 14, 2013 10:00 am
- Real Name: H.G. Muller
Re: Interfacing with a GUI
Normally you would just read upto a linefeed when you want to read the next command. E.g. with fgets().
When you want to check for input during search, rather than just read it and wait until it arrives, (as you would need to do during pondering or analysis), however, I noticed that input buffering can cause an effect similar to what you describe. Even though my engine would only attempt to read a single line of text when it detected input, it seems that the input library routine then would read all input that was available at the time, and hide it in some buffer. So that the program would get a negative answer when it was checking if there was more input in the pipe, and thus would never see the later commands arriving together with the first. This was in particular a problem when XBoard sent time + otim + usermove during ponder, where to determine if you have a ponder hit you would need to examine the move. But the engine would only process the 'time' command, and when checking if there was more input would be told there was none. And thus continue pondering waiting for the move to arrive, which would of course never happen until XBoard would send new commands. (And that command would of course always be the one that told the engine it had now forfeited on time...)
Switching off input buffering with setbuf or setvbuf solved that problem.
When you want to check for input during search, rather than just read it and wait until it arrives, (as you would need to do during pondering or analysis), however, I noticed that input buffering can cause an effect similar to what you describe. Even though my engine would only attempt to read a single line of text when it detected input, it seems that the input library routine then would read all input that was available at the time, and hide it in some buffer. So that the program would get a negative answer when it was checking if there was more input in the pipe, and thus would never see the later commands arriving together with the first. This was in particular a problem when XBoard sent time + otim + usermove during ponder, where to determine if you have a ponder hit you would need to examine the move. But the engine would only process the 'time' command, and when checking if there was more input would be told there was none. And thus continue pondering waiting for the move to arrive, which would of course never happen until XBoard would send new commands. (And that command would of course always be the one that told the engine it had now forfeited on time...)
Switching off input buffering with setbuf or setvbuf solved that problem.
Re: Interfacing with a GUI
I got this working, and I'm pleased I did because setting it against Gnuchess, thus not having to find the time to babysit, has shown up a whole load of problems, probably for another thread if I can't solve them.
Cheers guys!
Cheers guys!