matplotlib-devel Mailing List for matplotlib (Page 490)

On Wed, Feb 22, 2006 at 08:49:16PM -0600, John Hunter wrote:
> >>>>> "Albert" == Albert Chin <mat...@ml...> writes:
> 
>     Albert> We've built 0.87 with Python 2.4.2/GCC 3.4.3 on Solaris,
>     Albert> HP-UX, Tru64 UNIX, IRIX, and Redhat Linux. It works fine
>     Albert> on all platforms except HP-UX/PA (HP-UX 11.23/IA64 works
>     Albert> fine). Some of the examples, like two_scales.py, work fine
>     Albert> if run once. However, with ~/.matplotlib/ttffont.cache
>     Albert> existing, a second run of two_scales.py (or any other
>     Albert> example), fails with the following: terminate called after
>     Albert> throwing an instance of 'Py::RuntimeError'
> 
> Please clear the tex cache dir and then run the example both times
> with the --verbose-debug flag, and post the output along with the
> complete traceback.

~/tex.cache is empty.

  $ rm -rf ~/.matplotlib
  $ python two_scales.py --verbose-debug 2>&1 | tee /tmp/output.1
  $ python two_scales.py --verbose-debug 2>&1 | tee /tmp/output.2

The failure occurs when displaying the data. I've also tried
anim_tk.py to determine if it was a problem with the GTK+ backend but
anim_tk.py fails in the same way.

What do you mean by "traceback"? Stack trace from Python after the
error? None is given.

-- 
albert chin (ch...@th...)

>>>>> "Albert" == Albert Chin <mat...@ml...> writes:

    Albert> We've built 0.87 with Python 2.4.2/GCC 3.4.3 on Solaris,
    Albert> HP-UX, Tru64 UNIX, IRIX, and Redhat Linux. It works fine
    Albert> on all platforms except HP-UX/PA (HP-UX 11.23/IA64 works
    Albert> fine). Some of the examples, like two_scales.py, work fine
    Albert> if run once. However, with ~/.matplotlib/ttffont.cache
    Albert> existing, a second run of two_scales.py (or any other
    Albert> example), fails with the following: terminate called after
    Albert> throwing an instance of 'Py::RuntimeError'

Please clear the tex cache dir and then run the example both times
with the --verbose-debug flag, and post the output along with the
complete traceback.

JDH

We've built 0.87 with Python 2.4.2/GCC 3.4.3 on Solaris, HP-UX, Tru64
UNIX, IRIX, and Redhat Linux. It works fine on all platforms except
HP-UX/PA (HP-UX 11.23/IA64 works fine). Some of the examples, like
two_scales.py, work fine if run once. However, with
~/.matplotlib/ttffont.cache existing, a second run of two_scales.py
(or any other example), fails with the following:
  terminate called after throwing an instance of 'Py::RuntimeError'

Anyone have any ideas?

-- 
albert chin (ch...@th...)

For those of you who don't follow the user's list....  Thanks Charlie
for doing this

Notable notes:
   - Built against numpy-0.9.5
   - A wealth of bugfixes

http://sourceforge.net/project/showfiles.php?group_id=80706

===============================================================
2006-02-22 Released 0.87

2006-02-21 Fixed portrait/landscape orientation in postscript backend - DSD

2006-02-21 fix bug introduced in yesterday's bug fix - SC

2006-02-20 backend_gtk.py FigureCanvasGTK.draw(): fix bug reported by
           David Tremouilles - SC

2006-02-20 Remove the "pygtk.require('2.4')" error from
           examples/embedding_in_gtk2.py - SC

2006-02-18 backend_gtk.py FigureCanvasGTK.draw(): simplify to use (rather than
           duplicate) the expose_event() drawing code - SC

2006-02-12 Added stagger or waterfall plot capability to LineCollection;
           illustrated in examples/collections.py. - EF

2006-02-11 Massive cleanup of the usetex code in the postscript
backend. Possibly
           fixed the clipping issue users were reporting with older versions of
           ghostscript - DSD

