[vtk-developers] python wrapping bug?

David Gobbi david.gobbi at gmail.com
Mon Jul 26 13:59:10 EDT 2010


What are you doing to get the vtkInstantiator CreateFunction methods
to wrap?  They don't get wrapped on my system.

My plan was to leave VTK_IGNORE_BTX=ON until all or most of the BTX
markers are removed from VTK.  After that, BTX/ETX will be re-enabled.
 To turn this option off, you must actually edit CMakeLists.txt, i.e.
change the line to SET(VTK_IGNORE_BTX OFF).

It sounds like you want a bit more control than a simple on/off
switch.  What I want to do eventually as a replacement for BTX/ETX is
to use the comments in the header file to tell the wrappers to ignore
methods, e.g. so that any method marked "INTERNAL USE ONLY" will never
be wrapped.  This is something that I can implement fairly quickly.
Even that doesn't sound like it is quite what you need, though.  I
really need to know why those vtkInstantiator methods are being
wrapped on your system...

The idea of giving a list of what extra types to support in the
wrappers is something that I do not want.  Could you provide a bit
more detail about what you need?

   David



On Mon, Jul 26, 2010 at 11:25 AM, Clinton Stimpson <clinton at elemtech.com> wrote:
>
> What's the plan for the cmake flag to ignore BTX/ETX?
> While I'm experimenting with external types (such as Qt types), I'd like
> some level of control on what gets wrapped.  I've been relying on BTX/ETX to
> mark things that should be ignored.
> For example, Common/vtkInstantiator has a CreateFunction type and a couple
> functions that use it, which are now getting wrapped with my experimental
> modifications, when it shouldn't be.
> But I'd like the functions in GUISupport/Qt/vtkQtTreeView.h that deal with
> Qt types wrapped.
>
> How should one control what gets wrapped in these cases?
> Should the wrapper generator instead take an input of what extra types to
> support, and how to support them?
>
> Clint
>
> On 07/24/2010 11:16 AM, David Gobbi wrote:
>>
>> If you do find that more types can be successfully python-wrapped,
>> don't be shy about pushing the changes.  I'll be committing the
>> keyword fixes sometime this afternoon.
>>
>>   David
>>
>>
>> On Sat, Jul 24, 2010 at 10:55 AM,<clinton at elemtech.com>  wrote:
>>>
>>> Thanks, I also thought they just needed to be ignored.
>>> I was experimenting with external types in the VTK wrappers and I ended
>>> up with explicit being a type instead of a keyword, and it gave me compile
>>> errors.
>>>
>>> Clint
>>>
>>> ----- Original Message -----
>>>>
>>>> Hi Clinton,
>>>>
>>>> I'm glad to hear that you are using this stuff, so far I have received
>>>> zero feedback from people using vtkVariant or the vtkArray helper
>>>> classes from python.
>>>>
>>>> There are a handful of C++ keywords that aren't understood by the
>>>> wrappers yet. They're all trivial to add, since the parser mostly
>>>> just has to ignore them... I've just been lazy. So, yeah, I'd better
>>>> add them, eh?
>>>>
>>>> David
>>>>
>>>>
>>>> On Sat, Jul 24, 2010 at 9:49 AM, Clinton Stimpson
>>>> <clinton at elemtech.com>  wrote:
>>>>>
>>>>>  Hi,
>>>>>
>>>>> It appears the wrapping code doesn't handle the c++ keyword
>>>>> "explicit"
>>>>> correctly.
>>>>> It fails to wrap a couple constructors in vtkArrayExtents which have
>>>>> the
>>>>> explicit keyword.
>>>>> Should it handle those?
>>>>>
>>>>> Clint
>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>>
>>>>>
>
>



More information about the vtk-developers mailing list