January 2009 - IMP-dev

providing more control over builds
by Daniel Russel 20 Jan '09

20 Jan '09

There is currently no way (as far as I can tell) to tell IMP to build a debug (non-optimized) version. I propose replacing the "release" configure option with a "build" option which can be one of - "debug" which makes a non-optimized version of the library with debugging symbols - "release" which makes an optimized version of the library but with runtime checks enabled - "fast" (or some better name, perhaps "ndebug") which used NDEBUG to disable runtime checks (and is optimized and doesn't have debugging symbols).

2 1

atom module
by Daniel Russel 20 Jan '09

20 Jan '09

Since we have various atomic functionality and are getting more, we should probably start the atom module. Initially it will just have AtomDecorator ResidueDecorator MolecularHierarchyDecorator I would be inclined to put a wrapper for the modeller pdb reader there too, so that we don't have modeller dependencies scattered throughout the example files.

2 3

molecular hierarchy helper methods
by Daniel Russel 20 Jan '09

20 Jan '09

We have been kind of inconsistent about molecularhierarchy-related helper methods, for example molecular_hierarchy_get_by_type. Some of the methods have a molecular_hierarchy_ prefix and some not. I propose (as was Ben's preference when this was discussed before) to remove the prefix from the methods which have it: molecular_hierarchy_get_by_type becomes get_by_type and molecular_hiearchy_get_residue becomes get_residue

2 1

Moving atom and residue types
by Daniel Russel 20 Jan '09

20 Jan '09

I moved the atom and residue predfined types from being static members of the respective decorator (i.e IMP::core::AtomDecorator::AT_C) to being members of the IMP::core namespace (IMP::core::AT_C) so that swig could manage to export them to python. This shouldn't affect too much code as they were not previously usable from python, but just be aware.

1 0

decorator improvements
by Daniel Russel 19 Jan '09

19 Jan '09

Most of the decorators now that things as arguments to their create function. For example, you can now do XYZDecorator.create(p, IMP.Vector3D(1,2,3)). Just something to be aware of. The IMP_DECORATOR macro also changed in case anyone else uses it. Read the documentation to see how to use the new one.

1 0

Removing particle storage in restraints
by Daniel Russel 17 Jan '09

17 Jan '09

I had mentioned this a while ago and would like to bring it up again since now seems like a good time to deal with it: I would like to remove the particle storage in the Restraint base class. The reasons for this are: - a significant fraction of the restraints don't use it so it is just taking up space (not significant) and presenting an opportunity for bugs since you could accidently look at the wrong storage or use the default get_interacting_particles when it is inappropriate. - if a Restraint does used it, it imposes an unstructured storage mechanism on the restraint: that is, restrictions on the set of particles (since that it is always two particles, or always a set of pairs) are ignored. This makes a number of the restraints more complicated. - for the Restraints which do use it, the amount of code savings in minimal to negative (it is negative in the case where the raw storage mechanism is exposed since that has to be done through using statements. - If it is removed, to port restraints which currently use it you would simply add: IMP_LIST(protected, Particle, particle, Particle*) to your class declaration and IMP_LIST_IMPL(Restraint, Particle, particle,Particle*,,,); in your .cpp file. if you used the default get_interacting_particles, (you are probably doing a bad thing), you would also have to add ParticlesList get_interacting_particles() const { return ParticlesList(1, Particles(particles_begin(), particles_end())); } in your header.

3 4

TNT
by Daniel Russel 16 Jan '09

16 Jan '09

there is now a version of TNT checked in to the algebra module. The classes are in the internal namespace so IMP::algebra::internal::TNT::Array2D. Oof.

1 0

New 'algebra' module
by Ben Webb 16 Jan '09

16 Jan '09

As discussed earlier, there is now a new 'algebra' module. Unless there are objections, I'll also put VectorD in there. Ben -- ben(a)salilab.org http://salilab.org/~ben/ "It is a capital mistake to theorize before one has data." - Sir Arthur Conan Doyle

1 0

Index objects
by Daniel Russel 16 Jan '09

16 Jan '09

After talking with Dina, I realized that there isn't really any circumstance under which it makes sense to use the ParticleIndex (or RestraintIndex) objects as one is always better off storing the Particle pointers. I propose removing the indexes and replacing the storage with a boost intrusive list. This will make it clear to new people that they should not be using the Indexes and make various code much simpler (since the range will always be full, even after deletions). Likewise the ParticleIterators in model probably should be hidden so people aren't tempted to use them, but doing this is complicated by the macros being reused in many places and so is not as trivial a change.

2 1

string utilities and boost.string
by Daniel Russel 15 Jan '09

15 Jan '09

shouldn't we use boost.string for those sorts of things rather than wrap them?

2 1