- IMP-dev - salilab.org

For emacs users
by Daniel Russel 07 Jan '12

07 Jan '12

I added emacs config code to a new emacs page in the wiki that: - turns characters beyond the 80 character limit red - removes blank spaces and the ends of lines when you save.

1 0

Improved nightly build results
by Daniel Russel 16 Dec '11

16 Dec '11

The nightly build page is much less used than it should be (I don't think anyone other than Ben or I looks at it regularly). This is, in part, I think because it is hard to extract the useful information from it. As i think it would be really nice to have more people looking at it after they submit changes and be able to get the information they want out more easily, I started a wiki page on ideas for improvement < https://salilab.org/imp/wiki/nightly>. Please add/change ideas.

1 0

No more IMP releases?
by Daniel Russel 16 Dec '11

16 Dec '11

Now that Ben has made the nightly builds available online it might make sense to move away from our current nominally release based distribution model to one based on just making the actively developed version of IMP more readily available. To make it clearer what I mean, the model would look something like: - some set of current and historical nightly test results are publicly available on line such that one can - check how the nightly tests went for a given night - if they were satisfactory, easily update your svn to that version or download the corresponding pre-built binary - large rearrangements of modules should be preformed by creating a new module (eg domino2 or multifit2) and working on that new module then merging the changes back in to the main module (or replacing it wholesale). - we perhaps include a periodically updated pointer to a stable version to use for people who don't want to think too much about it Basically, this is a formalization of what we are already doing, with a few extra features: - multiple versions of the nightly builds available - saving of the nightly test results - moving of the svn version associated with the nightly test results to a more prominent place in the page - links from the nightly test results to the corresponding downloads - a link somewhere to one of the nightly build pages as the current "stable" version (and, perhaps, a corresponding svn tag so that someone can fetch it from svn without thinking too much) Good? Bad? Scary?

3 9

Using git as an svn client
by Daniel Russel 09 Dec '11

09 Dec '11

I've been using git as my svn client for a few weeks now and can quite recommend it for anyone who is - writing large amounts of for IMP or an IMP module that is shared with others - writing code that sits in modules but is not committed back to svn for long periods The advantages of using git as your svn client instead of straight svn include - you can commit files locally (without sending them to the SVN repository) so that you have backups and tracking of your changes without subjecting everyone to them. For example, if you add a new class to the ISD module and have it in a working state, you can commit locally. Then if you make some changes that break something, you can see what the changes are and roll back if needed. Similarly, you can locally branch. - you selectively commit some of your changes, even when several changes touch the same file. You just have to commit the file with the first set of changes and then are free to make another set to the same file. - git does much better merging than svn, so it handles cases like sending patches back and forth between people with aplomb - moving around in the imp history is very fast with git, so if an update isn't happy, going back to the previous version is trivial and fast. If anyone is interested, a doc on how to get started can be found here: < http://maymay.net/blog/2009/02/24/how-to-use-git-svn-as-the-only-subversion… > As a few comments: - the first fetching of the files from svn takes quite a long time (an hour or so) - amazingly, the resulting checkout is significantly smaller than an svn checkout despite containing the complete history of the svn project

1 0

Moving display up in the world
by Daniel Russel 01 Dec '11

01 Dec '11

I'd like to move the display module up so that core and atom depend on it (rather than vice versa). This will have various nice effects such as - algebra and kernel tests that use display don't require building almost all of IMP - display can be used in core and atom C++ code to aid in debugging - code to display various decorators goes with the decorators - display now looks like statistics and algebra in that it provides low level services that can be used by many other modules The externally visible breaking change caused by this will be that various display::Geometry subclasses for displaying decorators will be moved to other modules. Specifically: IMP::display::XYZRGeometry will move to core IMP::display::HierarchyGeometry will move to atom IMP::display::SelectionGeometry will move to atom Objections, comments?

1 0

Maximum number of restraints
by Davide Baù 29 Nov '11

29 Nov '11

Hi, is it possible to set a maximum number of restraints to a particle? Thanks, Davide

2 4

algebra::get_unit_bounding_box_d()
by Daniel Russel 23 Nov '11

23 Nov '11

algebra::get_unit_bounding_box_d() currently returns a bounding box with diameter 1 (that is, one reaching from 0 to 1 in each coordinate). This isn't documented and is kind of inconsistent with algebra::get_unit_sphere_d() which returns a sphere with radius 1. I'd like to change the former to be consistent (so get_bounding_box(get_unit_sphere_d()) == get_unit_bounding_box_d()). It doesn't look like anything in IMP depends on the old behavior, but it is used in various tests and examples (at least some of which seem to assume the behavior I'd like to change it to). Thoughts? Objections?

1 0

Documentation pages
by Davide Baù 21 Nov '11

21 Nov '11

Hi, is there a problem with the online documentation? It seems I can access only the example pages. Thanks! Davide

3 4

breaking changes to RMF
by Daniel Russel 09 Nov '11

09 Nov '11

I'm making some breaking changes to RMF files as part of a cleanup. I think they are all in obscure areas that no one is using yet, but I just want to make sure that no one is surprised: - bonds will be stored using a different scheme. As a result, existing bonds in the file will be ignored. Adding backward compatibility support for this would be pretty easy. - the API for storing/extracting bonds has changed (the old API is still there, just no longer documented and now deprecated). There is now a general purpose API for storing data related to tuples. - the way triangulated surfaces are store is changing (and triangulated surfaces from IMP aren't supported at the moment as I have not gotten around to updating it). It now uses the variable length entries rather than external hdf5 data sets - the way segments and cylinders are stored has changed On the plus side: - you can now associate arbitrary data with any tuple of hierarchy nodes (at the moment, the tuple must have size <= 4). So you can store information about bonds, torsion angles, angles etc. - mesh surfaces that vary from frame to frame are now supported - external HDF5 data sets are not used - polylines and poly-cylinders are now supported

1 0

IMP.atom.Chain.set_id()
by Keren Lasker 31 Oct '11

31 Oct '11

hi: IMP.atom.Chain(mh).set_id('A') does not result in: IMP.atom.get_chain(IMP.atom.get_leaves(mh)[0]) == 'A' what am i doing wrong? thanks, keren.

2 3