[Insight-developers] using swig to wrap ITK - a summary of the
tcon (and a little much)
Gaëtan Lehmann
gaetan.lehmann at jouy.inra.fr
Sun Nov 19 11:36:09 EST 2006
Le Sun, 19 Nov 2006 05:06:17 +0100, Bill Hoffman
<bill.hoffman at kitware.com> a écrit:
> Gaëtan Lehmann wrote:
>>
>> Hi,
>>
>> Because I'm not sure how much clear I have been during the tcon, here
>> is in short what have been said, and also some things I have forgotten:
>>
>> The current wrapping system:
>> - work on linux and windows with tcl, python and java
>> - known to have problems on mac os (java, python) and solaris (java)
>> - the problems detailed in the WrapITK article, including the small
>> coverage, and inconsistency in wrapped types
>>
>> WrapITK:
>> - 66% of the filters wrapped
>> - tcl, python, java
>> - python typemaps, to be able to use python types rather than simple
>> itk objects,
>> like FixedArray, Index, Size, ...
>> - no typemaps for tcl and java
>> - lacks some custom classes from the previous wrapping system in java
>> and tcl
>> - tested on linux, mac os, and recently, solaris
>> - still lots of problems with windows (especially with java), even if
>> some users have reported using it on that plateform (msvc 7.1 only I
>> think)
>>
>> What will be better with swig:
>> - a lot easier to customize
>> - build with python 2.5
>> - should help to fix problems with very long file names
>> - may help to fix build caused by too big generated c++ files
>> - no need to maintain a branch of swig
>>
>> WrapITK with swig status:
>> - swig is still not able to read ITK headers - they still need to be
>> read by gccxml. The output of gccxml is converted to a swig interface
>> with igenerator.py
>> - python only
>> - made on mac os
>> - all currently wrapped itk classes builds with swig
>> - no customization from the current wrapitk, like typemaps
>> - but some other customizations, like vector support
>> - no cmake configurations support
>> - based on cableidx and pygccxml, so need python to build
>> - problems with cmake dependencies
>> - don't group the groups in a few shared modules
>> - no template with dict interface
>> - require pygccxml cvs and swig cvs because some bugs have been fixed
>> while working on wrapping ITK with swig
>> - only a few changes have been made (to respect the wrapping order
>> imposed by swig) in the WrapITK/Modules directory
>> - roughly, igenerator.py have took about 2 days of work, modifying
>> WrapITK have took 1 day. The bugs above, and a misunderstanding of
>> pygccxml query interface took me one more day
>>
>> What need to be done (* mark for what I need help), in the order I
>> think it should be done:
>> - fix the cmake dependencies *
>> - add the customizations
>> - basic types like std::string, std::exception, ...
>> - typemaps currently in WrapITK
>> - PyCommand, PyImageToImageFilter
>> - fix the dict interface for the templates
>> (at that point, the current python tests should all pass on unix-like
>> systems)
>> - support cmake configurations
>> - make it work on all the systems, and submit daily tests for all
>> those systems on the dashboard *
>> - add support for java (*?)
>> - add support for tcl and the customizations from the current wrapper
>> (TkImageViewer2D, TclCommand, ...) *
>> - more python customizations: __getitem__(), __len__(), __str__(), ...
>> like in the current optional patch
>> - recode igenerator.py in c++ to no more use pygccxml (igenerator.py
>> is attached for the ones who want to have an idea of the work to do) *
>> (the following items are too be done later)
>> - better filter coverage *
>> - support more languages
>> - ...
>>
>> What still remain to decide:
>> - when switch to swig (I think it's clear that the switch is a good
>> thing)
>> - who can/want to work on the the items marked with a "*" in the "What
>> need to be done" section above (any help is welcome for the other items
>> too :-)
>> - how to proceed:
>> - fix WrapITK with cableswig on windows, or switch first to swig,
>> and make sure it builds on windows after that
>> - create a new cvs branch or a new cvs check out
>>
>> Gaetan
>>
> I think that generation of swig .i files is the right way to go. Using
> the cable part of CableSwig it should be easy to do.
> Cable is basically a c++ class description library that can be populated
> by reading the xml output by gccxml.
>
> That said, before moving forward, I think that a key proof of concept
> demo needs to be done with swig.i files.
> By hand or generated, we need to see working swig .i files that wrap
> several classes that inherit from each
> other but are in different libraries. We need to see how the import and
> module stuff will be handled in the swig
> .i files. The demo should be something like this:
>
> module A (classes A B wrapped)
> module B ( classes C D wrapped)
> module C (classes E F wrapped)
>
> With inheritance going across the module boundaries and member functions
> that reference classes
> that go across the module boundaries. (by modules I mean shared
> libraries .so or .dll on windows.)
> Then the example should be done in all the target languages (java, tcl,
> python) on all the target platforms
> (windows, linux, osx). This should not be a complicated thing to do for
> a swig expert. (I am BTW, not
> a swig expert). Once this proof of concept is working, then we can
> worry about auto-generating it with
> gccxml. Before this has been done, and we know it works, it is not
> worth discussing this as an option
> IMO.
Bill,
It works with python !
And better, it works for all the classes currently wrapped in WrapITK, not
only 2 or 3 classes partially wrapped, and even better, it's already
automatically generated !
All the classes are wrapped in different modules, so when I use a median
filter, it imports all the modules with the superclasses.
A example of a test I have just run, with :
import itkImageFileReaderPython
import itkMedianImageFilterPython
reader = itkImageFileReaderPython.itkImageFileReaderIUS2_New()
median = itkMedianImageFilterPython.itkMedianImageFilterIUS2IUS2.New()
median.SetInput(reader.GetOutput())
import itkImageFileWriterPython
writer = itkImageFileWriterPython.itkImageFileWriterIUS2_New()
reader.SetFileName('/Users/glehmann/Desktop/tub.tif')
writer.SetFileName('out.png')
import itkGrayscaleFillholeImageFilterPython
fillhole =
itkGrayscaleFillholeImageFilterPython.itkGrayscaleFillholeImageFilterIUS2IUS2.New()
fillhole.SetInput(median.GetOutput())
import itkRescaleIntensityImageFilterPython
rescale =
itkRescaleIntensityImageFilterPython.itkRescaleIntensityImageFilterIUS2IUS2.New()
rescale.SetInput(fillhole.GetOutput())
writer.SetInput(rescale.GetOutput())
writer.Update()
python is nice enough to tell us how many modules we have:
21> len([a for a in sys.modules if a.startswith("itk") or
a.startswith("vnl")])
21> 79
Is that enough modules for you ?
But I will NOT make it work in tcl and java, until I'm sure it will be
used, simply because I know nearly nothing in tcl, and I'm not used to
wrap classes in java. I will NOT make it work on windows by myself,
because I don't have windows, because I never have used a microsoft
compiler, because that's something new to learn and my time is limited.
Also, the work done here is done on my free time - I also have a familly
life, and a work to do.
And like you, I'm not a swig expert - I'm just a guy who try to make
things work.
> CableSwig does some tricks on the internals of swig as it runs right now
> making all of this work.
Again: which tricks ??
I'm still waiting for a reply about my last question: why grouping the
swig modules, like itkImageToImageFilter, itkImage, ..., in bigger
modules, like ITKCommonA ?
I can't understand why the communication is so difficult. Perhaps that's
because all the communications are done by email ? I'm not sure, but
that's for this reason I joined the tcon last friday - and believe it,
that's a huge effort for me.
It would have be nice to disscuss about that during this tcon.
> I do not know how to do those same things in a swig .i file. I suspect
> that it will work, but until
> I see it, I would not be willing to make any commitments to this effort.
>
You know that making WrapITK work with all those systems is difficult. You
know that make WrapITK work with all those languages is difficult. I will
not make that alone.
If I'm alone, I stop the tcl and java parts, I take care of gcc on linux
and my mac, I stop taking care of the cmake configurations, I stop
writting mails to this mailing list (it should save me lot of time, and
some frustration for all the mails without answer). If I'm alone, I move
back WrapITK to its darcs repository on my server, and continue to develop
it alone on my side, with a better versionning tool, without being afraid
of breaking things I shouldn't.
Gaetan
--
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
More information about the Insight-developers
mailing list