[vtkusers] Experimental enhanced wrappers for VTK

[David Gobbi]

I've pushed the last of the changes to my "wrapping" branch on github.
 It's ready for merge.

   David


On Wed, May 26, 2010 at 4:49 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> In the new wrappers, there is already full support vtkStdString
> support Tcl and Java, and I've even added string regression test for
> Tcl.
>
> Unicode was easy to add to Python (a few hours work), and it should be
> similarly easy for someone to add it for Tcl and Java.  There are
> plenty of people who want it, I'm sure.
>
> Divergence is a concern, but at least all wrappers use the same
> front-end, so transferring enhancements from one set of wrappers to
> another is that much easier.  And Brad King mentioned a wrapper
> utility .cxx that all wrappers use... this would be great, because
> right now there is a huge amount of code duplication.
>
> I'll switch over to the branch immediately, and in the future I will
> make branches for any other projects that involve multiple classes.
>
>   David
>
>
> On Wed, May 26, 2010 at 3:58 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Hi David,
>> On Wed, May 26, 2010 at 5:46 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>
>>> Thanks for doing this!  I was not looking forward to doing the
>>> clean-up work myself... when I started it never occurred to me to
>>> create a branch, my plan was to eventually re-base my changes on the
>>> VTK master.
>>
>> Topic branches are much easier for us to work with, and if you avoid merging
>> into them/rebasing then the eventual merge into master becomes simpler. Now
>> that we have it you could continue your work in that branch, or we could
>> cherry pick the commits you make.
>>>
>>> There are just two minor changes that I can squeeze in over the next
>>> two days, and I will email you when they are done.  After that, the
>>> sooner that the branch can be merged into master, the better.  In
>>> order for the special-type wrapping to be fully realized, most (or
>>> all) of the BTX's will have to be removed from the code.  A change
>>> that big will probably be easier to do in the master than to merge in
>>> from a branch.
>>
>> A global change like that is definitely something that would be easier done
>> in master as you say. We can take care of that once it looks ready to go
>> in.
>>>
>>> I've already tested VTK (with python, tcl, and java) without BTX/ETX.
>>> The Tcl and Java wrappers compiled and tested cleanly, and so did
>>> Python after I did some small fixes to the way that it does special
>>> type wrapping.  It is these python fixes that I need to commit before
>>> the merge.
>>>
>> I think one of the remaining concerns is how much the wrapping might
>> diverge, i.e. if Python supports vtkVariant, unicode, vtkStdString etc but
>> other languages did not. I am certainly very pleased with the changes in
>> Python, and can see how much it will improve the Python wrapping in charts
>> and infovis.
>>
>>>
>>> There are other changes that I'm planning for the Python wrappers
>>> (enums, etc) but for them I'd prefer to wait until after the merge.
>>> I'll put together a wiki page so that they can be reviewed.
>>>
>> You could publish them in a topic branch for us to review. The main caveats
>> remain to avoid rebasing/merging from master. Once we are ready to merge
>> into master we can take care of that. Thanks for putting this together, and
>> to Keith for preparing this topic branch.
>> I am very hopeful that we can merge these changes in soon. We have been
>> working away behind the scenes to get this ready to be reviewed and merged
>> in.
>> Thanks,
>> Marcus
>>>
>>> On Wed, May 26, 2010 at 2:39 PM, Keith Fieldhouse
>>> <keith.fieldhouse at kitware.com> wrote:
>>> > David
>>> > I've been spending some time looking at your Wrapping work.  It appears
>>> > that
>>> > your git tree was built with a mixture of rebasing and merging which
>>> > resulted in a somewhat wonky commit history (duplicated commits
>>> > interspersed
>>> > with commits coming from VTK master).
>>> > In order to get a clean topic branch that will be a little easier for
>>> > folks
>>> > here to look at (and to eventually merge with master) I spent a  bit of
>>> > time
>>> > untangling your history (mostly by examining parentage and looking at
>>> > commit
>>> > subjects).  In the end, by cherry picking the right commits in what I
>>> > considered the "right" order I was able to build a clean topic branch
>>> > with
>>> > no conflicts.  Once I had that, I rebased it against master (as of this
>>> > afternoon sometime when I did it).  The result can be found in
>>> > git://github.com/keith-fieldhouse/VTK.git
>>> > As the topic branch Gobbi/Wrapping.
>>> > The result builds and the tests run so I believe that I've built a a
>>> > representative branch from your work.
>>> > If you plan on doing additional work on this, would it be possible for
>>> > you
>>> > to grab this topic branch and work on that (without rebasing or merging
>>> > for
>>> > now)?    That way we'll have a clean topic branch  for an eventual merge
>>> > to
>>> > "Next" when we switch to branchy development for VTK.  Or if branchy
>>> > development comes later, this clean topic branch will be easier to
>>> > rebase as
>>> > well.
>>> > Thanks again for your work on this.
>>> > Keith
>>> > --
>>> > Keith Fieldhouse
>>> > R&D Engineer, Kitware Inc.
>>> > (518) 836-2190
>>> >
>>> >
>>> >
>>> >
>>
>>
>