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

[Dan Mueller]

Hi Gaetan,

(FYI: I have moved this discussion to the developers list).

Firstly, thanks for your work on WrapITK. As you have surmised, at
some point last year I took WrapITK and mangled it for my own
purposes. There *are* a lot of similarities between the two projects,
however there are also a number of differences (the biggest being the
code generation as you have pointed out). I have a number of concerns
regarding the integration of ManagedITK with the new WrapITK:

1. Code generation.
To make my feelings clear, I do not want to use SWIG for the code
generation of ManagedITK. SWIG C# code generation uses what is called
P/Invoke, which is a lot less flexible than the "It Just Works"
mechanism currently employed by ManagedITK. That said, if the new
WrapITK will support other code generation mechanisms, then I do not
foresee any issues moving the code generation make files to
Languages/ManagedITK.

2. Refactoring.
I have taken a brief look at the new WrapITK. Although you said it was
designed to be reusable for something else than CableSWIG or SWIG, it
seems there is still (significant?) refactoring work for this to
become a reality. For example, it still assumes CableSWIG is required.
As with many ITK developers, I do ITK stuff during my personal time,
and therefore I have limited resources to spend on this particular
project. How much help would you (and other ITK Developers) be
providing to make the new WrapITK truly independent from SWIG? Or have
I misinterpreted things?

3. Wrapped types.
As you pointed out, there are some types wrapped by one project and
not the other. The main reason for this is that type conversion in
ManagedITK (ie. native ImageRegion to "managed" ImageRegion) is
performed manually (see Source/Common/itkManagedTypes.cxx). To support
"complex" (real and imaginary) types for example, a manual mapping
must be made between the native complex object and a managed object.
Therefore, if these two projects come together, I feel there must be a
mechanism to exclude some wrap_*.cmake files for ManagedITK. The same
may be needed for WrapITK, which for example does not (currently)
support mesh filters, and may not be able to in the same way as
ManagedITK does.

4. Module names.
The module names *are* important for ManagedITK -- in the sense that
each module is compiled as a separate *.dll. The Microsoft compiler
can not handle putting all the files into a single dll. As such the
dll names need to be meaningful so that users can intuitively find
their filters. I do not think the WrapITK module names are intuitive.
For example: how do you differentiate which filters are in
"SimpleFilters" versus "Filtering"?

5. Underscore before template definition.
This is not a problem. The underscore can be removed in ManagedITK to
make it the same as WrapITK.

6. Backwards compatibility.
Does WrapITK fall under the same backwards compatibility policy as the
rest of ITK? If so, I'm not sure I would be willing to concede on all
the above points in order for ManagedITK to be integrated with
WrapITK. However, if a middle ground could be found, then I think it
may be possible to move forward.

In summary:
1. It should be possible to move the code generation to the Languages folder.
2. The new WrapITK needs to support wrapper generation without SWIG or
CableSWIG.
3. There needs to be a mechanism to turn some wrapped types off and
on, depending on whether WrapITK or ManagedITK, or other.
4. Module names are a point of contention for me. More discussion is needed.
5. Underscores -- no problem.
6. Backwards compatibility must be a consideration as we plan the next steps.

Cheers, Dan

2008/7/8 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
> 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 :-)
>
> Regards,
>
> 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