2006-02-11 Added autolim kwarg to axes.add_collection.  Changed
           collection get_verts() methods accordingly. - EF

2006-02-09 added a temporary rc parameter text.dvipnghack, to allow
Mac users to get nice
           results with the usetex option. - DSD

2006-02-09 Fixed a bug related to setting font sizes with the usetex
option. - DSD

2006-02-09 Fixed a bug related to usetex's latex code. - DSD

2006-02-09 Modified behavior of font.size rc setting. You should
define font.size in pts,
           which will set the "medium" or default fontsize. Special
text sizes like axis
           labels or tick labels can be given relative font sizes like
small, large,
           x-large, etc. and will scale accordingly. - DSD

2006-02-08 Added py2exe specific datapath check again.  Also added new
           py2exe helper function get_py2exe_datafiles for use in py2exe
           setup.py scripts. - CM

2006-02-02 Added box function to pylab

2006-02-02 Fixed a problem in setupext.py, tk library formatted in unicode
           caused build problems - DSD

2006-02-01 Dropped TeX engine support in usetex to focus on LaTeX. - DSD

2006-01-29 Improved usetex option to respect the serif, sans-serif, monospace,
           and cursive rc settings. Removed the font.latex.package rc setting,
           it is no longer required - DSD

2006-01-29 Fixed tex's caching to include font.family rc information - DSD

2006-01-29 Fixed subpixel rendering bug in *Agg that was causing
           uneven gridlines - JDH

2006-01-28 Added fontcmd to backend_ps's RendererPS.draw_tex, to support other
           font families in eps output - DSD

2006-01-28 Added MaxNLocator to ticker.py, and changed contour.py to
           use it by default. - EF

2006-01-28 Added fontcmd to backend_ps's RendererPS.draw_tex, to support other
           font families in eps output - DSD

2006-01-27 Buffered reading of matplotlibrc parameters in order to allow
           'verbose' settings to be processed first (allows verbose.report
           during rc validation process) - DSD

2006-01-27 Removed setuptools support from setup.py and created a
           separate setupegg.py file to replace it. - CM

2006-01-26 Replaced the ugly datapath logic with a cleaner approach from
           http://wiki.python.org/moin/DistutilsInstallDataScattered.
           Overrides the install_data command. - CM

2006-01-24 Don't use character typecodes in cntr.c --- changed to use
           defined typenumbers instead. - TEO

2006-01-24 Fixed some bugs in usetex's and ps.usedistiller's dependency

2006-01-24 Added masked array support to scatter - EF

2006-01-24 Fixed some bugs in usetex's and ps.usedistiller's dependency
           checking - DSD

Hi Alex,

On Friday 17 February 2006 18:48, Alex Gontmakher wrote:
> Here it goes again. And sorry for the delay, I was busy with other
> things, will catch up...
> Yes, I believe it does not conflict with the savefig's
> landscape-vs-portrait handling. Some of the EPS viewers need this flag
> in order to show the plot in its original orientation (read: heads up).
>
> In addition, I find the code in lines 1049-1053 of bakend_ps.py somewhat
> strange: in my understanding, landsape means that the plot's "up"
> direction is oriented to the left, i.e., the plot is rotated 90CCW. This
> has nothing to do with the plot's width and height. However, that's not
> my code I wouldn't like to fix that myself without knowing the original
> author's intent. Comments?

I'm not the original maintainer of the postscript backend, but I agree that 
those lines were strange. I just committed my changes to cvs, 
portrait/landscape orientation should be better supported now.

Darren

Works perfectly using the cvs version!
Great!

Thanks again,

David

2006/2/21, Steve Chaplin <ste...@ya...>:

> The previous fix was not quite right.
>     self._need_redraw =3D True
> should come before
>     if GTK_WIDGET_DRAWABLE(self):
>
> It is now (hopefully) fixed in CVS.
>
> regards,
> Steve
>
>

On Mon, 2006-02-20 at 20:38 -0800,
mat...@li... wrote:
> Hi,
> No more traceback with the matplolib cvs version. 
> However, I observe now some strange behavior.  
> I join a new example code.
>   When you launch the script and press replot button (circle should
> become a line in both tab), then switch to the second tab everything
> ok. But back to the first tab and press replot (line should become a
> circle in both tab), switch to the second tab... still see a line. If
> you use the  "pan" tool  in the toolbar and move a bit the graph then
> the figure is the updated and become a circle.
> 
> Regards,
> 
> David

The previous fix was not quite right.
    self._need_redraw = True
should come before
    if GTK_WIDGET_DRAWABLE(self):

It is now (hopefully) fixed in CVS.

regards,
Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Tom" == Tom Denniston <tom...@al...> writes:

    Tom>  I am generating a few hundred graphs and doing so takes on
    Tom> the order of about 10-15 minutes.  Which seems to me rather
    Tom> slow.  When I profile my code it identifies the calls to
    Tom> get_yticklabels and get_xticklabels as taking over 90% of the
    Tom> time.  This seems strange but my calls to these functions are
    Tom> merely a sort round about way of setting the font size of the
    Tom> axis tick labels and suppressing the text for the
    Tom> xticklabels.  Is there a more efficient and cleaner way to do
    Tom> this?  artist.setp(axes.get_yticklabels(), visible=True,
    Tom> fontsize=7) artist.setp(axes.get_xticklabels(),
    Tom> visible=False)

This is a known performance bottleneck.  There are two reasons it is
slow.  Every tick label is handled as an independent object, when they
in most cases share most of their properties (font size, orientation)
and so could be better handled as a TextCollection, which does not
exist yet.  The second reason is that the text layout engine is doing
layout for newline separated strings with an arbitrary rotation for
every tick label, which is almost never used.  So some special case
optimizations to handle the no rotation, no newline text instances
(basically just bypass the layout machinery) would help a lot here.

Are you using matplotlib mathtext also, by chance?  This slows things
down a bit too, though is better in recent versions.

JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
    Andrew> It goes deeper -- even Figure.add_axes() returns an old
    Andrew> Axes instance if the rect given has been seen before. I'd
    Andrew> argue that people delving into the OO innards of
    Andrew> matplotlib should be able to handle keeping a reference to
    Andrew> instances of Axes they've created. Can we change this
    Andrew> behavior or would it cause massive breakage somewhere?

This used to be handled in pylab helpers, but because there was some
desire for OO matplotlib and pylab to have the same functionality, and
to simplify the code, I moved the current axes handling into the
figure class.  The core of the current axes handling is what is
causing the problem you have.

Did you see this in the add_axes  docstring

        Eg, if you want two axes that are
        otherwise identical to be added to the axes, make sure you give them
        unique labels:

            add_axes((l,b,w,h), label='1')
            add_axes((l,b,w,h), label='2')

Ie, the problem and the workaround are explicitly mentioned in the
add_axes docs, and since the functionality is fairly core, I am
inclined to leave it.  One might do

for i,data enumerate(mydata):
   a = fig.add_axes(somerect, label='axes%d'%i)

and then update some rect later.

JDH

Hi,
No more traceback with the matplolib cvs version.
However, I observe now some strange behavior.
I join a new example code.
  When you launch the script and press replot button (circle should become a
line in both tab), then switch to the second tab everything ok. But back to
the first tab and press replot (line should become a circle in both tab),
switch to the second tab... still see a line. If you use the  "pan" tool  in
the toolbar and move a bit the graph then the figure is the updated and
become a circle.

Regards,

David


2006/2/20, Steve Chaplin <ste...@ya...>:
>
> On Sun, 2006-02-19 at 22:09 -0800,
> mat...@li... wrote:
> > Here is a quick and dirty minimal code reproducing the problem.
> >
> > David
> [snip ...]
>
> It is slightly obscure - why would you write a callback to display an
> widget in a notebook tab which is not visible? However, the
> FigureCanvasGTK should be able to handle this case so it is a bug.
>
> The problem is with the "canvas2.draw()" line.
> When you run the test the second canvas widget is not immediately
> displayed, so it does not get realized() and its gdk.Window has not been
> created which causes problems with code which uses the gdk.Window. The
> expose_event() code checks for this case with
>     if GTK_WIDGET_DRAWABLE(self):
> but FigureCanvasGTK.draw() was missing this check.
>
> Its fixed now in CVS (I also simplified the draw() code a little).
>
> Steve
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>

