Daniel Russel wrote: > Since by now things are a bit mixed up, here is a monster diff.
Most of this should be in now. If I missed anything, send in a (hopefully less monstrous) diff...
Although everything compiles, MSVC spits out a bunch of warnings about the MKSUnit stuff; perhaps you could take a look and either satisfy yourself that this isn't a problem or (ideally) disambiguate things sufficiently so that it's happy: https://salilab.org/internal/imp/logs/imp/bin.i386-w32.log
> - The level of checks can now be set at runtime using the methods > set_check_level and get_check_level. Valid values for the levels are > NONE, CHEAP, EXPENSIVE. NDEBUG works as before in that it permentantly > turns off various checks but the speed difference compared to running > with NONE appears to be small. I suggest that python code be run with > cheap checks and interactive python run with expensive checks.
I'll put this in shortly. Maybe I'm mistaken but it looked like NDEBUG didn't permanently disable the checks, just set the default check level. Most users would expect NDEBUG to disable the stuff at compile time. I'll check this to make sure that's really the case before it goes in.
> - A new class BondCoverScoreState is added > > - there is now BD optimizer.
I didn't see any testcases for these in the patch...
> I am not sure of a good way to test such stochastic things.
Usually you can only really test average properties, e.g. energy conservation.
> - I tried to roll back Ben's disabling of some tests which had been > failing, but didn't try very hard, so they might not all be back.
Why would you want to do that? Those were bug fixes. The tests weren't failing - they were exposing bugs. By rolling back the changes, you reintroduce the bugs...
> - The default check level should probably always be cheap and the unit > test should turn on expensive tests. I don't know how to add code to all > IMP unit tests.
Put it in the base class's setUp() method, I guess. You just need to be a little bit careful that that is called by any subclass that also defines a setUp method. But I can do that.
> - there is code in restraints and things to return how much memory they > used.
I don't like this so much, since you add a virtual method to Object, which increases the overhead for everything. If you have to instrument, couldn't you just instrument the Restraint and/or ScoreState classes?
Ben