My suggestion is: module/example - simple examples of specific code as now module/bin - utilities to run functionalities of the module that produce meaningful output (basically what that is in applications now and javi's 2dem/bin is a great example) applications/method - subdirectory for each complete method (paper) + tutorial if written applications/systems - subdirectory for each biological system (such as Nup84
This is the current organization, there is just a shortage of things in all of the categories, especially as one gets further down the list :-) We also don't have a way to specify for an application whether the code is intended to be read or not (so it should be include in the list of examples).
i am not completely sure how to best divide application module/bin, module/example. To my understanding applications was suppose to be a complete protocol for a specific complex (such as Nup84). I added simple scripts like resampling / simulating density maps to applications/em, but they should probably move to em/bin. the problems with the current system are: 1. when someone opens IMP and looks for where to start, it would be good to direct to clear and simple tutorials. This is not the case now.
Sure, there should be more tutorials/examples in a easy to find place, but I don't see that an example module vs a tutorial module is a clean divide to have both.
2. each application in application/module and tutorials uses more than one module, so users that want to look for application of modeling +em should go to atom / modeller / em / 2dem / multifit - its not clear.
Yeah, it would be nice to automatically generate links from a module to all example code which uses it. I'm not sure how to do things, but I haven't looked. Just scanning the example files from other places for "import IMP.modulename" and "#include <IMP/modulename" and including this list in the example page for the module would be pretty easy to implement.
On Oct 30, 2010, at 11:13 AM, Dina Schneidman wrote: