[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [computer-go] How to play go with other programe?



I write windows programs, not console programs.  In a win32 program, there
is no
stdin and stdout, since there is no command line console window.  Can
someone
tell me how to make this kind of program talk to stdin/stdout?  It happens
that I understand
winsock, since my program can talk to nngs/igs, so I don't actually need the
answer :)  But
I don't like the requirement to talk stdin/stdout.

A big hurdle for a tournament organizer is writing a referee program.  Why
don't people consider
using nngs/igs protocol, which also works over tcp, and the nngs referee
program already exists.

David

> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx 
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of 
> Paul Pogonyshev
> Sent: Wednesday, August 11, 2004 1:02 PM
> To: computer-go
> Subject: Re: [computer-go] How to play go with other programe?
> 
> 
> yonik wrote:
> > > Personally I prefer this standard: program talks GTP on 
> > > stdin/stdout,
> > period.
> > > Engine shouldn't bother with things like TCP, PPP or 
> whatever else.  
> > > It is way easier to use an external proxy ("glue") to 
> plug an stdio 
> > > program on
> > the
> > > connection you need/want/have to use.
> > 
> > You are confusing interface with implementation.  What should be 
> > standardized, and what engine authors have to worry about are two 
> > entirely different things.  GTP/TCP should be standardized.  That 
> > doesn't *require* an engine author to implement it.  They 
> could talk 
> > GTP over stdin/stdout and use an adapter, like you say, or use 
> > whatever other library they want to implement the full stack.  
> > Implementation details are up to the engine developer, but the full 
> > *interface* should be required so interoperability can be achieved.
> > 
> > Again, back to HTML and HTTP:  HTML content authors don't 
> necessarily 
> > need to worry about the delivery mechanism (HTTP) since that is 
> > handled by a separate component (web server usually), but HTTP 
> > certainly has to be standardized for interoperability!
> 
> Well, maybe I misunderstood you.  But I still cannot see the 
> need for standartization of GTP/TCP.  HTML and HTTP are of 
> different class of use.  The Web is an international 
> integrated system.  I cannot imagine GTP being used on such a scale.
> 
> > Trying to run a tournament where the only requirements were for 
> > programs to speak stdin/stdout would be a nightmare.  Either
> > a) the tournament provider would have to have hardware & operating 
> > systems in every conceivable combination to run
> 
> Why?  In any case you _have_ to worry about different 
> systems, unless you take a fascistic position and insist on 
> using only one of them for your tournament.
> 
> Regarding hardware, I don't see the problem.  It is natural 
> to require that any computer brought in the tournament has 
> certain means of connecting to the local network (e.g. a LAN 
> adapter---I don't know the details). In modern computers the 
> exact hardware doesn't matter because implementation details 
> are hidden in drivers.
> 
> And the tournament provider doesn't need to think of it.  He 
> goes to google and grabs a set of already written 
> scripts/programs (maybe even GoGui, judging by Arend's 
> messages it's capable of many things).
> 
> > b) it would be up to the engine authors to make sure their programs 
> > ran on a platform provided by the tournament providers
> 
> This is not an acceptable option of course.
> 
> > c) tournament providers would have to provide adapters that ran on 
> > every conceivable platform.
> 
> Take any portable language, say Java.  Write a set of simple 
> scripts. It is done.
> 
> > The greatest common denominator of computer systems today is TCP.  
> > That should be leveraged.
> 
> What I don't see is the point of this standardization.  You 
> say "TCP is great", go and write a set of "glue" scripts that 
> provide a way to organize a tournament over TCP connection 
> without stressing engine's authors.  A tournament organizer, 
> mr. A, bumps into your scripts, thinks "wow, that's what I 
> was looking for" and starts a tournament, everybody is happy.
> 
> Now let's say mr. X decides that null-modem cable is the best 
> way of communication in the world.  He writes a set of 
> scripts that allow to host a tournament on a set of computers 
> connected by such cables. Another tournament provider, mr. B 
> decides that those scripts are a masterpiece and hosts 
> another GTP tournament.
> 
> Now, we have two GTP tournaments, hosted with different 
> communication channels used to transfer GTP sessions.
> 
> * Do engine authors care?  No, because tournament providers 
> both accept programs speaking on stdin/stdout.
> 
> * Do mr. A or mr. B care?  No, because they both host working 
> tournaments. They don't need to intercommunicate with each 
> other, because they have two different tournaments there.  
> They can easily switch from mr. X's scripts to yours or vice versa.
> 
> Paul
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx 
> http://www.computer-go.org/mailman/listinfo/computer-go/
> 

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