Trouble building matplotlib on Solaris 8

Community matplotlib-users
1

>>> plot([1,2,3,4])

    > [<matplotlib.lines.Line2D instance at 0x8790d6c>]
    > >>> show()

    > (process:3261): GLib-GObject-CRITICAL **: gtype.c:2253:
    > initialization assertion failed, use g_type_init() prior to
    > this function
    > Segmentation Fault (core dumped)

The problem here is that "show" starts the GUI mainloop when using a
GUI backend (GTKAgg is the default). To use the GTK, WX, or Qt
backends from a shell, you need to use a shell that starts the GUI
mainloop in a separate thread (Tkinter is special in this regard, in
that it can be use from the shell with no special threading calls, so
if you need to use the standard python shell for interactive work, you
should use the TkAgg backend). Also, you should not be using "show"
when working interactively from the shell. This is discussed in more
detail at

  http://matplotlib.sourceforge.net/interactive.html

and

  http://matplotlib.sourceforge.net/faq.html#SHOW

The recommended approach for using the GTK/WX/Qt backends
interactively from the shell is to use the ipython shell. ipython is
an easy install (pure python) and in addition to lots of nice
interactive features, has matplotlib support. Specifically, in the
pylab mode

  > ipython -pylab

it will read your matplotlibrc file, detect your backend, issue the
proper threading and timer/idle calls as needed for GTK, WX, Qt or Tk,
import the pylab namespace and wash your dishes

  http://ipython.scipy.org

Eg, you can do

ipython -pylab

Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
Type "copyright", "credits" or "license" for more information.

In [1]: hist(randn(10000), 100)

and your plot should appear automagically.

If for some reason ipython is not an option for you, and you need to
use a GTK backend from the shell, there is some template code in the
matplotlib examples directory showing how to write a custom shell with
the proper gtk threading calls.

JDH

2

The problem here is that "show" starts the GUI mainloop when using

    > a GUI backend (GTKAgg is the default)....

    > The recommended approach for using the GTK/WX/Qt backends
    > interactively from the shell is to use the ipython shell.

    > Eg, you can do

    >> ipython -pylab
    > Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
    > Type "copyright", "credits" or "license" for more information.

    > In [1]: hist(randn(10000), 100)

    > and your plot should appear automagically.

Thanks for the continued help. I installed ipython 0.6.15 and the default
matplotlibrc. Ipython needed one tweak to the matplotlib import (it was
looking for matplotlib.matlab and matplotlib.pylab, but not
matplotlib.mlab). Your interactive hist(...) example also segfaults.

I tried a simple script:

    import pygtk
    pygtk.require('2.6')
    import gtk

    from pylab import *
    plot([1,2,3,4])
    show()

    gtk.main()

run in batch. That also segfaults. The gdb backtrace was massive. I gave
up looking after 600+ frames had been displayed and resorted to pystack
instead:

    (gdb) pystack
    /opt/lang/python/lib/python2.3/site-packages/matplotlib/backends/backend_gtk.py (611): _init_toolbar2_4
    /opt/lang/python/lib/python2.3/site-packages/matplotlib/backends/backend_gtk.py (567): _init_toolbar
    /opt/lang/python/lib/python2.3/site-packages/matplotlib/backend_bases.py (971): __init__
    /opt/lang/python/lib/python2.3/site-packages/matplotlib/backends/backend_gtk.py (507): __init__
    Previous frame inner to this frame (corrupt stack?)

Reducing my simple script to just

    from pylab import *
    plot([1,2,3,4])
    show()

yields another segfault, with this minimalist backtrace:

    (gdb) bt
    #0 0xd0cf29fc in strlen () from /lib/libc.so.1
    #1 0xd0d47e3e in _ndoprnt () from /lib/libc.so.1
    #2 0xd0d4af3b in vsnprintf () from /lib/libc.so.1
    #3 0xcf8e9cda in g_printf_string_upper_bound () from /usr/lib/libglib-2.0.so.0

It would appear something else is going on here other than straightforward
issues of whether or not I'm running interactively. Unfortunately, the wild
differences between the two gdb backtraces suggest that I'm going to have to
drag out Electric Fence or some other malloc debugger to figure out what's
wrong (oh joy, oh happy thought...), which I don't have time for at the
moment.

Any simpler suggestions?

Skip

3

skip@...789... wrote:
[ pain and suffering with gdb and EE menacingly lurking on the horizon ]

Any simpler suggestions?

Can you use TkAgg as your backend (set it in ~/.matplotlib/matplotlibrc)? Personally I don't use any of the threaded backends, but just plain old Tk. While not as flashy as the others, it has the advantage of being very stable, allowing Ctrl-C to interrupt long-running computations, and letting me use other Tk-based apps I need.

Even if you need GTK/WX, you may want to test with Tk just to see what happens, before pulling the heavy artillery out.

Further, note that in ipython -pylab, you can type:

run myscript.py

and it will run your script (it's basically a wrapper around execfile() with fancy namespace hacks and control of matplotlib's rendering loop).

Let us know how that goes, I'll try to help as well.

Cheers,

f

4

Any simpler suggestions?

    > Can you use TkAgg as your backend (set it in
    > ~/.matplotlib/matplotlibrc)?

Thanks for the suggestion. To be honest, I'd never even considered Tk since
we're a Gtk shop. That worked in both interactive and batch (well, at least
the simple first example from the tutorial worked). That narrows my problem
space down to Gtk and PyGtk. I suspect I could have guessed the problem was
in the Gtk space without performing any tests though...

    > Even if you need GTK/WX, you may want to test with Tk just to
    > see what happens, before pulling the heavy artillery out.

Granted.

Skip

5

skip@...789... wrote:

    >> Any simpler suggestions?

    > Can you use TkAgg as your backend (set it in
    > ~/.matplotlib/matplotlibrc)?

Thanks for the suggestion. To be honest, I'd never even considered Tk since
we're a Gtk shop. That worked in both interactive and batch (well, at least
the simple first example from the tutorial worked). That narrows my problem
space down to Gtk and PyGtk. I suspect I could have guessed the problem was
in the Gtk space without performing any tests though...

Good. Most likely, everything will work. I use TkAgg for all my stuff, and it's fine. Even if you get GTK to build, it won't mean you're out of the woods. John and I have been trying, unsuccessfully, to track down a very bizarre GTK-only crash. Since ipython plays thread tricks to make an interactive console coexist happily with the gtk event mainloop, it's bound to be a more brittle setup than plain old Tk.

So unless you end up needing to embed mpl into GTK apps or have a burning desire to spend the weekend in the company of Electric Fence and gdb, Tk might just be enough.

Cheers,

f

6

So unless you end up needing to embed mpl into GTK apps ...

That was precisely my thought... Even if we only get it working with Tk,
we'll at least have a much better tool than GNUplot.

Skip