> "Loic Dachary" <[EMAIL PROTECTED]> writes: > > If by "thread support" you mean that the poker-eval library is not > thread safe, I think that's a correct assumption.
That's what i thought. :=) > Absolutely. Let me know your gna.org account and you've won a free > ticket > to svn commits ;-) At the moment, this is not needed. I work in another environment, and i'm far than ready to commit anything to pokersource directly...so i won't bother until the moment i'm satisfied with my work. I'll put links on this list once the project shows some progress though. > The only rule here is that each line commited must be associated with a > unit test that covers it. Very simple rule that prevents lots of trouble. I hear you :=) > If you think about modifying the poker-eval code structure, there is > an addition requirement. You must write and run benchmarks covering > all impacted code and show that you've not introduced something that > slows down the library. A number of poker-eval users rely on its > performances. Well aware of this. I think real thread-safe implementation most probably requires quite some changes in poker-eval itself...again, i'd like to do this and test this in my own environement. I will be basing my work on poker-eval version 134 (as provided in ubuntu), but i can't find such a tag in the svn sources. does it exist? I also assume that poker-eval module does not go through alot of changes now...it's extensive, stable...so even if i take long, there will not be many troubles merging my work in (if i get to the point)...it's gonna be C++ and will also rely on Qt environment (as i see it now). Don't expect anything soon...but maybe some day there will be a thread-safe poker-eval library. -- sumac _______________________________________________ Pokersource-users mailing list [email protected] https://mail.gna.org/listinfo/pokersource-users
