Question about winboard commands to the engine

[Fguy64]

but it sounds like I will need also to use isdigit and isalpha, etcetera, if I want to communicate with some engines that do not implement usermove?

no.
don't forget...an engine does not normally communicate directly with other engines...only with the GUI, so if the FEATURE command
feature usermove=1
is sent to the GUI
the GUI will respond:
accepted usermove

afterward the GUI will indicate moves in the following format:
usermove e2e4

yes this make parsing the input a bit easier...
you simply have to wait until the command line contains usermove,
then parse the next 5 characters for the (actual) move

duly noted. I wasn't thinking straight. We are talking GUI to engine, and I'm mostly interested in using my GUI with other engines as well as my own, so usermove or not is really not a problem.

onwards and upwards.

[Fguy64]

hmmm one thing leads to another.

From reading the posts here, after the GUI first says "go" to the engine, then moves are passed back and forth. It has been pointed out that the GUI sends a move and expects one back, or else some kind of a result.

Q: When things are in "go" mode, does that limit the number of different commands that might be sent by the GUI. Maybe just moves, and a command to leave "go" mode? That would make things easier for the programmer.

If the answer is yes, then just sending repeated "go" commands would not be the way to have a computer play itself. It sounds like one would have to alternate "go" and "force" with no moves being sent by the GUI, for the engine to play itself?

"go" is a command, not a mode....
for ex:
use any wb engine...
type go
then type go
then type go
then type go
etc...

the engine will play an entire game against itself...
it simply thinks and makes a move when it sees the "go" command...

ok understood. I had used "go" mode somewhat loosely as the alternative to "force" mode, in the sense that one only needed to issue the go command once to play automatically against the human. and I had mistakenly thought that "go" only worked when the engine was in "force" mode

[hgm]

Q: When things are in "go" mode, does that limit the number of different commands that might be sent by the GUI. Maybe just moves, and a command to leave "go" mode? That would make things easier for the programmer.

There are no such restrictions on commands. Note that some commands will change the mode, though. A "setboard" will always leave the engine in force mode, even when it was received whie the engine was in black or white mode.

Some commands only have a well-defined effect when they are sent after a "new" command before any moves are done, though. In particlar this holds for a "level" which defines a number of moves to play in a certain time. If an engine receives that during a game, it is not clear if it should counting the oves from the current position, or from the original beginning of the game (which would create the possibility that it has already done more moves than the specified number).

[Fguy64]

Thanks HG. OK I think I have a pretty good grasp of the protocol now, but...

I am having a little difficulty undertsanding the use of standard I/O as a winboard communication channel. I am using Java because I want to learn java, it is not clear to me if the same issues apply to c++.

Anyways, below is a quote from the SUN documentation http://java.sun.com/docs/books/tutorial ... io/cl.html


Standard Streams are a feature of many operating systems. By default, they read input from the keyboard and write output to the display. They also support I/O on files and between programs, but that feature is controlled by the command line interpreter, not the program.

The Java platform supports three Standard Streams: Standard Input, accessed through System.in; Standard Output, accessed through System.out; and Standard Error, accessed through System.err. These objects are defined automatically and do not need to be opened. Standard Output and Standard Error are both for output; having error output separately allows the user to divert regular output to a file and still be able to read error messages. For more information, refer to the documentation for your command line interpreter.

And now two quotes from Tim Mann's protocol document..

An xboard chess engine runs as a separate process from xboard itself, connected to xboard through a pair of anonymous pipes. The engine does not have to do anything special to set up these pipes. xboard sets up the pipes itself and starts the engine with one pipe as its standard input and the other as its standard output. The engine then reads commands from its standard input and writes responses to its standard output. This is, unfortunately, a little more complicated to do right than it sounds; see section 6 below.

A WinBoard chess engine is a Win32 console program that simply reads from its standard input and writes to its standard output.

Here is my problem...

