Re: [gnugo-devel] dynamic connection status?

[Gunnar Farneback]

Dan wrote:
> > For the time being I think it's more constructive to work with the
> > connect/disconnect test cases in connect.tst and connection.tst.
> 
> But I disagree for two reasons: 
> 
> (1) Linking it in has to be done anyway, unless we abandon
> this code and start again from scratch, so why not do it now;

Because linking it in will involve lots of experimentation, which is
much easier to do once readconnect works solidly. 

> (2) We will definitely get useful information by being able
> to play real games using this code. For one thing we will be
> able to use the regressions to identify the moment when
> the new code does more good than harm.
> 
> Incidentally (ignoring timing matters, which I'm testing
> right now) we've reached that point with the experimental
> semeai code, and we wouldn't know that if we didn't have
> the experimental compilation option.

There's a huge difference in complexity between linking in the
connection reader and the semeai code. The latter is limited to an
alternative function call, new_semeai() instead of semeai(). Linking
in the connection reader will involve lots of alternative code,
especially when we start breaking up the amalgamation process.

This notwithstanding, I don't mind if people start doing experiments
with things that can be done on a small scale. But I still think it's
more constructive to improve the connection reader itself at this
time. Unfortunately I don't know how to proceed within Tristan's
design, so unless he adds some input soon I'll try an alternative
approach.

If people want to help with this without getting involved in the code
it would be very valuable with additions to the test suite. In
particular systematic tests of standard connection tesujis would be
helpful, similar to the monkey jumps with variations in
connection:34-47. 

/Gunnar