[vtk-developers] ANN: Merging in updated wrapping branch into VTK master tomorrow

[Marcus D. Hanwell]

On Wed, Jun 16, 2010 at 2:31 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> On Wed, Jun 16, 2010 at 11:14 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
> >
> > Just to confirm that this was committed to VTK master earlier today, I
> fixed
> > one issue in vtkTextAnalysis and so far the dashboards are looking pretty
> > good. Please let us know if you encounter any problems.
> > Thanks,
> > Marcus
>
> I have to give a big thanks to Marcus and Keith for merging this, and
> to anyone else at Kitware who was involved.  You can bet that I fully
> appreciate all the time that was put into testing the code, plus all
> the work that went into rebasing my commits to the current VTK master
> (something you must have had to do at least two or three times).
>

I appreciate all the time you have put into fixing up the issues we found,
and am very pleased we could get this in. Some of my work was being impeded
by restrictions in the bindings generators, and with these improvements much
more of our C++ API can be wrapped, and I can stop writing duplicate
functions for the wrapped languages.

I would like to thank the community for holding off on pushing stuff into
VTK master. Please feel free to resume development as normal. There are a
few issues we need to work through, some new failures on the nightly
submissions.

>
> This merge adds the following to VTK:
>
> 1) Proper vtkStdString support for all wrappers, it used to sort-of
> work but was mostly broken.  By "all wrappers", I mean Tcl, Java,
> Python, and ParaView's VTKClientServer.
>
> 2) Support for vtkUnicodeString and vtkVariant within the python
> wrappers, with the potential of supporting scores of other currently
> unwrapped classes in the coming weeks.
>
> 3) A major clean-up of the lex/yacc front-end for the wrappers, it
> understands much more C++ now.
>

You forgot the much improved readability of the wrapping code too. A lot of
work has gone into refactoring some of the code, and removing some of the
old unused code.

>
> The main thing that I hope this merge will bring is a solid foundation
> for moving the wrappers forward.  Lately too much of VTK has become
> accessible only from C++.
>

Agreed (or we have been forced to write redundant API to help wrapped
languages).

>
> For any interested parties, I wrote a disorganized wiki page about the
> changes to the wrapper code:
> http://www.vtk.org/Wiki/index.php?title=VTK/Wrapping_Special_Types
>
> Specifically for Python, I have updated README_WRAP.txt:
> http://vtk.org/gitweb?p=VTK.git;a=blob;f=Wrapping/Python/README_WRAP.txt
>
> The wrapping in VTK is now much clearer to me. I might even take a stab at
fixing some stuff up myself as and when necessary. I have a few other minor
improvements in mind such as removing the hard coded lib prefix for Python
modules on POSIX systems, making the wrapping more flexible around class
names for other projects such as Titan that are using the VTK wrapping code.

Thanks,

Marcus
--
Marcus D. Hanwell, Ph.D.
R&D Engineer, Kitware Inc.
(518) 881-4937
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100617/10d9b098/attachment.html>