Gunnar wrote:
Actually there should be a way of getting the whole position from the engine
This already exists in GNU Go.
How? Not through showboard, which writes its output to stderr and is therefore invisible to the controller.
A perusal of the commands listed by help doesn't show anything else that you could be referring to.
In principle there's no need for a loadsgf command since the controller could read the sgf file and feed the moves to the engine. Then it would also have full knowledge of board size and other information. On the other hand, the experience from the GNU Go regression system clearly shows that loadsgf is worth having and then, as you say, some query commands are needed (at least boardsize and komi).
This presumes that the controller has access to the same files as the engine.
In the choice between 'boardsize' without argument and 'query_boardsize', I definitely prefer the latter.
That's my opinion too. Such a command is added in the patch metamachine_1_3.1 currently up at the development page.
Metamachine is a program that sits between a GTP client and a GTP engine, passing commands back and forth and modifying them in some cases.
To the client it appears to be a GTP engine.
stdin pipe a GTP client ----> metamachine -----> GTP engine <---- <----- stdout pipe b
Most commands are passed verbatim to the engine. The exception is gg_genmove, which is intercepted then processed differently. The top two moves are both tried, the position evaluated by estimate_score, and the move yielding the higher score is selected. Usage: no arguments gives normal GTP behavior. 'metamachine --debug' sends diagnostics to stderr.
Unfortunately this program does not work with twogtp for reasons that are mysterious to me. The requisite processes get spawned then swiftly and suddenly vanish away, to never be heard from again.
But it does work with the regressions (and does poorly on them, at least for the time being).
Dan