Dear Gunnar,
Thanks a lot, your answers really makes sense. Comments follow:
On Wednesday 09 October 2002 01:07, Gunnar FarnebXck wrote: ...
The kind of commands you want may be better to call diagnostic, or something like that.
Yes, that is correct. ...
Still I would encourage you to do experiments with a GUI and multiple engines to find out how well diagnostic commands work in practice. This may well be stuff for a future extension of the protocol.
OK, will do! My point is that for heuristic engines like GNU Go, Wallyplus, Amigoplus or Baduki, it is interesting to know the exact heuristic used by the engine to generate its move. And it would be nice to have a GTP command for this purpose, so that this information can be made available to the opponent (when the engine is playing against a human) or observer (when two engines are playing against each other) or programmer of the engine (in a regression testing situation).
For a non-heuristic engine (e.g. Neurogo), I still believe that it would be interesting to know in some way how the engine generated its move, although the answer will not be of the form: "Using rule XXX to generate move". ...
What is the correct behaviour?? Output to stderr or stdout?
The simple answer is that in GTP version 2 stdout is correct.
Aaah! OK!
The original GNU Go implementation was to output to stderr, mainly because that was easiest to implement, but also because it sufficed for our purposes. If you are observant you may notice that if stderr and stdout are merged, the output is not syntactically correct, but on stdout the output is a correct empty response.
Yes, I did observe that somehow and I was curious about it. That prompted my question.
Current GNU Go development versions still use GTP version 1, but this will change before 3.4.
OK, that is good news, in the sense that it would be useful to have a GTP V2 reference implementation.
The somewhat more complex answer is that the output should be over the GTP communication channel, but it's up to the program whether it communicates through stdout, stderr, a socket, or whatever. For a typical unix program, though, using stdin/stdout would usually make most sense.
Yes, I have understood also that GTP does not specify the streams through which the programs should communicate. IMHO, that is a Good Thing. Different environments will need different modes of communication, and specifying e.g. stdin/stdout would restrict the protocol without any advantage.
OTOH, I saw no reason to make one command (showboard) different from all the others, by responding on a different output stream.
Regards,