Re: computer-go: gnugoclient 2.0

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

You asked a lot of good questions.

Whether a program has "undo"  or not isn't really  a big deal.  But in
my  opinion  the  real  issue  is  getting   this very  basic  feature
documented right away.

Imagine  what might happen  if we don't  make this a standard command.
Also, imagine  that GTP really takes off.   How will  people implement
undo?  One person will implement "retract", another "takeback" and who
knows what different variations we will see?

So to me  the issue is getting the  basic features of a good  protocol
nailed  down, not so  much as  to  insist that it gets  implemented by
gnugo (although gnugo really should have this.)

Another issue is that  it would be  very desirable to know in  advance
what the  working set is, so that  you can write  cool software and be
able to depend on certain things working.

So we could just concentrate on defining  what the commands should be,
and not worry about  whether they are all  implemented.  That's not my
preference,   because I want   to   write tools  that have  guaranteed
functionality.   It is easier  to say,  "If you  have  implemented the
'standard' command set of GTP, this interface will work."

I  see  undo as completely  trivial to  implement,  but  that may have
something to do with how  I wrote my  program.   Still, I have a  hard
time believing that any programmer would a difficult time implementing
it.


Don



   From: Dave Denholm <dave.denholm@xxxxxxxxxxxxxxxxx>
   Date: 03 Aug 2001 12:29:08 +0100
   Lines: 59
   X-Mailer: Gnus v5.7/Emacs 20.4
   Content-Type: text
   Content-Length: 2116

   Daniel Bump <bump@xxxxxxxxxxxxxxxxx> writes:

   > > Is  there  agreement that  if  your  Go  engine  does not implement  a
   > > command, it should return something like "not_implemented" ?
   > > 
   > > The idea of a minimal set is  guaranteed compatibility.  I can't write
   > > a good interface  without 'undo', but I  at least could write one that
   > > reports back  to  me that "undo"  is not  supported by the  underlying
   > > engine.
   > > 
   > > How difficult is it to get undo into play_gtp?
   > 
   > I think undo should be part of the irreducible set of commands.


   I'm not so sure : it was a long time before gnugo was able to 
   do undo. Seems to me that if someone is starting a new engine,
   they don't really want to worry about these kinds of details
   until much later. If they want to use GTP, supporting undo
   shouldn't be imposed on them.


   I've been wondering for a while : is it intended that
   there be a distinction between commands "not_implemented"
   and generic unknown commands ?

   Eg is it necessary for undo to be one of the irreducible
   commands, yet be permitted to return "not_implemented".
   Why not just return "unknown_command" for *any*
   unimplemented command.

   It is fair enough to reserve the syntax of 'undo',
   so that anyone who does implement it agrees on the
   parameters. But I'm not sure all engines should
   recognise it just so they can report a different
   message.
    But perhaps I've misunderstood the intention
   behind a "not_implemented" reply.


   > 
   > I discussed how undo should be implemented in GNU Go's gtp
   > with Gunnar today and he suggested a scheme that was simpler
   > than the one I was thinking of. I think it should be easy
   > to do. He wants to keep a stack of all moves that are
   > played, just as I did. While I wanted to also keep track
   > of captures, his idea was that if undo is called you just
   > go back to the beginning of the stack and play each move.
   > That should be fast enough.


   And even if an engine doesn't keep track of the moves,
   the driving program could use gtp commands to reset the
   state and replay the moves..?


   dd
   -- 
   dave.denholm@xxxxxxxxxxxxxxxxx          http://www.insignia.com