Christian Anthon wrote: > > a) have you compared the sgf files of analyzed matches between the > 0.15 and current branches?
I've been comparing exported html between 0.16 before my changes and the current code. The results are the same, I think some of the data needs protecting though, UpdateStatContext for example. Hopefully some other people will test that the results are still the same - I have lost track a bit at times... > b) from a code maintenance point of view having only one thread > implementation would be best. Are there any advantage of windows > threads over gthreads? If you really have to use functions from > pthreads I think it would be better not to mix them with glib. I'll look at the GPrivate stuff and if I can get the glib coding working fine I'll remove the windows code (as long as the performance is the same). > c) lets remove the REDUCTION code. My guess is that it is largely > unused and at some point will stop working anyway. I've gotten confused about this, is it not compatible with the SSE code and hence not used much anymore? > d) gnubg compiles with minor changes on linux with or without changes, > but there is a problem with makebearoff and the other utility > programs: when multithread in config.h is enabled eval.c implies > multithread.c, which implies gnubg.c and gnubg.c has it's own main > function. I'll take a look. > e) when the code becomes stable I think it would be nice to be able to > compile threads in always and to enable them at startup or when the > user wishes to. Then on both windows and in linux distributions only > one binary would be needed. Ideally, if everything works out ok we can remove the USE_MULTITHREADED define and then either run with 1 or more threads (or single threaded with the MULTITHREADED define in multithread.c). Jon
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
