matplotlib-devel Mailing List for matplotlib

Kersey Black wrote:
> I have run across what I think is a bug in the markevery functionality.
> 
> Running OSX 10.6.2
> Python 2.6.4 |EPD 6.1-1 (32-bit)| (r264:75706, Dec 11 2009, 10:58:54)
> mp.__version__ '0.99.1.1'
> 
> I have 16 lines plotted in a plot which is embedded in a wxpython application frame.
> I am using the WXAgg backend
> 
> For each line, I am plotting the two variables (distances in this case) against each 
> other an am using the 'markevery' functionality to mark just one point along each line.
> I do this with this construction using the line list returned from the plot command.
> new_line[0].set_markevery(every=(t0[0],9999))
> The data set is much smaller than 9999 points, so 
> this insures only having one point highlighted along the line.
> It works great, and does just what I want.
> 
> However, when I zoom and pan the plot, for about half of the lines the highlighted point 
> (which should stay put) actually migrates along the line as I am panning the plot. 
> The marked points seem to start moving when they get close to the edge of the plot frame, 
> as if to stay visible, but it is not quite that simple.
> 
> Has anyone else observed this? Or have a fix? I saw a previous bug reported 
> with markevery from Jan 2009, but that seemed to be resolved.
I just committed what I think will be a fix, in svn 8289.
Eric
> 
> Kersey
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I have run across what I think is a bug in the markevery functionality.
Running OSX 10.6.2
Python 2.6.4 |EPD 6.1-1 (32-bit)| (r264:75706, Dec 11 2009, 10:58:54)
mp.__version__ '0.99.1.1'
I have 16 lines plotted in a plot which is embedded in a wxpython application frame.
I am using the WXAgg backend
For each line, I am plotting the two variables (distances in this case) against each 
other an am using the 'markevery' functionality to mark just one point along each line.
I do this with this construction using the line list returned from the plot command.
 new_line[0].set_markevery(every=(t0[0],9999))
The data set is much smaller than 9999 points, so 
this insures only having one point highlighted along the line.
It works great, and does just what I want.
However, when I zoom and pan the plot, for about half of the lines the highlighted point 
(which should stay put) actually migrates along the line as I am panning the plot. 
The marked points seem to start moving when they get close to the edge of the plot frame, 
as if to stay visible, but it is not quite that simple.
Has anyone else observed this? Or have a fix? I saw a previous bug reported 
with markevery from Jan 2009, but that seemed to be resolved.
Kersey

Mark Roddy wrote:
> On Wed, Apr 28, 2010 at 12:30 PM, Mark Roddy <mar...@gm...> wrote:
>> On Wed, Apr 28, 2010 at 11:49 AM, Michael Droettboom <md...@st...> wrote:
>>> Thanks. Yes, I would consider tabs a bug. A patch is very welcome.
>>>
[...]
> 
> I added a patch to the tracker:
> https://sourceforge.net/tracker/?func=detail&aid=2993733&group_id=80706&atid=560720
> 
Your patch has been applied. Thank you.
Eric
> -Mark

On Wed, Apr 28, 2010 at 12:30 PM, Mark Roddy <mar...@gm...> wrote:
> On Wed, Apr 28, 2010 at 11:49 AM, Michael Droettboom <md...@st...> wrote:
>> Thanks. Yes, I would consider tabs a bug. A patch is very welcome.
>>
>> Mike
>>
>> Mark Roddy wrote:
>>>
>>> I'm trying to resolve an issue with my source base that uses
>>> matplotlib. We run our CI tests with the '-tt' option which causes
>>> errors on mixed tabs/spaces, and this has caused our builds to start
>>> failing since the inclusion of matploblib on one of our projects due
>>> to mixed use of tab and space characters in some of the pure python
>>> code. We're using v0.99.0 and I count 43 occurences of tab characters
>>> across 5 files in this release. I checked out the trunk and found 26
>>> occurrences across 9 files. I determined these via:
>>> find -name \*.py|xargs grep -P '\t', and
>>> find -name \*.py|xargs grep -Pl '\t'
>>>
>>> According to the style guide[1], use of tabs is a bug, but I wanted to
>>> inquire if this standard is still in place before filing a bug report.
>>> I can provide a patch if so (which should only consist of running
>>> reindent).
>>>
>>> Thanks,
>>> Mark
>>>
>>> 1:
>>> http://matplotlib.sourceforge.net/devel/coding_guide.html#naming-spacing-and-formatting-conventions
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>
> Thanks Mike. I'll open a bug with the patch attached.
>
> -Mark
>
I added a patch to the tracker:
https://sourceforge.net/tracker/?func=detail&aid=2993733&group_id=80706&atid=560720
-Mark

On Wed, Apr 28, 2010 at 11:49 AM, Michael Droettboom <md...@st...> wrote:
> Thanks. Yes, I would consider tabs a bug. A patch is very welcome.
>
> Mike
>
> Mark Roddy wrote:
>>
>> I'm trying to resolve an issue with my source base that uses
>> matplotlib. We run our CI tests with the '-tt' option which causes
>> errors on mixed tabs/spaces, and this has caused our builds to start
>> failing since the inclusion of matploblib on one of our projects due
>> to mixed use of tab and space characters in some of the pure python
>> code. We're using v0.99.0 and I count 43 occurences of tab characters
>> across 5 files in this release. I checked out the trunk and found 26
>> occurrences across 9 files. I determined these via:
>> find -name \*.py|xargs grep -P '\t', and
>> find -name \*.py|xargs grep -Pl '\t'
>>
>> According to the style guide[1], use of tabs is a bug, but I wanted to
>> inquire if this standard is still in place before filing a bug report.
>> I can provide a patch if so (which should only consist of running
>> reindent).
>>
>> Thanks,
>> Mark
>>
>> 1:
>> http://matplotlib.sourceforge.net/devel/coding_guide.html#naming-spacing-and-formatting-conventions
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
Thanks Mike. I'll open a bug with the patch attached.
-Mark

Thanks. Yes, I would consider tabs a bug. A patch is very welcome.
Mike
Mark Roddy wrote:
> I'm trying to resolve an issue with my source base that uses
> matplotlib. We run our CI tests with the '-tt' option which causes
> errors on mixed tabs/spaces, and this has caused our builds to start
> failing since the inclusion of matploblib on one of our projects due
> to mixed use of tab and space characters in some of the pure python
> code. We're using v0.99.0 and I count 43 occurences of tab characters
> across 5 files in this release. I checked out the trunk and found 26
> occurrences across 9 files. I determined these via:
> find -name \*.py|xargs grep -P '\t', and
> find -name \*.py|xargs grep -Pl '\t'
>
> According to the style guide[1], use of tabs is a bug, but I wanted to
> inquire if this standard is still in place before filing a bug report.
> I can provide a patch if so (which should only consist of running
> reindent).
>
> Thanks,
> Mark
>
> 1: http://matplotlib.sourceforge.net/devel/coding_guide.html#naming-spacing-and-formatting-conventions
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm trying to resolve an issue with my source base that uses
matplotlib. We run our CI tests with the '-tt' option which causes
errors on mixed tabs/spaces, and this has caused our builds to start
failing since the inclusion of matploblib on one of our projects due
to mixed use of tab and space characters in some of the pure python
code. We're using v0.99.0 and I count 43 occurences of tab characters
across 5 files in this release. I checked out the trunk and found 26
occurrences across 9 files. I determined these via:
find -name \*.py|xargs grep -P '\t', and
find -name \*.py|xargs grep -Pl '\t'
According to the style guide[1], use of tabs is a bug, but I wanted to
inquire if this standard is still in place before filing a bug report.
 I can provide a patch if so (which should only consist of running
reindent).
Thanks,
Mark
1: http://matplotlib.sourceforge.net/devel/coding_guide.html#naming-spacing-and-formatting-conventions

I think this is due to improper use of the path.simplify_threshold value 
in the simplification code. It should have been squared since it's used 
in a 2-dimensional euclidean distance calculation.
I have made the change to SVN r8280 and updated a few of the unit tests 
that are now more accurate than they used to be. As a workaround (if 
you're not running from SVN and don't want to rebuild), you can set the 
rcParam path.simplify_threshold to 0.01, rather than 0.1.
Mike
Michael Droettboom wrote:
> Thanks. I can confirm this with today's SVN. I'm looking into the cause.
>
> Mike
>
> On 04/25/2010 07:11 PM, Tom Aldcroft wrote:
> 
>> import numpy
>> import matplotlib
>> matplotlib.use('Agg')
>> import matplotlib.pyplot as plt
>>
>> y = numpy.array([
>> 4., 2., 2., 3., 3., 2., 2., 6., 6., 5., 5., 4., 4.,
>> 7., 7., 2., 2., 4., 4., 2., 2., 2., 2., 4., 4., 4.,
>> 4., 4., 4., 7., 7., 3., 3., 5., 5., 4., 4., 5., 5.,
>> 4., 4., 7., 7., 6., 6., 2., 2., 2., 2., 5., 5., 4.,
>> 4., 4., 4., 6., 6., 3., 3., 4., 4., 3., 3., 2., 2.,
>> 3., 3., 4., 4., 4., 4., 4., 4., 6., 6., 5., 5., 4.,
>> 4., 7., 7., 3., 3., 4., 4., 4., 4., 5., 5., 4., 4.,
>> 7., 7., 3., 3., 4., 4., 4., 4., 6., 6., 4., 4., 4.,
>> 4., 4., 4., 2., 2., 5., 5., 6., 6., 3., 3., 5., 5.,
>> 4., 4., 0., 0., 5., 5., 1., 1., 4., 4., 5., 5., 4.])
>>
>> plt.figure(figsize=(7,4))
>> plt.plot(y)
>> plt.savefig('test.png')
>>
>> plt.xlim(-12000, 8274)
>> plt.savefig('test_panned.png')
>> 
>> 
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
I've come across a memory leak when saving multiple figures in a row.
The figure contains a single pcolormesh artist, which I need to
rasterize in my application. However, turning on rasterization causes
a memory leak.The attached script reproduces the problem; swap out the
commented section at the bottom to eliminate memory growth for each
new figure.
I'm not sure what the cause is, though to toss one idea out, might it
have to do with a references that aren't cleaned up from the
rasterizing part of the mixed-mode renderer?
Tested on Mac OS X and, thanks to Patrick Marsh, on Windows.
Thanks,
Eric

I made a small change to the test harness so that the tolerance can be 
set on a per-test basis. I increased the tolerance for the figimage 
test so it passes on my machine.
Cheers,
Mike
Michael Droettboom wrote:
> Jouni K. Seppänen wrote:
> 
>> The following message is a courtesy copy of an article
>> that has been posted to gmane.comp.python.matplotlib.devel as well.
>>
>> Jouni K. Seppänen <jks...@pu...> writes:
>>
>> 
>> 
>>>> It looks like Jouni wrote that test... Jouni: could you verify that the 
>>>> difference isn't significant? If it's not, we can just create a new 
>>>> baseline image.
>>>> 
>>>> 
>>> I can't replicate the problem: for me "nosetests
>>> matplotlib.tests.test_image:test_figimage" passes (Python 2.6.1,
>>> matplotlib revision 8276, OS X 10.6.3). Could you post the failing
>>> images somewhere?
>>> 
>>> 
>> Thanks for the images Michael. If I change all E1 bytes in the current
>> baseline image to E0 bytes, the images match perfectly. Sounds like a
>> change in the discretization of floating-point values to integer bytes.
>>
>> The difference is definitely not significant, but as I said, I get the
>> old image on my system. I don't object to changing the baseline image,
>> but the best solution would be to make the image diff less sensitive.
>> Unfortunately I don't have the time to pursue this now.
>> 
>> 
> Thanks for the analysis. I'll look into the image diffing and see what 
> can be done.
>
> Mike
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Jouni K. Seppänen wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.python.matplotlib.devel as well.
>
> Jouni K. Seppänen <jks...@pu...> writes:
>
> 
>>> It looks like Jouni wrote that test... Jouni: could you verify that the 
>>> difference isn't significant? If it's not, we can just create a new 
>>> baseline image.
>>> 
>> I can't replicate the problem: for me "nosetests
>> matplotlib.tests.test_image:test_figimage" passes (Python 2.6.1,
>> matplotlib revision 8276, OS X 10.6.3). Could you post the failing
>> images somewhere?
>> 
>
> Thanks for the images Michael. If I change all E1 bytes in the current
> baseline image to E0 bytes, the images match perfectly. Sounds like a
> change in the discretization of floating-point values to integer bytes.
>
> The difference is definitely not significant, but as I said, I get the
> old image on my system. I don't object to changing the baseline image,
> but the best solution would be to make the image diff less sensitive.
> Unfortunately I don't have the time to pursue this now.
> 
Thanks for the analysis. I'll look into the image diffing and see what 
can be done.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Jouni K. Seppänen <jk...@ik...> writes:
>> It looks like Jouni wrote that test... Jouni: could you verify that the 
>> difference isn't significant? If it's not, we can just create a new 
>> baseline image.
>
> I can't replicate the problem: for me "nosetests
> matplotlib.tests.test_image:test_figimage" passes (Python 2.6.1,
> matplotlib revision 8276, OS X 10.6.3). Could you post the failing
> images somewhere?
Thanks for the images Michael. If I change all E1 bytes in the current
baseline image to E0 bytes, the images match perfectly. Sounds like a
change in the discretization of floating-point values to integer bytes.
The difference is definitely not significant, but as I said, I get the
old image on my system. I don't object to changing the baseline image,
but the best solution would be to make the image diff less sensitive.
Unfortunately I don't have the time to pursue this now.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Michael Droettboom <md...@st...> writes:
> Thanks, Eric. I can confirm the failure on figimage, but with the same 
> seemingly miniscule difference.
>
> It looks like Jouni wrote that test... Jouni: could you verify that the 
> difference isn't significant? If it's not, we can just create a new 
> baseline image.
I can't replicate the problem: for me "nosetests
matplotlib.tests.test_image:test_figimage" passes (Python 2.6.1,
matplotlib revision 8276, OS X 10.6.3). Could you post the failing
images somewhere?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Thanks, Eric. I can confirm the failure on figimage, but with the same 
seemingly miniscule difference.
It looks like Jouni wrote that test... Jouni: could you verify that the 
difference isn't significant? If it's not, we can just create a new 
baseline image.
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> I'm noticing that SVN r8269 is failing a great number of regression 
>> tests -- with pretty major things like the number of digits in the 
>> formatter being different. The buildbot seems to be getting the same 
>> failures I am, but I don't see any buildbot e-mails since Wednesday. 
>> Does anyone know the source of these errors? It seems to have to do 
>> with changes to the formatters.
>
> Mike,
>
> I have fixed all but one test--in some cases, partly by fixing tests 
> and/or the baseline images.
>
> The one exception is figimage. I don't think I have changed anything 
> that would affect that in any obvious way, but certainly I could be 
> wrong, and I haven't looked into it. The immediate problem is that I 
> can't see what the difference is between the baseline and what I am 
> generating now. They look identical to my eye, on my screen. The diff 
> plot shows up as a black square. The png files are different, 
> differing in length by 2 bytes, so something has changed--but what? 
> Given that I can't *see* any difference, I am tempted to just change 
> the baseline plot so that the test will pass, but maybe that would be 
> a mistake.
>
> Building mpl from a version 2 months ago, I am still seeing the 
> figimage failure.
>
> Eric
>
>
>>
>> Mike
>>
>> ------------------------------------------------------------------------------ 
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> I'm noticing that SVN r8269 is failing a great number of regression 
> tests -- with pretty major things like the number of digits in the 
> formatter being different. The buildbot seems to be getting the same 
> failures I am, but I don't see any buildbot e-mails since Wednesday. 
> Does anyone know the source of these errors? It seems to have to do 
> with changes to the formatters.
Mike,
I have fixed all but one test--in some cases, partly by fixing tests 
and/or the baseline images.
The one exception is figimage. I don't think I have changed anything 
that would affect that in any obvious way, but certainly I could be 
wrong, and I haven't looked into it. The immediate problem is that I 
can't see what the difference is between the baseline and what I am 
generating now. They look identical to my eye, on my screen. The diff 
plot shows up as a black square. The png files are different, differing 
in length by 2 bytes, so something has changed--but what? Given that I 
can't *see* any difference, I am tempted to just change the baseline 
plot so that the test will pass, but maybe that would be a mistake.
Building mpl from a version 2 months ago, I am still seeing the figimage 
failure.
Eric
> 
> Mike
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 04/26/2010 02:37 PM, Eric Firing wrote:
> Michael Droettboom wrote:
>> I'm noticing that SVN r8269 is failing a great number of regression 
>> tests -- with pretty major things like the number of digits in the 
>> formatter being different. The buildbot seems to be getting the same 
>> failures I am, but I don't see any buildbot e-mails since Wednesday. 
>> Does anyone know the source of these errors? It seems to have to do 
>> with changes to the formatters.
>
> Mike,
>
> What is the easiest way to run a single test? I want to work on one 
> failure at at time.
You can provide a dot-separated path to the module and function, eg. 
(this is assuming the test is installed):
nosetests matplotlib.tests.test_simplification:test_clipping
Mike
>
> Eric
>
>
>>
>> Mike
>>
>> ------------------------------------------------------------------------------ 
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Michael Droettboom wrote:
> I'm noticing that SVN r8269 is failing a great number of regression 
> tests -- with pretty major things like the number of digits in the 
> formatter being different. The buildbot seems to be getting the same 
> failures I am, but I don't see any buildbot e-mails since Wednesday. 
> Does anyone know the source of these errors? It seems to have to do 
> with changes to the formatters.
Mike,
What is the easiest way to run a single test? I want to work on one 
failure at at time.
Eric
> 
> Mike
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michael Droettboom wrote:
> I'm noticing that SVN r8269 is failing a great number of regression 
> tests -- with pretty major things like the number of digits in the 
> formatter being different. The buildbot seems to be getting the same 
> failures I am, but I don't see any buildbot e-mails since Wednesday. 
> Does anyone know the source of these errors? It seems to have to do 
> with changes to the formatters.
I suspect I'm the culprit. I will look into it.
Eric
> 
> Mike
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I'm noticing that SVN r8269 is failing a great number of regression 
tests -- with pretty major things like the number of digits in the 
formatter being different. The buildbot seems to be getting the same 
failures I am, but I don't see any buildbot e-mails since Wednesday. 
Does anyone know the source of these errors? It seems to have to do 
with changes to the formatters.
Mike

Thanks. I can confirm this with today's SVN. I'm looking into the cause.
Mike
On 04/25/2010 07:11 PM, Tom Aldcroft wrote:
> import numpy
> import matplotlib
> matplotlib.use('Agg')
> import matplotlib.pyplot as plt
>
> y = numpy.array([
> 4., 2., 2., 3., 3., 2., 2., 6., 6., 5., 5., 4., 4.,
> 7., 7., 2., 2., 4., 4., 2., 2., 2., 2., 4., 4., 4.,
> 4., 4., 4., 7., 7., 3., 3., 5., 5., 4., 4., 5., 5.,
> 4., 4., 7., 7., 6., 6., 2., 2., 2., 2., 5., 5., 4.,
> 4., 4., 4., 6., 6., 3., 3., 4., 4., 3., 3., 2., 2.,
> 3., 3., 4., 4., 4., 4., 4., 4., 6., 6., 5., 5., 4.,
> 4., 7., 7., 3., 3., 4., 4., 4., 4., 5., 5., 4., 4.,
> 7., 7., 3., 3., 4., 4., 4., 4., 6., 6., 4., 4., 4.,
> 4., 4., 4., 2., 2., 5., 5., 6., 6., 3., 3., 5., 5.,
> 4., 4., 0., 0., 5., 5., 1., 1., 4., 4., 5., 5., 4.])
>
> plt.figure(figsize=(7,4))
> plt.plot(y)
> plt.savefig('test.png')
>
> plt.xlim(-12000, 8274)
> plt.savefig('test_panned.png')
> 

