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

[Dan Mueller]

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.

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. 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> -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!