matplotlib-devel Mailing List for matplotlib (Page 2)

On Fri, May 28, 2010 at 10:52 AM, Jason Grout
<jas...@cr...> wrote:
> I just noticed here:
>
> http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_xlim
>
> that the keywords that are documented for set_xlim are actually the
> keywords for set_ylim. Surely this is just a copy-paste error.
Surely. Fixed in SVN, thanks for the report.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

I just noticed here:
http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_xlim
that the keywords that are documented for set_xlim are actually the 
keywords for set_ylim. Surely this is just a copy-paste error.
Thanks,
Jason

I'm on to something -- some callbacks are being created that are never 
disconnected.
In Line2D.set_axes:
 self._xcid = ax.xaxis.callbacks.connect('units', self.recache_always)
gets called twice. This is problematic because the id of the first 
connection is simply lost. Also, there doesn't seem to be any code to 
attempt to remove either of them.
I'm looking into it further -- forcibly deleting these callbacks reduces 
the reference count on the line object, but doesn't seem to completely 
eliminate the leak.
Mike
On 05/28/2010 10:12 AM, John Hunter wrote:
> On Fri, May 28, 2010 at 3:18 AM, Pearu Peterson<pe...@ce...> wrote:
> 
>> Hi,
>>
>> In an application that updates a plot with
>> new experimental data, say, every second and the experiment
>> can last hours, I have tried two approaches:
>> 1) clear axes and plot new experimental data - this is
>> slow and takes too much cpu resources.
>> 2) remove lines and plot new experimental data - this is
>> fast enough but unfortunately there seems to be a memory
>> leakage, the application runs out of memory.
>>
>> Here follows a simple script that demonstrates the
>> leakage problem:
>>
>> #
>> import numpy
>> from numpy.testing.utils import memusage
>> import matplotlib.pyplot as plt
>> x = range (1000)
>> axes1 = plt.figure().add_subplot( 111 )
>> y = numpy.random.rand (len (x))
>> while 1:
>> if 1:
>> # leakage
>> for line in axes1.lines:
>> if line.get_label ()=='data':
>> line.remove()
>> else:
>> # no leak, but slow
>> axes1.clear()
>> axes1.plot(x, y, 'b', label='data')
>> print memusage (), len (axes1.lines)
>> #eof
>>
>> When running the script, the memory usage
>> is increasing by 132 kbytes per iteration, that is,
>> with an hour this example application will consume
>> 464MB RAM while no new data has been generated. In real
>> application this effect will be even worse.
>>
>> So, I am looking for an advice how to avoid
>> this memory leakage without clearing axes.
>> 
> Hey Pearu -- thanks for the report. We'll try and track down and fix
> this leak. In the interim, would an acceptable work around for you be
> to *reuse* an existing line by calling set_data on it. That way you
> wouldn't have to do the add/remove that is causing your leak. Have
> you confirmed this leak on various backends (eg Agg, PDF, PS)?
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Fri, May 28, 2010 at 3:18 AM, Pearu Peterson <pe...@ce...> wrote:
>
> Hi,
>
> In an application that updates a plot with
> new experimental data, say, every second and the experiment
> can last hours, I have tried two approaches:
> 1) clear axes and plot new experimental data - this is
> slow and takes too much cpu resources.
> 2) remove lines and plot new experimental data - this is
> fast enough but unfortunately there seems to be a memory
> leakage, the application runs out of memory.
>
> Here follows a simple script that demonstrates the
> leakage problem:
>
> #
> import numpy
> from numpy.testing.utils import memusage
> import matplotlib.pyplot as plt
> x = range (1000)
> axes1 = plt.figure().add_subplot( 111 )
> y = numpy.random.rand (len (x))
> while 1:
>  if 1:
>    # leakage
>    for line in axes1.lines:
>      if line.get_label ()=='data':
>        line.remove()
>  else:
>    # no leak, but slow
>    axes1.clear()
>  axes1.plot(x, y, 'b', label='data')
>  print memusage (), len (axes1.lines)
> #eof
>
> When running the script, the memory usage
> is increasing by 132 kbytes per iteration, that is,
> with an hour this example application will consume
> 464MB RAM while no new data has been generated. In real
> application this effect will be even worse.
>
> So, I am looking for an advice how to avoid
> this memory leakage without clearing axes.
Hey Pearu -- thanks for the report. We'll try and track down and fix
this leak. In the interim, would an acceptable work around for you be
to *reuse* an existing line by calling set_data on it. That way you
wouldn't have to do the add/remove that is causing your leak. Have
you confirmed this leak on various backends (eg Agg, PDF, PS)?

