KGS Issue - Kogo's Joseki Dictionary

   

This is the discussion of the wish to allow to use Kogo's Joseki Dictionary with CGoban2.

wms: The problem is that Kogo's is generated with WinMGT, and WinMGT produces bogus SGF files. CGoban 2 is very careful to only be able to write valid SGF; in fact, its internal data structures are not capable of holding invalid SGF. When it reads a file that is invalid, it reports errors. CGoban 1 (and most other apps) aren't as careful and don't notice the mistakes in the file. I have exchanged email with the author of WinMGT about this, and his answer was that the SGF standard is stupid and he won't fix his program. I could probably make CGoban 2 do a better job of fixing the problems as it reads in Kogo's, but as you can imagine, writing code to repair files written by programs whose authors have that attitude isn't real high on my list of things to do. My advice: Please complain to the author of WinMGT, and tell him to make his program emit valid SGF. Once he fixes his program, and Kogo/Gary Odom start using a fixed version, then these errors will disappear.

  • Fwiffo: I've found a workaround for those who want to use Kogo's Joseki Dictionary with cgoban2... There is a command line tool on the [ext] SGF home page called [ext] SGFC for checking and fixing SGF files. I've run Kogo's through it and it looks like it fixes it up nicely. It would still be nice if WinMGT got fixed, but this is a good alternative in the mean time.
    • Cheyenne: just a little note.. the SGFC tool is the reference implementation for the SGF file standard.
      • pel?: After fixing the sgf-file, it still takes a huge amount of time to load the file compared to, for instance, glgo. It is almost as if the program actually renders (without displaying) the board for every position in the game tree.
      • wms: Nope. Doesn't. What does take a lot of time is validating the whole file. The internal structure I use to record SGF checks every single property that gets added to make sure that it doesn't conflict with any other property in the node. This slows things down a lot. Not a big deal in any case except when reading truly massive SGF files, of which exactly one is at all popular, and that's Kogo's. Because exactly one file is actually affected by this slowness, and that file has real problems anyway, I don't plan on changing this - this thorough validation has caught a lot of times that I accidentally coded CGoban in a way that would have produced illegal SGF.

Bill: I have also found a remedy. Replace every "AW[" with ";AW[" and every "AB[" with ";AB[". Easy. :-)

Dronak: For what it's worth, I just tried the fix Bill gave and it removed the initial warning message CGoban 2 was giving me. The file still took a while to load up, but I guess that's just the validation process wms mentioned. It looks like it has to do this every time the file is loaded. It would be nice if the program could know that the file was already validated once and not validate it again on every load, as long as the file isn't changed at all. But since this is apparently the only popular file big enough to show delays in loading, I suppose it's not really worth it.


This is a copy of the living page "KGS Issue - Kogo's Joseki Dictionary" at Sensei's Library.
(OC) 2005 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About