Here it goes again. And sorry for the delay, I was busy with other 
things, will catch up...
Yes, I believe it does not conflict with the savefig's 
landscape-vs-portrait handling. Some of the EPS viewers need this flag 
in order to show the plot in its original orientation (read: heads up).

In addition, I find the code in lines 1049-1053 of bakend_ps.py somewhat 
strange: in my understanding, landsape means that the plot's "up" 
direction is oriented to the left, i.e., the plot is rotated 90CCW. This 
has nothing to do with the plot's width and height. However, that's not 
my code I wouldn't like to fix that myself without knowing the original 
author's intent. Comments?

-- Alex

Index: lib/matplotlib/backends/backend_ps.py
===================================================================
RCS file: 
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_ps.py,v
retrieving revision 1.81
diff -r1.81 backend_ps.py
1054a1055,1056
 >         else:
 >             print >>fh, "%%Orientation: Portrait"

Thanks for the fix. I'll try the CVS version ASAP.

The small example I sent was just to reproduce the problem.
I was not able to trace the problem myself as I'm a just a poor scientist
and not a software engineer (even if I like programming)
To make my need a bit more clear:
Roughly, I have a notebook to display my data 3 different ways, each in one
notebook tabs.
Data processing is controlled in the first notebook so after changes I have
to update the plots in the others tabs.
I could update the plot each time I make a tab visible but it will
unnecessarily slow down the switching in between tabs.


Again thank you very much for your help.
And thanks to all matplotlib developers for their great work!
Hope, Numpy/Scipy/Matplotlib/Pytables/Pyvisa/pygtk will attract more and
more users.
I strongly suggest all scientist to try this combination, it's amazingly
powerful.

David

2006/2/20, Steve Chaplin <ste...@ya...>:
>
> On Sun, 2006-02-19 at 22:09 -0800,
> mat...@li... wrote:
> > Here is a quick and dirty minimal code reproducing the problem.
> >
> > David
> [snip ...]
>
> It is slightly obscure - why would you write a callback to display an
> widget in a notebook tab which is not visible? However, the
> FigureCanvasGTK should be able to handle this case so it is a bug.
>
> The problem is with the "canvas2.draw()" line.
> When you run the test the second canvas widget is not immediately
> displayed, so it does not get realized() and its gdk.Window has not been
> created which causes problems with code which uses the gdk.Window. The
> expose_event() code checks for this case with
>     if GTK_WIDGET_DRAWABLE(self):
> but FigureCanvasGTK.draw() was missing this check.
>
> Its fixed now in CVS (I also simplified the draw() code a little).
>
> Steve
>
> Send instant messages to your online friends http://au.messenger.yahoo.co=
m
>
>

On Sun, 2006-02-19 at 22:09 -0800,
mat...@li... wrote:
> Here is a quick and dirty minimal code reproducing the problem.
> 
> David
[snip ...]

It is slightly obscure - why would you write a callback to display an
widget in a notebook tab which is not visible? However, the
FigureCanvasGTK should be able to handle this case so it is a bug.

The problem is with the "canvas2.draw()" line.
When you run the test the second canvas widget is not immediately
displayed, so it does not get realized() and its gdk.Window has not been
created which causes problems with code which uses the gdk.Window. The
expose_event() code checks for this case with 
    if GTK_WIDGET_DRAWABLE(self):
but FigureCanvasGTK.draw() was missing this check.

Its fixed now in CVS (I also simplified the draw() code a little).

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

 I am generating a few hundred graphs and doing so takes on the order of
about 10-15 minutes.  Which seems to me rather slow.  When I profile my cod=
e
it identifies the calls to  get_yticklabels and get_xticklabels as taking
over 90% of the time.  This seems strange but my calls to these functions
are merely a sort round about way of setting the font size of the axis tick
labels and suppressing the text for  the xticklabels.  Is there a more
efficient and cleaner way to do this?
      artist.setp(axes.get_yticklabels(), visible=3DTrue, fontsize=3D7)
      artist.setp(axes.get_xticklabels(), visible=3DFalse)