On 05/28/2010 09:18 AM, Pearu Peterson wrote:
> , say, every second and the experiment
> can last hours, I have tried two approaches:
> 1) clear axes and plot new experimental data - this is
> slow and takes too much cpu resources.
> 2) remove lines and plot new experimental data - this is
> fast enough but unfortunately there seems to be a memory
> leakage, the application runs out of memory.
>
Why don't you just update the exiting line with the new data, as shown 
in the animation examples in 
http://matplotlib.sourceforge.net/examples/animation/index.html ?
For example:
#
import numpy
from numpy.testing.utils import memusage
import matplotlib.pyplot as plt
x = range (1000)
fig = plt.figure()
axes1 = fig.add_subplot( 111 )
y = numpy.random.rand (len (x))
line = None
while 1:
 if not line:
 line, = axes1.plot(x, y, 'b', label='data')
 else:
 line.set_data(x,y)
	fig.canvas.draw()
 print memusage ()/(1024.0*1024.0),"MB", len (axes1.lines)
#eof
Regards,
João Silva

Hi,
In an application that updates a plot with
new experimental data, say, every second and the experiment
can last hours, I have tried two approaches:
1) clear axes and plot new experimental data - this is
slow and takes too much cpu resources.
2) remove lines and plot new experimental data - this is
fast enough but unfortunately there seems to be a memory
leakage, the application runs out of memory.
Here follows a simple script that demonstrates the
leakage problem:
#
import numpy
from numpy.testing.utils import memusage
import matplotlib.pyplot as plt
x = range (1000)
axes1 = plt.figure().add_subplot( 111 )
y = numpy.random.rand (len (x))
while 1:
 if 1:
 # leakage
 for line in axes1.lines:
 if line.get_label ()=='data':
 line.remove()
 else:
 # no leak, but slow
 axes1.clear()
 axes1.plot(x, y, 'b', label='data')
 print memusage (), len (axes1.lines)
#eof
When running the script, the memory usage
is increasing by 132 kbytes per iteration, that is,
with an hour this example application will consume
464MB RAM while no new data has been generated. In real
application this effect will be even worse.
So, I am looking for an advice how to avoid
this memory leakage without clearing axes.
I am using matplotlib from SVN.
Thanks,
Pearu

Hi
I have seen that there has been some mails asking about this problem
and it seems it was solved. Nevertheless, I am using the version
0.99.1 in windows and the problem still persists. Do I have any way to
apply a local patch?
Thanks,
Norberto

On Sun, May 23, 2010 at 4:15 AM, Peter Butterworth <bu...@gm...> wrote:
> On Sat, May 22, 2010 at 11:30 PM, Darren Dale <dsd...@gm...> wrote:
>> On Sat, May 22, 2010 at 4:19 PM, Peter Butterworth <bu...@gm...> wrote:
>>> On Sun, May 16, 2010 at 1:53 PM, Darren Dale <dsd...@gm...> wrote:
>>>> I don't think the demo is ready for inclusion. Clicking in the plot
>>>> window to open the dialog conflicts with all the other functionality
>>>> on the toolbar.
>>>
>>> Feel free to amend the example as needed. Clicking in the plot window
>>> to open the dialog is obviously not required.
>>
>> In that case I don't see the point of the demo.
>
> It is useful to provide code showcasing the full functionnality and
> allowing to test it quickly. That said I agree that it probably
> doesn't make sense to have a separate file for this.
> Should I move the test code back to if __name__ == "__main__": in
> figureoptions.py removing the mouse click binding ?
>
>>
>>>> Also, when I open the figure options dialog, the dialog window
>>>> background is transparent instead of using the desktop default. Why is
>>>> that?
>>>
>>> No idea. I haven't encountered this issue before. I use Python 2.6.5 +
>>> PyQt 4.7.2 on Win32.
>>>
>>> Could you possibly narrow this down a bit ? Is it caused by new code
>>> in figureoptions.py ?
>>
>> I have no idea, and I don't have enough time to dig into it. I'm sorry.
>
> Darren: your help is greatly appreciated.
> Is the platform/config specific transparent background issue blocking
> ? There is nothing in the figureoptions code that should cause this
> IMO.
I don't know if it is platform specific, although I tested on a 64-bit
kubuntu lucid with qt-4.6.2.
I'm not comfortable checking in changes that introduce problems I
don't understand.
Darren

