VTK-8.1.0 wheels for all platforms on pypi!

I cannot believe it has been 6 years since my last blog post!  Anyway, I have some good news to announce here.

In the Python community, VTK has always been somewhat difficult to install (in comparison to pure Python packages). One has required to either use a specific package management tool or resort to source builds. This has been a major problem when trying to install tools that rely on VTK, like Mayavi.

During the SciPy 2017 conference held at Austin last year, a few of the Kitware developers, notably Jean-Christophe Fillion-Robin  (JC for short) and some of the VTK developers got together with some of us from the SciPy community and decided to try and put together wheels for VTK.

JC did the hard work of figuring this out and setting up a nice VTKPythonPackage during the sprints to make this process easy. As of last week (Jan 27, 2018) Mac OS X wheels were not supported. Last weekend, I finally got the time (thanks to Enthought) to play with JC's work. I figured out how to get the wheels working on OS X. With this, in principle, we could build VTK wheels on all the major platforms.

We decided to try and push wheels at least for the major VTK releases. This in itself would be a massive improvement in making VTK easier to install. Over the last few days, I have built wheels on Linux, OS X, and Windows. All of these are 64 bit wheels for VTK-8.1.0.

Now, VTK 8.x adds a c++11 dependency, and so we cannot build these versions of VTK for Python 2.7 on Windows.

So now we have 64 bit wheels on Windows for Python versions 3.5.x and 3.6.x.
Unfortunately, 3.4.x required a different Visual Studio installed and I lost patience setting things up on my Windows VM.

On Linux, we have 64 bit wheels for Python 2.7.x, 3.4.x, 3.5.x, and 3.6.x.

On MacOS, we have 64 bit wheels for Python 2.7.x, 3.4.x, 3.5.x, and 3.6.x.

So if you are using a 64 bit Python, you can now do

   $ pip install vtk

and have VTK-8.1.0 installed!

This is really nice to have and should hopefully make VTK and other tools a lot easier to install.

A big thank you to JC, the other Kitware developers, the VTK Python developers, especially David Gobbi who has worked on the VTK Python wrappers for many many years now,  for making this happen. Apologies if I missed anyone but thank you all!

Enjoy!

Debugging Python scripts

Elementary debugging

I've noticed that many students who submit assignments in Python for a course I teach don't know how to use a debugger. Here are some simple notes on debugging Python scripts to get people started. Lets say you have the following trivial code:

# -- junk.py ---
print "hello"
foo
a = 1
print a+1

Importing this from IPython produces this::

In [1]: import junk
hello
---------------------------------------------------------------------------
         Traceback (most recent call last)

/tmp/ in ()

/tmp/junk.py in ()
  1 print "hello"
----> 2 foo
  3 a = 1
  4 print a+1
  5

exceptions.NameError: name 'foo' is not defined

If you have a non-trivial program you can debug this right away using IPython's %debug magic.

In [2]: %debug
> /tmp/junk.py(2)()
  1 print "hello"
----> 2 foo
  3 a = 1

ipdb>

This drops you into ipdb which is an enhanced, pdb. At this point you can print variables and step through your code, go up the stack of execution etc. For more details on ipdb read the pdb documentation.

If you use the %pdb magic then IPython automatically drops you into the debugger whenever it sees an error. This is often very convenient.


Debugging a VTK-Python script

This is obviously a little more complicated (because VTK is implemented in C++ and you want to step through C++ code to figure out what is wrong) and there are a few ways of doing this. In the following I assume that you are doing this on a *nix/Linux/Mac machine. Suppose you run a Python script that segfaults and need to figure out where it crashed you can do the following (assuming you have gdb installed of course):

$ gdb python
(gdb) run your_script.py
[gdb messages]
Segmentation fault (or whatever)
(gdb) backtrace

The backtrace should typically give you more information about the crash.

Several weeks ago I needed to debug a VTK related problem where a window was not being resized if the off screen rendering mode was set. Debugging this can again be achieved by running the script using Python started from gdb and then setting a breakpoint in gdb. However, I thought I'd illustrate a very handy gdb feature of debugging running applications. In my particular case, I had a simple Python script that was demonstrating a VTK bug. At the appropriate location wher, I added a simple raw_input('DBG:') to give me a point where execution would be paused. I then ran the script like so:

$ python offscreen.py

On another shell I did the following:

$ ps uax | grep python

Using the PID of the process (30708) I did the following:

$ gdb
(gdb) attach 30708
[tons of output]
Loaded symbols for /usr/lib/libwx_gtk2u_gl-2.8.so.0
Reading symbols from /usr/lib/libGLU.so.1...done.
Loaded symbols for /usr/lib/libGLU.so.1
0xffffe410 in __kernel_vsyscall ()
(gdb)

On the gdb prompt I specify a break point where I want to stop execution::

(gdb) br vtkXOpenGLRenderWindow.cxx:1185
Breakpoint 1 at 0xb52846a0: file /skratch/prabhu/vtk/cvs/VTK/Rendering/vtkXOpenGLRenderWindow.cxx, line 1185.
(gdb) c
Continuing.
[Switching to Thread -1210595664 (LWP 30708)]

Breakpoint 1, vtkXOpenGLRenderWindow::SetSize (this=0x99bfb78, width=800,
height=800)
at /skratch/prabhu/vtk/cvs/VTK/Rendering/vtkXOpenGLRenderWindow.cxx:1185
1185      if ((this->Size[0] != width)||(this->Size[1] != height))
Current language:  auto; currently c++
(gdb)

At this point I can step through the code and try and figure out what is going on. This is extremely convenient and handy.