On Mar 21, 2010, at 12:56 PM, Daniel Russel wrote:
> First, an effort to make compilation of the python wrapper feasible > again. To do this, I propose we use python lists instead of > compiling many different versions of classes which look more or less > like python lists. eg, IMP.Particles() is equivalent to [], as is > IMP.Vector3Ds(). I have experimented with this and found a few > effects: > - this makes compilation of the python wrappers of imp much, much > faster (it is now quite pleasant to build IMP on my laptop, where as > before it took hours) > - overloaded functions where the only way to tell the functions > apart is the type of the collection are not supported. There aren't > too many such cases in IMP. This is, in most cases, simply a > limitation of SWIG and so we can work around it in important cases > if desired. SWIG produces a warning so we will know where it is > happening. > - passing value types (eg IMP.Particles()) by pointer or storing > pointers to passed value types would not work on calls from python. > I consider this a feature as such things are bad programming > practices.
Daniel - can you please elaborate what is the meaning of this change from the c++ side ?
> > > Second, there is a bit of a mess with the containers in terms of > informing them about the model (since in increasing number of them > need to register score states with the model). I propose that all > containers need to get the model as part of their constructor. The > main effect would be that the default constructors of > List*Containers take a model (instead of being the default > constructor). This would simplify a lot of things and make caching > much easier in the containers which do not currently do it. no problems here. > > Comments? Objections? > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev