matplotlib-users Mailing List for matplotlib

Hi All,
i'm starting to learn matplotlib,
for my study i need to parse the nmea sentence from a gps
and plot a "sky graphic" to plot satellite visibility.
(i tried to write code from scratch ... it works but my teacher 
suggest me to not reinvent the well, so, to have a good nema parser, i 
installed gpsd ... it has in the source code a nice python code that 
allow me to retrieve satellite constallation iformation).
now i need to learn how to produce a sky plot,
have you any suggestion on how to produce such kind of graphic ?
thanks to all for any suggestion!
Massimo.

sorry, i replied to Mike and not to the list. see below.
On Thu, Jul 2, 2009 at 2:57 PM, Ralf Gommers <ral...@go...>wrote:
> Thanks for looking into this Mike.
>
> On Thu, Jul 2, 2009 at 10:39 AM, Michael Droettboom <md...@st...>wrote:
>
>> It is not surprising that memory usage is much lower without printing the
>> plot. Very little is actually done by the "plot" command other than setting
>> up a tree of objects that is later rendered during the printing process
>> (where most of the work happens).
>>
>> The attached script based on what you provided doesn't leak memory for me
>> with matplotlib 0.98.5.2. It would appear that there is something else in
>> your application triggering the leak. Perhaps there is something holding a
>> reference longer than it should?
>>
>
> Your attached script memleak2.py is indeed fine, it never takes up more
> than 60Mb of RAM. But did you try to run the PyQt4 GUI I attached? There
> the same save_png() function does increase memory usage for each call.
>
> I'm not sure how to exactly measure memory usage for a GUI program, but it
> is so large I can look at "System Activity" (or Task Manager on XP) and get
> the approximate number:
>
> Loading the GUI: 30.5Mb
> 1st call to save_png: 82Mb
> 2nd call: 116Mb
> 10th call: 380Mb
>
> I can see the memory usage drop after some calls, so I guess it is a
> problem of references being held and sometimes being released as you said.
> But memory use does seem to be unbounded. Waiting for minutes, or
> interacting with the GUI, never releases any memory. It is strange, the
> PyQt4 demo program is fine by itself, save_png() is fine by itself, but
> combine them and there's a memory problem.
>
> Cheers,
> Ralf
>
>
>
>> You can see from the attached massif plots that memory usage never becomes
>> unbounded. It is normal for Python to delay deallocation for efficiency
>> reasons. Calling gc.collect (the second graph) does help keep memory usage
>> more compact however, if that is a primary concern.
>>
>> Cheers,
>> Mike
>>
>> Ralf Gommers wrote:
>>
>>> Hi,
>>>
>>> I am working on a PyQt4 application with some embedded MPL figures, and
>>> am also trying to save some figures as png's without displaying them. I am
>>> observing huge memory increases (10s or 100s of Mb) the moment I try to save
>>> a png. I reproduced the issue by combining two mpl examples,
>>> http://matplotlib.sourceforge.net/examples/user_interfaces/embedding_in_qt4.htmland
>>> http://matplotlib.sourceforge.net/examples/api/agg_oo.html. Full code is
>>> attached. When pressing the "save figure" button, memory usage shoots up,
>>> multiple clicks keep sending it higher (although not monotonically).
>>>
>>> I tested on two different platforms
>>> - Matplotlib 98.5.2 and Python 2.6.2 on Ubuntu.
>>> - latest Enthought Python Distribution on Windows XP.
>>>
>>> The function that does the png saving is:
>>>
>>> def save_png():
>>> """Save an image as a png file"""
>>>
>>> pngpath = 'test_mplsave.png'
>>>
>>> fig = Figure()
>>> canvas = FigureCanvas(fig)
>>> ax = fig.add_subplot(111)
>>> x = arange(5e3)
>>> ax.plot(x, sin(x))
>>> canvas.print_figure(pngpath)
>>>
>>> ## tried all things commented out below, all makes no difference ##
>>> #fig.savefig(pngpath)
>>>
>>> #del(fig)
>>> #del(canvas)
>>> #del(ax)
>>>
>>> #import matplotlib.pyplot as plt
>>> #plt.close(fig)
>>>
>>> #import gc
>>> #gc.collect()
>>>
>>> Commenting out the canvas.print_figure line fixes the issue.
>>>
>>> Am I doing something obviously wrong, or mixing two incompatible ways of
>>> doing things?
>>>
>>> Cheers,
>>> Ralf
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> from matplotlib.backends.backend_agg import FigureCanvasAgg as
>> FigureCanvas
>> from matplotlib.figure import Figure
>>
>> from numpy import arange, sin
>>
>> import gc
>>
>> def save_png():
>> """Save an image as a png file"""
>>
>> pngpath = 'test_mplsave.png'
>>
>> fig = Figure()
>> canvas = FigureCanvas(fig)
>> ax = fig.add_subplot(111)
>> x = arange(5e3)
>> ax.plot(x, sin(x))
>> canvas.print_figure(pngpath)
>>
>> # The below is not necessary to prevent a leak, but it does make
>> # memory usage more compact
>> gc.collect()
>>
>> for i in range(100):
>> save_png()
>>
>>
>>
>>
>

