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

[Ali -]

This is the current design of WrapITK:

[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, but this *will* make the synchronisation a difficult job. 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.

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.

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 :)


-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/