ITK/Release 4/Wrapping: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
(→Topics) |
(→Topics) |
||
Line 112: | Line 112: | ||
* migrating to WrapITK 0.3 | * migrating to WrapITK 0.3 | ||
* recode igenerator.py in C++ | * recode igenerator.py in C++ | ||
reuse cable code. already read gccxml output. | |||
* languages support | * languages support | ||
** keep python 2 | ** keep python 2 | ||
** keep java | ** keep java | ||
** add C# | ** add C# | ||
** add Python 3? | ** add Python 3? maybe | ||
** remove Tcl? | ** remove Tcl? sure | ||
* redefine the WrapITK libraries (grouping of classes) | * redefine the WrapITK libraries (grouping of classes) | ||
* Default wrapped types and abbreviated naming scheme | * Default wrapped types and abbreviated naming scheme | ||
* Wrapping coverage | * Wrapping coverage |
Revision as of 14:22, 13 August 2010
Wrapping
Requirements
- Avoid unnecessary dependencies
- Wrap +80% of the toolkit
- Have ITK look similar to the native wrapped language
Tools
- WrapITK
- Swig
- CableSwig
- MUMMY
Languages
What languages to wrap
- Python
- Lua ?
- Tcl ?
Discussions
Tcon July 19 2010
- Dropping CableSwig
- Using Swig Directly
- Along with GCC_XML
- Two Levels of Wrapping
- Wrapping the Simplified Layer (many wrapping tools will do)
- Wrapping the Templated Layer (WrapITK,GCC_XML)
- Managing multiple component images
- Microscopy use cases
- Remote Sensing cases
- itkVectorImage ?
- need a "component-by-component" filter driver ?
- Make easy to add new types (e.g. another pixel type for the image...)
- Run time binding may help here (along with the internal finder)
- Make possible (easy?) to distribute binaries of the wrapping.
- Maybe use the package manager (Ryppl ?).
- The same goes for the C++ version.
- Remove (or deprecate) itkSetVectorMacro and itkGetVectorMacro
they make the generated methods unusable in the target languages, and are not used that much in ITK
[glehmann@gbook build]$ grep -r etVectorMacro ~/src/Insight/Code/*/*.h | wc -l 34
They are used in two quite common filters - ChangeInformationImageFilter and PadImageFilter - and this makes this filter at least partly unusable in the target languages.
Tcon 808310
Agenda 081310
- gccxml maintenance
who does it? migration to CLang?
- migrating to WrapITK 0.3
- recode igenerator.py in C++
- languages support
- keep python 2
- keep java
- add C#
- add Python 3?
- remove Tcl?
- redefine the WrapITK libraries (grouping of classes)
It seems to be tightly linked to ITK_Release_4/Modularization.
- Default wrapped types and abbreviated naming scheme
Some choices are already made for [[ITK_Release_4/SimpleITK | SimpleITK]
- Wrapping coverage
100% filters coverage?
- Binary distribution
- ITK Image to/from target language array conversion
- Automatic Inline documentation
- Target language inheritance (SWIG directors)
- Automatic type selection in Python
- Improve 64bits support in ITK — surely done elsewhere already
- GDCM wrapping integration?
Minutes 081310
Attendees
- Luis Ibañez
- Gabe Hart
- Gaëtan Lehmann
- Brad King
Topics
- gccxml maintenance
Brad working on it. Getting harder with newer compiler. Will probably possible for the next couple of years.
CLang must be explored as a replacement.
- migrating to WrapITK 0.3
- recode igenerator.py in C++
reuse cable code. already read gccxml output.
- languages support
- keep python 2
- keep java
- add C#
- add Python 3? maybe
- remove Tcl? sure
- redefine the WrapITK libraries (grouping of classes)
- Default wrapped types and abbreviated naming scheme
- Wrapping coverage
- Binary distribution
- ITK Image to/from target language array conversion
- Automatic Inline documentation
- Target language inheritance (SWIG directors)
- Automatic type selection in Python
- Improve 64bits support in ITK — surely done elsewhere already
- GDCM wrapping integration?