← Back to team overview

dolfin team mailing list archive

Re: SWIG 2.0.2

 


On 10/03/11 19:29, Johan Hake wrote:
> 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?
> 

I'm pretty sure. Everything was breaking, so I'm just trying to get back
to a working version from which I can test in isolation.

Garth

> 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



Follow ups

References