matplotlib-users Mailing List for matplotlib

Jason Heeris, on 2011年04月21日 12:23, wrote:
> I'm playing around with using Matplotlib in my PyGTK app, and keep
> triggering a crash. I've narrowed it down to this bit of code:
... 
> Am I doing something obviously wrong? (Apart from the lack of plots, I
> mean... I removed them because they didn't change the behaviour.)
Thanks for the report, Jason. It's a bug - could you please file
a bug report, so we can keep track of it? 
It looks like this gets triggered by the fact that the ylabel is
being clipped. I don't have time to look into this further, but
here are two workaround for you. Either do:
 figure.subplotpars.right=.8 # make smaller if still crashes
or if it's an option, use gtkagg, which doesn't suffer from the crash.
 from matplotlib.backends.backend_gtkagg import FigureCanvasGTKAgg
as FigureCanvasGTK
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

While trying to recreate this outside of my work code, I found that I cannot
do it in a simple manner- that is, just creating a ton of points and
plotting them doesn't reproduce the problem. I'm going to revisit this and
make sure it isn't a problem in my working program versus what I thought it
was, e.g. some sort of drawing limitation.
FYI, I get this using the Qt4Agg backend and am using MPL 1.0.1
-dw

The repository is now on github, so if you want the very latest, you 
should get it from here:
https://github.com/matplotlib/matplotlib
(We haven't done a terribly good job of advertising that change).
I'm not seeing any leak myself with your script with matplotlib HEAD 
plus this pull request:
https://github.com/matplotlib/matplotlib/pull/89
so we may be getting to the bottom of this type of leak.
Mike
On 04/20/2011 05:18 PM, Oren Gampel wrote:
> I have now tested this with version 1.1.0svn from the trunk of the dev 
> repository. I believe this version contains Michael Droettboo's patch 
> for pyCXX. ( 
> https://sourceforge.net/tracker/index.php?func=detail&aid=3115633&group_id=3180&atid=103180 
> <https://sourceforge.net/tracker/index.php?func=detail&aid=3115633&group_id=3180&atid=103180> 
> )
>
> Unfortunately the leak is still evident in the small script I've 
> attached. Again, please note that this script has no axes, plots, or 
> drawn components, only an empty canvas that is being redrawn and 
> causes the memory growth.
>
> Any ideas how to resolve this or further debug this?
>
> Thanks for your help,
> Oren
>
> On Mon, Apr 11, 2011 at 6:37 PM, Oren Gampel <or...@fu... 
> <mailto:or...@fu...>> wrote:
>
> I'm having a memory leakage using matplotlib 1.0.1 with wx
> 2.8.11.0, on windows XP.
>
> To reproduce, I used the sample from here:
> http://matplotlib.sourceforge.net/examples/animation/dynamic_image_wxagg2.html
> and deleted most of the significant lines (see below). I only
> create a canvas but I don't create any axes, nor plot any data.
> The only thing I do is draw() on a timer event. This makes my
> process grow about 6Mbyte per minute.
>
> Is this reproduced in other environments? Any ideas on how to
> resolve this?
>
> Thanks,
> Oren
>
>
> """
> Copyright (C) 2003-2005 Jeremy O'Donoghue and others
>
> License: This work is licensed under the PSF. A copy should be
> included
> with this source code, and is also available at
> http://www.python.org/psf/license.html
>
> """
> import sys, time, os, gc
>
> import matplotlib
> matplotlib.use('WXAgg')
>
> from matplotlib import rcParams
> import numpy as npy
>
> import matplotlib.cm <http://matplotlib.cm> as cm
>
> from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg
> from matplotlib.backends.backend_wx import NavigationToolbar2Wx
>
> from matplotlib.figure import Figure
> from wx import *
>
>
> TIMER_ID = NewId()
>
> class PlotFigure(Frame):
>
> def __init__(self):
> Frame.__init__(self, None, -1, "Test embedded wxFigure")
>
> self.fig = Figure((1,1), 50, facecolor='.95')
> self.canvas = FigureCanvasWxAgg(self, -1, self.fig)
> # Now put all into a sizer
> sizer = wx.BoxSizer(wx.VERTICAL)
> # This way of adding to sizer allows resizing
> sizer.Add(self.canvas, 1, wx.LEFT|wx.TOP|wx.GROW)
> self.SetSizer(sizer)
> self.Fit()
>
> self._price_ax = self.fig.add_subplot(111)
>
>
> wx.EVT_TIMER(self, TIMER_ID, self.onTimer)
> self.t = wx.Timer(self, TIMER_ID)
> self.t.Start(1000)
>
> def onTimer(self, evt):
> self.canvas.draw()
>
>
> if __name__ == '__main__':
> app = PySimpleApp()
> frame = PlotFigure()
> # Initialise the timer - wxPython requires this to be connected to
> # the receiving event handler
> t = Timer(frame, TIMER_ID)
> t.Start(100)
>
> frame.Show()
> app.MainLoop()
>
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hi, everyone.
Let me explain what I wanted to do: First, I wanted to make a polar
plot with angles from 0 to 90. I could do it by adopting the
curvelinear grid demo ( http://goo.gl/kruXf ). And then I wanted to
present the radius in log10 scale. But setting the plot command to
semilogy or trying to set 'set_rscale('log')' all failed. Below I
pasted the code that works for radius in linear scale.
[Code]
#!/usr/bin/env python
import matplotlib.pyplot as plt
import numpy as np
#Modified from http://matplotlib.sourceforge.net/plot_directive/mpl_toolkits/axes_grid/examples/demo_floating_axis.py
#def curvelinear_test2(fig, lp_r, lp_t):
def curvelinear_test2(fig, lp_t, lp_r, rLower, rUpper):
 rmin = np.min(lp_r)
 rmax = np.max(lp_r)
 print 'rm: ', rmin, 'rM: ', rmax,'rL: ', rLower, 'rU: ', rUpper
 """
 polar projection, but in a rectangular box.
 """
 global ax1
 import mpl_toolkits.axisartist.angle_helper as angle_helper
 from matplotlib.projections import PolarAxes
 from matplotlib.transforms import Affine2D
 from mpl_toolkits.axisartist import SubplotHost, ParasiteAxesAuxTrans
 from mpl_toolkits.axisartist import GridHelperCurveLinear
 from mpl_toolkits.axisartist.grid_helper_curvelinear import
GridHelperCurveLinear
 # see demo_curvelinear_grid.py for details
 tr = Affine2D().scale(np.pi/180., 1.) + PolarAxes.PolarTransform()
 extreme_finder = angle_helper.ExtremeFinderCycle(20, 20,
 lon_cycle = 360,
 lat_cycle = None,
 lon_minmax = (0, 360),
 lat_minmax =
(-np.inf, np.inf),
 #lat_minmax =
(rmin, np.inf),
 )
 grid_locator1 = angle_helper.LocatorDMS(12)
 tick_formatter1 = angle_helper.FormatterDMS()
 grid_helper = GridHelperCurveLinear(tr,
 extreme_finder=extreme_finder,
 grid_locator1=grid_locator1,
 tick_formatter1=tick_formatter1
 )
 ax1 = SubplotHost(fig, 1, 1, 1, grid_helper=grid_helper)
 fig.add_subplot(ax1)
 # make ticklabels of all axis visible.
 ax1.axis[:].major_ticklabels.set_visible(True)
 #ax1.axis["top"].major_ticklabels.set_visible(True)
 #ax1.axis["left"].major_ticklabels.set_visible(True)
 #ax1.axis["bottom"].major_ticklabels.set_visible(True)
 # show angle (0) at right and top
 ax1.axis["right"].get_helper().nth_coord_ticks=0
 ax1.axis["top"].get_helper().nth_coord_ticks=0
 # show radius (1) at left and bottom
 ax1.axis["left"].get_helper().nth_coord_ticks=1
 ax1.axis["bottom"].get_helper().nth_coord_ticks=1
 # set labels
 ax1.axis["left"].label.set_text(r'ylabel')
 ax1.axis["bottom"].label.set_text(r'xlabel')
 ax1.axis["bottom"].major_ticklabels.set_rotation(-30)
 ax1.set_aspect(1.)
 ax1.set_xlim(rLower, rUpper)
 ax1.set_ylim(rLower, rUpper)
 #ax1.rscale('log')
 # A parasite axes with given transform
 ax2 = ParasiteAxesAuxTrans(ax1, tr, "equal")
 # note that ax2.transData == tr + ax1.transData
 # Anthing you draw in ax2 will match the ticks and grids of ax1.
 ax1.parasites.append(ax2)
 ax2.plot(lp_t, lp_r, 'o-')
 #ax2.semilogy(lp_t, lp_r, 'o-')
 #ax2.set_rscale('log')
 #ax1.set_xscale('log')
 #ax1.set_yscale('log')
 ax1.grid(True)
if __name__ == "__main__":
 fig = plt.figure(1, figsize=(5, 5))
 fig.clf()
 rmin = 1e-1
 rmax = 1e2
 lp_t = np.linspace(0., 90., 5)
 lp_r = np.linspace(rmin, rmax/10, 5)*5
 print "lp_t: ", lp_t
 print "lp_r: ", lp_r
 print "log10(lp_r): ", np.log10(lp_r)
 curvelinear_test2(fig, lp_t, lp_r, rmin, rmax)
 #curvelinear_test2(fig, lp_t, np.log10(lp_r), np.log10(rmin), np.log(rmax))
 plt.show()
[/Code]
I'm using Enthought Python Distribution Version: 7.0-2 (32-bit) Python
2.7.1 on win32
and matplotlib.__version__ is '1.0.1'.
Thanks,
Junghun Shin
--
Division of Electrical, Electronic and Information Engineering,
Graduate School of Engineering, Osaka University,
2-6 Yamada-oka, Suita-shi, Osaka, 565-0871, JAPAN
Tel / Fax: +81-6-6879-8755
E-mail: jh...@ef...
Group Homepage: http://www.eie.eng.osaka-u.ac.jp/ef/

On Thu, Apr 21, 2011 at 11:22 AM, Michael Droettboom <md...@st...> wrote:
> There is no hard coded limit to the number of quads in a pcolormesh.
> (Unlike the limit of the number of points in a path in the Agg backend).
> Can you provide some code that reproduces the error?
>
> Also, which version of matplotlib, platform and backend are you using?
Is this potentially a path.simplify issue? If you set path.simplify
to False in your rc params, does the problem go away?
 import matplotlib
 matplotlib.rcParams['path.simplify'] = False
In older versions of matplotlib, there was a bug in path.simplify that
caused it to simplify paths to the point where it caused perceptual
problems. The current path.simplify is not supposed to produce
detectable changes, so as Michael said please include your mpl version
in your response.
JDH

Ok. I think I've found a leak in the way the spines' paths were being 
updated.
https://github.com/matplotlib/matplotlib/pull/89
Can you apply the patch there and let me know how it improves things for 
you?
Cheers,
Mike
On 04/21/2011 08:35 AM, Caleb Constantine wrote:
> On Wed, Apr 20, 2011 at 1:04 PM, Michael Droettboom<md...@st...> wrote:
> 
>> On 04/20/2011 11:27 AM, Caleb Constantine wrote:
>> 
>>> On Wed, Apr 20, 2011 at 9:29 AM, Michael Droettboom<md...@st...> wrote:
>>> 
>>>> On 04/20/2011 07:48 AM, Caleb Constantine wrote:
>>>> 
>>>>> On Tue, Apr 19, 2011 at 2:25 PM, Michael Droettboom<md...@st...> wrote:
>>>>> 
>>>>>> Ok. I have a RHEL5 Linux box with Python 2.7.1.
>>>>>>
>>>>>> With Numpy 1.4.1 and 1.5.1 I don't see any leaks. With Numpy git HEAD,
>>>>>> I did see a leak -- I submitted a pull request to Numpy here:
>>>>>>
>>>>>> https://github.com/numpy/numpy/pull/76
>>>>>>
>>>>>> I get the same results (no leaks) running your wx, tk and agg scripts
>>>>>> (with the Windows-specific stuff removed).
>>>>>>
>>>>>> FWIW, I have wxPython 2.8.11.0 and Tkinter rev 81008.
>>>>>>
>>>>>> So the variables are the platform and the version of Python. Perhaps
>>>>>> it's one of those two things?
>>>>>>
>>>>>> Mike
>>>>>> 
>>>>> Consider the following:
>>>>>
>>>>> matplotlib 1.0.1, numpy 1.5.1, python 2.7.1, wxPython 2.8.11.0,
>>>>> Windows XP SP3
>>>>>
>>>>> - 1 hour
>>>>> - Plotted 3601 times, about 1Hz
>>>>> - Memory usage increased by about 1.16MB (41.39 - 40.23), or
>>>>> about 0.33K per redraw
>>>>>
>>>>> It seems the same memory leak exists. Given you don't have this issue
>>>>> on Linux with the same Python configuration, I can only assume it is
>>>>> related to some Windows specific code somewhere. I'll run for a longer
>>>>> period of time just in case, but I don't expect the results to be
>>>>> different.
>>>>> 
>>>> One way to rule out Windows-specific code may be to run with the Agg
>>>> backend only (without wx). Have you plotted the memory growth? This
>>>> amount of memory growth is well within the pool allocation sizes that
>>>> Python routinely uses. Does the value of len(gc.get_objects()) grow
>>>> over time?
>>>>
>>>> 
>>> New results follows.
>>>
>>> matplotlib 1.0.1, numpy 1.5.1, python 2.7.1, wxPython 2.8.11.0, Windows XP SP3
>>>
>>> agg
>>> - 3601 redraws (1 hour), about 1Hz
>>> - Memory usage: 28.79 - 27.57 = 1.22 MB
>>> - len(gc.get_objects()): 23424 at beginning and end
>>> - Plot of memory growth: roughly linear, increasing with slope of 0.26KB
>>>
>>> tkagg
>>> - 3601 redraws (1 hour), about 1Hz
>>> - Memory usage: 33.22 - 33.32 = -0.1 MB
>>> - len(gc.get_objects()): 24182 at beginning and end
>>> - Plot of memory growth: very irregular (up and down), but a line fit
>>> has a slope of about 0.025KB (I could run longer and see if slope
>>> approaches 0)
>>>
>>> wxagg
>>> - 3601 redraws (1 hour), about 1Hz
>>> - Memory usage: 43.28 - 41.80 = 1.5 MB
>>> - len(gc.get_objects()): 41473 at beginning and end
>>> - Plot of memory growth: roughly linear, increasing with slope of 0.32KB
>>> 
>> Thanks. These are very useful results.
>>
>> The fact that gc.get_objects() remains constant suggests to me that this
>> is not a simple case of holding on to a Python reference longer than we
>> intend to. Instead, this is either a C-side reference counting bug, or
>> a genuine C malloc-and-never-free bug. Puzzlingly, valgrind usually
>> does a very good job of finding such bugs, but is turning up nothing for
>> me. Will have to scratch my head a little bit longer and see if I can
>> come up with a proper experiment that will help me get to the bottom of
>> this.
>>
>> 
> For completeness, I ran more tests over a 10 hour period at an
> increased redraw rate. Details follows. Note tkagg memory usage is
> flat, agg and wxagg are not.
>
> matplotlib 1.0.1, numpy 1.5.1, python 2.7.1, wxPython 2.8.11.0, Windows XP SP3
>
> agg
> - 52214 redraws
> - Memory usage: 27.55 - 43.46 = 15.22 MB
> - len(gc.get_objects()): 23424 at beginning and end
> - Plot of memory growth: linear, increasing with slope of 0.31KB
>
> tkagg
> - 71379 redraws
> - Memory usage: 30.47 - 30.25 = 0.22 MB
> - len(gc.get_objects()): 24171 at beginning, 24182 at end, but mostly
> constant at 24182
> - Plot of memory growth: very irregular (up and down), but a line fit
> has a slope of about 0.0002KB.
>
> wxagg
> - 72001 redraws
> - Memory usage: 62.08 - 40.10 = 21.98 MB
> - len(gc.get_objects()): 41473 at beginning and end
> - Plot of memory growth: linear, increasing with slope of 0.31KB
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

There is no hard coded limit to the number of quads in a pcolormesh. 
(Unlike the limit of the number of points in a path in the Agg 
backend). Can you provide some code that reproduces the error?
Also, which version of matplotlib, platform and backend are you using?
Mike
On 04/21/2011 12:20 PM, Daniel Welling wrote:
> Greetings, MPL Users.
>
> I have a very detailed array that I am visualizing using pcolor mesh. 
> When the size of the array surpasses some threshold (I don't know the 
> value), pcolormesh stops drawing polygons/patches. Thus, I only see 
> some percentage of my array. Is there a way to increase the number of 
> polygons/patches MPL will draw to screen?
>
> Thanks.
> -dw
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Greetings, MPL Users.
I have a very detailed array that I am visualizing using pcolor mesh. When
the size of the array surpasses some threshold (I don't know the value),
pcolormesh stops drawing polygons/patches. Thus, I only see some percentage
of my array. Is there a way to increase the number of polygons/patches MPL
will draw to screen?
Thanks.
-dw

On Wed, Apr 20, 2011 at 1:04 PM, Michael Droettboom <md...@st...> wrote:
> On 04/20/2011 11:27 AM, Caleb Constantine wrote:
>> On Wed, Apr 20, 2011 at 9:29 AM, Michael Droettboom<md...@st...> wrote:
>>> On 04/20/2011 07:48 AM, Caleb Constantine wrote:
>>>> On Tue, Apr 19, 2011 at 2:25 PM, Michael Droettboom<md...@st...>  wrote:
>>>>> Ok. I have a RHEL5 Linux box with Python 2.7.1.
>>>>>
>>>>> With Numpy 1.4.1 and 1.5.1 I don't see any leaks. With Numpy git HEAD,
>>>>> I did see a leak -- I submitted a pull request to Numpy here:
>>>>>
>>>>>   https://github.com/numpy/numpy/pull/76
>>>>>
>>>>> I get the same results (no leaks) running your wx, tk and agg scripts
>>>>> (with the Windows-specific stuff removed).
>>>>>
>>>>> FWIW, I have wxPython 2.8.11.0 and Tkinter rev 81008.
>>>>>
>>>>> So the variables are the platform and the version of Python. Perhaps
>>>>> it's one of those two things?
>>>>>
>>>>> Mike
>>>> Consider the following:
>>>>
>>>>    matplotlib 1.0.1, numpy 1.5.1, python 2.7.1, wxPython 2.8.11.0,
>>>> Windows XP SP3
>>>>
>>>>    - 1 hour
>>>>    - Plotted 3601 times, about 1Hz
>>>>    - Memory usage increased by about 1.16MB (41.39 - 40.23), or
>>>> about 0.33K per redraw
>>>>
>>>> It seems the same memory leak exists. Given you don't have this issue
>>>> on Linux with the same Python configuration, I can only assume it is
>>>> related to some Windows specific code somewhere. I'll run for a longer
>>>> period of time just in case, but I don't expect the results to be
>>>> different.
>>> One way to rule out Windows-specific code may be to run with the Agg
>>> backend only (without wx). Have you plotted the memory growth? This
>>> amount of memory growth is well within the pool allocation sizes that
>>> Python routinely uses. Does the value of len(gc.get_objects()) grow
>>> over time?
>>>
>> New results follows.
>>
>> matplotlib 1.0.1, numpy 1.5.1, python 2.7.1, wxPython 2.8.11.0, Windows XP SP3
>>
>> agg
>> - 3601 redraws (1 hour), about 1Hz
>> - Memory usage: 28.79 - 27.57 = 1.22 MB
>> - len(gc.get_objects()): 23424 at beginning and end
>> - Plot of memory growth: roughly linear, increasing with slope of 0.26KB
>>
>> tkagg
>> - 3601 redraws (1 hour), about 1Hz
>> - Memory usage: 33.22 - 33.32 = -0.1 MB
>> - len(gc.get_objects()): 24182 at beginning and end
>> - Plot of memory growth: very irregular (up and down), but a line fit
>>  has a slope of about 0.025KB (I could run longer and see if slope
>> approaches 0)
>>
>> wxagg
>> - 3601 redraws (1 hour), about 1Hz
>> - Memory usage: 43.28 - 41.80 = 1.5 MB
>> - len(gc.get_objects()): 41473 at beginning and end
>> - Plot of memory growth: roughly linear, increasing with slope of 0.32KB
> Thanks. These are very useful results.
>
> The fact that gc.get_objects() remains constant suggests to me that this
> is not a simple case of holding on to a Python reference longer than we
> intend to. Instead, this is either a C-side reference counting bug, or
> a genuine C malloc-and-never-free bug. Puzzlingly, valgrind usually
> does a very good job of finding such bugs, but is turning up nothing for
> me. Will have to scratch my head a little bit longer and see if I can
> come up with a proper experiment that will help me get to the bottom of
> this.
>
For completeness, I ran more tests over a 10 hour period at an
increased redraw rate. Details follows. Note tkagg memory usage is
flat, agg and wxagg are not.
matplotlib 1.0.1, numpy 1.5.1, python 2.7.1, wxPython 2.8.11.0, Windows XP SP3
agg
- 52214 redraws
- Memory usage: 27.55 - 43.46 = 15.22 MB
- len(gc.get_objects()): 23424 at beginning and end
- Plot of memory growth: linear, increasing with slope of 0.31KB
tkagg
- 71379 redraws
- Memory usage: 30.47 - 30.25 = 0.22 MB
- len(gc.get_objects()): 24171 at beginning, 24182 at end, but mostly
 constant at 24182
- Plot of memory growth: very irregular (up and down), but a line fit
 has a slope of about 0.0002KB.
wxagg
- 72001 redraws
- Memory usage: 62.08 - 40.10 = 21.98 MB
- len(gc.get_objects()): 41473 at beginning and end
- Plot of memory growth: linear, increasing with slope of 0.31KB

This seems to be a bug in matplotlib.
I just opened a bug track for it.
https://github.com/matplotlib/matplotlib/issues/88
As a workaround, try
ax3.tick_params(pad=20)
Regards,
-JJ
On Tue, Mar 15, 2011 at 10:43 AM, NotBrianCox <sam...@gm...> wrote:
>
> I'm plotting a series of sub plots within a figure, where most are small sub
> plots, but the last one spans the width of the figure. For the final subplot
> only, I want to set the xtick pad to 20. Something like:
>
>
> import matplotlib.pyplot as plt
>
> fig = plt.figure()
> ax1 = fig.add_subplot(2,2,1)
> ax2 = fig.add_subplot(2,2,2)
> ax3 = fig.add_subplot(2,1,3)
>
>
> plt.setp(ax3.xaxis.get_major_ticks(), pad=20)
> plt.show()
>
> But this doesn't have any effect on the final plot. I've also tried getting
> the ticks individually and calling set_pad(20) i.e.:
>
> for tick in ax3.xaxis.get_major_ticks():
>  tick.set_pad(20)
>
> But this does't work either. Anyone have an ideas?
>
>
> --
> View this message in context: http://old.nabble.com/Different-xtick-pads-for-subplots-within-figure-tp31150430p31150430.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Tue, Apr 12, 2011 at 3:31 AM, Jonathan Slavin
<js...@cf...> wrote:
> (Shouldn't the default behavior
> be to scale to height if the colorbar is vertical and width if its
> horizontal?)
Because of the design of the matplotlib, this is not straight forward
to implement.
While there could be a few ways to do it, you may try axes_grid1 toolkit.
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#colorbar-whose-height-or-width-in-sync-with-the-master-axes
Regards,
-JJ

I'm playing around with using Matplotlib in my PyGTK app, and keep
triggering a crash. I've narrowed it down to this bit of code:
----
import pygtk
import gtk
from matplotlib.backends.backend_gtk import FigureCanvasGTK
from matplotlib.figure import Figure
def TestGraph(one, two, three):
 figure = Figure()
 ax1 = figure.add_subplot(111)
 ax2 = ax1.twinx()
 # Remove this line and it all works:
 ax2.set_ylabel("Y")
 return FigureCanvasGTK(figure)
graph = TestGraph(
 [[0,1,2],[0.1, 0.2, 0.35]],
 [[0,1,2],[9,22,29]],
 [[0,1,2],[10,20,30]])
window = gtk.Window()
window.add(graph)
def destroy(widget, data=None):
 gtk.main_quit()
window.connect('destroy', destroy)
window.show_all()
gtk.main()
----
Running this gives me:
$ Projects/python-virt/bin/python mpltest.py
The program 'mpltest.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
 (Details: serial 553 error_code 8 request_code 73 minor_code 0)
 (Note to programmers: normally, X errors are reported asynchronously;
 that is, you will receive the error a while after causing it.
 To debug your program, run it with the --sync command line
 option to change this behavior. You can then get a meaningful
 backtrace from your debugger if you break on the gdk_x_error() function.)
$
Am I doing something obviously wrong? (Apart from the lack of plots, I
mean... I removed them because they didn't change the behaviour.)
This is under...
Debian Squeeze/Wheezy/Sid
Python: 2.6.5
Matplotlib: SVN r8988
GTK: 2.20.1
PyGTK: 2.17.0
Cheers,
Jason