[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