Re: [computer-go] Wishlist for playing programs on KGS

[drd@xxxxxxx]

William,

I've read your proposal, and all the responses so far
and I like your suggestion.    

I would be perfectly happy if you implemented it as is.

You are not actually providing a game end function however.
This is fine with me, because I like that you are providing
a nice way to communicate with an engine WHILE it's running
and even for the engine to respond with a text message.

The game end procedure can be implemented without any of
the changes you propose,  just by the engine author providing
a private way to communicate to his engine to stop the game 
after clear board.    So Pete's point is well taken.  But
I like that you are providing a general mechanism to handle
this,  so I don't have to create my own mechanism. 

- Don



On Wednesday 12 October 2005 7:54 pm, William M. Shubert wrote:
> On Thu, 2005-10-13 at 10:55 +1300, Peter McKenzie wrote:
> > My feeling is that we are getting carried away with all this
> > flexibility.
> >
> > Top priority should be a simple way of exiting after the current game.
> > I believe that the idea of sending a command, via chat text, is a
> > solution that will satisfy this requirement for most people.
> >
> > This functionality should reside in kgsGTP for two reasons:
> >
> > 1) It is the natural place for it.  Most (all?) other logic regarding
> > dis/connecting to the server and selecting games to play currently
> > resides in kgsGTP.
> >
> > 2) If the option of forwarding the command to the engine is used, then
> > the engine author would have to implement the logic to:
> >  a) parse the command
> >  b) somehow authenticate the command (i.e. check the user)
> >  c) update some internal "last game" state to indicate that it should
> > exit after the current game
> >  d) exit when a clear_board command is received and the engine is in a
> > "last game" state (see (c))
> >
> > This logic would end up being implemented in the vast majority of
> > engines.  To my way of thinking it is less than ideal that all engine
> > authors have to do this, when it could have been simply solved once in
> > kgsGTP.
> >
> > If a command is added which allows direct communicaiton with the
> > engine then that is great too.  But I think it is of secondary
> > importance.
> >
> > cheers,
> > Peter
>
> I think you maybe only want a way to stop the engine after a game. But I
> have gotten many requests from other users for a way to query the engine
> of information while it is running. The way I see it, this solves two
> problems at once. Yes, it would be some more work for the engine authors
> who only want to be able to shut their engine down at the end of a game,
> but I have trouble believing much more (how much? one line to detect a
> shutdown request; one to set a flag; one to check the flag after a game
> ends - three lines of code maybe?) So in the end, it just seems to make
> sense to push all such decisions down into the engine, where people can
> do whatever they like.
>
> _______________________________________________
> 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/