On Sat, May 22, 2010 at 11:30 PM, Darren Dale <dsd...@gm...> wrote:
> On Sat, May 22, 2010 at 4:19 PM, Peter Butterworth <bu...@gm...> wrote:
>> On Sun, May 16, 2010 at 1:53 PM, Darren Dale <dsd...@gm...> wrote:
>>> I don't think the demo is ready for inclusion. Clicking in the plot
>>> window to open the dialog conflicts with all the other functionality
>>> on the toolbar.
>>
>> Feel free to amend the example as needed. Clicking in the plot window
>> to open the dialog is obviously not required.
>
> In that case I don't see the point of the demo.
It is useful to provide code showcasing the full functionnality and
allowing to test it quickly. That said I agree that it probably
doesn't make sense to have a separate file for this.
Should I move the test code back to if __name__ == "__main__": in
figureoptions.py removing the mouse click binding ?
>
>>> Also, when I open the figure options dialog, the dialog window
>>> background is transparent instead of using the desktop default. Why is
>>> that?
>>
>> No idea. I haven't encountered this issue before. I use Python 2.6.5 +
>> PyQt 4.7.2 on Win32.
>>
>> Could you possibly narrow this down a bit ? Is it caused by new code
>> in figureoptions.py ?
>
> I have no idea, and I don't have enough time to dig into it. I'm sorry.
Darren: your help is greatly appreciated.
Is the platform/config specific transparent background issue blocking
? There is nothing in the figureoptions code that should cause this
IMO.

On Sat, May 22, 2010 at 4:19 PM, Peter Butterworth <bu...@gm...> wrote:
> On Sun, May 16, 2010 at 1:53 PM, Darren Dale <dsd...@gm...> wrote:
>> I don't think the demo is ready for inclusion. Clicking in the plot
>> window to open the dialog conflicts with all the other functionality
>> on the toolbar.
>
> Feel free to amend the example as needed. Clicking in the plot window
> to open the dialog is obviously not required.
In that case I don't see the point of the demo.
>> Also, when I open the figure options dialog, the dialog window
>> background is transparent instead of using the desktop default. Why is
>> that?
>
> No idea. I haven't encountered this issue before. I use Python 2.6.5 +
> PyQt 4.7.2 on Win32.
>
> Could you possibly narrow this down a bit ? Is it caused by new code
> in figureoptions.py ?
I have no idea, and I don't have enough time to dig into it. I'm sorry.
Darren

On Sun, May 16, 2010 at 1:53 PM, Darren Dale <dsd...@gm...> wrote:
> I don't think the demo is ready for inclusion. Clicking in the plot
> window to open the dialog conflicts with all the other functionality
> on the toolbar.
Feel free to amend the example as needed. Clicking in the plot window
to open the dialog is obviously not required.
> Also, when I open the figure options dialog, the dialog window
> background is transparent instead of using the desktop default. Why is
> that?
>
> Darren
No idea. I haven't encountered this issue before. I use Python 2.6.5 +
PyQt 4.7.2 on Win32.
Could you possibly narrow this down a bit ? Is it caused by new code
in figureoptions.py ?
>
> On Thu, May 13, 2010 at 3:11 AM, Peter Butterworth <bu...@gm...> wrote:
>> patch attached
>>
>> qt4ed_demo.py is an example file which should be put in
>> matplotlib\examples\pylab_examples
>> other than that figureoptions.py is the only file changed.
>>
>>
>> On Wed, May 12, 2010 at 11:56 PM, Darren Dale <dsd...@gm...> wrote:
>>> No, I'm sorry. Its unfair to you that I am the bottleneck here. I just
>>> looked for the patch at
>>> http://sourceforge.net/tracker/?func=detail&aid=2981606&group_id=80706&atid=560722
>>> but didn't find it. Is the figureoptions.py file there all that is
>>> needed?

I did some more digging and I think I have a hypothesis for what is
happening.
There is only one main difference between a call to .drawstates() and
.readshapefiles() with respect to loading and plotting data. .drawstates()
loads *only* the line segments that coincide with the defined map
boundaries, while .readshapefiles() loads all of the data in the shapefile.
Therefore, the LineCollection that gets attached to the axis contains data
from outside the stated domain.
In addition, the basemap versions of the plotting functions have the benefit
of finishing their calls with a call to .set_axes_limits(), which keeps the
axes in check. However, a non-basemap version would not call that
automatically, thereby having its axes automatically expanded to contain all
of the data in the LineCollection.
I am not sure what exactly should be done about this. This is certainly
un-intuitive behavior, though. Maybe there could be a keyword option in
.readshapefile() to have only the data for the stated domain loaded? That
might solve the issue.
Thanks,
Ben Root
On Fri, May 21, 2010 at 4:08 PM, Benjamin Root <ben...@ou...> wrote:
> Hello,
>
> I have been tracking down an annoying (but easily worked around) issue with
> Basemap. It seems that if you call .readshapefile() to create, for example,
> roads on your image, and then call any pyplot command afterwards for that
> axis, the axis will reset itself to the entire domain (I guess it would be
> the complete domain stated in the shapefile, maybe?). This does not happen
> if you call the equivalent function from the Basemap instance, though.
> Also, this does not happen with drawstates() and its ilk.
>
> I have made a test script and a couple of supporting shapefile in a tar.gz
> file to demonstrate the issue. It is available here:
> http://dl.dropbox.com/u/7325604/basemaptest.tar.gz
>
>
> I have also attached a png file showing the resulting image as it appears
> on my computer. I have no clue as to the cause and I hope that someone here
> might have an idea.
>
> Thanks,
> Ben Root
>

On 05/21/2010 03:55 AM, João Luís Silva wrote:
> Hi,
>
> Using the SVN version the following example fails with:
>
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/colors.py", line
> 815, in inverse
> raise ValueError("Inversion requires valid vmax> vmin")
> ValueError: Inversion requires valid vmax> vmin
>
> This was introduced in svn revision 8308.
>
> Example script: ---------------------------------------
>
> import numpy as np
> import matplotlib.pyplot as plt
>
> plt.imshow(np.zeros((10,10)))
> plt.colorbar()
> plt.show()
>
> ------------------------------------------------
>
> Regards,
> João Silva
Thank you. It's fixed in 8331.
Eric
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

If possible, can you try the latest svn version and see if it makes
any difference?
Also, see if increasing the dpi helps, i.e.,
savefig(..., dpi=150)
Given the nature of the rasterization, I'm not sure if we can
completely avoid the white gap for low dpi settings.
But the displacement issue you see (although think it has been fixed
in the svn) needs to be fixed.
Regards,
-JJ

Markus,
Looking again at your image, I realized that you are probably using real
data, not simulated data, therefore you can't easily use a higher grid
resolution.
So, I created a test script to examine this. I have found that there is
definitely a difference between filetypes. In my test script, there is a
white row that occurs for pcolor, but not for pcolormesh (Note, I have a
patched version of matplotlib that rasterizes pcolormesh). Also, this
effect does not happen if rasterization is set to False. Lastly, the effect
is more pronounced with lower-resolution data.
Let me clean up the test script so that the devels to use to visualize this
issue.
Ben Root
On Fri, May 21, 2010 at 9:45 AM, Markus Haider <mar...@ui...>wrote:
> Hi,
>
> Thank you for your reply.
>
> > I have been doing some testing with pcolor() and pcolormesh() with
> > regards to rasterization. I can not see a displacement when choosing
> > between different file types or with setting rasterized to be True or
> > False. What I have noticed is a half grid-space displacement between
> > pcolor() and pcolormesh().
>
> Can you see the displacement in the before enclosed pdf file?
>
> > You can see if this is the cause of your displacement by choosing a
> > higher resolution grid. In such a case, the displacement should be
> > smaller.
>
> How can I choose a higher resolution grid?
> Thank you for your help,
> Greetings,
> Markus
>
> > Ben Root
> >
> > On Fri, May 21, 2010 at 5:03 AM, Markus Haider
> > <mar...@ui...> wrote:
> > Hello,
> >
> > I make colormap plots in matplotlib using pcolor or
> > pcolormesh. With
> > both I have a problem:
> >
> > If I use pcolormesh ("p2 =
> > ax2.pcolormesh(10**temp,rasterized=True)") I
> > get perfectly small file sizes, but the position of the
> > rasterized
> > colormap is a little bit displaced with respect to the frame,
> > showing a
> > white border on the top and right side. Is this a bug, or can
> > I change
> > this?
> >
> > If I try with pcolor, I get the
> > message/usr/lib/pymodules/python2.6/matplotlib/artist.py:562:
> > UserWarning: Rasterization of
> > '<matplotlib.collections.PolyCollection
> > object at 0x2aac890>' will be ignored
> > warnings.warn("Rasterization of '%s' will be ignored" % self)
> >
> >
> > Thank you very much for your help,
> > Markus
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
>
>
>

Hi,
Thank you for your reply.
> I have been doing some testing with pcolor() and pcolormesh() with
> regards to rasterization. I can not see a displacement when choosing
> between different file types or with setting rasterized to be True or
> False. What I have noticed is a half grid-space displacement between
> pcolor() and pcolormesh().
Can you see the displacement in the before enclosed pdf file?
> You can see if this is the cause of your displacement by choosing a
> higher resolution grid. In such a case, the displacement should be
> smaller.
How can I choose a higher resolution grid?
Thank you for your help,
Greetings,
Markus
> Ben Root
> 
> On Fri, May 21, 2010 at 5:03 AM, Markus Haider
> <mar...@ui...> wrote:
> Hello,
> 
> I make colormap plots in matplotlib using pcolor or
> pcolormesh. With
> both I have a problem:
> 
> If I use pcolormesh ("p2 =
> ax2.pcolormesh(10**temp,rasterized=True)") I
> get perfectly small file sizes, but the position of the
> rasterized
> colormap is a little bit displaced with respect to the frame,
> showing a
> white border on the top and right side. Is this a bug, or can
> I change
> this?
> 
> If I try with pcolor, I get the
> message/usr/lib/pymodules/python2.6/matplotlib/artist.py:562:
> UserWarning: Rasterization of
> '<matplotlib.collections.PolyCollection
> object at 0x2aac890>' will be ignored
> warnings.warn("Rasterization of '%s' will be ignored" % self)
> 
> 
> Thank you very much for your help,
> Markus
> 
> ------------------------------------------------------------------------------
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 

I have been doing some testing with pcolor() and pcolormesh() with regards
to rasterization. I can not see a displacement when choosing between
different file types or with setting rasterized to be True or False. What I
have noticed is a half grid-space displacement between pcolor() and
pcolormesh().
You can see if this is the cause of your displacement by choosing a higher
resolution grid. In such a case, the displacement should be smaller.
Ben Root
On Fri, May 21, 2010 at 5:03 AM, Markus Haider <mar...@ui...>wrote:
> Hello,
>
> I make colormap plots in matplotlib using pcolor or pcolormesh. With
> both I have a problem:
>
> If I use pcolormesh ("p2 = ax2.pcolormesh(10**temp,rasterized=True)") I
> get perfectly small file sizes, but the position of the rasterized
> colormap is a little bit displaced with respect to the frame, showing a
> white border on the top and right side. Is this a bug, or can I change
> this?
>
> If I try with pcolor, I get the
> message/usr/lib/pymodules/python2.6/matplotlib/artist.py:562:
> UserWarning: Rasterization of '<matplotlib.collections.PolyCollection
> object at 0x2aac890>' will be ignored
> warnings.warn("Rasterization of '%s' will be ignored" % self)
>
>
> Thank you very much for your help,
> Markus
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi,
Using the SVN version the following example fails with:
File "/usr/local/lib/python2.6/dist-packages/matplotlib/colors.py", line 
815, in inverse
 raise ValueError("Inversion requires valid vmax > vmin")
ValueError: Inversion requires valid vmax > vmin
This was introduced in svn revision 8308.
Example script: ---------------------------------------
import numpy as np
import matplotlib.pyplot as plt
plt.imshow(np.zeros((10,10)))
plt.colorbar()
plt.show()
------------------------------------------------
Regards,
João Silva

Hello,
I make colormap plots in matplotlib using pcolor or pcolormesh. With
both I have a problem:
If I use pcolormesh ("p2 = ax2.pcolormesh(10**temp,rasterized=True)") I
get perfectly small file sizes, but the position of the rasterized
colormap is a little bit displaced with respect to the frame, showing a
white border on the top and right side. Is this a bug, or can I change
this?
If I try with pcolor, I get the
message/usr/lib/pymodules/python2.6/matplotlib/artist.py:562:
UserWarning: Rasterization of '<matplotlib.collections.PolyCollection
object at 0x2aac890>' will be ignored
 warnings.warn("Rasterization of '%s' will be ignored" % self)
Thank you very much for your help,
Markus

On Wed, May 19, 2010 at 11:29 AM, Stan West <sta...@nr...> wrote:
> Hi, developers. While trying to set the properties of all text in a figure,
> I noticed that the offset text of each axis was not being returned by
> get_children(), so the offset text wasn't receiving the new properties. I
> opened a tracker with a demonstration and suggested trivial patch at
> http://sourceforge.net/tracker/?func=detail&atid=560720&aid=3001208&group_id=80706.
>
> Thank you for your continued work on matplotlib.
>
Thanks for the patch -- applied to branch and trunk.
JDH

Hi, developers. While trying to set the properties of all text in a figure, I
noticed that the offset text of each axis was not being returned by
get_children(), so the offset text wasn't receiving the new properties. I
opened a tracker with a demonstration and suggested trivial patch at
<http://sourceforge.net/tracker/?func=detail&atid=560720&aid=3001208&group_id=
80706>
http://sourceforge.net/tracker/?func=detail&atid=560720&aid=3001208&group_id=8
0706.
Thank you for your continued work on matplotlib.

On 5/17/2010 12:13 PM, Ryan Wagner wrote:
>
> Does anyone know if/when MPL will be supported on Python 2.7? Thanks!
I built matplotlib 1.0.svn for Python 2.7b2 (32 and 64-bit) against 
numpy 2.0.dev using the attached patch. Unofficial Windows installers 
are at <http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>. It works 
for me but I would not recommend to use it in a production environment: 
Python 2.7, matplotlib 1.0, numpy 2.0, PyGTK-py2.7 and PyQt4-py2.7 are 
not released yet.
--
Christoph
Index: setupext.py
===================================================================
--- setupext.py	(revision 8316)
+++ setupext.py	(working copy)
@@ -997,7 +997,7 @@
 message = None
 if sys.platform == 'win32':
 major, minor1, minor2, s, tmp = sys.version_info
- if major == 2 and minor1 == 6:
+ if major == 2 and minor1 in (6, 7):
 module.include_dirs.extend(['win32_static/include/tcl85'])
 module.libraries.extend(['tk85', 'tcl85'])
 elif major == 2 and minor1 in [3, 4, 5]:

Does anyone know if/when MPL will be supported on Python 2.7? Thanks!
-Ryan

On 05/17/2010 07:12 AM, Jeff Klukas wrote:
> I noticed a small problem in axes.py; when setting weights with a
> histogram, a variable 'w' is accessed before it's assigned. It looks
> like this is a typo where 'w' should instead be 'weights'. The patch
> is copied below and attached.
Fixed in 8317--thanks very much!
Eric
>
> Cheers,
> Jeff
>
> || Jeff Klukas, Research Assistant, Physics
> || University of Wisconsin -- Madison
> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
> || http://www.hep.wisc.edu/~jklukas/
>
>
> Index: lib/matplotlib/axes.py
> ===================================================================
> --- lib/matplotlib/axes.py	(revision 8316)
> +++ lib/matplotlib/axes.py	(working copy)
> @@ -7364,7 +7364,7 @@
> raise ValueError("color kwarg must have one color per dataset")
>
> if weights is not None:
> - if isinstance(w, np.ndarray):
> + if isinstance(weights, np.ndarray):
> w = np.array(weights)
> if w.ndim == 2:
> w = w.T
>
>
>
> ------------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I noticed a small problem in axes.py; when setting weights with a
histogram, a variable 'w' is accessed before it's assigned. It looks
like this is a typo where 'w' should instead be 'weights'. The patch
is copied below and attached.
Cheers,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
|| http://www.hep.wisc.edu/~jklukas/
Index: lib/matplotlib/axes.py
===================================================================
--- lib/matplotlib/axes.py	(revision 8316)
+++ lib/matplotlib/axes.py	(working copy)
@@ -7364,7 +7364,7 @@
 raise ValueError("color kwarg must have one color per dataset")
 if weights is not None:
- if isinstance(w, np.ndarray):
+ if isinstance(weights, np.ndarray):
 w = np.array(weights)
 if w.ndim == 2:
 w = w.T