On Thu, Feb 10, 2011 at 10:48 AM, Anders Logg <[email protected]> wrote: > On Thu, Feb 10, 2011 at 09:43:16AM +0000, Garth N. Wells wrote: >> >> >> On 10/02/11 09:39, Anders Logg wrote: >> > On Thu, Feb 10, 2011 at 09:22:39AM +0000, Garth N. Wells wrote: >> >> >> >> >> >> On 10/02/11 09:19, Anders Logg wrote: >> >>> On Thu, Feb 10, 2011 at 09:11:26AM +0000, Garth N. Wells wrote: >> >>>> >> >>>> >> >>>> On 10/02/11 09:09, Anders Logg wrote: >> >>>>> On Thu, Feb 10, 2011 at 08:48:55AM +0000, Garth N. Wells wrote: >> >>>>>> >> >>>>>> >> >>>>>> On 10/02/11 07:38, Johan Hake wrote: >> >>>>>>> On Wednesday February 9 2011 23:32:55 Anders Logg wrote: >> >>>>>>>> On Wed, Feb 09, 2011 at 04:40:19PM -0800, Johan Hake wrote: >> >>>>>>>>> Nice fix! >> >>>>>>>>> >> >>>>>>>>> I thought we needed to introduce shared_ptr versions of >> >>>>>>>>> refinements call. >> >>>>>>>>> But I realise this fix only work for SWIG 2.0. As all >> >>>>>>>>> shared_ptr_foo are >> >>>>>>>>> renamed to foo. >> >>>>>>>>> >> >>>>>>>>> We need to add an extra layer of %rename/%ignore for the SWIG 2.0 >> >>>>>>>>> case. >> >>>>>>>>> >> >>>>>>>>> I can do this. But again it introduces another layer of complexity >> >>>>>>>>> you >> >>>>>>>>> mention in your other post. >> >>>>>>>> >> >>>>>>>> That didn't seem to work. The buildbot now says: >> >>>>>>>> >> >>>>>>>> File >> >>>>>>>> "/home/fenicsslave/jhbuildbot/fenics/lib/python2.6/site-packages/dolfin/mes >> >>>>>>>> h/refine.py", line 30, in refine >> >>>>>>>> return mesh.child_shared_ptr() >> >>>>>>>> TypeError: in method 'HierarchicalMesh_child_shared_ptr', argument 1 >> >>>>>>>> of type 'dolfin::Hierarchical< dolfin::Mesh > *' >> >>>>>>>> >> >>>>>>>> What does that mean? mesh.child_shared_ptr() should return a >> >>>>>>>> shared_ptr to an object of class T (in this case Mesh), which it >> >>>>>>>> does >> >>>>>>>> in the C++ interface. It should not return a pointer to an object of >> >>>>>>>> class Hierarchical<T>. >> >>>>>>> >> >>>>>>> It is related to the "fix" Garth introduced. He used foo_shared_ptr, >> >>>>>>> but that >> >>>>>>> one does not work for SWIG < 2.0. These methods are now ignored or >> >>>>>>> renamed for >> >>>>>>> all SWIG versions, and everything should be well and fine for both >> >>>>>>> versions of >> >>>>>>> SWIG. >> >>>>>>> >> >>>>>> >> >>>>>> I don't think that this is really a fix. The Python refine should >> >>>>>> return >> >>>>>> a shared_ptr, otherwise we can have problems with things going out of >> >>>>>> scope. The underlying problem is SWIG not wrapping the Mesh >> >>>>>> shared_ptrs >> >>>>>> properly. >> >>>>> >> >>>>> But isn't that exactly what's happening now? The C++ shared_ptr_foo() >> >>>>> functions are renamed to foo() so when you call foo() in Python you >> >>>>> get the shared_ptr. >> >>>>> >> >>>> >> >>>> That was my fix, which was reverted. Looks to me like a reference is >> >>>> returned. >> >>> >> >>> From site-packages/dolfin/mesh/refine.py: >> >>> >> >>> return mesh.child() >> >>> >> >>> From dolfin/swig/shared_ptr_classes.i: >> >>> >> >>> boost::shared_ptr<DERIVED_TYPE> child() >> >>> { return self->child_shared_ptr(); } >> >>> >> >>> So when mesh.child() is called in refine.py, it really returns >> >>> mesh.child_shared_ptr(). >> >>> >> >> >> >> OK. >> >> >> >> It' pretty confusing having stuff dotted around in different files. >> >> We'll be able to remove it when we moving to SWIG 2. >> > >> > Is it the case that it won't be in Ubuntu 11.04 and we will have to >> > wait until 11.10? >> > >> >> It will be in 11.04, but the executable will be called swig2.0. >> >> The sooner we can move, the better. Saves maintaining and testing double >> SWIG code. > > Agree. The new name of the executable shouldn't be a problem. > > Isn't it just a matter of (i) some fixes to the buildsystem for DOLFIN > (which I'm sure Johannes can handle) and (ii) some fixes to Instant > and the UFC wrapper utils?
It is only Instant that must be fixed. Johannes >> > And what's the status of the Python Trilinos wrappers? Do we need >> > them? I guess there's a small chance that Trilinos will move to 2.0 >> > any time soon. >> > >> >> The next PyTrilinos release will require SWIG 2.0. It should also fix >> the MPI finalisation issues. > > ok. > > -- > Anders > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
