Re: [computer-go] GTP and Tourney in SmartGo 1.4

[David Fotland <fotland@xxxxxxxxxxxxxxx>]

I haven't heard of anyone talking about patching up GMP.  GMP was designed to
let programs communicate over 1200 baud unreliable modems, before the internet
was in general use.  So it had to be binary, and it had to support retries, 
with sequence
numbers, etc.  It is silly to talk about extending it.  It's used in 
tournaments just due
to inertia, since so many programs implement some (usually compatible) 
subset of it.

I don't think it will be quite so easy to integrate it into a windows 
program with a GUI.

I don't need GTP for testing, since I already have a test system that works 
well.  There
is no point in rewriting it.  I'd rather work on the go engine.

I don't need GTP for tournaments, since it hasn't been required by one.  If 
a GTP tournament
requires me to provide a linux executable, I probably won't enter.

So why should I implement it?  I think it would take more than an hour just 
to find and read the spec :)

Regards,

David

At 10:26 AM 3/12/2004 -0500, Don Dailey wrote:

> >  I am starting to feel like an old man who has been used to GTP for all
> >  his life, got accustoned to its benefits and is just unable to
> >  understand any of the reasons why the younger generation dislikes it...
>
> But it's the  older generation that doesn't like  it, because it's not
> the way  they have  always done it.   It's the standard  resistance to
> change even if beneficial.    There is also the possibility that they
> might have to take an hour to actually implement it.  That's how long
> it took me.
>
> Here is my experience with GTP:
>
> 1. I implemented  it based on the  documentation for it in  my weak Go
>    program.
>
> 2. I  didn't  have (or  use)  a  reference  implementation to  compare
>    against.
>
> 3. I then  designed a GTP autotester.   I did nothing to  try to prove
>    that I had  implemented GTP correctly.  I only  knew that it worked
>    together with my own tools.
>
> 4. William Shubert  provided a java  script that will interface  a GTP
>    speaking program to his server.
>
> 5. I downloaded  it, plugged  my program in,  and it WORKED  the first
>    time.
>
> This implies that it was easy to get it right, especially since I'm just
> an average programmer.   But William Shubert must have got it right too,
> at least they work together easily.
>
> So I don't  really understand ANY of these comments  that imply GTP is
> screwed up.  (It's not perfect, but  what are you offering in place of
> it, GMP?)
>
> So I  would view  any criticism  as flattery in  this case.   The ones
> criticizing GTP are not even trying to compare it against GMP in their
> posts.
>
> Is  GTP ready  for automated  tournaments?  There  are  certainly some
> rough edges, but what is the counter proposal, GMP????  Let's patch up
> GMP, "the well established standard" to do this since GTP stinks.  Any
> volunteers?  I didn't think so ...
>
> - Don
>
>
>
>    On Fri, 12 Mar 2004, A van Kessel wrote:
>
>    > > translated into \r\n pairs... I don't know if this will be 
> happening in
>    > > this case, but I'd rather not have to worry about it at all.
>    >
>    > This is a historic pain. We 'll have to deal with it.
>    > I think the simplest way to handle \r is to just ignore
>    > them.
>
>    That is exactly what GTP does.
>
>    > > Another thing I don't like about GTP is the fact that the 
> controller does
>    > > not have to wait for an answer before sending its next message. I 
> see no
>    > > merit in this. It simply makes debugging harder.
>    >
>    > I fully agree. But: there is no other way.
>    > Since the program's response is influenced
>    > by it's internal (board)state, it is -in general-
>    > not possible to think of the next GTP-command before
>    > having read the first one's response.
>    > a related topic is the implicit ordering of commands.
>    > [ it would be a nice feature to inspect a program's internals,
>    > while it is executing/processing a command. GTP won't let you]
>
>    I am confused. First you say the controller should wait with issuing the
>    next command until it got the answer of the previous one.
>
>    > The sequencenumbers in the GTP request/respons lines serve
>    > *no* purpose. They are just grep-beef.
>
>    > not to play games. The absence of rules and timing
>    > causes these to be handled in a program-specific way.
>
>    What do you mean by "absence of timing"?
>
>    > The timing is the wordt part: it causes too much
>    > logic to be placed into the GTP controller ("driver")
>    > program. This logic is program specific, and since
>    > there is no "language" for expressing them (to the
>    > other end of the connection) it is also tournament-
>    > specific...
>
>    Did you look at time_settings and time_left? What else should there be?
>
>    Arend
>
>    _______________________________________________
>    computer-go mailing list
>    computer-go@xxxxxxxxxxxxxxxxx
>    http://computer-go.org/mailman/listinfo/computer-go
>
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://computer-go.org/mailman/listinfo/computer-go

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