If we define the standard output of the engine (or any program) as the channel by which the program sends information to the screen, And standard input as the channel by which winboard would accept any information from the keyboard (?) then

1. what is the mechanism by which the standard output of the engine is linked to the standard input of winboard.
2. Are we not diverting "system" streams, which would make the keyboard and screen unavailable for their normal purpose?

naturally since this is a two way communication, the same would apply for commands from winboard to engine.

[Sven]

Here is my problem...

If we define the standard output of the engine (or any program) as the channel by which the program sends information to the screen, And standard input as the channel by which winboard would accept any information from the keyboard (?) then

1. what is the mechanism by which the standard output of the engine is linked to the standard input of winboard.
2. Are we not diverting "system" streams, which would make the keyboard and screen unavailable for their normal purpose?

naturally since this is a two way communication, the same would apply for commands from winboard to engine.

1. A pipe.
2. No

If you google "standard input output" you may find useful explanations of how output redirection and pipes are working. Both are concepts from UNIX but also available on other operating systems.

By "diverting" (I think this means the same as redirecting) the standard input/output streams of a certain program you do not affect any other program, nor do you affect the keyboard or the screen themselves as a whole.

What happens is that WinBoard/XBoard, as the parent process, starts an engine as its child process and creates two pipes such that one serves for sending command lines to the engine and the other one serves for receiving answers from the engine. This is a local communication mechanism between two processes. (In fact three since in case of an engine-engine game there are two engines running as child processes, and two pairs of pipes are created.)

Sven

[Fguy64]

Here is my problem...

If we define the standard output of the engine (or any program) as the channel by which the program sends information to the screen, And standard input as the channel by which winboard would accept any information from the keyboard (?) then

1. what is the mechanism by which the standard output of the engine is linked to the standard input of winboard.
2. Are we not diverting "system" streams, which would make the keyboard and screen unavailable for their normal purpose?

naturally since this is a two way communication, the same would apply for commands from winboard to engine.

1. A pipe.
2. No

If you google "standard input output" you may find useful explanations of how output redirection and pipes are working. Both are concepts from UNIX but also available on other operating systems.

By "diverting" (I think this means the same as redirecting) the standard input/output streams of a certain program you do not affect any other program, nor do you affect the keyboard or the screen themselves as a whole.

What happens is that WinBoard/XBoard, as the parent process, starts an engine as its child process and creates two pipes such that one serves for sending command lines to the engine and the other one serves for receiving answers from the engine. This is a local communication mechanism between two processes. (In fact three since in case of an engine-engine game there are two engines running as child processes, and two pairs of pipes are created.)

Sven

OK thanks, that helps a lot, one final question, I'll be looking into this myself also, is it a necessity that Winboard, or any other GUI that implements the protocol (such as mine) start the engine as a "child process", or is that just a convenience?

[hgm]

Yes, it is. Because it is very dificult (if not impossible) to set up a pipe between two unrelated processes. The way the pipes are set up is that one process creates them (and is then in posession of both ends of each pipe), and then forks of a child process, which inherits the access to the pipes. Each proces (parent and child) then closes its copy the end of the pipe it does not need, and the child then connects its end to the standard input or output.

[Zach Wegner]

Yes, it is. Because it is very dificult (if not impossible) to set up a pipe between two unrelated processes.

mkfifo.

Granted, that won't work on standard IO unless the child process specifically opens it up and dup2()s it.

[Fguy64]

Yes, it is. Because it is very dificult (if not impossible) to set up a pipe between two unrelated processes. The way the pipes are set up is that one process creates them (and is then in posession of both ends of each pipe), and then forks of a child process, which inherits the access to the pipes. Each proces (parent and child) then closes its copy the end of the pipe it does not need, and the child then connects its end to the standard input or output.

heh heh thanks much, it's no wonder I was having such a hard time understanding the concept.

It looks like I'm go to forge ahead. onwards and upwards.