On Wednesday 01 March 2006 14:19, Gunnar Farneb�ck wrote:
How does your implementation handle errors? If there's an illegal move, does it try to tell which move was illegal? Does it restore the board state to before the command or does it leave the successful moves played?
I implemented play_sequence only in the Explorer program so far. If the sequence contains an illegal move, the error response gives information about the illegal move and move number. If the command fails, the original board state is restored. This is easy to implement and avoids that the GUI is out of sync with the program.
Notice that gg-undo, as implemented in GNU Go, does not try to restore the board state on failure.
GoGui never requests more moves to undo than there were actually played. I don't think there is any reason why a Go program that implements gg-undo should fail to undo a valid number of moves.
Ouch, I find undoing anything other than regular moves very ugly, which is why handicap stones (or clear_board) can't be undone. Is there any good use case for this, other than to be able to faithfully navigate an arbitrary sgf file?
No other reason. I found it ugly too, this is why GoGui originally only supported setup stones in the root node. But the fact is that SGF files exist that contain setup stones after moves were played (e.g. problem collections) and I want to be able to load these files and synchronize the Go program with any position in the file. At present, GoGui just assumes, that setup stones don't kill anything when transmitted as play commands, but this is not a good solution and could cause undetected error, which is even more ugly.
- Markus