IMP-dev

imp-dev@salilab.org

869 discussions

TransformationModifier
by Keren Lasker 29 Nov '08

29 Nov '08

hi, Trying to implement misc.TransformationModifier that inherits from core.SingletonModifier #include "misc_exports.h" #include "internal/misc_version_info.h" ... #include "IMP/core/SingletonModifier.h" IMPMISC_BEGIN_NAMESPACE class IMPMISCEXPORT TransformationModifier : public SingletonModifier The compiler can not recognize SingletonModifier, specifically I get: g++ -pthread -o modules/misc/pyext/misc_wrap.os -c -g -fPIC -fno- strict-aliasing -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -- param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC - Ibuild/include -I/usr/include/python2.5 modules/misc/pyext/misc_wrap.cc In file included from build/include/IMP/misc.h:22, from modules/misc/pyext/misc_wrap.cc:3236: should I change something in the SConsript file of mics/include? thank you, Keren.

2 4

Protecting destructors
by Daniel Russel 26 Nov '08

26 Nov '08

In order to avoid issues like the one I patched in the angle restraint, this class protects the destructors of the ref counted bases classes. These classes should always be controlled through ref counted pointers and so should never be directly deleted.

1 0

Request to simplify IMP config
by Daniel Russel 26 Nov '08

26 Nov '08

