>>I begin to see something interesting. If you run gnubg with a GUI from >>an xterm (or, I suppose, a DOS window) and enter the commands Jon >>posted, you'll get the erroneous results identical to the CLI version >>- this one calls CommandHint() followed by CommandRollout(). In the >>GUI if you pop up a Hint window and then select some moves ans ask for >>them to be rolled out, you get the correct result. In this case, it >>calls ScoreMoveRollout(). The two routines have much in common, so >>much so that they need to be merged into a single routine. The logic is >>fairly complicated, but I think the cause lies in a failure to >>correctly set up the board and the flags needed for a rollout. > >Yes, that sounds right. Sharing as much code as possible between the >GUI and the CLI would probably be a good idea here.
I agree with the idea of sharing as much as possible but it seems to me that many of the nasty bugs reported are more due to extensive use of global data structures. I've seen a few post regarding a redesign of internal data structures : the posts were focused on game and move lists, but maybe that's the right time to rethink also the eval/rollout context stuff (and possibly all the rest). As a side, the extensive use of global data also made very difficult the implementation of a multi-thread version of gnubg (i have no idea where we stand wrt this). IMO, the multi-thread thing could be a major feature : when I met F.Berger in the last Computer Olympics in Torino he told me he was ready to buy a dual core laptop just to see what BG Blitz can gain running on such platforms ... of course his life is easier since he's using java ... MaX. _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
