Re: Go Programming Environment Offered (?)

[Jeffrey Greenberg <jeffg@xxxxxxxxxx>]

Matt Gokey wrote:

> This looks like fine work! I was contemplating doing a similar environment myself
> eventually - its a big effort! And a big effort to give away! Hats off ;)   I'd
> thought of writing a specification for the environment and interfaces and publishing
> it to the Go programming community to hash out final interfaces and build interest.
> >From the information available, I'd say the design looks good and implements just
> enough, but would you consider publishing a full specification (functionality and
> public interfaces) for review and comments before a release is made public?
>
> Some questions/comments:
>     1.  Would you release full sources or binaries only?

Given the state of maturity, source code is the only way.

>     2.  Would/could the engines/players be implemented as DLLs or shared libraries?
>           or are they statically linked?

As there is no abstraction for dll's it's statically linked.  However, each 'player' is
actually a proxy for the actual player. Nothing prevents an out-of-process interface
between the a player and an engine, if you must.

>     3.  Could engines written for this environment legally compete in tournaments?

To the extent that the Go Modem Protocol, I've implemented is robust, why not?  (I'm
sure the GMP needs some cleanup).

>     4.  How can it be designed to allow for a customizable user interface?

The gui portion is broken out if you don't want what I have.  You could re-implement it
as you wanted.

>     5.  The argument raised in several responses about a class library as opposed to
>
>          a full playing environment, I think has merits also.  Both ways have their
> pros
>          cons.  I could see classes for the GMP, for reading/writing game files, a
> go
>          board custom control class, abstract go engine class, zobrist hashing
> class,
>          abstract revertable container class maybe, pattern matching class
> potentially, etc.
>          To really make them work well together, you'd probably have to standardize
>          on some data types and values though, but its worth considering as well.

My purpose has been to get the programming going. Much of the above are available for
use in your engine  (i.e. they are public classes), but they have been first oriented to
getting the environment going.As you note in the last sentence, the environment has it's
own datatypes on which it is built.  It is not clear whether a programmer will prefer to
use their own or use what is provided  (I expect the former.)  Thus all the other
classes may be useful or useless depending.
(fyi: it has a hashing algorithm not based on zobrist -- it needs to replaced with one
of the zobrist algorithms posted here over the last weeks, as it will occasionally
detect ko when in fact there hasn't been one.  -- There's a bit of this that I'd like to
get fixed with a few hackers before I expose it to everyone.)

> BTW, my vote is for OpenGo and if you need any help, I'd be interested - I'm
> familiar with some variants of Unix, and Mfc/Win32 environments and C/C++.   My
> available time in the near future is not too good, however.
>
> Matt Gokey

 Ahh time...  This is the critical item.

--
Jeffrey Greenberg
Mgr. Aegis Adv. Dev.
Acuson Corp.
www.ultrasound.com
www.acuson.com
650-694-5422