On Thursday February 10 2011 09:36:18 Anders Logg wrote: > On Thu, Feb 10, 2011 at 06:19:59AM -0800, Johan Hake wrote: > > On Thursday February 10 2011 02:11:42 Johannes Ring wrote: > > > 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-pac > > > >> >>>>>>>> kage s/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. > > > > It's on my todo list > > Great. So the conclusion is we move to SWIG 2.0 after the release of > Ubuntu 11.04?
And after DOLFIN 0.9.10 I would say. I am pretty loaded for the moment... Johan > -- > Anders > > > Johan > > > > > 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. > > > > > > _______________________________________________ > > > 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
