IMP-dev

imp-dev@salilab.org

869 discussions

IMP_OUTPUT_OPERATOR now in IMP_VALUES
by Daniel Russel 24 Dec '10

24 Dec '10

In order to reduce the amount of boilerplate that is needed per class, IMP_VALUES now includes IMP_OUTPUT_OPERATOR. I tried to remove all redundant macro calls, but if I missed one, just delete the IMP_OUTPUT_OPERATOR call.

1 0

XYZR
by Daniel Russel 20 Dec '10

20 Dec '10

Does anyone use XYZR with a custom radius attribute? I suspect no, in which case I would propose removing the capability as it complicates a bunch of things (and, probably, slows them down) and the XYZR is simple enough that an alternate implementation could be provided if one using another attribute was desired. Thanks.

2 1

Propositions for IMP::em DisplayMap
by Benjamin SCHWARZ 20 Dec '10

20 Dec '10

The propositions consist mainly in : - allowing users to choose and modify the protein density constant (factorization and replacement of the 1/1.21 constant) : - either by directly modifying that constant - or by using known constants from the literature - slight modification of the approximate_molecular_mass to : - reflect the actual protein density - correct the minor bug reported in a previous message - proposition of code to compute the intensity threshold needed to obtain a set of voxels with a given mass or volume Attached are two files where code can be found for possible insertion in IMP/module/em/DensityMap.{h,cpp}. Please let me know if there is anything to change, add, or if you would rather have diff files for easier insertion through the "patch" command. --Ben

2 2

new tests
by Daniel Russel 19 Dec '10

19 Dec '10

When you check the nightly builds or run tests, you will probably encounter some new errors. These are because I discovered that python support introspection and added new tests which attempt to better check that the code follows the some of the more useful rules outlined in the developer and user guides. Specifically there are automatic checks that: - all classes are labeled as with object or value types, and passed appropriately - everything supports show - class names are in CamelCase - method names are in lower case and use underscores (actually, I don't check the latter) - method names begin with a verb These tests (especially the last one), are, obviously, heuristics. The idea is to cause one to think for a second as to whether the claimed violation of the rules makes sense before forging ahead, rather than to strictly control behavior. As a result, there are ways of adding exceptions to everything, as explained in the test failure messages (basically by adding arguments in the test/SConscript file for the module). --Daniel

1 0

Making PDBSelectors Objects
by Daniel Russel 19 Dec '10

19 Dec '10

I'd like to make PDBSelectors IMP::Objects. The change would not affect python code. For C++ users, PDBSelectors would have to be created with new instead of on the stack. So in general, a call that was read_pdb(name, CAlphaPDBSelector()) would become read_pdb(name, new CAlphaPDBSelector()) The advantages are - we could now provide AndPDBSelector and OrPDBSelector which work in python - there aren't annoying corner cases which cause problems due to the selectors being sliced. Objections?

1 0

recently in IMP
by Daniel Russel 17 Dec '10

17 Dec '10

- IMP::display::PlaneGeometry was added to display planes - the optimize methods on optimizers was moved to a "non-virtual interface". Usage has not changed, but optimizers should implement IMP::Optimizer::do_optimize() instead of IMP::Optimizer::optimize() to benifit from better checking. - the two-vector constructor for IMP::algebra::Plane3D now expects the second vector to be a unit vector as otherwise one could switch the order around without noticing. - the io functions in the kernel have been cleaned up a bit (the old ones are there for backwards compatibility). See IMP::write_particles(), IMP::write_particles_binary(), IMP::write_particles_to_buffer() and IMP::read_particles(), IMP::read_particles_binary(), IMP::read_particles_from_buffer() - IMP::core::WriteModelOptimizerState is going away as it duplicated IMP::WriteParticlesOptimizerState. - the IMP::algebra::Grid3D has been changed to make it support any (fixed) dimension when used with sparse storage. The template arguments have also been changed to remove a redundant one. See IMP::algebra::GridD. - the biological systems specification has been improved a little adding ability to run some rudamentary tests to make sure the scripts are ok and to not require that everything be run from the svn directory. - A new method IMP::atom::create_compatible_rigid_body() which creates a rigid body from a hierarchy which has the same internal coordinates as another rigid body. A way to make the rigid body construction more canonical would be nice (so we don't need this function), but I'm not sure how to do that.

1 0

minor bug in em::approximate_molecular_mass
by Benjamin SCHWARZ 16 Dec '10

16 Dec '10

I think return d->get_spacing()*counter/1.21; should be replaced by double s=d->get_spacing(); return s*s*s*counter/1.21; --Ben

1 0

building of lone modules/applications/biological_systems
by Daniel Russel 13 Dec '10

13 Dec '10

IMP now supports building of modules/applications/biological_systems without a full checkout of IMP svn. This means that you can create a directory containing only your module/application/biological_system (henceforth mabs) in a subdir, link the IMP SConstruct and scons_tools entries, make your config's includepath, libpath, pythonpath, and swigpath point to valid IMP headers, libraries, python modules and swig files, you can then happily build and test your module without - dealing with scons randomly rebuilding parts of IMP - having to compiling IMP yourself at all - sit through scons setting up other modules This makes sense to do if - you are not working on IMP core code (just adding stuff to your own mabs or working on a module like saxs or multifit that is not used by other modules) - what you are doing is not so bleeding edge that you need IMP updates more than once a day or so - we provide some sort of usable nightly build... My suggestion for how we could best take advantage of this would be to have useful nightly builds (release and fast with all dependencies against the desktop linux version) installed into a shared location each night in a directory labeled by the svn version or the date (eg /diva1/imp/release/12_11_2010). You could then point your local config.py at a given date's build rebuild only your code. Updating to a newer version of IMP would simply requiring changing where your config.py is pointing and rebuild only your code (so very fast). Having a repository of old builds of IMP would be very nice (I think Dina would agree) in tracking down changes in behavior and performance. The same thing could be done on the cluster. I'm not sure if there is much one could do with laptops though. Does this sound useful?

3 6

compilation errors
by Daniel Russel 13 Dec '10

13 Dec '10

if you are having compilation errors today, just delete the build directory (or even just build/swig) and try again. I renamed some files to make them easier to track and the scons setup has some issues with dependency tracking and the swig files (since it looks for dependencies before updating the files to use the new names).

1 0

http://en.opensuse.org/Build_Service
by Daniel Russel 11 Dec '10

11 Dec '10

Seems like a cool way to deal with almost all the various linux distributions at once both for building releases as well as, perhaps, for doing nightly tests.

1 0

← Newer
1
...
24
25
26
27
28
29
30
...
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