[Insight-developers] Re: a problem with cable swig cvs

Gaëtan Lehmann gaetan.lehmann at jouy.inra.fr
Mon Nov 19 11:11:14 EST 2007


Le 19 nov. 07 à 17:07, Gaëtan Lehmann a écrit :

>
> Le 19 nov. 07 à 16:23, Brad King a écrit :
>
>> Gaëtan Lehmann wrote:
>>> I see that you have added the gcc 4.2 support in cableswig cvs.  
>>> That's
>>> great :-)
>>> I'll test it soon.
>>>
>>> However, I noticed a new problem with cableswig cvs. The python  
>>> typemaps
>>> are broken, I think because of a very simple problem: the numbers  
>>> in the
>>> template name get an additionnal "u" compared to the previous  
>>> version.
>>> It seem to break the comparison of types produced by the swig
>>> "$descritor()" command.
>>>
>>> For example, itk::Image< unsigned short, 3 > is now translated in:
>>>
>>>   SWIGTYPE_p_itk__ImageTunsigned_short_3u_t
>>>
>>> but it was:
>>>
>>>   SWIGTYPE_p_itk__ImageTunsigned_short_3_t
>>>
>>> with cableswig 3.4
>>>
>>> The .xml files also have that additional "u" (as well as the .idx
>>> files), so it seem that this change in the behavior comes from  
>>> gccxml.
>>>
>>>
>>> I'm not sure what is the best way to proceed: restore the previous
>>> behavior in gccxml, or patch cableswig to make it produce that
>>> additionnal "u", as gccxml does?
>>
>> This change came from GCC 4.2's internals.  When specifying an  
>> unsigned
>> integer literal it now correctly gives it the 'u' suffix to make the
>> literal the correct type.  The behavior from gccxml is not wrong.
>>
>> The question is why does this change break swig.  It should always  
>> see
>> the name with the 'u' in place now.  Can you send an example python
>> script that does not work with the new wrappers?
>>
>
> It only breaks the typemaps. The rest of the code is ok.
> I think that's because, when writting a typemap like
>
>
> %typemap(out) itk::Image< unsigned char,2 > * {
>   <snip>
> }
>
> the string "itk::Image< unsigned char,2 >" is not matched with the  
> one from gccxml: "itk::Image< unsigned char,2u >"


I have just confirmed that behavior, by manually adding the u in the  
typemap declaration:

%typemap(out) itk::Image< unsigned char,2u > * {
   <snip>
}

The typemaps are working as they should in that case.

Gaëtan


-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?=
Url : http://www.itk.org/mailman/private/insight-developers/attachments/20071119/8fa203e0/PGP.pgp


More information about the Insight-developers mailing list