Is this an ideas thread?
How about a "copy image to clipboard" button for the toolbar.
Gary R.
Pierre GM wrote:
> Eh, can I play ?
> * Something I'd really like to see is a way to access a given patch/ 
> line/collection/... by a string (a name) instead of having to find the 
> corresponding element in a list. That would mean converting lists into 
> dictionaries, or at least provide a way to map the list to a dictionary.
> An example of application would be "del lines['first']" to delete the 
> line named 'first'. By default, if no name is explicitly given to an 
> object, we could use the order in which it is drawn...

The dropbox link is broken (you need a public url).
What version of mpl and what backend are you using?
There was a similar problem which has now been fixed.
Try the work-around described in the thread below, and see if works.
http://www.nabble.com/problems-with-contourf---alpha-td22553269.html
Regards,
-JJ
On Thu, Jul 2, 2009 at 4:26 PM, Rick Muller<rpm...@gm...> wrote:
> When I do contourf plots in matplotlib, I get lines connecting the contour
> levels. This doesn't only appear to be an artifact of my plotting
> algorithms, it appears in this example from the matplotlib cookbook:
>
> http://www.scipy.org/Cookbook/Matplotlib/Gridding_irregularly_spaced_data
>
> at least on my mac.
>
> (I think this is the link to the output I get from that:
> https://dl-web.getdropbox.com/get/Photos/griddata-test.png?w=007c9af9
> )
>
> Is there a way to keep these lines from happening? If not, is there a way to
> turn off all of the black lines separating the contour levels?
>
> Thanks in advance,
>
> Rick
>
> --
> Rick Muller
> rpm...@gm...
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

When I do contourf plots in matplotlib, I get lines connecting the contour
levels. This doesn't only appear to be an artifact of my plotting
algorithms, it appears in this example from the matplotlib cookbook:
http://www.scipy.org/Cookbook/Matplotlib/Gridding_irregularly_spaced_data
at least on my mac.
(I think this is the link to the output I get from that:
https://dl-web.getdropbox.com/get/Photos/griddata-test.png?w=007c9af9
)
Is there a way to keep these lines from happening? If not, is there a way to
turn off all of the black lines separating the contour levels?
Thanks in advance,
Rick
-- 
Rick Muller
rpm...@gm...

OK, thanks. I don't really know why it's failing, but I'm going to continue
trying to get other backends installed to test them. 
I also now have independent reasons not to use the MacOSX backend:
Thu Jul 2 14:51:48 Python-64[56094] <Error>: CGContextSetLineDash: invalid
dash array: negative lengths are not allowed.
I can't draw dashed lines.
Adam
-- 
View this message in context: http://www.nabble.com/ipython-threading-fails-with-macosx-backend-tp24311071p24313852.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi,
For a contour plot I use the option 'manual=True' in clabel
to set the location of the labels manually.
Before the plotting command I set some figure properties using
rcParams as explained on this site:
http://www.scipy.org/Cookbook/Matplotlib/LaTeX_Examples
My Problem is, that the manual-option changes the figure 
properties and when I use savefig I get a very different result
compared to 'manual=False'.
Is there some way to prevent this or alternatively set the 
properties after manually setting the labels?
Thanks in advance,
Valentin
Here is an example.
=====================================
from math import pi
import numpy as np
import pylab as pl
#######################
fig_width_pt = 246.0 # Get this from LaTeX using \showthe\columnwidth
inches_per_pt = 1.0/72.27 # Convert pt to inch
golden_mean = 1 #(sqrt(5)-1.0)/2.0 # Aesthetic ratio
fig_width = fig_width_pt*inches_per_pt # width in inches
fig_height =fig_width*golden_mean # height in inches
fig_width = fig_width
fig_size = [fig_width,fig_height]
params = {'backend': 'ps',
 'axes.labelsize': 10,
 'text.fontsize': 10,
 'legend.fontsize': 10,
 'xtick.labelsize': 8,
 'ytick.labelsize': 8,
 'figure.figsize': fig_size}
pl.rcParams.update(params)
ax = pl.axes([0.15, 0.15, 0.8, 0.8])
dummy = np.linspace(0, 2*pi, 101)
s, t = np.meshgrid(dummy, dummy)
f = np.sin(2*s)**2* np.cos(t)
cs = pl.contour(s, t, f) 
pl.clabel(cs, manual=True)
pl.xlim(0, 2*pi)
pl.ylim(0, 2*pi)
pl.savefig('test.png')
=====================================

