scripting xboard with positions

[Anonymous]

I would like to script xboard using Python, feeding xboard a series of positions, letting xboard accept a move from the user and sending the move back to the script for evaluation, feedback, etc. I've tried communicating with an xboard process with a pipe, as described in [1], but I never get anything back when I read from the pipe. Can anyone give me any tips on how to go about this? Is xboard (or winboard) not the most appropriate interface for implementing what I want?

Thanks, and happy new year!

Bob Kline

[Anonymous]

Oops! Forgot to plug in the URL for my footnote:

[1] http://www.tim-mann.org/xboard/engine-intf.html

Sorry!

[Alessandro Scotti]

Hi Bob,
xboard is a GUI that interfaces to chess engines, as described by the document you mention. xboard itself does not follow that protocol, although you can have it perform a lot of things using command line options.
So you should interface your Python script with a chess engine such as for example Crafty, Yace or Kiwi (all these run on Linux and fully support the xboard protocol), not with xboard directly.
Hope this helps!

[Anonymous]

One more note, to anticipate initial questions: I am turning off buffering as Tim instructs, so that's not the problem.

Bob

[Anonymous]

[quote="Alessandro Scotti"]
... So you should interface your Python script with a chess engine such as for example Crafty, Yace or Kiwi (all these run on Linux and fully support the xboard protocol), not with xboard directly. ...[/quote]

Thanks for your quick reply! I'm having a little difficulty understanding how this would work. If I launch crafty under xboard, crafty will be sending its output to xboard, not to my script, right? So how would I get back the move the user makes in the GUI?

Bob

[Alessandro Scotti]

If I launch crafty under xboard, crafty will be sending its output to xboard, not to my script, right? So how would I get back the move the user makes in the GUI?

Hi Bob,
yes correct, xboard will talk to Crafty so you have to launch Crafty by yourself and talk to it.
If you want to receive also the moves performed by the user while inside xboard, probably the best option is to pretend to be a chess engine and talk both with xboard and with a "real" chess engine. Basically, you just forward everything xboard sends to the chess engine and viceversa, but since you are in the middle you can do anything with the commands you see.

[Anonymous]

OK, I think this brings us back to my original question, which is how to get the commands being sent by xboard, which I''m not seeing in my own program. (I don't think I really need crafty or another real chess engine, because what I'm doing is much simpler than what crafty can do; my program knows just enough about how to evaluate the move the user makes for a given position, because it's working with a limited number of positions, which are pre-stored, and for which it already has the evaluation information for the possible moves.)

To provide a clearer picture of what I'm doing that's not working: my python program launches xboard with command-line arguments telling it to load a specific position from a file of FEN positions, then reads from the pipe to get the MOVE command when the user makes a move in the xboard GUI. The call to read a line never returns until xboard is shut down, and the input from the pipe is empty. Again, I'm making sure that the I/O is not buffered.

Cheers,
Bob

[eric_oldre]

If I launch crafty under xboard, crafty will be sending its output to xboard, not to my script, right? So how would I get back the move the user makes in the GUI?

Hi Bob,
yes correct, xboard will talk to Crafty so you have to launch Crafty by yourself and talk to it.
If you want to receive also the moves performed by the user while inside xboard, probably the best option is to pretend to be a chess engine and talk both with xboard and with a "real" chess engine. Basically, you just forward everything xboard sends to the chess engine and viceversa, but since you are in the middle you can do anything with the commands you see.

Alessandro,
I thought I'd also mention I'd be very interested in having "command line" functionality built into winboard. basically, I would like to have a program of mine be like a tournament manager.

There are two problems I need to solve. (which you could make MUCH easier).

1) the ability for my program to track the status of the game as it progresses. I suppose I could read the log file like TLCV does. but if winboard could be modified to output the moves to stdio this would be much simpler.

2) the ability to hide the UI of winboard. I could play with some tricks like sending a message to hide the window through the windows API, or maybe somehow reposition the window off the screen, but a command line option to "be invisible" would be much more convient.

If you find the time and desire to ever make those changes to winboard I would be very happy. Since my alternative is to write a new program which acts like winboard as a "referee" to the engines, I'm finding this pretty difficult to do since not all engines use the xboard protocol exactly the same.

Eric

[Sven Schüle]

To provide a clearer picture of what I'm doing that's not working: my python program launches xboard with command-line arguments telling it to load a specific position from a file of FEN positions, then reads from the pipe to get the MOVE command when the user makes a move in the xboard GUI. The call to read a line never returns until xboard is shut down, and the input from the pipe is empty. Again, I'm making sure that the I/O is not buffered.

Hi Bob,

AFAIK xboard/WinBoard opens two pipes (for sending and for receiving) to each of the (up to two) engines specified on the command line as first or second chess engine. It is also responsible for launching these engines.

Now if you have another program, say your python script, which launches xboard/WinBoard, you can't expect xboard to communicate via any pipe to this program. This would require that xboard/WinBoard communicates via stdio if no chess engine connection is configured, and that the other program itself opens the two pipes, but I think the stdio behaviour is currently not implemented.

Alessandro, can you confirm this?

Happy New Year,
Sven

[Anonymous]

AFAIK xboard/WinBoard opens two pipes (for sending and for receiving) to each of the (up to two) engines specified on the command line as first or second chess engine. It is also responsible for launching these engines.

I see. So I need to write two programs: a driver to invoke xboard, and a second program for xboard to launch, which wil communicate to me via my standard input, and to which I respond using my stdandard output (a little like the CGI model). I'm trying that, and it also fails (that is, the second program never receives any input from xboard). I'm specifying the second program using the -fcp command-line argument, and again I'm ensuring that standard input and output are unbuffered.

Thanks for your reply, Sven.

Bob

[Alessandro Scotti]

Now if you have another program, say your python script, which launches xboard/WinBoard, you can't expect xboard to communicate via any pipe to this program. This would require that xboard/WinBoard communicates via stdio if no chess engine connection is configured, and that the other program itself opens the two pipes, but I think the stdio behaviour is currently not implemented.

Alessandro, can you confirm this?

Hi Sven,
yes this is what I was trying to say, although you said it quite more clearly!
Also, I think graphics application in Windows do not have stdin/stdout at all.

[Alessandro Scotti]

There are two problems I need to solve. (which you could make MUCH easier).

1) the ability for my program to track the status of the game as it progresses....

2) the ability to hide the UI of winboard...

Hi Eric,
I'm very interested in making life easier for tournament managers, especially free ones!
Feature 1) would be very nice to have. Actually, I put it into Winboard at one time, and removed it later. The idea was that such stuff as move history, evaluation diagram, alternate boards and so on could be implemented with "plugins", i.e. external DLL's or processes that were automatically loaded by Winboard and notified of relevant events.
I got it up to the point where Winboard was starting and talking to another process (written in Delphi), forwarding events related to the move history.
This would have given me considerable freedom in implementing nice graphics and features, but there are also serious drawbacks. Besides requiring quite a bit of supporting code, it seems to me that it somewhat betrays Winboard's philosophy of being a simple and self contained application, so eventually I scrapped everything and proceeded to implement this stuff directly within Winboard itself (in C and using only the Win32 API... ugh!).
Ops sorry for the digression! Anyway, I can probably manage to add a "simplified" version of the above, as things get considerably easier if we just stick to the event notification part (without messing with windows management).
Feature 2) seems to be more feasible, but I've yet to look at the code.
No promises and timelines, but I'll try to see if I can help!