On Sat, 2007-03-03 at 10:39 -0700, Markus Enzenberger wrote:
> These are different things and therefore you cannot really compare GTP
> to UCI
> or call UCI more advanced.
Yes I can. I have had a lot of experience coding up engines for both
protocols and I have no reservations about this, UCI is more
advanced.
And you CAN compare GTP directly to UCI because both are designed for
the
same purpose and both are simple text based protocols and the
similarities
are much greater than the differences.
> I cringe, when I think about how to write tools
> that need to access functionality of Go engines, but have to deal
> with
> unexpected messages or state changes at any time.
This is one of those things things that turns out to be much easier
than you imagined.
>From the engine side, it's only slightly more difficult to implement
than GTP. You have a loop that listens for commands and executes them
when they come. This is no different than GTP. Here is what IS
different:
1. Your input routine must be non-blocking unless it runs in a
separate thread (but this is not necessary and probably
ill-advised.)
2. Your engine should be prepared to respond fairly quickly to
any command.
Both of these are easily accomplished. The I/O loop can be handled as
a simple function that that can be called repeatedly from anywhere in
the program, like a simplified co-routine.
This is nothing like the complexity of programming with threads with
deadlock possiblities and difficult debugging sessions. It's very
easy to get this working right. With UCI (as well as GTP) I spent
more time looking at the specification and making sure I understood
it than I did implementing it.
When I say it's more advanced, a good example is thinking on the
opponents time. You can get this pretty much for free if you
implement the protocol in your engine since the GUI can handle
this for you. You simply honor the commands sent and you will have
thinking on the opponents time. That's worth it's weight in gold
if you want pondering for your program.
I'm not suggesting we move to UCI, but a GTP asycronous mode would
accomplish everything needed with the addition of a couple of more
GTP commands. Then it would be pretty much the same as UCI except
in the mundane details.
You simply cannot have a sophisticated GO program GUI using GTP.
At least not as it currently exists. Unless of course you
implement your own non-standard hacks, but then it's not GTP.
My suggestion is to offer asycronous versions of a few commands
as extensions to the protocol, while taking great care NOT to
deprecate any of the current commands. I do not recommend a
major unheaval of the standard - it will hurt computer go.
I cannot help but remember the initial resistance to the far
superior GTP over GMP protocol. But in this case, it doesn't
have to be a distruptive improvement, just an improvement.
- Don
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