On Thu, Jul 2, 2009 at 1:00 PM, Pierre GM<pgm...@gm...> wrote:
> Eh, can I play ?
> * Something I'd really like to see is a way to access a given patch/
> line/collection/... by a string (a name) instead of having to find the
> corresponding element in a list. That would mean converting lists into
> dictionaries, or at least provide a way to map the list to a dictionary.
> An example of application would be "del lines['first']" to delete the
> line named 'first'. By default, if no name is explicitly given to an
> object, we could use the order in which it is drawn...
>
Take a look at findobj with an arbitrary match function (eg set the
label property on the obj you want to find and then call find obj with
a function that checks the label)
http://matplotlib.sourceforge.net/examples/pylab_examples/findobj_demo.html

As I understand it the Mac backend uses the PyOS_ImputHook trick, which
means that no custom threading code is needed in IPython. Thus it should
"just work" without any threading flags in both IPython *and* regular
python. Just as an aside, wx is the only GUI toolkit that doesn't support
this "new" type of interactive usage. We (ipython devs) are working with
the wx devs to change that. Once that is done, we should be able to get rid
of all the nasty threading code in ipython. More details will follow.
Cheers,
Brian
On Thu, Jul 2, 2009 at 10:48 AM, Michael Droettboom <md...@st...> wrote:
> The Mac OS backend is fairly new, and I don't believe any of the
> backend-specific threading code that ipython requires has been
> implemented for the OS-X backend. Just wanted to drop a note to say
> "it's probably not you". But as a non-Mac user, I may be wrong, and I
> hope to be corrected :)
>
> Michiel: any idea how much effort would be involved here?
>
> Cheers,
> Mike
>
> keflavich wrote:
> > Hi, I'm using ipython 0.9.1 with the svn version of matplotlib on 64 bit
> > python on mac os x 10.5.7.
> >
> > I have only been able to get python-64 running with the MacOSX backend;
> all
> > of the others (wxpython, gtk, qt, tk) have failed for one reason or
> another.
> >
> > I've tried ipython without any flags and importing pylab on the command
> > line:
> > from pylab import *
> > and ipython -pylab,
> > and then plotting from a script. I retain access to the command line
> unless
> > I type "show()" at the command line, at which point I can't return to the
> > command line unless I close all of my graphics windows.
> >
> > I don't have this problem when running 32 bit python with qt or tk as the
> > backends.
> >
> > Is this an error? Should there be a command-line flag for ipython to
> start
> > threading for MacOSX specifically?
> >
> > Thanks,
> > Adam
> >
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On my system, this example appears to be working just fine. I even bumped
the number of data points from 1000 to 10,000. I'm on OS X 10.5.7 with:
matplotlib 0.98.5.2
PyQt 4.5.1 (GPL)
Qt 4.5 (LGPL)
Maybe try updating your PyQt installation?
BZ
On Thu, Jul 2, 2009 at 6:46 AM, Ole Streicher <ole...@gm...>wrote:
> Hello Darren,
>
> OK, in this context it seems to work.
>
> I attach a script that shows the problem.
>
> Run it, move the second diagram below the first, adjust their sizes so
> that they take roughly the same size:
>
> +---------------+-------+
> | Diagram 1 | |
> | | |
> | | Hello |
> +---------------+ World |
> | Diagram 2 | |
> | | |
> | | |
> +---------------+-------+
>
> (you will see that the Diagram 2 will not alway update properly :-( [*] )
> and then move the slider between the diagrams and the "Hello World"
> label. There is a good chance that the program will segfault. If it does
> not, increase the number of points in the diagrams.
>
> BTW,could you reproduce my last example with diagram and scrollbar? It
> still remains unsolved (and is reproduced here [*]).
>
> Versions (all 64 bit):
>
> openSUSE 11.1:
> Qt Open Source Edition 4.4.3
> PyQt 4.4.3
> Matplotlib 0.98.5.2
>
> Kubuntu 9.04:
> Qt Open Source Edition 4.5.0
> PyQt 4.4.4
> Matplotlib 0.98.5.2
>
> Best regards
>
> Ole
>

Eh, can I play ?
* Something I'd really like to see is a way to access a given patch/ 
line/collection/... by a string (a name) instead of having to find the 
corresponding element in a list. That would mean converting lists into 
dictionaries, or at least provide a way to map the list to a dictionary.
An example of application would be "del lines['first']" to delete the 
line named 'first'. By default, if no name is explicitly given to an 
object, we could use the order in which it is drawn...

On Thu, Jul 2, 2009 at 9:46 AM, Ole Streicher <ole...@gm...>wrote:
> Hello Darren,
>
> Darren Dale <dsd...@gm...> writes:
> > I can't produce a segfault with the attached script. I have Qt-4.5.2,
> > PyQt-4.5.1, and a checkout of the matplotlib trunk.
>
> OK, in this context it seems to work.
>
> I attach a script that shows the problem.
>
> Run it, move the second diagram below the first, adjust their sizes so
> that they take roughly the same size:
>
> +---------------+-------+
> | Diagram 1 | |
> | | |
> | | Hello |
> +---------------+ World |
> | Diagram 2 | |
> | | |
> | | |
> +---------------+-------+
>
> (you will see that the Diagram 2 will not alway update properly :-( [*] )
> and then move the slider between the diagrams and the "Hello World"
> label. There is a good chance that the program will segfault. If it does
> not, increase the number of points in the diagrams.
>
I can't reproduce the problem. The diagrams update properly and I don't see
a segfault. Maybe it is an issue that was fixed in Qt-4.5.[1,2] or
PyQt-4.5.1.
> BTW,could you reproduce my last example with diagram and scrollbar? It
> still remains unsolved (and is reproduced here [*]).
>
Yes, I responded this afternoon and I have asked on the pyqt mailing list.
Darren

The Mac OS backend is fairly new, and I don't believe any of the 
backend-specific threading code that ipython requires has been 
implemented for the OS-X backend. Just wanted to drop a note to say 
"it's probably not you". But as a non-Mac user, I may be wrong, and I 
hope to be corrected :)
Michiel: any idea how much effort would be involved here?
Cheers,
Mike
keflavich wrote:
> Hi, I'm using ipython 0.9.1 with the svn version of matplotlib on 64 bit
> python on mac os x 10.5.7.
>
> I have only been able to get python-64 running with the MacOSX backend; all
> of the others (wxpython, gtk, qt, tk) have failed for one reason or another. 
>
> I've tried ipython without any flags and importing pylab on the command
> line:
> from pylab import *
> and ipython -pylab,
> and then plotting from a script. I retain access to the command line unless
> I type "show()" at the command line, at which point I can't return to the
> command line unless I close all of my graphics windows.
>
> I don't have this problem when running 32 bit python with qt or tk as the
> backends.
>
> Is this an error? Should there be a command-line flag for ipython to start
> threading for MacOSX specifically?
>
> Thanks,
> Adam
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi, I'm using ipython 0.9.1 with the svn version of matplotlib on 64 bit
python on mac os x 10.5.7.
I have only been able to get python-64 running with the MacOSX backend; all
of the others (wxpython, gtk, qt, tk) have failed for one reason or another. 
I've tried ipython without any flags and importing pylab on the command
line:
from pylab import *
and ipython -pylab,
and then plotting from a script. I retain access to the command line unless
I type "show()" at the command line, at which point I can't return to the
command line unless I close all of my graphics windows.
I don't have this problem when running 32 bit python with qt or tk as the
backends.
Is this an error? Should there be a command-line flag for ipython to start
threading for MacOSX specifically?
Thanks,
Adam
-- 
View this message in context: http://www.nabble.com/ipython-threading-fails-with-macosx-backend-tp24311071p24311071.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Yep, the same library (physical, on our network) fails depending only
the computer, thus on its own internal libraries called by GEOS.
By the way, I tried basemap with geos 3.0.4, and saw the "simplify()"
method working. That's funny!
On Thu, Jul 2, 2009 at 2:08 PM, Jeff Whitaker<js...@fa...> wrote:
> Stephane Raynaud wrote:
>>
>> Hi (Jeff),
>>
>>
>> I recently performed updates to matplotlib and basemap.
>> >From this time, I have a random and reccurent error when I create a
>> Basemap instance.
>> Here is one example :
>>
>>
>>>>>
>>>>> from mpl_toolkits.basemap import Basemap
>>>>> Basemap(**{'lon_0': -4.5250263598141309, 'urcrnrlat':
>>>>> 49.140154231678416, 'projection': 'cyl', 'llcrnrlon': -7.2999968048710144,
>>>>> 'lat_ts': 47.468781818043126, 'urcrnrlon': -1.7500559147572474,
>>>>> 'area_thresh': 0.1, 'llcrnrlat': 45.797409404407844, 'resolution': 'i',
>>>>> 'lat_0': 47.468781818043126})
>>>>>
>>
>> GEOS_ERROR: TopologyException: found non-noded intersection between
>> 8.67583 4.66292, 8.70206 4.66997 and 8.71039 4.67664, 8.67708 4.64997
>> 8.70205 4.66997
>>
>> It depends on the area and the resolution (polygons).
>>
>> I have version '0.99.3' of basemap.
>>
>> Any idea?
>>
>
> Stephane: I'd say it's an issue with your geos library installation that
> basemap is linking to. I don't see that error using your example for geos
> 2.2.3 or geos 3.0.3.
>
> I'd suggest rebuilding the geos library, then recompiling basemap.
>
> -Jeff
>
-- 
Stephane Raynaud

I can reproduce the error with the svn version.
It seems that the problem is not SubplotHost specific, i.e., you have
same problem if you use mpl's original axes with twinx.
I think it has something to do with the axes sharing in general.
Preventing autoscale of xaxis suppress the error.
host.set_autoscalex_on(False)
par1.set_autoscalex_on(False)
par2.set_autoscalex_on(False)
But you have to manually adjust the x-limits later
par1.set_xlim(dates[0], dates[-1])
However, autofmt_xdata does not work. And I guess this is a bug in the
SubplotHost. I may take a more look later today.
Regards,
-JJ
On Sun, Jun 28, 2009 at 1:34 PM, David GUERINEAU<da...@gu...> wrote:
> Hi matplotlib_users !
>
> I'm David from Berlin, and believe I'm experiencing some problem with the
> SubplotHost module:
>
> I'm generating graphs from hudge databases of cpu and ethernet statistics,
> and I wanted to mix several graphs concerning ethernet statistics in the
> same figure,
> with time as x axis, and bytes-in, bytes-out, packets-in, packets-out and
> number of
> collisions as three different y axes, with three different scale.
>
> I took the inspiration from
>
> for the x axes and from
>
> http://matplotlib.sourceforge.net/examples/axes_grid/demo_parasite_axes2.html
> for the y axes
>
> The following code is a synthetic reproduction of the problem I'm
> experiencing (it is also attached):
>
> from matplotlib.dates import date2num
> from matplotlib import pyplot
> from matplotlib import pylab
> from mpl_toolkits.axes_grid.parasite_axes import SubplotHost
> from datetime import datetime
>
> dates = [ 733581.20833333337, 733581.20837962965, 733581.20842592593,
> 733581.20847222221, 733581.20851851848,
>    733581.20855324075, 733581.20858796302, 733581.2086342593,
> 733581.20866898145, 733581.20871527772]
> rxB = [054L, 130L, 144L, 54L, 36L, 9L, 35L, 43L, 85L, 43L]
> txB = [4L, 9L, 9L, 5L, 4L, 4L, 4L, 5L, 6L, 5L]
> rxP = [77, 228, 251, 112, 77, 42, 75, 97, 147, 91]
> txP = [61, 177, 188, 90, 61, 40, 64, 76, 113, 77]
> col = [1, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>
> ethPlot = pyplot
> fig = ethPlot.figure()
> host = SubplotHost(fig, 111)
>
> host.set_ylabel("kB/s")
> host.set_xlabel("Time")
>
> par1 = host.twinx()
> par2 = host.twinx()
>
> par1.set_ylabel("Packets/s")
>
> par2.axis["right"].set_visible(False)
>
> offset = 60, 0
> new_axisline = par2.get_grid_helper().new_fixed_axis
> par2.axis["right2"] = new_axisline(loc="right",
>           axes=par2,
>           offset=offset)
>
> par2.axis["right2"].label.set_visible(True)
> par2.axis["right2"].set_label("Collisions")
>
> par1.set_ylim(0, 6000)
> par2.set_ylim(0, 7000)
>
> host.axis([ dates[0], ( dates[0] + 0.041 ), -7000, 7000])
> par1.axis([ dates[0], ( dates[0] + 0.041 ), -10000, 10000])
> par2.axis([ dates[0], ( dates[0] + 0.041 ), -700, 700])
>
> fig.add_axes(host)
> ethPlot.subplots_adjust(right=0.75)
>
> drawRxByt, = host.plot_date(dates, rxB, 'g', tz=None, xdate=True,
> ydate=False, label="kB/s in")
> drawTxByt, = host.plot_date(dates, txB, 'b', tz=None, xdate=True,
> ydate=False, label="kB/s out")
> drawRxPaq, = par1.plot_date(dates, rxP, 'm', tz=None, xdate=True,
> ydate=False, label="packets/s in")
> drawTxPaq, = par1.plot_date(dates, txP, 'y', tz=None, xdate=True,
> ydate=False, label="packets/s out")
> drawColls, = par2.plot_date(dates, col, 'r', tz=None, xdate=True,
> ydate=False, label="collisions")
>
> fig.autofmt_xdate()
>
> host.set_xlabel("Time")
> host.set_ylabel("kB/s")
> par1.set_ylabel("Packets/s")
>
> host.legend()
>
> host.axis["left"].label.set_color(drawRxByt.get_color())
> host.axis["left"].label.set_color(drawTxByt.get_color())
> par1.axis["right"].label.set_color(drawRxPaq.get_color())
> par1.axis["right"].label.set_color(drawtxPaq.get_color())
> par2.axis["right2"].label.set_color(drawColls.get_color())
>
> ethPlot.draw()
> pylab.savefig( './test.png', dpi=(640/8))
>
>
>
>
> Maybe I do something wrong somewhere here, but other scripts that do the
> same for a single graphwork like a charm. So it's not a question of dataType
> or something. To compare with a working code, here is the first version of
> the fuction that does the job on single graphs without any problem :
>
> def drawEthGraph(filename, hdates, rxP, txP, rxB, txB, col):
>  ethPlot = pyplot
>  fig = ethPlot.figure()
>  ax = fig.add_subplot(111)
>  ax.plot_date(hdates, rxP, 'g', None, True, False)
>  ax.plot_date(hdates, txP, 'b', None, True, False)
>  ax.plot_date(hdates, rxB, 'g', None, True, False)
>  ax.plot_date(hdates, txB, 'b', None, True, False)
>  ax.plot_date(hdates, col, 'r', None, True, False)
>  ax.axis([ hdates[0], ( hdates[0] + 0.042 ), -7000, 7000])
>  ax.grid(True)
>  fig.autofmt_xdate()
>  pylab.savefig( filename, dpi=(640/8))
>
>
> I don't think I understand the whole process of generation, but I thought at
> least at the beginnig I was having a good feeling with this API.
> Now I wonder how to go around this. Maybe you'll have an idea :-o
>
> Best regards
>
> DvD
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hello Darren,
Darren Dale <dsd...@gm...> writes:
> I can't produce a segfault with the attached script. I have Qt-4.5.2,
> PyQt-4.5.1, and a checkout of the matplotlib trunk.
OK, in this context it seems to work.
I attach a script that shows the problem.
Run it, move the second diagram below the first, adjust their sizes so
that they take roughly the same size:
+---------------+-------+
| Diagram 1 | |
| | |
| | Hello |
+---------------+ World |
| Diagram 2 | |
| | |
| | |
+---------------+-------+
(you will see that the Diagram 2 will not alway update properly :-( [*] )
and then move the slider between the diagrams and the "Hello World"
label. There is a good chance that the program will segfault. If it does
not, increase the number of points in the diagrams.
BTW,could you reproduce my last example with diagram and scrollbar? It
still remains unsolved (and is reproduced here [*]).
Versions (all 64 bit):
openSUSE 11.1:
Qt Open Source Edition 4.4.3
PyQt 4.4.3
Matplotlib 0.98.5.2
Kubuntu 9.04:
Qt Open Source Edition 4.5.0
PyQt 4.4.4
Matplotlib 0.98.5.2
Best regards
Ole

Hello Darren,
Darren Dale <dsd...@gm...> writes:
> I can't produce a segfault with the attached script. I have Qt-4.5.2,
> PyQt-4.5.1, and a checkout of the matplotlib trunk.
OK, in this context it seems to work.
I attach a script that shows the problem.
Run it, move the second diagram below the first, adjust their sizes so
that they take roughly the same size:
+---------------+-------+
| Diagram 1 | |
| | |
| | Hello |
+---------------+ World |
| Diagram 2 | |
| | |
| | |
+---------------+-------+
(you will see that the Diagram 2 will not always update properly :-( [*] )
and then move the slider between the diagrams and the "Hello World"
label. There is a good chance that the program will segfault. If it does
not, increase the number of points in the diagrams.
BTW, could you reproduce my last example with diagram and scrollbar? It
still remains unsolved (and is reproduced here [*]).
Versions (all 64 bit):
openSUSE 11.1:
Qt Open Source Edition 4.4.3
PyQt 4.4.3
Matplotlib 0.98.5.2
Kubuntu 9.04:
Qt Open Source Edition 4.5.0
PyQt 4.4.4
Matplotlib 0.98.5.2
Best regards
Ole
------------------------------------8<---------------------------------------
import random
import sys
from PyQt4 import QtGui, QtCore
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as FigureCanvas
from matplotlib.figure import Figure,SubplotParams
class AppForm(QtGui.QMainWindow):
 def __init__(self, parent=None):
 QtGui.QMainWindow.__init__(self, parent)
 self.create_dock_widgets()
 self.resize(700, 600)
 def create_dock_widgets(self):
 self.setDockNestingEnabled(True)
 w1 = QtGui.QDockWidget('Diagram 1', self)
 self.addDockWidget(QtCore.Qt.TopDockWidgetArea, w1)
 w1.setWidget(InnerDiagramWidget(self))
 w2 = QtGui.QDockWidget('Diagram 2', self)
 self.addDockWidget(QtCore.Qt.TopDockWidgetArea, w2)
 w2.setWidget(InnerDiagramWidget(self))
 w3 = QtGui.QDockWidget('Label', self)
 self.addDockWidget(QtCore.Qt.TopDockWidgetArea, w3)
 w3.setWidget(QtGui.QLabel('Hello World'))
 
class InnerDiagramWidget(FigureCanvas):
 def __init__(self, parent):
 fig = Figure()
 self.axes = fig.add_subplot(111)
 # Increase this number to rise your chances for a segfault.
 range = xrange(1000)
 l = [ random.randint(-5, 5) for i in range ]
 self.axes.plot(range, l, drawstyle='steps')
 FigureCanvas.__init__(self, fig)
 self.setParent(parent)
 FigureCanvas.setSizePolicy(self,
 QtGui.QSizePolicy.Expanding,
 QtGui.QSizePolicy.Expanding)
 FigureCanvas.updateGeometry(self)
a = QtGui.QApplication(sys.argv)
w = AppForm()
w.show()
a.exec_()
------------------------------------8<---------------------------------------

It is not surprising that memory usage is much lower without printing 
the plot. Very little is actually done by the "plot" command other than 
setting up a tree of objects that is later rendered during the printing 
process (where most of the work happens).
The attached script based on what you provided doesn't leak memory for 
me with matplotlib 0.98.5.2. It would appear that there is something 
else in your application triggering the leak. Perhaps there is 
something holding a reference longer than it should?
You can see from the attached massif plots that memory usage never 
becomes unbounded. It is normal for Python to delay deallocation for 
efficiency reasons. Calling gc.collect (the second graph) does help 
keep memory usage more compact however, if that is a primary concern.
Cheers,
Mike
Ralf Gommers wrote:
> Hi,
>
> I am working on a PyQt4 application with some embedded MPL figures, 
> and am also trying to save some figures as png's without displaying 
> them. I am observing huge memory increases (10s or 100s of Mb) the 
> moment I try to save a png. I reproduced the issue by combining two 
> mpl examples, 
> http://matplotlib.sourceforge.net/examples/user_interfaces/embedding_in_qt4.html 
> and http://matplotlib.sourceforge.net/examples/api/agg_oo.html. Full 
> code is attached. When pressing the "save figure" button, memory usage 
> shoots up, multiple clicks keep sending it higher (although not 
> monotonically).
>
> I tested on two different platforms
> - Matplotlib 98.5.2 and Python 2.6.2 on Ubuntu.
> - latest Enthought Python Distribution on Windows XP.
>
> The function that does the png saving is:
>
> def save_png():
> """Save an image as a png file"""
>
> pngpath = 'test_mplsave.png'
>
> fig = Figure()
> canvas = FigureCanvas(fig)
> ax = fig.add_subplot(111)
> x = arange(5e3)
> ax.plot(x, sin(x))
> canvas.print_figure(pngpath)
>
> ## tried all things commented out below, all makes no difference ##
> #fig.savefig(pngpath)
>
> #del(fig)
> #del(canvas)
> #del(ax)
>
> #import matplotlib.pyplot as plt
> #plt.close(fig)
>
> #import gc
> #gc.collect()
>
> Commenting out the canvas.print_figure line fixes the issue.
>
> Am I doing something obviously wrong, or mixing two incompatible ways 
> of doing things?
>
> Cheers,
> Ralf
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Jul 2, 2009 at 3:06 AM, Ole Streicher <ole...@gm...>wrote:
> Hi Brian,
>
> I have also some layout problems with the Qt4 backend. The worst one is
> a SegFault when adjusting the width.
>
> Brian Zambrano <br...@gm...> writes:
> > vbox = QVBoxLayout()
> > vbox.addWidget(self.canvas)
> > self.setLayout(vbox)
>
> Could you just try to add a second canvas to the layout?
>
> vbox = QVBoxLayout()
> vbox.addWidget(self.canvas1)
> vbox.addWidget(self.canvas2)
> self.setLayout(vbox)
>
> and then try to adjust the size by moving the separator between the
> central and right widget? In my code, I can reproduce a crash here on
> Linux. Also, depending on the speed (content) of the canvases, the width
> is not always ajusted correctly.
>
> I am still not sure whether this is fault of Qt, PyQt, or matplotlib.
>
I can't produce a segfault with the attached script. I have Qt-4.5.2,
PyQt-4.5.1, and a checkout of the matplotlib trunk.
Darren

Stephane Raynaud wrote:
> Hi (Jeff),
>
>
> I recently performed updates to matplotlib and basemap.
> >From this time, I have a random and reccurent error when I create a
> Basemap instance.
> Here is one example :
>
> 
>>>> from mpl_toolkits.basemap import Basemap
>>>> Basemap(**{'lon_0': -4.5250263598141309, 'urcrnrlat': 49.140154231678416, 'projection': 'cyl', 'llcrnrlon': -7.2999968048710144, 'lat_ts': 47.468781818043126, 'urcrnrlon': -1.7500559147572474, 'area_thresh': 0.1, 'llcrnrlat': 45.797409404407844, 'resolution': 'i', 'lat_0': 47.468781818043126})
>>>> 
>
> GEOS_ERROR: TopologyException: found non-noded intersection between
> 8.67583 4.66292, 8.70206 4.66997 and 8.71039 4.67664, 8.67708 4.64997
> 8.70205 4.66997
>
> It depends on the area and the resolution (polygons).
>
> I have version '0.99.3' of basemap.
>
> Any idea?
> 
Stephane: I'd say it's an issue with your geos library installation 
that basemap is linking to. I don't see that error using your example 
for geos 2.2.3 or geos 3.0.3.
I'd suggest rebuilding the geos library, then recompiling basemap.
-Jeff

Hi (Jeff),
I recently performed updates to matplotlib and basemap.
>From this time, I have a random and reccurent error when I create a
Basemap instance.
Here is one example :
>>> from mpl_toolkits.basemap import Basemap
>>> Basemap(**{'lon_0': -4.5250263598141309, 'urcrnrlat': 49.140154231678416, 'projection': 'cyl', 'llcrnrlon': -7.2999968048710144, 'lat_ts': 47.468781818043126, 'urcrnrlon': -1.7500559147572474, 'area_thresh': 0.1, 'llcrnrlat': 45.797409404407844, 'resolution': 'i', 'lat_0': 47.468781818043126})
GEOS_ERROR: TopologyException: found non-noded intersection between
8.67583 4.66292, 8.70206 4.66997 and 8.71039 4.67664, 8.67708 4.64997
8.70205 4.66997
It depends on the area and the resolution (polygons).
I have version '0.99.3' of basemap.
Any idea?
-- 
Stephane Raynaud

Hi Brian,
I have also some layout problems with the Qt4 backend. The worst one is
a SegFault when adjusting the width.
Brian Zambrano <br...@gm...> writes:
> vbox = QVBoxLayout()
> vbox.addWidget(self.canvas)
> self.setLayout(vbox)
Could you just try to add a second canvas to the layout?
vbox = QVBoxLayout()
vbox.addWidget(self.canvas1)
vbox.addWidget(self.canvas2)
self.setLayout(vbox)
and then try to adjust the size by moving the separator between the
central and right widget? In my code, I can reproduce a crash here on
Linux. Also, depending on the speed (content) of the canvases, the width
is not always ajusted correctly.
I am still not sure whether this is fault of Qt, PyQt, or matplotlib.
Thanks
Ole

Hi all,
I'm having a problem with resizing a FigureCanvas using the Qt4 backend when
the FigureCanvas is used alongside some dock widgets. What happens is that
the figure never grows beyond the original size set when the window or other
dock widgets are expanded. It's probably easier to look at a screenshot
taken after I resized (grew) things a bit:
http://brianz.s3.amazonaws.com/mpl_buggy.png
The simple code I used to generate and test this is located here:
http://brianz.s3.amazonaws.com/mpl_qt_buggy.py.txt
To get the FigureCanvas to resize at all, I'm passing the resizeEvent from
the parent widget down to the FigureCanvas's resizeEvent.
Am I doing something incorrectly here or is this a bug?
Thanks,
BZ

Le mercredi 01 juillet 2009 à 10:13 +0200, Sandro Tosi a écrit :
> On Tue, Jun 30, 2009 at 14:12, Fabrice Silva<si...@lm...> wrote:
> > Le lundi 29 juin 2009 à 16:11 -0400, Jae-Joon Lee a écrit :
> >> In the svn version of matplotlib, there are some helper classes to
> >> ease this job a bit.
> > Thanks for your pointer. Sadly the mpl.toolkits.axes_grid is not shipped
> > by debian package, and downloading it requires other stuff. So I adapted
> 
> I'm the debian maintainer for matplotlib: if you need something
> missing in Debian, get in touch with us, for example reporting a bug
> against matplotlib requesting this toolkit.
> 
> I didn't check further, but probably it was not release because of
> this phrase: "In the svn version of matplotlib".
Hi Sandro,
thanks for packaging matplotlib for debian. I hope you did not
understand my words as a blame. In fact mpl_toolkits.axes_grid is still
in svn only and not in 0.98.x
I tried to download the mpl.toolkits.axes_grid module files, but I had
errors raising when importing that...
-- 
Fabrice Silva <si...@lm...>
LMA UPR CNRS 7051