IMP-dev

imp-dev@salilab.org

869 discussions

Start a nNew thread

modeller dependency
by Keren Lasker 25 Apr '09

25 Apr '09

hi, Currently building IMP fails if modeller is not installed ( required by benchmarks/connectivity.o) Keren.

3 2

This week in IMP
by Daniel Russel 24 Apr '09

24 Apr '09

- Support for taking advantage of rigid bodies in collision detection has been added via the IMP::core::RigidClosePairsFinder<https://salilab.org/imp/doc/doxygen/classIMP_1_1core_1_1RigidClosePairsFind…> . - All IMP::core::ClosePairsScoreState<https://salilab.org/imp/doc/doxygen/classIMP_1_1core_1_1ClosePairsScoreStat…>-related functinality has been optimized and should be noticeably faster. - The EMBED project has been merged into the IMP::em<https://salilab.org/imp/doc/doxygen/namespaceIMP_1_1em.html>module. Thus, it is no longer necessary to obtain EMBED separately to build IMP::em <https://salilab.org/imp/doc/doxygen/namespaceIMP_1_1em.html>. - All C++ methods which work with std::istream or std::ostream arguments should now be usable from Python: any Python file-like object can be used. - The SWIG interface now ties in to the reference counting mechanism used in the C++ code, for all classes derived from IMP::RefCounted<https://salilab.org/imp/doc/doxygen/classIMP_1_1RefCounted.html>. So, for example, deleting a Python object should not free the underlying C++ object if another C++ object holds a reference to it, and unrefing a C++ object should not delete it if a Python object still holds a reference to it. There should be no further need to manually keep references to Python objects to prevent things from being prematurely cleaned up. This should be transparent to the user; please report any problems. - IMP::atom::AtomDecorator<https://salilab.org/imp/doc/doxygen/classIMP_1_1atom_1_1AtomDecorator.html>no longer inherits from IMP::core::XYZDecorator<https://salilab.org/imp/doc/doxygen/classIMP_1_1core_1_1XYZDecorator.html> .

1 0

default epsilon ?
by Javier Ángel Velázquez Muriel 23 Apr '09

23 Apr '09

Hi all I am going to suggest something that is not very "correct", but that it is already "de facto" in IMP. I would suggest a default epsilon value for the cases where the use of "almost_equal" function cannot be avoided. That is dangerous, I know, but I think it is even more dangerous to have the code full of different epsilons if they don't need to be different. I'm saying this because IMP::em already has a EPS value of 1e-6 that is thoroughly used, and probably makes sense to define one EPS in other modules. My need is to compute the correlation between two em::Images, that in fact is going to be the correlation between their algebra::MultiArrays containing the data, and I need to check for values of the standard deviation (which is a double) near zero. I don't see how to avoid the use of almost_equal() here, and again, a default epsilon for IMP::algebra sounds reasonable to me.

2 1

SWIG behavior with overloaded functions
by Javier Ángel Velázquez Muriel 23 Apr '09

23 Apr '09

Hi all I have this problem when wrapping an overloaded function: File "test_project.py", line 85, in test_project_Z_opposite result,dy,dx,angles,shift ,tolerance) NotImplementedError: Wrong number of arguments for overloaded function 'project_given_euler_angles'. Possible C/C++ prototypes are: IMP::em::project_given_euler_angles(IMP::em::DensityMap &,IMP::algebra::Matrix2D< float > &,int const,int const,IMP::em::EulerAnglesZYZ const &,IMP::algebra::Vector3D const &,double const) IMP::em::project_given_euler_angles< float >(IMP::algebra::Matrix3D< float > &,IMP::algebra::Matrix2D< float > &,int const,int const,IMP::em::EulerAnglesZYZ const &,IMP::algebra::Vector3D const &,double const) Although the program complains about a wrong number of arguments, it is correct. I guess that the problem comes from overloading the function. Any help?

2 1

Minor breaking change and a proposal for some other changes
by Daniel Russel 18 Apr '09

18 Apr '09

First, AtomDecorator, ResidueDecorator etc. now inherit from MolecularHierarchyDecorator, on Javi's suggestion. This saves a lot of typing in most cases. Some existing code may break, but fixing it is simply a matter of removing a call the MHD::create (since a previous call to AtomDecorator::create added all the necessary data). See the change history for more details. Second, I propose renaming MolecularHierarchyDecorator to HierarchyDecorator since it is in the atom namespace already. This would save a ton of typing as MolecularHierarchyDecorator is a bit ridiculously long. And, with the exception of people like me who do "using namespace IMP::atom", all user code could be updated with sed. Thirdly, I propose removing coordinates from AtomDecorator. The reasons for this are mostly philosophical: we are trying to get away from people being fixed on atomic coordinates and it is only due to quantum mechanical details which have no bearing on what we do that they make any more sense than coordinates for any other level of the atom::Hierarchy. Also, having them makes the AtomDecorator a bit of a mess since it has to inherit from two other decorators.