I am using matplotlib version 0.83.1 and the .png format for my output, if
that helps.  Though the profiler seems to suggest that the output is
blazingly fast and it is only these calls to the get_?ticklabels that are
slow.

Note:
  The "crash" only occurs if you run the script and press directly the
replot button.
If you click on the second page of the notebook then back to the first and
"replot"
no problem. Though no problem at all if the "# GTK+ 2.x style draw()" is
used in
matplotlib_gtk.py

Regards,

David

2006/2/19, David TREMOUILLES <dav...@gm...>:
>
> Here is a quick and dirty minimal code reproducing the problem.
>
> David
>
> 2006/2/17, Steve Chaplin <ste...@ya...>:
> >
> > On Wed, 2006-02-15 at 20:36 -0800,
> > mat...@li... wrote:
> > > Hello,
> > >
> > >     I'm using matplotlib figures in several places at a time in my GT=
K
> >
> > > based app (means different page in a notebook).
> > > I have trace a bug I partially solved but still doubting if it is a
> > > matplotlib bug or a bad design of my app.
> > >
> > > Matplotlib 0.86.2
> > > pygtk-2.8.4
> > > gtk+-2.8.6
> > >
> > > Here is the problem:
> > >
> > > in matplotlib/backends/backend_gtk.py file, in
> > > class FigureCanvasGTK (gtk.DrawingArea, FigureCanvasBase):
> > > ... in:
> > >
> > >  def draw(self):
> > >         # synchronous window redraw (like GTK+ 1.2 used to do)
> > >         # Note: this does not follow the usual way that GTK redraws,
> > >         # which is asynchronous redraw using calls to
> > > gtk_widget_queue_draw(),
> > >         # which triggers an expose-event
> > >
> > >         # GTK+ 2.x style draw()
> > >   1-   self._need_redraw =3D True
> > >   1-   self.queue_draw()
> > >
> > >         # synchronous draw (needed for animation)
> > >   2-   x, y, w, h =3D self.allocation
> > >   2-   if w<3 or h<3: return # empty fig
> > >
> > >   2-   self._pixmap_prepare (w, h)
> > >   2-   self._render_figure(self._pixmap, w, h)
> > >   2-   self._need_redraw =3D False
> > >   2-   self.window.draw_drawable (self.style.fg_gc[self.state],
> > >   2-                                 self._pixmap, 0, 0, 0, 0, w, h)
> > >
> > >
> > > If I use method 1- (and comment 2-) no problem, all run smoothly...
> > > But using the default method, switching on method 2- (and comment 1-)
> > > I get the followig error message when trying to redraw one of the
> > > figure
> > > (the figure is plotted correctly the first time. No change made to th=
e
> > > figure, just redrawing...)
> > >
> > > ***/python2.4/site-packages/matplotlib/backends/backend_gtk.py:298:
> > > GtkWarning: gdk_pixmap_new: assertion `(drawable !=3D NULL) || (depth=
 !=3D
> >
> > > -1)' failed
> > >   self._pixmap_height)
> > > Traceback (most recent call last):
> > > ...
> > >     self.canvas_leak.draw()
> > >   File
> > > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", lin=
e
> >
> > > 250, in draw
> > >     self._pixmap_prepare (w, h)
> > >   File
> > > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", lin=
e
> > > 298, in _pixmap_prepare
> > >     self._pixmap_height)
> > > RuntimeError: could not create GdkPixmap object
> > >
> > > Somebody has a clue ???
> > >
> > Its difficult to say if its bug in backend_gtk.py, it depends on exactl=
y
> > what your application is doing. You would need to post a minimal test
> > case that demonstrates the bug so we could see whats going on.
> >
> > Steve
> >
> > Send instant messages to your online friends
> > http://au.messenger.yahoo.com
> >
> >
>
>

Here is a quick and dirty minimal code reproducing the problem.

David

2006/2/17, Steve Chaplin <ste...@ya...>:
>
> On Wed, 2006-02-15 at 20:36 -0800,
> mat...@li... wrote:
> > Hello,
> >
> >     I'm using matplotlib figures in several places at a time in my GTK
> > based app (means different page in a notebook).
> > I have trace a bug I partially solved but still doubting if it is a
> > matplotlib bug or a bad design of my app.
> >
> > Matplotlib 0.86.2
> > pygtk-2.8.4
> > gtk+-2.8.6
> >
> > Here is the problem:
> >
> > in matplotlib/backends/backend_gtk.py file, in
> > class FigureCanvasGTK (gtk.DrawingArea, FigureCanvasBase):
> > ... in:
> >
> >  def draw(self):
> >         # synchronous window redraw (like GTK+ 1.2 used to do)
> >         # Note: this does not follow the usual way that GTK redraws,
> >         # which is asynchronous redraw using calls to
> > gtk_widget_queue_draw(),
> >         # which triggers an expose-event
> >
> >         # GTK+ 2.x style draw()
> >   1-   self._need_redraw = True
> >   1-   self.queue_draw()
> >
> >         # synchronous draw (needed for animation)
> >   2-   x, y, w, h = self.allocation
> >   2-   if w<3 or h<3: return # empty fig
> >
> >   2-   self._pixmap_prepare (w, h)
> >   2-   self._render_figure(self._pixmap, w, h)
> >   2-   self._need_redraw = False
> >   2-   self.window.draw_drawable (self.style.fg_gc[self.state],
> >   2-                                 self._pixmap, 0, 0, 0, 0, w, h)
> >
> >
> > If I use method 1- (and comment 2-) no problem, all run smoothly...
> > But using the default method, switching on method 2- (and comment 1-)
> > I get the followig error message when trying to redraw one of the
> > figure
> > (the figure is plotted correctly the first time. No change made to the
> > figure, just redrawing...)
> >
> > ***/python2.4/site-packages/matplotlib/backends/backend_gtk.py:298:
> > GtkWarning: gdk_pixmap_new: assertion `(drawable != NULL) || (depth !=
> > -1)' failed
> >   self._pixmap_height)
> > Traceback (most recent call last):
> > ...
> >     self.canvas_leak.draw()
> >   File
> > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> > 250, in draw
> >     self._pixmap_prepare (w, h)
> >   File
> > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> > 298, in _pixmap_prepare
> >     self._pixmap_height)
> > RuntimeError: could not create GdkPixmap object
> >
> > Somebody has a clue ???
> >
> Its difficult to say if its bug in backend_gtk.py, it depends on exactly
> what your application is doing. You would need to post a minimal test
> case that demonstrates the bug so we could see whats going on.
>
> Steve
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>

