Re: [computer-go] GTP and Tourney in SmartGo 1.4

["Yonik Seeley" <yseeley@xxxxxxxxxxxxxxx>]

As far as I understand, GTP doesn't specify the communications channel.
Therefore, saying that "named pipes are hard in Windows" isn't a drawback to
GTP at all, but would only be a drawback to choosing that mechanism of
communication.  I can imagine getting GTP to work over pipes or sockets in a
couple of hours, but I wouldn't even attempt GMP.

Pipes (named or otherwise) are also a bad idea for the "standard"
communication channel since they only allow communication within the same
computer!  This obviously isn't acceptable for running a tournament.

Personally, I would choose TCP sockets... probably the most common and
widest used communications channel, supported by all common operating
systems and languages out-of-the-box.  This is what you would want to use if
you were hosting a tournament... every program could easily talk to every
other program in their native environment.

Obviously, the communications channel needs to be baked into some sort of
standard to get 100% interoperability.  How about GTP/TCP for the
specification of how to put GTP over TCP sockets?  It fully specifies the
whole stack without precluding future possibilities such as GTP/HTTP, etc.
The TCP part would probably add a page or less to the length of the spec.

Go communication technology should be brought up to the 90's  ;-)

-Yonik

ps: for Windows, if you want UNIX APIs, then use cygwin or Microsoft's SFU
(both freely available).  Now your code to create pipes or whatever looks
the same on UNIX and Windows!

----- Original Message ----- 
From: "Persson, Magnus" <persson@xxxxxxxxxxxxxxxxx>
To: "computer-go" <computer-go@xxxxxxxxxxxxxxxxx>
Sent: Sunday, March 14, 2004 4:30 PM
Subject: RE: [computer-go] GTP and Tourney in SmartGo 1.4


Just getting it to play using kgsGTP took me at most 4 hours, the tricky
part was add an interface in my engine, there was no appropriate procedures
to call that produced coordinates. But please not that this code is only
supposed to work with kgsGTP and is not a proper implementation.

But I want to return to the pipe-thing. Windows has no simple communication
available in the OS as far as I know. You *have* to be a good experienced
Windows programmer or spend 10 hours just to enable the communication.

With the knowledge I have now it is very easy, to do the console stdin/out
thing or 2 named pipes.

The reason why 2 named pipes work with kgsgtp is that you add the explicit
names of the pipes as a command line parameter to kgsgtp, but I do not think
most other implementations do that. If not then I would have to spawn child
processes and redirecting in/out pipes and mess around which is sure to be
messy as well.

One idea I have is that someone should write a simple console "Adapter" that
uses std in/out but then creates 2 named pipes and/or connect to two named
pipes and/or provide a socket internet connection.

It is important though, to add a tutorial in how to program the pipes in
windows, otherwise it is useless.


--
Magnus Persson
Center for Adaptive Behavior and Cognition


-----Original Message-----
From: Gunnar Farnebäck [mailto:gunnar@xxxxxxxxxxxxxxxxx]

Magnus Persson wrote:
> But my conclusion is that it is easy (if you know how to do it) to use
> GTP together with a program such as kgsGTP. But only with named pipes!

Except for the technicalities of getting pipes to work under Windows,
did you experience any other difficulties in implementing GTP in your
program? Is there any chance you can estimate how much time you needed
for the implementation, besides the pipe stuff?

/Gunnar
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go