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

[Dan Mueller]

Hi Luis,

1. Release schedule.
Unfortunately I feel the 15th July deadline for ITK 3.8 is too tight.
I have two (2) concerns:
    A. The bureaucratic wheels at my university move very slow. I have
initiated the copyright transfer procedure, but I doubt the issue will
be fully resolved by this date.
    B. I am moving house this weekend and will not have access to the
internet for 1-2 weeks thereafter. As such my communication with ITK
developers during this critical time may be hindered.

Unfortunately, I think it best we aim for ITK 4.0 (unless the release
date has some more give in it).

2. CVS 'temporary' directory
I feel that the new WrapITK -- which will subsume ManagedITK -- will
look very different to the existing ManagedITK (different directory
structure, shared cmake scripts, etc.). If we stick to the option of
including ManagedITK "as is" before the refactoring, I don't think
there is much we can do to prevent the 'temporary' non-deletable
directory. What is the actual concern regarding this temporary
directory? Just keeping things neat? Disk space?

Regards, Dan


2008/7/8 Luis Ibanez <luis.ibanez at kitware.com>:
>
> 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
>>
>>
>