Little Go 1.3.1 released, and another Ko bug squashed

Little Go 1.3.1 has been published a couple of days ago on the App Store. This release contains a single bugfix only - but one that I consider to be very important!

There's more to read after the break. The App Store update notes and the GitHub release page both have a shorter text.

The bug manifested itself as an alert message that starts with the information "Your move was rejected by Fuego", an indication that Little Go's bookkeeping of moves has somehow become out-of-sync with Fuego's internal data structures (keep in mind: Little Go is just the iOS user interface to Fuego, the Go engine that does all the real work in the background).

Over the years I have received many reports for this bug, but every time I made an attempt to locate the root issue I became stuck somewhere, and after a few hours of analysis the effort fizzled and I gave up. However, after each new release I had to wait only for a relatively short time until I got a new report, which diminished my pride in the shiny new software version I had created and reminded me that I had not done my duty. It was a thorn in my side, my nemesis, in short: I really hated this bug!

Well, no longer! Thanks to Manuel Braun, who sent me another bug report at the start of this week, I was finally able to reproduce the problem (see GitHub issue #307 for details) and convert this into an ex-bug. Bereft of life, it rests in peace. As usual, it was a small and stupid error that has entered the code base almost 4 years ago in version 0.10.0, when support for viewing old board positions was added.

After looking back on the development history of Little Go, it's remarkable how many coding errors I have made in the logic that determines whether the player's next move is legal or not. I clearly remember that soon after I had started coding Little Go, I had to decide whether to implement the "is this a legal move?" logic myself, or instead delegate to Fuego's well-established logic via the "is_legal" GTP command. If I remember correctly I decided to do this myself because the GTP command's result does not provide a reason why a move is not legal - and that's an information I absolutely wanted to feed back to the user, especially thinking of Go novices who might not be able to see why they can't play on intersection X. Also, I had had a look at how GoGui (a desktop UI frontend for Fuego) handles this problem, and they also implement their own "is this a legal move?" logic.

Well, with hindsight it might have been better to rely on Fuego's logic, and instead patch Fuego's source code so that the "is_legal" GTP command provides the reason. Maybe I will still do this if more errors in my implementation pop up... (*touches wood*)