2 3

This week in IMP
by Daniel Russel 17 Apr '09

17 Apr '09

Week of April 13 - The decorators IMP::atom::AtomDecorator, IMP::atom::ChainDecorator, IMP::atom::ResidueDecorator etc. now inhertic from IMP::atom::MolecularHierarchyDecorator. This means they can set their IMP::atom::MolecularHierarchyDecorator::Type properly and saves a lot of typing in the common case. We can always make hierarchy decorators zero memory overhead if we find that the cost matters. Unless anyone objects, AtomDecorator will soon cease to inherit from XYZDecorator. - The base classes IMP::Comparable, IMP::NullDefault, IMP::ValidDefault and IMP::UninitializedDefault were added to document what the default constructors and comparisons do for various objects in IMP.

1 0

Interface changes to the IMP.em module
by Ben Webb 13 Apr '09

13 Apr '09

As previously discussed, I just made some interface changes to the IMP.em module, to remove unnecessary prefixes or suffixes: IMP::em::EMFitRestraint is now IMP::em::FitRestraint IMP::em::ImageEM is now IMP::em::Image IMP::em::VolumeEM is now IMP::em::Volume Note that Dina intends to make similar changes to the SAXS module in the near future. Some other minor changes which do not affect the Python interface, but do affect the C++ headers: - Fixed spelling (convertors.h -> converters.h) - Renamed headers (headers that do not define classes should be given names separated by underscores, not CamelCase; EMnoise.h -> noise.h, EMproject.h -> project.h, HeaderConverters.h -> header_converters.h) 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

Problem with set_coordinates in XYZDecorator
by Javier Ángel Velázquez Muriel 12 Apr '09

12 Apr '09

Dealing with the code below, if I try to set the particle's coordinates with the commented version, it produces a Segmentation fault. If I use the create function of the decorator with 2 arguments, no failure. I don't really mind using the 2nd version, just reporting. Particle *p; IMP::core::XYZDecorator d; for (IMP::algebra::Sphere3Ds::iterator s = ss.begin(); s != ss.end(); ++s) { p =new Particle(model); d.create(p,s->get_center()); // d.create(p); // d.set_coordinates(s->get_center()); p->add_attribute(radius,s->get_radius(),false); ps.push_back(p); } }

2 1

This week in IMP
by Daniel Russel 10 Apr '09

10 Apr '09

* IMP::Object now defines pure virtual methods IMP::Object::get_version_info() and IMP::Object::show(). All non-abstract classes which inherit from IMP::Object must implement them. Doing this means they are more uniformly implemented and are documented in one place. * IMP::Object is now reference counted (the only objects this changes are IMP::Model and IMP::Optimizer). As a result optimizers and IMP::Model objects must be created on the heap. * IMP::RefCounted has had its name changed and no longer inherits from IMP::Object. This makes it easier to use independently. * the docs for reference counting (IMP::RefCounted) and Decorators decorators (and IMP::Decorator) have been improved * running doxygen produces no warnings. Let's try to keep it that way. Run scons doc > /dev/null before you check in large blocks of new code to make sure that you didn't introduce warnings. * Helper classes have been added to make SingletonModiefier and PairModifier objects look like functors for C++ and python. This makes it so you can use map in Python and for_each in C++. See IMP::SingletonFunctor and IMP::PairFunctor for more information. * The recent changes page has moved to a doxygen page to make it easier to link changes back to the relevant source code. This hasn't yet made it to the web as I keep breaking the build. Hopefully tonight :-)

1 0

Minimum SWIG version increased to 1.3.34
by Ben Webb 09 Apr '09

09 Apr '09

I've increased the minimum version of SWIG required to build IMP to 1.3.34 (it was 1.3.31 before). This is needed because the infrastructure to handle reference counting properly was only added to SWIG in 1.3.34. All of the lab machines run SWIG 1.3.36, so you shouldn't notice any difference. If, however, you're building IMP on a non-lab machine, you may need to upgrade your version of SWIG. For example, Macs running 10.5 ship with SWIG 1.3.31, so you'll need to install a newer version, either with Fink or MacPorts, or by compiling it yourself. If you install the MacPorts version, you'll need to add path='/opt/local/bin' to your config.py in order for scons to pick up your newer SWIG rather than Apple's copy in /usr/bin/. To compile from source just download swig-1.3.36.tar.gz, extract it, then run "./configure --prefix=/usr/local && make && sudo make install" or similar. (The advantage of building from source yourself is that the MacPorts package takes forever to build because it seems to have a lot of not-really-necessary dependencies; the disadvantage of course is that the resulting installation is not controlled by a package system.) The actual fix to get the IMP Python wrappers to use this functionality to do reference counting properly will follow once we have ironed out any problems that crop up with the newer SWIG (if any) and I have had a chance to adequately test the new code. 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

← Newer
1
...
44
45
46
47
48
49
50
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev