[vtk-developers] VTK Wrapping

[David Gobbi]

Another small discrepancy that I noticed is that the first time the
module loads, it loads with the path
/beck/data/dgobbi/Kitware/ParaView-gitbin/bin/./libvtkCommonPython.so
and the second time, it loads with the path
/beck/data/dgobbi/Kitware/ParaView-gitbin/bin/libvtkCommonPython.so
i.e. there is an extra "./" the first time around.  This is probably
just a red herring, but I thought it was worth mentioning.

   David


On Mon, Jul 12, 2010 at 11:51 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Pat,
>
> The problem is that libvtkCommonPython is being loaded twice.  I have
> added an "if" check to get rid of the segfault, but still, there seems
> to be something fishy about the way that the interpreter is loading
> the modules.
>
> Whenever a module is loaded, it should appear in "sys.modules", but
> after calling cp.vtkCPPythonScriptPipeline(), when I do
> "dir(sys.modules)" I don't see any of the VTK modules.  This could be
> because the modules are being loaded into a separate interpreter, I
> don't know what vtkCPPythonScriptPipeline() does.  But in any case,
> because libvtkCommonPython isn't added to sys.modules, calling "import
> libvtkCommonPython" causes the module initialization code to be
> re-executed.  And that is what was causing the segfault.
>
>   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
>>>
>>
>>
>