[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SV: [computer-go] How to play go with other programe?
In Delphi you can get access to std input/output by calling the Windows function GetStdHandle. I do not understand low level windows programming but it seems to me that some aspects of the console is always there. It just the console window that does not show up.
FConsoleInput := GetStdHandle(STD_INPUT_HANDLE);
FConsoleOutput := GetStdHandle(STD_OUTPUT_HANDLE);
These handles can then be used just as any file handle using Writefile and ReadFile.
Magnus Persson
-----Ursprungligt meddelande-----
Från: David Fotland [mailto:fotland@xxxxxxxxxxxxxxxxx]
Skickat: to 2004-08-12 06:03
Till: 'computer-go'
Kopia:
Ämne: 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/
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/