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

[Dan Mueller]

Hi Gaëtan,

Thanks for your work with WrapITK. Indeed, I still intend to merge
automated C# wrapping into this new WrapITK. On a side note: I guess
it needs a new name now? "Unstable WrapITK" is no longer valid :P

Unfortunately this task (WrapITK C# support) is third on the my todo
list: behind some enhancements to Fast Marching, and alternative image
memory models (i.e. sliced-contiguous and random/sparse images). I
expect to start work on WrapITK C# in a few months. I'll touch base
with you then.

Regards, Dan

2009/1/28 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
> Hi Dan,
>
> I'm resurrecting an old subject :-)
>
> Le 8 juil. 08 à 16:04, Gaëtan Lehmann a écrit :
>
>>
>> Le 8 juil. 08 à 08:07, Dan Mueller a écrit :
>>
>>>
>>>
>>> 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.
>>
>
> Finally, I did it. WrapITK can now build without cable swig and swig.
> The Doc language - not much a language, so I'm thinking to rename "language"
> in "target" or something like that - can be built without them for example.
>
> http://code.google.com/p/wrapitk/source/detail?r=191
>
>>
>>>
>>>
>>> 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.
>
> I think that's the place where we should begin to work, if you're still
> interested in merging the two projects.
>
>>
>>>
>>>
>>> 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.
>
> Things are fixed on that side - all my contributions build both on wrapitk
> stable and unstable for example.
>
> 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
>
>