[vtk-developers] python wrapping bug?

[David Gobbi]

Since you are modifying vtkParse.l, you can add your own equivalent of
"BTX" specific to your own needs.  For example, for a long time I had
BWX/EWX in my own copy of vtkParse.l as an alternative to BTX.

Recognizing Qt types in vtkParse.l/.y sounds reasonable.  Doing it
anywhere else would be a fair bit more complex.

The fact that the wrappers leave a blank/incomplete file after a
syntax error is surprising to me.  This is something that definitely
needs to be fixed.  Whenever you find a new bit of code that the
parser chokes on, be sure to send me an email.

   David


On Mon, Jul 26, 2010 at 12:15 PM, Clinton Stimpson <clinton at elemtech.com> wrote:
>
> I've made modifications in my copy of the code to support wrapping methods
> in VTK classes that take Qt types as arguments.  I was using
> VTK_PARSE_UNKNOWN in vtkWrapPython.c and hoping a generic method for dealing
> with external types will work out.
> That's why some of these extra methods are getting wrapped.  But maybe I'm
> not doing it the way it should be done, which is why I'm asking.
>
> But now I've started taking another approach and am modifying the .l and .y
> file so they recognize Qt types.  Then I knowing they are Qt types, I can
> generate the proper code for them.  I've got hand-written code working with
> VTK classes that take Qt types.  I just want to auto-generate that code.
>
> Do you have any other recommendations?
>
> Also, I think I'll still need at least a simple on/off switch, and the way
> BTX/ETX behaved has helped me the last few weeks.
>
> BTW, I've noticed that if there is a syntax error with the wrapper parsing a
> header file, and I ignore that error and try building again, I don't get the
> error again.  I'm guessing its a build dependency issue.
>
> Clint
>
>
> On 07/26/2010 11:59 AM, David Gobbi wrote:
>>
>> 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
>>>>>>>
>>>>>>>
>>>
>
>