On Wednesday 25 August 2004 17:31, Arend Bayer wrote:

a) Stdin/Stdout. It is not very widely known that Windows GUI programs can use console stdin and stdout, too. See

I don't like the word *console* stdin/stdout, because it just adds to the confusion that was inherent in the recent discussion on the computer-go list. Every process on Unix and Windows has the default streams stdin/stdout. If a process creates a child process, they can be used for inter-process communication. Of course the streams can be connected to a console/shell , but that's just a special case, they don't have to.

- Markus

...

Don Dailer, author of several go programs.

Should be Don Dailey. (Actually I don't know whether he has written more than one program, but maybe he can comment himself.)

Don Dailey is correct.

Yes, I have written several go programs. But only 1 of them is available to the public as "Ogo" which runs on Palm OS.

- Don

I am especially grateful for comments on the windows part, since I have never done any windows programming.

Peter Strempel wrote:

Arend Bayer wrote:

...

6. Windows.

There are several options for the communication stream under Windows.

a) Stdin/Stdout. It is not very widely known that Windows GUI programs can use console stdin and stdout, too. See

This Q&A set makes no sense to me. I am absolutely no capable Win32 API programmer, but with my mere knowledge I did know that you can grab stdin/out to a processes on Windows just like you can do on Unix. A Win32 guru who has never programmed on Unix would rather ask "How can I do it on Unix?" Your writing suggests Unix is the norm and Windows is something special. I'd suggest to keep that sort of stuff out of a GTP FAQ.

First there is a misunderstanding here: I was talking about the engine side implementation. My understanding is that a windows program cannot just use fprinft(stdout, ...).

Anyway, there needs to be section about setting up the communication stream under windows, since that seems to have cause the most misunderstandings about GTP (judging from the computer-go list). Many people seem to assume that only a program running in DOS mode has stdin/stdout.

Below is my next try.

Arend

1. Why should I implement GTP in my go program?

Because it is easy, and because it saves you doing many other tasks. Once you have implemented it, you have a big choice of GUIs with which you can use your program. You can have your program play on any of NNGS, IGS, KGS by using one of the existing client. You can use existing test suites. Or you can use the existing tools (as, for example, distributed with GNU Go) with your own test suite. You can easily play matches against other GTP engines.

You can also use GoGui and its GTP-to-GMP bridge to take part in tournaments that require the GMP protocol.

2. Why should I implement GTP in my graphical go client?

GTP is a convenient way to connect to go programs, and it is superior to the older GMP: For example, GMP lacks good support to resume games. There are many other ways to use GTP; for example, it is very easy to write an automatic scoring mode by connecting to a GTP engine.

3. I heard GTP is hard to implement. Is that right?

No.

"qGo only supports GTP, not GMP. GTP looks much better and was very easy to implement." Peter Strempel, author of qgo, gGo, glGo.

"Implementing it was trivial and simple." "...it was easy to get it right." Don Dailey, author of several go programs.

"Now that I've finally written the GTP client for KGS, I wish I'd done it sooner - it was much easier than I'd expected." William Shubert, programmer of KGS and kgsGtp.

4. In what setups can GTP be used?

While other setups are possible, here are the commonly used ones. You can find links to programs implementing the controller side of each setup from the GTP home page.

For a game computer vs human: GUI ------> GTP engine

To have a go program play on a server: GTP engine <------ Server client ------> Go Server

Matches between GTP engines: GTP engine <------ Controller script --------> GTP engine

To run a test suite: Controller script ------> GTP engine

5. How to set up the communication stream between controller and engine? (engine side implementation)

GTP does intentionally not specify this, as it depends on the setup you want to use. The only requirement is a bidirectional stream to communicate text messages.

a) Unix environment Here this is naturally done by the engine using stdin/stdout. All existing controllers can start the engine and grab its stdin/stdout to set up the stream.

b) Windows

There are several natural options for the communication stream under Windows.

- Stdin/Stdout of the engine. It is not very widely known that Windows GUI programs can use stdin and stdout, too. See http://dslweb.nwnexus.com/~ast/dload/guicon.htm.

- Named pipes. See e.g. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw98bk/htm...

- TCP/IP. You can have your program listen and reply on a TCP/IP port. You can use netgtp(1) as a wrapper in case the controller needs the GTP stream via stdin/stdout.

http://computer-go.org/pipermail/computer-go/2004-March/000463.html (example with code) http://computer-go.org/pipermail/computer-go/2004-March/000470.html http://computer-go.org/pipermail/computer-go/2004-August/000837.html

6. How can I play matches between different programs with GTP?

On a Unix platform with both engines accepting GTP via stdin/stdout, you can use one of the twogtp scripts coming with GNU Go. (In fact, you can use them on any platform provided you have Pike, Python or Perl installed, respectively.) GoGui comes with java scripts to do the same.

7. Can I play GTP matches between programs on different computers?

Yes. Assuming that the computers are connected with a network, you can do the following (assuming you have Java and GoGui):

- Have both engines listen on a TCP/IP port; if an engine accepts GTP via stdin/stdout, use gtpserver(1) to redirect the input/output to the port.

- Run GoGui on the controller machine, and use twogtp(1) and netgtp(1) to connect to the engines.

In this:http://computer-go.org/pipermail/computer-go/2004-March/000499.html post to the computer go mailing list, Gunnar Farneback describes a slightly different setup in a Unix environment using tcplisten and mkfifo.

Another way is to use "ssh -c ..." on the controller machine to connect to another computer and start the GTP engine there.

(1) These programs are all part of GoGui.

On Thu, 26 Aug 2004, Dave Denholm wrote:

[snip]

...

You can also use GoGui and its GTP-to-GMP bridge to take part in tournaments that require the GMP protocol.

could perhaps add something along the lines of

...and it is probably easier to implement GTP and use this (or a similar) bridge, rather than implement GMP directly in the engine.

(ie even if it's actually GMP you want, it's probably easier to implement it by implementing GTP)

Well there is a little bit of an issue with the GTP-to-GMP bridge, It requires a java module for accessing the serial port, which a) doesn't seem to be part of the standard Java installations, b) isn't even officially supported under Linux (can be installed using some wrappers around the solaris versions of the module).

Maybe Markus Enzenberger can correct me if I am wrong.

It's probably still easier than implementing GMP, but...

Arend