IMP-dev April 2009

imp-dev@salilab.org

6 participants
19 discussions

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

Re: [IMP-dev] Towards the IMP release
by Daniel Russel 09 Apr '09

09 Apr '09

On Apr 9, 2009, at 10:41 AM, Ben Webb wrote: > Dina Schneidman wrote: >> regarding "complicated projects", I think what we mean is having a >> "black box" program or a script, that can be used by any user. >> The input data should come from the user. We can have some sample >> input data as an example. >> I have a couple of programs for saxs data and we should put there >> more >> for other data types. >> it could be nice to combine them. I think for this purpose we should >> have some common >> mechanism for reading user input parameters. > > Sounds reasonable, although we should be careful to avoid too many > special-purpose applications - the principal aim of IMP after all is > to > allow things to be easily mixed and matched. I think the key thing here is that the applications be made from IMP components and the code in the applications only do things like selecting the correct restraints and optimization protocols and managing data. Then they can both be useful and show off the rest of the IMP code.

1 0

Re: [IMP-dev] Towards the IMP release
by Daniel Russel 08 Apr '09

08 Apr '09

2009/4/8 Ben Webb <ben(a)salilab.org>: > That sounds reasonable to me, although I guess it depends on what you > mean by a "complicated project" and how much data that project might > have. For example, our experience with the 26S has certainly been that > experimental data lives elsewhere (typically it has rather a rather > different distribution, and if nothing else, it's big). I only have a vague idea what I meant by it :-) We have had the general idea floating around all along of having some code that takes a certain restricted set of data is some nice human-readable file format (csv or yaml or something simple) or standard experimental data types (pdb, em maps etc) and produces structures without someone having mess about with more complicated things like python code, restraints, particles, or xml. That was the sort of the thing I meant. The only data in svn would be sample data.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev April 2009