Hello; those of you who know me know that I love Go Grinder. I think it is the best program out there for doing tsumego.

I've recently fixed a bug in Go Grinder which prevented it from correctly processing some of the SGF files from goproblems.com. I've alerted the author to my fix, so be aware that a new version of Go Grinder may hopefully be coming out soon. I don't mind e-mailing anyone the fixed jar either, if you want it.

Secondly, if you check on the goproblems.com forums I've updated tail's perl script for sorting by difficulty percentage and kyu/dan ranks.

Put two and two together and you have a very powerful tsumego reader and tsumego database software.

As a result of these developments I've decided to work on the 2010 usagi edition of goproblems.com. The 2006 edition, released with permission, is still out there somewhere (but it's rather rare, and hopelessly outdated -- it has less than half the tsumego that goproblems.com has today, and many errors). I won't try and release the 2010 edition just yet, but anyone can do, basically, exactly what I did now that gogrinder is fixed and tail's script has been updated.

Good luck and happy Tsumegoing!

Please tell me that it was the AE tag you fixed.

_________________
FusekiLibrary, an opening library.
SGF converter tools: Wbaduk NGF to SGF | 440 go problems | Fuseki made easy | Tesuji made easy | Elementary training & Dan level testing | Dan Tutor Shortcut To Dan

I don't see a reason to use an AE tag, but what is the problem there?

The problem I fixed is when you have a solution with RIGHT, and then two more moves are given, with another RIGHT at the end; such a problem causes Go Grinder to mess up the next problem. This is because it uses a separate thread for the responder and this thread sleeps for 250ms. When the problem finds the first "right", the responder sleeps through the successful solve and then plays the next move of the puzzle.

The first fix I made was to check if the node's parent.isRight() was true; if so, I made the responder NOT call doNode().

However this had some minor artifacts so I simply made it reset a global variable called "pristine" to true at the beginning of nextProblem(). If a mouse click event occurred, it would set pristine to false. And if pristine was true, doNode() would simply return. That solution had no artifacts.

A better solution would be to rewrite the program not to use a thread for the responder. There's no reason to do that which I can see. But now it works fine for what I am using it for (the goproblems.com collection).

It would allow these kind of joseki problems. They work in Drago but not in GoGrinder. I'd love for GoGrinder to support it.

_________________
FusekiLibrary, an opening library.
SGF converter tools: Wbaduk NGF to SGF | 440 go problems | Fuseki made easy | Tesuji made easy | Elementary training & Dan level testing | Dan Tutor Shortcut To Dan

Ahh, I see.

That should be relatively trivial. I'll see about updating the source and pass the info back to the author. It would be possible to see this in by the weekend.

p.s. that's an interesting idea, there may be some value in this. You can replay games in many programs including go grinder -- but I don't see a way for the final position to be shown first without AE tags.

If you could squeeze that in, you'd be my hero. That was the format I choose for the joseki problems from "Elementary training & Dan level testing" so we are a few who is sitting on a couple of hundreds such problems

The eidogo problem displayer used here is a little weird in that it displays the first two moves even without me specifying it. I believe it shouldn't do that. It should just remove the stones within the AE tag and leave all others.

If you PM your email address I could send you some sample problems to test with.

_________________
FusekiLibrary, an opening library.
SGF converter tools: Wbaduk NGF to SGF | 440 go problems | Fuseki made easy | Tesuji made easy | Elementary training & Dan level testing | Dan Tutor Shortcut To Dan