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

[Luis Ibanez]

Hi Dan,

The concern about creating temporary directories is
mostly related to keeping things neat in the repository.

One alternative is to use the NAMIC Sandbox (public a
Subversion repository) for performing the integration of
ManagedITK and WrapITK, until it is stable. Then move
the resulting version into ITK.

There are probably many other options...


    Luis


--------------------
Dan Mueller wrote:
> 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
>>>
>>>
>