[vtk-developers] VTK Wrapping

[David Gobbi]

Hi Pat,

Thanks for the info, I just got a ParaView build going with the
COPROCESSING option. My guess is that my code that builds docstrings
for special objects is buggy.

  David


On Mon, Jul 12, 2010 at 4:45 PM, pat marion <pat.marion at kitware.com> wrote:
> Hi David,
>
> I uncovered a new segfault.  Admittedly this is a very strange case, but it
> used to work:
>
> import libvtkCoProcessorPython as cp
> pipeline = cp.vtkCPPythonScriptPipeline()
>
> # crash here
> import libvtkCommonPython
>
> Run with vtkpython, or regular python.  You might need to add
> /path/to/paraview-build/bin to sys.path.  You get the vtkCoProcessorPython
> library if you build paraview with python and PARAVIEW_ENABLE_COPROCESSING.
>
> Here is what is happening- the ctor of vtkCPPythonScriptPipeline initializes
> paraview (vtkPVMain::Initialize), creates a vtkPVPythonInterpretor, and
> execs code in the new interpreter that imports vtk modules.  If it makes any
> difference, the vtk that is imported is paraview/vtk/__init__.py, not the
> regular vtk/__init__.py.  Note, it doesn't crash if I import
> libvtkFilteringPython, or any other kit, just vtkCommon.  I guess because
> vtkCommon contains the specially wrapped vtkTimeStamp.
>
>
>
> backtrace-
>
> 0x00007fffe43c6bfe in PyVTKSpecialType_New (newmethod=0x7fffe4a18180,
> methods=0x7fffe4a180e0, constructors=0x7fffe4a18140,
>     classname=0x7fffe47a310e "vtkTimeStamp", docstring=0x7fffe4a181e0,
> smethods=0x7fffe4a181a0)
>     at
> /source/paraview/ParaView/VTK/Wrapping/Python/PyVTKSpecialObject.cxx:341
> 341      newmethod->ml_doc = PyString_AsString(info->docstring);
>
> (gdb) bt
> #0  0x00007fffe43c6bfe in PyVTKSpecialType_New (newmethod=0x7fffe4a18180,
> methods=0x7fffe4a180e0, constructors=0x7fffe4a18140,
>     classname=0x7fffe47a310e "vtkTimeStamp", docstring=0x7fffe4a181e0,
> smethods=0x7fffe4a181a0)
>     at
> /source/paraview/ParaView/VTK/Wrapping/Python/PyVTKSpecialObject.cxx:341
> #1  0x00007fffe46fbb4a in PyVTKClass_vtkTimeStampNew () at
> /source/paraview/build/VTK/Common/vtkTimeStampPython.cxx:164
> #2  0x00007fffdd07cf4c in initlibvtkCommonPython () at
> /source/paraview/build/VTK/Common/vtkCommonPythonInit.cxx:1055
> #3  0x00000000004c081c in _PyImport_LoadDynamicModule ()
> #4  0x00000000004bed93 in ?? ()
> #5  0x00000000004bf00f in ?? ()
> #6  0x00000000004bf6cb in ?? ()
> #7  0x00000000004bfc14 in PyImport_ImportModuleLevel ()
> #8  0x00000000004a16ab in ?? ()
> #9  0x000000000041f0c7 in PyObject_Call ()
> #10 0x00000000004a226f in ?? ()
> #11 0x00000000004a55fc in PyEval_EvalFrameEx ()
> #12 0x00000000004a9671 in PyEval_EvalCodeEx ()
> #13 0x00000000004a9742 in PyEval_EvalCode ()
> #14 0x00000000004c9a0e in PyRun_FileExFlags ()
> #15 0x00000000004c9c24 in PyRun_SimpleFileExFlags ()
> #16 0x000000000041a7ff in Py_Main ()
>
>
> On Tue, Jul 6, 2010 at 9:51 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> Hi All,
>>
>> Another wrapping update was pushed this morning.  This time, the
>> parser and the wrappers have been updated so that they can build while
>> ignoring the BTX/ETX markers in the header files. Here is a new CMake
>> variable for people to play with:
>>
>> VTK_IGNORE_BTX "Ignore BTX and ETX in header files."
>>
>> If you turn this option ON, then the wrappers will parse the header
>> files as if all the BTX/ETX markers had were removed, i.e. //BTX and
>> //ETX will be treated as if they were just regular comments.
>>
>> Turning on this option will break any external wrapping, e.g. ParaView
>> or Titan, because I do not yet export the hierarchy files.  For now,
>> it is just an experimental option for stand-alone VTK builds.
>>
>>   David
>> _______________________________________________
>> 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
>>
>
>