[Insight-users] INSIGHT JOURNAL: managedITK (ITK 3.8 ?)

[Gaëtan Lehmann]

Le 8 juil. 08 à 00:35, Gaëtan Lehmann a écrit :

>
> Le 7 juil. 08 à 22:15, Gaëtan Lehmann a écrit :
>
>>
>>>
>>> Is there material that can be merged/shared with the other
>>> wrappings ?
>>
>> Dan,
>>
>> I wanted to ask you the same question — Luis did it first :-)
>>
>> Despite you said that WrapITK is a "totally separate project",  
>> ManagedITK has reused lot of code from WrapITK. Actually, they  
>> still share a lot of code — a quick look at   
>> managed_itkCastImageFilter.cmake, from ManagedITK, and  
>> wrap_itkCastImageFilter.cmake would be quite convincing: they even  
>> share the comments :-)
>> They are not all as similar of course, so the question is:
>>
>> Would it be possible to avoid the current code duplication?
>>
>> The reason why I wanted to ask that question now, is because  
>> WrapITK has made great progress in the last weeks. Some times ago,  
>> I began to work on a pure swig implementation of WrapITK. The work  
>> was left unchanged for a quite long time, but recently, Ali decided  
>> to work on the java part. His work convinced me to work again on  
>> python part. At this time, wrapitk unstable is nearly completed in  
>> python — I already began to use it for real image analysis task, to  
>> benefit of the numerous improvements — and Ali is using java part  
>> on his side. The code is available at:
>>
>> http://code.google.com/p/wrapitk/source
>>
>> In WrapITK unstable, I took care to completely separe the type  
>> declarations — in the wrap_*.cmake — and the language specific  
>> code. The goal is to make all that hard job of defining template  
>> parameters for type instantiation fully reusable for something else  
>> than wrapping with cableswig or swig. The examples I had in mind  
>> were:
>> * wrapping python with PyBoost
>> * ExplicitITK
>> * ManagedITK
>>
>> If you agree, I would be pleased to try to see with you a way to  
>> merge ManagedITK and WrapITK.
>
>
> After a bit of reading of ManagedITK code, I'm quite convinced that  
> there is some factorizing to do, and that it would benefit to both  
> projects.
> The big differences I see are:
> * the code generator, of course very specific of ManagedITK
> * the Common directory, which is specific of ManagedITK
> * the wrapped types — some types available in WrapITK are not in  
> ManagedITK (complex types for example) and some in ManagedITK are  
> not in WrapITK (RGBA for example). It would be nice for both to have  
> them :-)
> * the modules names
> * the managed property definitions
> * the underscore before the template parameters in the instantiated  
> name
> * the external projects implementation
>
> Specific code is quite well separated, and some of the code specific  
> of one project would benefit to the other.
> The only specific code mixed with generic code at this time is the  
> managed property definitions. I do think they can be quite nicely  
> moved outside the generic files, in the /Languages/Managed/ 
> Properties/ for example (to reuse the wrapitk directory layout).  
> Then, when END_WRAP_CLASS() is called in the /Modules/*/wrap_*.cmake  
> files, the content of corresponding managed_*.cmake file can be read  
> (if it exists), to define the properties for the current classes.
> That way, all generic code can be common to both projects, and  
> specific code is localized in a single subdirectory of the / 
> Languages directory.
>
> The module names may be a problem depending on their importance in  
> ManagedITK.
>
> The rest looks much like details — underscore in name can be used in  
> wrapitk or can be manageditk specific without problem, and external  
> project shouldn't be that difficult to implement in one way or the  
> other.
>
> Do you think this kind of organization for managed properties would  
> fit your needs?
> There are surely many other problems — I hope they are not too  
> difficult :-)
>

I'm re-reading my mails, and I see they can have been interpreted as  
some argumentations against the integration of ManagedITK in ITK.

   That's really not the case, for several reasons:

   * WrapITK use a swig interface generator coded in *python*, so even  
if one wants only the java part, he has to install python to build  
WrapITK. This generator must be recoded in C/C++, probably by reusing  
the existing code in cableswig. Obviously, it will not be done soon.

   * Even if both project can share lot of code, it would take time to  
have things done properly

I would prefer see ManagedITK integrated in ITK, and have it marked as  
experimental feature like WrapITK. That way, ManagedITK can be  
validated on more systems, and many users can use it in an easier way.  
Dan would get more feedbacks, and probably identify some lacks or some  
new features to add.

During this time, we could try to merge WrapITK and ManagedITK in  
another repository, as the unstable (development) version.

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  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/pipermail/insight-users/attachments/20080708/25409bd0/attachment-0001.pgp>