← Back to team overview

dolfin team mailing list archive

Re: Hierarchical wrapping troubles

 

On Wednesday February 2 2011 02:31:02 Johannes Ring wrote:
> On Wed, Feb 2, 2011 at 12:39 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Tue, Feb 01, 2011 at 11:35:28PM +0000, Garth N. Wells wrote:
> >> On 01/02/11 23:19, Johan Hake wrote:
> >> > On Tuesday February 1 2011 15:14:21 Anders Logg wrote:
> >> >> On Tue, Feb 01, 2011 at 03:12:05PM -0800, Johan Hake wrote:
> >> >>> On Tuesday February 1 2011 14:53:55 Anders Logg wrote:
> >> >>>> Something seems to go wrong with the Hierarchical Python wrappers.
> >> >>>> 
> >> >>>> C++ program:
> >> >>>>   UnitSquare mesh(3, 3);
> >> >>>>   mesh._debug();
> >> >>>> 
> >> >>>> Output:
> >> >>>> 
> >> >>>> Debugging hierarchical object.
> >> >>>> 
> >> >>>>   has_parent()    = 0
> >> >>>>   _parent.get()   = 0
> >> >>>>   _parent.count() = 0
> >> >>>>   has_child()     = 0
> >> >>>>   _child.get()    = 0
> >> >>>>   _child.count()  = 0
> >> >>>> 
> >> >>>> Debugging hierarchical object.
> >> >>>> 
> >> >>>>   has_parent()    = 0
> >> >>>>   _parent.get()   = 0
> >> >>>>   _parent.count() = 0
> >> >>>>   has_child()     = 0
> >> >>>>   _child.get()    = 0
> >> >>>>   _child.count()  = 0
> >> >>>> 
> >> >>>> Python program:
> >> >>>>   mesh = UnitSquare(3, 3)
> >> >>>>   mesh._debug()
> >> >>>> 
> >> >>>> Debugging hierarchical object.
> >> >>>> 
> >> >>>>   has_parent()    = 0
> >> >>>>   _parent.get()   = 0
> >> >>>>   _parent.count() = 0
> >> >>>>   has_child()     = 0
> >> >>>>   _child.get()    = 0
> >> >>>>   _child.count()  = 0
> >> >>>> 
> >> >>>> Debugging hierarchical object.
> >> >>>> 
> >> >>>>   has_parent()    = 1
> >> >>>>   _parent.get()   = cbd47290
> >> >>>>   _parent.count() = -878438560
> >> >>>>   has_child()     = 1
> >> >>>>   _child.get()    = cbd47290
> >> >>>>   _child.count()  = -878438560
> >> >>>> 
> >> >>>> The first call to Hierarchical::_debug is made from the constructor
> >> >>>> of Hierarchical and is correct in both C++ and Python, but then
> >> >>>> the Python object seems to lose contact with the reality.
> >> >>> 
> >> >>> Yes quite so...
> >> >>> 
> >> >>> I changed locally to swig 2.0 and the problem went away. shared_ptr
> >> >>> support has been rewritten in 2.0. I might be able to hack the
> >> >>> interface of Hierarchical in a similar manner as I did for
> >> >>> Variables. Just implementing the interface again in the C++ layer.
> >> >>> 
> >> >>> But I am not sure. The shared_ptr part of the SWIG interface starts
> >> >>> to be quite complex now with supporting SWIG version 1.3.37 to
> >> >>> 1.3.40 and 2.0
> >> >>> 
> >> >>> Maybe we should force SWIG 2.0?
> >> >> 
> >> >> Is that possible? It's not in Ubuntu yet, or is it?
> >> 
> >> It's in 11.04
> >> 
> >> Swig is super easy to install.
> > 
> > If we can include SWIG installation in Dorsal and Johannes is able to
> > make packages that rely on SWIG 2.0 then we might as well move to 2.0
> > to save us (mainly Johan) a lot of trouble.
> 
> I tried to build UFC and DOLFIN in Debian unstable with the swig2.0
> package (same package as in Ubuntu 11.04). One problem is that this
> package does not contain /usr/bin/swig but only /usr/bin/swig2.0. I
> fixed this by setting -DSWIG_EXECUTABLE:FILEPATH=/usr/bin/swig2.0 when
> building UFC and DOLFIN, but running the poisson Python demo failed
> because Instant was unable to find swig. The reason for naming the
> binary "swig2.0" is probably that SWIG 1.3 is still the default in
> Debian (and Ubuntu).

Ok then it might be difficult. We could maybe add some funcitonality to 
instant to define what executable it shold look for?

Johan

> Johannes
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp



Follow ups

References