Subject: Re: [IMP-dev] NBL cleanup and other small patches
From: Ben Webb <>
Date: Thu, 15 May 2008 11:24:01 -0700
Reply-to: List for IMP development <>
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:
- 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
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle