[computer-go] Collaboration project. Once again

Markus Enzenberger compgo at markus-enzenberger.de
Sat Aug 5 09:51:20 PDT 2006


On Saturday 05 August 2006 09:47, Mark Boon wrote:
> I think it could actually be very helpful to have a very separate
> front-end, communicating via GTP. It helps separation. In that case

yes, that was the main reason that I wrote the program, because I wanted to 
separate the tools that can be used with completely different engines, like 
NeuroGo and Explorer.

> extensions. If I'd make those extensions, I suppose only those
> extensions need to fall under the GPL.

that's right. you can fork a GPL version of GoGui and extend it, or contribute 
changes back to the main version. There is already a pretty general GTP 
command type for drawing on the board (the gfx command type) and the 
possibility to draw while a command is running by writing specially formatted 
messages to stderr. However it is a main feature of GTP (for good reasons) 
that there is a controller and an engine, so the engine can never initiate 
any actions.

> The other thing that I think would need to be added/modified is
> attachment of GTP engines through sockets. The pipes are all very
> nice, but they put the control of starting and stopping the engine at
> GoGUI. Since it's going to be a completely separate entity, I'd
> rather be able to stop and start the engine by itself and attach
> itself on a socket of GoGUI that keeps perpetually running. That will
> make it possible to run the engine in a source-level debugger and do
> hot-fix debugging and such without needing to jump through hoops.

There are two options: if your debugger allows to attach to a running process, 
you can debug your engine, while it is controlled by GoGui. If you have to 
recompile your engine, you can detach it from GoGui and attach it again, 
GoGui will send all the GTP commands to synchronize the engine with the 
position again.

I found it usually more convenient for debugging to create a small GTP file 
with commands to setup the environment to debug and then debugging the engine 
process directly (without a graphical interface).

Hope this helps

- Markus


More information about the computer-go mailing list