Hi,

I've got a situation where I'd like to create several instances of Axes
but not set their position until later. It seems I have to jump through
hoops to actually create a new axes, contrary to my expectation:

$ ipython -pylab
In [1]: a=axes()

In [2]: a
Out[2]: <matplotlib.axes.Subplot instance at 0x2aaab158a758>

In [3]: b=axes()

In [4]: b
Out[4]: <matplotlib.axes.Subplot instance at 0x2aaab158a758>

I can see what's happening here:

 1. pylab.axes() calls subplot(111) when no arguments are given.
 2. subplot(111) uses some smarts to figure out if an Axes instance for
subplot(111) has already been given and, if so, returns a reference to that.

Both points 1 and 2 seem reasonable on their own, but when combined, as
in my example, the outcome is not intuitive. Is this behavior desired?
Does anyone depend on it?

It goes deeper -- even Figure.add_axes() returns an old Axes instance if
the rect given has been seen before. I'd argue that people delving into
the OO innards of matplotlib should be able to handle keeping a
reference to instances of Axes they've created. Can we change this
behavior or would it cause massive breakage somewhere?

Cheers!
Andrew

I'm having two problems with the QtAgg backend. If I do:

>>> from pylab import *
>>> plot([1,2])
[<matplotlib.lines.Line2D instance at 0x2aaab1ead830>]
>>> show()

