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

Gaëtan Lehmann gaetan.lehmann at jouy.inra.fr
Wed Jul 9 08:45:58 EDT 2008 

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 - <saveez at hotmail.com>:
>> 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
>>
>>
>>
>> ________________________________
>>> Date: Tue, 8 Jul 2008 15:07:00 -0400
>>> From: luis.ibanez at kitware.com
>>> To: gaetan.lehmann at jouy.inra.fr
>>> CC: dan.muel at gmail.com; saveez at hotmail.com; insight-developers at itk.org
>>> Subject: Re: [Insight-users] INSIGHT JOURNAL: managedITK (ITK  
>>> 3.8 ?) &
>>> Release Schedule.
>>>
>>>
>>> Dan, Gaetan,
>>>
>>> It is great that you two have found common ground
>>> on how to integrate ManagedITK with WrapITK.
>>>
>>> Following your discussion, it seems that the current
>>> consensus is:
>>>
>>> 1) Introduce ManagedITK in Insight/Wrapping
>>>
>>> 2) Once the code is there, rework ManagedITK
>>> and WrapITK in order to factorize the common
>>> infrastructure
>>>
>>>
>>> If I got this right, then the immediate question at
>>> this point is:
>>>
>>>
>>> Do we do (1) before releasing ITK 3.8 ?
>>>
>>>
>>> and to put this in context, the release schedule
>>> http://www.itk.org/Wiki/ITK_Release_Schedule#Release_3.8_Schedule
>>>
>>> had a feature freeze expected at July 1st (which we already  
>>> passed...).
>>>
>>> Since we are running behind and we are still moving contributions  
>>> from
>>> the Insight Journal into the Code/Review directory, the suggested  
>>> freeze
>>> time would be *July 15th*, and we will still keep the date of July  
>>> 30th
>>> for releasing ITK 3.8.
>>>
>>>
>>> This translates into:
>>>
>>>
>>> Do we want to introduce ManagedITK in
>>> Insight/Wrapping before Monday July 14th ?
>>>
>>>
>>> Note that ManagedITK is too large for making it pass
>>> first through the Review directory, so we will have
>>> to put it directly in Insight/Wrapping and expose it
>>> conditionally under CMake variables.
>>>
>>> One concern with this move is whether you anticipate
>>> that the subdirectory structure of ManageITK will
>>> change when we move into factorizing common pieces
>>> with WrapITK.
>>>
>>> As you know, the limitation of CVS is that we can
>>> never fully get rid of subdirectories. Therefore,
>>> if we introduce ManagedITK with a 'temporary'
>>> sub-directory structure, that tree, will somehow
>>> become permanent.
>>>
>>>
>>> Please let us know what will be your preference
>>> between:
>>>
>>>
>>> a) ManagedITK by ITK 3.8 ?
>>> b) ManagedITK by ITK 4.0 ?
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>> Luis
>>>
>>>
>>>
>>> -----------------------
>>> Gaëtan Lehmann wrote:
>>>>
>>>> Le 8 juil. 08 à 08:07, Dan Mueller a écrit :
>>>>
>>>>> 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.
>>>>
>>>>
>>>> Yes, no swig on manageditk side is fine.
>>>>
>>>>>
>>>>>
>>>>> 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?
>>>>
>>>>
>>>> There are only a few things to do to not require cableswig and swig
>>>> anymore.
>>>> It hasn't been done yet, because both python and java requires  
>>>> it, but
>>>> all the internal code is well separated. I can complete that part
>>>> alone, as soon as I found a little time to work on wrapitk.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> Meshes are not supported because I know nearly nothing about  
>>>> them, and
>>>> so I was not able to choose the relevant types to wrap.
>>>> Meshes support would definitely be a positive impact of  
>>>> manageditk on
>>>> wrapitk.
>>>>
>>>> Excluding some stuff in one language or the other is already
>>>> implemented at the module level. It can be refined to fit all of  
>>>> our
>>>> needs.
>>>>
>>>>>
>>>>>
>>>>> 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"?
>>>>
>>>>
>>>> I don't differentiate them. I've never been pleased by the current
>>>> module names.
>>>> There is for sure a big place for discussions on this side.
>>>>
>>>>>
>>>>> 5. Underscore before template definition.
>>>>> This is not a problem. The underscore can be removed in  
>>>>> ManagedITK to
>>>>> make it the same as WrapITK.
>>>>
>>>>
>>>> Or they can be used in wrapitk — it would make no difference in  
>>>> python,
>>>> and can make things much clear in java and tcl.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> WrapITK is marked as experimental, so I don't think it fall under  
>>>> the
>>>> ITK's backward policy.
>>>> That being said, I tried to make things as backward compatible as
>>>> possible in python, with deprecation warnings when required (and
>>>> possible).
>>>>
>>>> Currently, external projects may need some small changes to build  
>>>> with
>>>> wrapitk unstable. Python code made for wrapitk stable runs without
>>>> changes on wrapitk unstable, but produce some deprecation warnings.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> No major problem so — nice :-)
>>>>
>>>> Gaëtan
>>>>
>>>>
>>>>>
>>>>>
>>>>> 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
>>>>
>>>>
>>
>> ________________________________
>> Find out how to make Messenger your very own TV! Try it Now!

-- 
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/8656c7b9/attachment.pgp>

More information about the Insight-developers mailing list