On Sun, Apr 25, 2010 at 1:09 PM, Miguel de Val Borro
<mig...@gm...> wrote:
> Hello,
>
> The amplitude of sharp peaks is not shown correctly when several plots
> are stitched together and the x scale becomes very large. I have
> noticed this problem with the pdf and png backends in the attached
> script.
This is a known bug which is fixed in svn. You need to set
path.simplify : False
in your matplotlibrc http://matplotlib.sourceforge.net/users/customizing.html

I've run into a case where the rendering in a line plot is incomplete
and some lines are not drawn at all. I submitted a question to
matplotlib-users with the same subject. Eric Firing responded that
this is a manifestation of the "infamous path simplification" bug,
which should be fixed in svn. However, the script below shows the
same problem for me using the current svn on CentOS-5 with python 2.6.
 For my purposes setting path.simplify to False is fine but Eric
requested that I provide an example, so here it is:
import numpy
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
y = numpy.array([
 4., 2., 2., 3., 3., 2., 2., 6., 6., 5., 5., 4., 4.,
 7., 7., 2., 2., 4., 4., 2., 2., 2., 2., 4., 4., 4.,
 4., 4., 4., 7., 7., 3., 3., 5., 5., 4., 4., 5., 5.,
 4., 4., 7., 7., 6., 6., 2., 2., 2., 2., 5., 5., 4.,
 4., 4., 4., 6., 6., 3., 3., 4., 4., 3., 3., 2., 2.,
 3., 3., 4., 4., 4., 4., 4., 4., 6., 6., 5., 5., 4.,
 4., 7., 7., 3., 3., 4., 4., 4., 4., 5., 5., 4., 4.,
 7., 7., 3., 3., 4., 4., 4., 4., 6., 6., 4., 4., 4.,
 4., 4., 4., 2., 2., 5., 5., 6., 6., 3., 3., 5., 5.,
 4., 4., 0., 0., 5., 5., 1., 1., 4., 4., 5., 5., 4.])
plt.figure(figsize=(7,4))
plt.plot(y)
plt.savefig('test.png')
plt.xlim(-12000, 8274)
plt.savefig('test_panned.png')
- Tom

Gökhan Sever wrote:
> On Sun, Apr 25, 2010 at 1:37 PM, Neal Becker
> <ndb...@gm...> wrote:
> 
>> Qt4Agg is the one that I used first - the one that doesn't work.
>>
> 
> Pardon my wrong guess :) Sometimes this Linux world goes beyond/behind my
> expectations...
> Can you run another Qt4 application properly?
> 
I'm sure I've used lots of PyQt4 apps before.
I just tried hp-toolbox, which seems to be PyQt4, and AFAICT it is working. 
Of course, matplotlib partly works also. Just the save dialog is broken.

On Sun, Apr 25, 2010 at 1:37 PM, Neal Becker <ndb...@gm...> wrote:
> Qt4Agg is the one that I used first - the one that doesn't work.
>
Pardon my wrong guess :) Sometimes this Linux world goes beyond/behind my
expectations...
Can you run another Qt4 application properly?
-- 
Gökhan

Gökhan Sever wrote:
> On Sun, Apr 25, 2010 at 1:28 PM, Neal Becker
> <ndb...@gm...> wrote:
> 
>> savefig works fine.
>>
>> Using 'gtk' backend I can save, but seems to have other problems.
>>
>> Using recommended TkAgg I get error that
>> ImportError: No module named backend_tkagg
>>
> 
> You will have to make some installations to bring TkAgg alive. I would
> suggest trying also the Qt4Agg backend since KDE based on Qt. It is always
> a good idea to use the package manager for these. Let me know if this
> helps.
Qt4Agg is the one that I used first - the one that doesn't work.