dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Thursday March 10 2011 11:21:51 Garth N. Wells wrote:
> On 10/03/11 19:17, Johan Hake wrote:
> > On Thursday March 10 2011 11:10:26 Garth N. Wells wrote:
> >> On 10/03/11 19:07, Johan Hake wrote:
> >>> This should be fixed now. It looked like it only was a bunch of
> >>> warnings. I just suppressed them.
> >>> 
> >>> We might want to eventually make Variable a shared_ptr stored class,
> >>> which will then remove almost all warnings. But then we need to turn
> >>> all the not shared_ptr stored derived classes of Variable into
> >>> shared_ptr stored classes. (Not sure they are that many though...)
> >> 
> >> I've added them all.
> > 
> > Ok that might be what we want eventually. If you have completely added
> > all of these classes we can removed
> > 
> >   IMPLEMENT_VARIABLE_INTERFACE
> > 
> > for swig version >= 2.0.
> > 
> >>> I did not have any trouble with the VertexFunction
> >> 
> >> Turns out that the real problem is with uint. SWIG gets confused with
> >> shared_ptr and templates instaniated with dolfin::uint and unsigned int.
> > 
> > Yes this corresponds to my experiences. I found that I cannot use
> > typedefs for declarations of shared_ptr classes. Therfore I have insane
> > long shared_ptr declarations for the two boost matrix classes.
> 
> The problem is that that I use 'unsigned int' in the shared_ptr
> declaration, but then SWIG gets confused if dolfin:uint is used in the
> DOLFIN interface, i.e. MeshFunction<uint>. Changing to 'unsigned int' on
> the DOLFIN C++ side, things go smoother.

Ok, I cannot recall having this particular problem. It looks like the 
shared_ptr features in SWIG needs better type recognition.

Are you sure you do not just have to change:

  DECLARE_MESHFUNCTION(MESHFUNCTION,dolfin::uint,UInt)

to 

  DECLARE_MESHFUNCTION(MESHFUNCTION,unsigned int,UInt)

in mesh_post.i?

Johan
  

> Garth
> 
> > Johan
> > 
> >> Garth
> >> 
> >>> Johan
> >>> 
> >>> On Thursday March 10 2011 08:33:50 Garth N. Wells wrote:
> >>>> On 10/03/11 15:57, Johan Hake wrote:
> >>>>> On Thursday March 10 2011 07:42:13 Garth N. Wells wrote:
> >>>>>> On 10/03/11 15:40, Johan Hake wrote:
> >>>>>>> On Thursday March 10 2011 04:47:13 Garth N. Wells wrote:
> >>>>>>>> The DOLFIN Python interface won't build with SWIG 2.0.2. This
> >>>>>>>> issue is that SWIG 2.0.2 demands that if a shared pointer is
> >>>>>>>> declared for a class, then all classes in the class hierarchy
> >>>>>>>> must be declared as shared pointers.
> >>>>>>> 
> >>>>>>> This has always been the case. It might be that we previously got
> >>>>>>> away with it.
> >>>>>>> 
> >>>>>>>> I've done this, but there are two sticking points:
> >>>>>>>>  - Unit tests fail for MeshFunctions. I expect that this is
> >>>>>>>>  related to
> >>>>>>>> 
> >>>>>>>> the SWIG magic that has been implemented for templated
> >>>>>>>> MeshFunctions.
> >>>>>>> 
> >>>>>>> Has something changed for MeshFunctions?
> >>>>>> 
> >>>>>> I'm digging more, and it seems that VertexFunction is the culprit.
> >>>>>> The other named MeshFunctions seem ok.
> >>>>>> 
> >>>>>>>> - SWIG reports:
> >>>>>>>>   Warning 520: Base class 'ufc::function' of 'Foo' is not
> >>>>>>>>   similarly marked as a smart pointer.
> >>>>>>>> 
> >>>>>>>> I don't understand this because I added
> >>>>>>>> '%shared_ptr(ufc::function)' to UFC.
> >>>>>>> 
> >>>>>>> It looks like we need to include
> >>>>>>> 
> >>>>>>>   %shared_ptr(ufc::function)
> >>>>>>> 
> >>>>>>> in shared_ptr_classes.i too. We already have:
> >>>>>>>   %shared_ptr(ufc::form)
> >>>>>> 
> >>>>>> I tried that, but have looked in much depth because I got stuck with
> >>>>>> the MeshFunctions.
> >>>>> 
> >>>>> Ok, I need to merge the swig binary stuff before I can have alook.
> >>>>> Will do that later today.
> >>>> 
> >>>> I'll leave it to you - it seems that almost everything breaks
> >>>> (MeshFunctions are just the start), so some serious SWIG skill is
> >>>> required.
> >>>> 
> >>>> Garth
> >>>> 
> >>>>>>> Johan
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> I will see if a minimal example regenerates the error.
> >>>>>>> 
> >>>>>>>> The almost working branch is at
> >>>>>>>> 
> >>>>>>>>     lp:~dolfin-core/dolfin/wells
> >>>>>>>> 
> >>>>>>>> Garth
> >>>>>>>> 
> >>>>>>>> _______________________________________________
> >>>>>>>> Mailing list: https://launchpad.net/~dolfin
> >>>>>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>>>>>>> Unsubscribe : https://launchpad.net/~dolfin
> >>>>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> Mailing list: https://launchpad.net/~dolfin
> >>>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>>>>> Unsubscribe : https://launchpad.net/~dolfin
> >>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>> 
> >>>> _______________________________________________
> >>>> Mailing list: https://launchpad.net/~dolfin
> >>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>>> Unsubscribe : https://launchpad.net/~dolfin
> >>>> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp