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

Wed Jul 9 07:48:26 EDT 2008

2008/7/9 Ali - <saveez at hotmail.com>:
> If you choose the non-SWIG approach, the design will be less dynamic and in
> the case WrapITK core design is changes, you have to maintain your code to
> get synchronised. To be honest, once you study the python or java SWIG code
> in WrapITK, i think it shouldn't take more than a few days to implement the
> .NET wrapper based on SWIG. When the SWIG code generator does offer .NET
> language binding, adding yet another code generator will be a duplication.

I aware of the capabilities SWIG. As I discussed in a previous email
in this thread, SWIG uses P/Invoke to wrap C#. I don't want to use
P/Invoke; hence my need to branch WrapITK to form ManagedITK.

If WrapITK will be remaining SWIG only, then I think ManagedITK will
be remaining a separate project...

> WrapITK is not fully factorised yet, once it is fully factorised, perhaps
> one or two pages of a SWIG interface file will be enough for a new language.
>
>
> -Ali
>
>
>>
>> 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!
>
> ________________________________
> Get Hotmail on your Mobile! Try it Now!