[VTK ARB] Planning the next ARB meeting

[David Gobbi]

This is very easy for me to add back to the wrappers.  I removed them
when I was cleaning up the docstrings by e.g. making vtkWrapPython
understand a few doxygen tags. But I see your point about the size
information.

All the docstring code in VTK was written by me, actually, both in the
old wrappers and in the new wrappers, so I'm intimately familiar with
it. ;)

I'll add back the pythonic signatures next week.

   David


On Sat, Jun 26, 2010 at 5:48 PM, Claudio T. Silva <csilva at sci.utah.edu> wrote:
> Hi,
>
> We currently have some issues with the new VTK wrapping as it related
> to VisTrails. Here is the problem. VTK usually provides method
> signatures for both Python and C++ function through Python's
> docstring. For example, in Python, with the old VTK, if one does:
>
>>> help(vtk.vtkProperty.GetColor)
>
> it returns:
> ====
> GetColor(...)
>   V.GetColor() -> (float, float, float)
>   C++: double *GetColor ();
>   V.GetColor((float, float, float))
>   C++: void GetColor (double rgb[3]);
>
>   Set the color of the object. Has the side effect of setting the
>   ambient diffuse and specular colors as well. This is basically
>   a quick overall color setting method.
> ====
> the "C++:" is the C++ signature while the V.* things are Python's
> signature. VisTrails use this to wrap Module's methods.
>
> However, in the new VTK, when doing the same help command we get
> ====
> GetColor(...)
>   double *GetColor()
>   void GetColor(double rgb[3])
>
> ...
> ====
>
> So it looks like users have to convert C++ signature to Python
> signature in order to use it. However, when VTK doing conversion, they
> have internal information, and we do not. For the case above, the
> correspond Python signature for
> double *GetColor()
> is
> V.GetColor() -> (float, float, float)
>
> Note the 3-value returns. If we manually convert from C++, we don't
> know how many value for the tuple. I guess VTK knows this from the
> SetColor function. I am not sure why they drop Python signature (or
> just not done yet with the new wrapping mechanism), but if they put
> back this feature from the old code, it should be much better for
> other systems like us to wrap VTK.
>
> Is this functionality going to be added back?
>
> Thanks,
>
> Claudio.
>
>
>
> On Sat, Jun 26, 2010 at 11:19 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi Jeff,
>>
>> Since there is a lot of talk about wrapping, I should probably chip in
>> my two cents even though I'm not involved with the ARB.  You could
>> call me "an interested third party."  In addition to the wrapper
>> changes that were recently merged with VTK, I'm also working on a
>> "WrapVTK" project that contains several useful wrapper tools that I
>> also plan to merge.
>>
>> The first two items will be merged into VTK as early as next week:
>>
>> 1) a new vtkParse that generates info for templates, constants, enums,
>> arbitrarily complex function pointers, multi-dimensional array
>> arguments, and that needs no BTX/ETX
>> 2) a vtkWrapHierarchy tool for generating typing information for
>> wrapper-generators to use
>> 3) a vtkParseProperties tool for extracting "properties" from VTK
>> header files by searching for Get/Set/Add/Remove methods, and storing
>> the properties in a simple struct for the wrappers to use
>> 4) a vtkParseMerge tool for merging all inherited methods into a
>> single ClassInfo data structure
>> 5) a vtkWrapXML tool for generating XML descriptions of VTK classes
>>
>> All the above is done and ready for anyone to download at
>> http://github.com/dgobbi/WrapVTK .  It could easily be expanded upon
>> to also parse useful items like typedefs and to recognize
>> doxygen-style comments.  This is all intended to be a new but
>> backwards-compatible front end for the wrappers.
>>
>> So all that I ask is that someone takes a look at it before the
>> meeting, it takes only two minutes to generate XML info for all the
>> VTK header files and it requires zero configuration apart from setting
>> VTK_DIR.  This isn't a VTK fork, it is a separate, small package that
>> builds on top of an existing VTK.  Of course, I would have no
>> objection if it was all moved into the VTK core eventually.
>>
>> That's my two cents, plus a dime and a nickel.
>>
>>   David
>>
>>
>> On Sat, Jun 26, 2010 at 10:02 AM, Wylie, Brian <bnwylie at sandia.gov> wrote:
>>> Can we put introspection on the agenda as well?
>>>
>>>
>>>
>>>   Brian Wylie - Org 1424
>>>
>>>   Sandia National Laboratories
>>>
>>>   MS 1323 - Building CSRI/242
>>>
>>>   (505)844-2238 FAX(505)284-2518
>>>
>>>        _______ __
>>>
>>>       /_  __(_) /_____ _____
>>>
>>>        / / / / __/ __ `/ __ \
>>>
>>>       / / / / /_/ /_/ / / / /
>>>
>>>      /_/ /_/\__/\__,_/_/ /_/
>>>
>>>        chown -R ours /ur/bases
>>>
>>>
>>>
>>> From: arb-bounces at vtk.org [mailto:arb-bounces at vtk.org] On Behalf Of Jeff
>>> Baumes
>>> Sent: Monday, June 21, 2010 1:26 PM
>>> To: arb at vtk.org
>>> Subject: [VTK ARB] Planning the next ARB meeting
>>>
>>>
>>>
>>> Hello all,
>>>
>>>
>>>
>>> Hope everyone's summer is starting off well (or winter to those in the
>>> southern hemisphere). It's been a few months, so I wanted to start planning
>>> a date to meet again. How does Wednesday, July 14th, 2pm EDT work for
>>> people? Feel free to suggest alternate times.
>>>
>>>
>>>
>>> Here are some potential topics:
>>>
>>>
>>>
>>> VTK 6.0 planning, timing
>>>
>>> Wrapping changes
>>>
>>> Library reorganization
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Jeff
>>>
>>> --
>>> Jeff Baumes, Ph.D.
>>> Technical Lead, Kitware Inc.
>>> (518) 881-4932
>>>
>>> _______________________________________________
>>> Arb mailing list
>>> Arb at vtk.org
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/arb
>>>
>>>
>> _______________________________________________
>> Arb mailing list
>> Arb at vtk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/arb
>>
>