[Insight-developers] [Insight-users] INSIGHT JOURNAL: managedITK (ITK 3.8 ?) & Release Schedule

Wed Jul 9 10:00:48 EDT 2008

Le 9 juil. 08 à 15:18, Ali - a écrit :

>
> This is the current design of WrapITK:

(The cmake part is was not there)

[cmake code generator]
|
> [c/c++ source]
> |
> (cable)
> |
> [xml, idx]
> |
> (igenerator)
> |
> [swig interfaces]
> |
> (swig)
> |___________________
> |                   |
> [languages 1]   [language 2]   ....
>
>
> Of course one is free to create a new branch from the [xml, idx]  
> point starting with another code generator

Dan's part would start directly from the cmake part — it doesn't need  
the xml and idx stuff

> , but this *will* make the synchronisation a difficult job.

I can't see why it would be harder — it would simply be another branch.

> For instance, we recently got rid of wrapping ITK c++ smart  
> pointers, which decreased code generation and compilation time, as  
> well as the binary size, almost down to half. Instead, the smart  
> pointer stuff were implemented in swig. If we have another branch of  
> code generator from the [xml, idx] point, that code generator should  
> also implement the smart pointer feature.

Dan has already done that IIRC, in a different way than we do — he's  
not using swig at all

>
> I was not aware of the fact that the swig wrapper for c# has some  
> undesired issues as Dan pointed out. If such feature is lacked in  
> swig, you may want to consider implementing it in swig rather than  
> starting yet another code generator. My personal point of view is  
> that when there exist well-established projects such as swig,  
> smaller code generators may go sooner or later obsolete. CableSwig  
> is an example for this. Another example is the VTK language wrappers  
> which were introduces probably before the swig project, the wrapper  
> is not very tidy, and at least, the java part has many memory leek  
> problems.

I don't think that Dan has done a new wrapping system — I think he  
only use the .Net one.

>
> While it is well possible, as Gaetan mentioned, I would not  
> recommend to invest on another code generator branch at the [xml,  
> idx] point. At the end of the day, this is an open source project  
> and anyone who doesn't mind taking the shortest path is welcome to  
> add any branches at any points :)

There is not invest to do on that side — Dan doesn't use xml and idx  
stuff, and ManagedITK already work!

Gaëtan

>
>
>
> -Ali
>
>
>>
>> Le 9 juil. 08 à 13:05, Dan Mueller a écrit :
>>
>>> Hi Ali, Gaëtan,
>>>
>>> I am hearing two different things:
>>>   Gaëtan: "Yes, no swig on manageditk side is fine."
>>>   Ali: "Any integration to WrapITK will required the use of
>>> standard SWIG."
>>>
>>> Which is it? Thanks for any clarification.
>>>
>>
>> Definitively "Yes, no swig on manageditk side is fine."
>> Ali, I'm afraid I have to disagree with most of what you said here.
>>
>>> In the short term I guess it does not matter -- ManagedITK will be
>>> integrated into version 3.8/4.0 "as is".
>>>
>>> Regards, Dan
>>>
>>> 2008/7/9 Ali - :
>>>> Hi all,
>>>>
>>>> I am not sure what the plan for integration of ManagedITK into
>>>> WrapITK will
>>>> be. Any integration to WrapITK will required the use of standard
>>>> SWIG,
>>>> WrapITK has been recently re-designed to be as standard SWIG-
>>>> oriented as
>>>> possible and the work on this will be carried on.
>>
>> That's wrong. WrapITK as be redesigned to be oriented on no specific
>> method. It has been separated in two main parts:
>> - the declaration of instantiated types (the Modules directory)
>> - the use of those declaration (the Languages directory)
>>
>> Several languages are implemented with swig, so some work as been
>> factorized on that point, but WrapITK is really not swig oriented.
>>
>>>> The ultimate goal of this
>>>> is to provide a framework where any developer with SWIG knowledge
>>>> can add
>>>> the language binding of interest with the minimum interaction with
>>>> the
>>>> ITK-specific part.
>>>>
>>
>> Yes, I agree on that — but it doesn't mean that wrapitk is swig
>> specific.
>>
>>>> In the case that ManagedITK uses a custom code generator for .NET
>>>> binding,
>>>> unfortunately, that code generator cannot be integrated into
>>>> WrapITK. Due to
>>>> this, I see this 'integration' more like introducing a new language
>>>> plugin
>>>> for WrapITK, which could possibly require work from scratch.
>>
>> Again, that's not true. One is free to implement a code generator in
>> wrapitk as he want, and especially without swig.
>> By the way, the swig part is implemented with the same mechanisms  
>> than
>> what Dan would use to merge wrapitk and manageditk.
>> As Dan noticed, at this time, wrapitk still require cableswig and
>> swig, but that something I will fix as soon as I have a little time  
>> to
>> do it (and I'm quite sure it won't be longer than a few hours).
>>
>>>>
>>>>
>>>> The main reason behind this forced pattern is to have a  
>>>> synchronised
>>>> language binding model. For instance, in long term we are
>>>> interested in the
>>>> use of explicit instantiation which is a common factor for wrapping
>>>> and
>>>> independent of the language of choice. Once this is implemented,
>>>> all the
>>>> languages benefit the improvements automatically. However, the use
>>>> of custom
>>>> code generators will be an obstacle for this design.
>>>>
>>
>> There is nothing forced, and managed part would also benefit of the
>> explicit instantiation part — there is no obstacle for that.
>>
>>>> Gaetan: Do we have any plans for releasing the recently improved
>>>> WrapITK in
>>>> 3.8? There are many polishings to be done and I am currently very
>>>> busy for
>>>> that.
>>>>
>>
>> I don't think we can put wrapitk as is in ITK, because igenerator is
>> coded in python, and because TCL part is not made.
>>
>> But we should think about making a new revision to the insight  
>> journal.
>>
>> Gaëtan
>>
>>>>
>>>> -Ali
>>
> _________________________________________________________________
> Find the best and worst places on the planet
> http://clk.atdmt.com/UKM/go/101719807/direct/01/

-- 
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  http://www.mandriva.org
http://www.itk.org  http://www.clavier-dvorak.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20080709/47dbcdde/attachment.pgp>