Having once again spent a reasonably large amount of time screwing with various bits of the IMP configure scripts in order to get things to work on a mac, I would really like us to simplify things. I suggest the configure options simply be extra_lib_paths="a//b/lib c/d/lib" extra_include_paths="a/b/include c/d/include" python_path="a/b/lib/python-2.5/..." which get parsed and prepended to the scon environment before any tests are performed and get added to all build environments. (I am not sure if space is the best delimiter, but that can be solved later, perhaps by using python syntax "['a/b/include', 'c/d/include']"). The cgal, boost, em, modeller etc arguments can then be removed and configure can then simply test if it can build against modeller, em, cgal, boost etc and not worry about making sure all the paths are added in the right places. We then only have to worry about adding the correct library dependencies to link commands and otherwise ignore dependencies in the build scripts. This also makes it clear that all libraries are searched for in all locations. Keren, Javi and I have all at various points been confused and frustrated by imp picking up copies of libimp in the diva modeller build when neither the imp config arguments nor the directory name (/ diva1/home/modeller-SVN) gave us any clue that such could happen. This also removes the distinction between setups which we happen to have encoded into our config system (which work magically) and setups which differ in some way from what is encoded (which can't be easily made to work). There is currently no way for a user to tell whether things will work, what to do to fix them if they don't and no simple way to document what will work. And we can't ship prebuilt mac binaries for C++ programmers since the boost versions have to match, so we have to support the large number of different ways things can be set up on macs at the very least. Any better suggestions?

3 8

IMP configure cleanup
by Daniel Russel 26 Nov '08

26 Nov '08

Here is a patch which cleans up a bunch of issues with the current IMP config and runtime setup. The only change that people are likely to see up front is that on a mac with macports installed in /opt/local you need to add "include=/opt/local" to your scons command line or your config.py. First, the normal dependencies (boost and cgal) no longer take a path as the value, instead the configure just searches for them in the provided include and link paths. Modeller might be too much of a mess to move to a normal installation, but embed probably should at some point (once someone writes an install script for it). Second, the patch fixes a bunch of places where the internal paths were Appended rather than Prepended, resulting in external headers/ libs being used instead of internal ones. Internal paths should always be searched before external ones. This change includes imppy.sh, so, in theory, once should be able to use modeller on diva again with IMP, but I have not tested this. We also need to be very careful that the library search paths (both link time and dynamic) are always in the same order. Third, the CGAL check checks for linking since it needs some special compiler arguments sometimes. The link check uses Scons.SConf which is not used elsewhere. Since it is been part of scons for several years now (and is part of the 1.0 release of SCons), it seems a bit silly not to use it. Fourth, it adds a way of adding compilation and link arguments to make it easier to handle eccentric setups (such as pre-release versions of CGAL). Fifth, it make the python libraries only link against the corresponding C++ libraries as that is all that is needed (since the C+ + library will pull in the external dependencies) and Mac OS complains about linking against something twice. Finally, the patch adds the external lib search paths to the linked library rpaths on linux (and removes them from imppy.sh on all patforms). There are several reasons to do this - first the LD_LIBRARY_PATH used in the imppy.sh overrides the internal library search paths for other peoples libraries and can result in linking problems if there are multiple libraries on your system with the same name. For example, on my mac there are a large number of libJPEG.dylibs. Adding /opt/local/lib to the LD_LIBRARY_PATH causes the one located there to be used in preference to any found on the internal search paths of the platform SDK libraries and results in link failures. - second, it makes it more likely that IMP is linked against the same libraries at run time and compile time since the two sets of search paths are the same. Various of us have run into nasty problems with this. - on macos the full paths to properly built libraries are embedded in the library upon linking so we don't need LD_LIBRARY_PATH analogs except for getting python started. Another note, the build/lib directory is not added as an rpath since that would change once the libraries are installed (and once they are installed, things that link against the installed libraries are responsible to make sure that imp). I would like to be able to add to the path from the command line but can't figure out how to do it early enough that SWIG is found using the new path.

1 0

module descriptions
by Daniel Russel 25 Nov '08

25 Nov '08

For an eventual IMP release, each module needs some sort of description page giving an overview of the module. I checked in files modules/core/src/core.dox (and a misc version) which provide a first crack at this. So far the page contains: - an overview which includes the namespace containing the code - a list of authors - a list of publications to cite when using the code - the license that the code is released under Anything more that should go in there?

3 4

Containers and Modifiers
by Daniel Russel 24 Nov '08

24 Nov '08

Following my proposal for share containers for particles, I have checked in a set of containers, restraints and score states which allow sets of particles to be shared between different objects. There are versions for Particles and pairs of Particles and there will be version for triplets as soon as Ben checks in the patch to the kernel. All the code is generated from common templates, so supporting different types is easy. The general idea is that you create an appropriate container of particles: say you just have a list of particles, then you create a ListSingletonContainer and put your particles in there. If you want to create a restraint by applying a score to each singleton, you create a SingletonsRestraint and pass the score and the container to the Restraint. If you want to find the close pairs, you create a ClosePairsScoreState and pass it your container. It fills a PairsContainer with all close pairs. You pass that pairs container to a PairsRestraint (just like if you made a ListPairsContainer yourself). Since the container is shared, when the ClosePairsScoreState updates its contents, the PairsRestraint will get the new contents. We also have a new set of base classes called Modifiers which change a particle (or pair of particles) in some way. These can be coupled with a PairsScoreState, for example, to apply the modifier to all of the pairs each time evaluate is called. This provides a way of enforcing hard symmetry constraints (by making one Particle a transformed version of another). Containers can be joined to make another container: i.e. a SingletonContainerSet is a SingletonContainer (just like the ListSingletonContainer above) that contains all the particles container in several SingletonContainers. My intent is to gradually move away from the following classes as their functionality is duplicated in a more flexible way by the new classes using less code: NonbondedRestraint BondedListScoreState SingletonListRestraint PairListRestraint MaxChangeScoreState PairChainRestraint BipartititeNBL AllNBL BondDecoratorListScoreState TripletChainRestraint PairChainRestraint BondDecoratorListRestraint Any comments would be appreciated. A list of the new classes can be found at <http://salilab.org/~drussel/imp/group__restraint.html>

1 0

xcode and imp
by Daniel Russel 24 Nov '08

24 Nov '08

Is anyone else interested in using xcode (the apple IDE) and IMP? I have found it an improvement over emacs (and Aquaemacs) for handling building and editing and debugging on my mac. If others are interested I can maintain an xcode project in the IMP repository. It uses the existing scons build system, it just requires keeping the list of files up to date (so that you can easily get to them in the editor).

2 4

Instantiation of boost code
by Javier Ángel Velázquez Muriel 19 Nov '08

19 Nov '08

Hi there I have a problem trying to use a template class based on Boost in Python. Here is the thing. I write this template: template<typename T> class IMPDLLEXPORT MultiArray: public boost::multi_array<T,MULTIARRAY_DIM> { bla, bla .... } The problem is that I am not able to get this class in Python. The only solution that I have found is to create another class that specifically instantiate the first one: class IMPDLLEXPORT sillyclass { public: MultiArray<Float> data_; }; I've also tried this more clever solution, trying to add this line to kernel/pyext/IMP.i : %template(MultiArrayF) IMP::MultiArray<Float>; but the compiler or SWIG (I don't know which one) complaints with: kernel/pyext/IMP.i:114: Warning(401): Nothing known about base class 'boost::multi_array<float,3 >'. Ignored. kernel/pyext/IMP.i:114: Warning(401): Maybe you forgot to instantiate 'boost::multi_array<float,3 >' using %template. Something that I don't know to fix. Help, please. Javi

1 0

add support for triplets of particles
by Daniel Russel 17 Nov '08

17 Nov '08

The patch adds a new type ParticleTriplet. This patch is needed for some upcoming changes to the containers. It also, as a side effect to clean up header inclusion order, moves the container macros to internal/container_macros.h (the macros need various headers to be included and so aren't as simple as the rest of the macros in macros.h).

1 0

Trac?
by Keren Lasker 17 Nov '08

17 Nov '08

can we use Trac ( or an alternative solution) to visualize the IMP SVN tracking. http://trac.edgewall.org/ ??

2 3

← Newer
1
...
58
59
60
61
62
63
64
...
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