My figure window should be 8in x 6in, but instead it is 6in tall and as wid=
e=20
as my screen will allow. So thats the first issue. The second is this: if I=
=20
close that window, and then do

>>> plot([1,2])
[<matplotlib.lines.Line2D instance at 0x2aaab1ebbcf8>]
>>> show()

I get the following traceback:

Traceback (most recent call last):
=A0 File "<stdin>", line 1, in ?
=A0 File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt=
=2Epy",=20
line 47, in show
=A0 =A0 manager.window.show()
RuntimeError: underlying C/C++ object has been deleted

I'm using qt version 3.3.4, with cvs mpl 0.86.2, on a gentoo linux system. =
The=20
only nondefault rc setting is the choice of backend.

Darren

Ew.  Ok.  No thanks.  :-)  I'll just stick with numpy 0.9.4 for now.

I appreciate the speedy response.

--bb

On 2/17/06, David M. Cooke <co...@ph...> wrote:
>
> Bill Baxter <wb...@gm...> writes:
>
> > After upgrading to numpy 0.9.5 (numpy-0.9.5.win32-py2.4.exe) running th=
e
> > following script causes a crash of python.exe:
> >
> > -------------test.py-----------------
> > import pylab
> > ----------------------------------------
> >
> >
> > In my .matplotlibrc file I have the following:
> > -------------
> > backend : WXAgg
> > numerix : numpy
> > -------------
> >
> >
> > Reinstalling numpy 0.9.4 fixed the problem.
> >
> > Matplotlib version is 0.86.2-win32-py2.4
> > I also tried reinstalling matplotlib, but that didn't help.
>
> You'll have to recompile matplotlib against the newer numpy.
>
> --
> |>|\/|<
>
> /------------------------------------------------------------------------=
--\
> |David M. Cooke
> http://arbutus.physics.mcmaster.ca/dmc/
> |co...@ph...
>



--
William V. Baxter III
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan  154-0023
+81 (3) 3422-3380

Bill Baxter <wb...@gm...> writes:

> After upgrading to numpy 0.9.5 (numpy-0.9.5.win32-py2.4.exe) running the
> following script causes a crash of python.exe:
>
> -------------test.py-----------------
> import pylab
> ----------------------------------------
>
>
> In my .matplotlibrc file I have the following:
> -------------
> backend : WXAgg
> numerix : numpy
> -------------
>
>
> Reinstalling numpy 0.9.4 fixed the problem.
>
> Matplotlib version is 0.86.2-win32-py2.4
> I also tried reinstalling matplotlib, but that didn't help.

You'll have to recompile matplotlib against the newer numpy.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

After upgrading to numpy 0.9.5 (numpy-0.9.5.win32-py2.4.exe) running the
following script causes a crash of python.exe:

-------------test.py-----------------
import pylab
----------------------------------------


In my .matplotlibrc file I have the following:
-------------
backend : WXAgg
numerix : numpy
-------------


Reinstalling numpy 0.9.4 fixed the problem.

Matplotlib version is 0.86.2-win32-py2.4
I also tried reinstalling matplotlib, but that didn't help.

--Bill Baxter

On Wed, 2006-02-15 at 20:36 -0800,
mat...@li... wrote:
> Hello,
> 
>     I'm using matplotlib figures in several places at a time in my GTK
> based app (means different page in a notebook).
> I have trace a bug I partially solved but still doubting if it is a
> matplotlib bug or a bad design of my app.
> 
> Matplotlib 0.86.2
> pygtk-2.8.4
> gtk+-2.8.6
> 
> Here is the problem:
> 
> in matplotlib/backends/backend_gtk.py file, in 
> class FigureCanvasGTK (gtk.DrawingArea, FigureCanvasBase):
> ... in:
> 
>  def draw(self):
>         # synchronous window redraw (like GTK+ 1.2 used to do)
>         # Note: this does not follow the usual way that GTK redraws,
>         # which is asynchronous redraw using calls to
> gtk_widget_queue_draw(),
>         # which triggers an expose-event
> 
>         # GTK+ 2.x style draw()
>   1-   self._need_redraw = True
>   1-   self.queue_draw()
> 
>         # synchronous draw (needed for animation)
>   2-   x, y, w, h = self.allocation
>   2-   if w<3 or h<3: return # empty fig
> 
>   2-   self._pixmap_prepare (w, h)
>   2-   self._render_figure(self._pixmap, w, h)
>   2-   self._need_redraw = False
>   2-   self.window.draw_drawable (self.style.fg_gc[self.state],
>   2-                                 self._pixmap, 0, 0, 0, 0, w, h)
> 
> 
> If I use method 1- (and comment 2-) no problem, all run smoothly...
> But using the default method, switching on method 2- (and comment 1-)
> I get the followig error message when trying to redraw one of the
> figure
> (the figure is plotted correctly the first time. No change made to the
> figure, just redrawing...)
> 
> ***/python2.4/site-packages/matplotlib/backends/backend_gtk.py:298:
> GtkWarning: gdk_pixmap_new: assertion `(drawable != NULL) || (depth !=
> -1)' failed
>   self._pixmap_height)
> Traceback (most recent call last):
> ... 
>     self.canvas_leak.draw()
>   File
> "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> 250, in draw
>     self._pixmap_prepare (w, h)
>   File
> "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> 298, in _pixmap_prepare
>     self._pixmap_height)
> RuntimeError: could not create GdkPixmap object
> 
> Somebody has a clue ???
> 
Its difficult to say if its bug in backend_gtk.py, it depends on exactly
what your application is doing. You would need to post a minimal test
case that demonstrates the bug so we could see whats going on.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

"Sajec, Mike TQO" <ms...@tq...> writes:

> Instead of only accepting an (mxn) matrix (x) and creating (n) boxplots
> from the columns of (x), optionally in place of the (mxn) matrix accept
> a list of numeric arrays which can be any length, and create boxplots
> for each of the arrays in the list.

In my opinion the idea is good. You can get the same result by calling
boxplot separately for each array, but then you need to keep track of
the positions and fix the axis limits manually afterwards. E.g.,

x1 = normal(10,3,[100,3])
x2 = normal(10,5,[150,2])
x3 = normal(10,1,[1000,4])
pos = 1
for x in x1, x2, x3:
    newpos = pos + x.shape[1]
    boxplot(x, positions=range(pos, newpos))
    pos = newpos
axis([0.5, pos-0.5, 0, 30])

Your implementation seems to reshape each array to only have one
column. I think it would be more useful and less surprising to plot
each column of each array in the list, as in the example above.

-- 
Jouni

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> Starting from CVS mpl, I tested examples/quadmesh_demo.py
    Eric> and found that it worked only with numarray; Numeric and
    Eric> numpy refused to cast the Float64 X and Y arrays to Float32.
    Eric> So I fixed that in CVS by using the astype method.  Now the
    Eric> demo works with numpy and numarray, but segfaults with
    Eric> Numeric.  I have not tried to track the problem down; it is
    Eric> very low priority for me.  Given the momentum towards numpy,
    Eric> it might not be worth tracking down at all.

I'm a little hesitant to leave in a segfault because they can be
very difficult to track down.  Perhaps Alex and/or Paul can address
this.

If it proves too difficult, we should at least check for Numeric in
calls to quadmesh and generate a warning before the segfault occurs.

JDH

>>>>> "Sajec," == Sajec, Mike TQO <ms...@tq...> writes:

    Sajec> I would like to propose modifying the boxplot function as
    Sajec> follows: Instead of only accepting an (mxn) matrix (x) and
    Sajec> creating (n) boxplots from the columns of (x), optionally
    Sajec> in place of the (mxn) matrix accept a list of numeric
    Sajec> arrays which can be any length, and create boxplots for
    Sajec> each of the arrays in the list.

Since I have never used boxplot I don't feel qualified to comment on
this, so I suggest you bring it up on the user's list.  If noone
objects, and you send me a patch against CVS, I'll include it.

Thanks,
JDH