matplotlib-users Mailing List for matplotlib

Todd Pataky wrote:
> I'm using the Enthought Python Distribution (EPD_Py25) and I enter 
> IPython with the command: "ipython".
....
> This problem does not occur if I use EPD's PyLab (i.e. "ipython - 
> pylab"). Does anyone know why?
because the whole point of the "pylab" flag to ipython is to tell 
ipython to start up the MPL plotting stuff in separate thread so that it 
can work like you want it to. If you don't' use that flag, then each 
call to pyplot tries to start up a new app, ,but the old one is still 
running, hence you problems.
ipython itself can be used for all sort of things that have nothing to 
do with matplotlib, so that's not its default behavior.
Just use ipython -pylab if you want to do interactive plotting, that's 
what it's for.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Adam Mercer wrote:
> On Wed, May 20, 2009 at 21:25, John Hunter <jd...@gm...> wrote:
> 
>> The problem here is that I built the site docs from svn, not the last
>> release. 0.98.6svn is the version stamp from svn. I have mixed
>> feelings about fixing this. On the one hand, there is merit to having
>> the site docs reflect the current stable release. On the other hand,
>> I like pushing people onto svn HEAD, because this is where all the
>> latest features and bugfixes are. By building the site docs from svn,
>> viewers of the gallery and examples directories, as well as the
>> plain-ol-docs, get a peak at what is possible from svn. If they try
>> it and find their latest installation doesn't support it, after
>> complaining on the mailing list they may try installing svn. And that
>> is a plus for mpl, because we have more testers on svn HEAD and more
>> potential developers.
> 
> That makes sense, however the reason I was asking is that I am the
> maintainer of the MacPorts matplotlib port and I wanted to a way to
> check for the latest release, I had been using a regex to the check
> the latest version as displayed on home page but when this was updated
> to the svn release this broke. Also as the 0.98.5.3 release is not a
> specific release but a sub release of 0.98.5 I can't use the
> sourceforge downloads page to query this.
> 
> It would be really helpful if a page was provided that listed the
> latest stable release that packagers could use to automatically query.
If there's a port of uscan for MacPorts (
http://manpages.debian.net/cgi-bin/man.cgi?query=uscan ) you could
simply use the debian watch file. It's contents are:
version=3
http://sf.net/matplotlib/matplotlib-([0-9]+(?:\.[0-9]+)*)\.tar\.gz

On Wed, May 20, 2009 at 21:25, John Hunter <jd...@gm...> wrote:
> The problem here is that I built the site docs from svn, not the last
> release. 0.98.6svn is the version stamp from svn. I have mixed
> feelings about fixing this. On the one hand, there is merit to having
> the site docs reflect the current stable release. On the other hand,
> I like pushing people onto svn HEAD, because this is where all the
> latest features and bugfixes are. By building the site docs from svn,
> viewers of the gallery and examples directories, as well as the
> plain-ol-docs, get a peak at what is possible from svn. If they try
> it and find their latest installation doesn't support it, after
> complaining on the mailing list they may try installing svn. And that
> is a plus for mpl, because we have more testers on svn HEAD and more
> potential developers.
That makes sense, however the reason I was asking is that I am the
maintainer of the MacPorts matplotlib port and I wanted to a way to
check for the latest release, I had been using a regex to the check
the latest version as displayed on home page but when this was updated
to the svn release this broke. Also as the 0.98.5.3 release is not a
specific release but a sub release of 0.98.5 I can't use the
sourceforge downloads page to query this.
It would be really helpful if a page was provided that listed the
latest stable release that packagers could use to automatically query.
Cheers
Adam

Hi, I'm new to matplotlib, trying to migrate from Matlab, so please 
excuse my rookie ignorance and Matlab thinking.
My question is: why does a GUI figure crash upon repeated calls in 
IPython?
Here is a detailed description:
I'm using the Enthought Python Distribution (EPD_Py25) and I enter 
IPython with the command: "ipython". I then run the script below 
using: %run myScript.py. Everything works fine: when I press 'Enter' 
while in the GUI the figure closes and I can retrieve the data from 
obj.x. However, when I run the script again using %run myScript.py a 
figure is generated but nothing happens; I am forced to reset 
everything using pyplot.close('all'), but cannot regain the GUI 
functionality without exiting IPython.
This problem does not occur if I use EPD's PyLab (i.e. "ipython - 
pylab"). Does anyone know why?
Here is the script:
from numpy.random import rand
from matplotlib import pyplot
class myGUI:
 def __init__(self,x):
 self.fig = pyplot.gcf()
 self.x = x
 #initiate figure:
 self.connect()
 pyplot.plot(self.x)
 pyplot.show()
 def connect(self):
 self.cidkeypress = 
self.fig.canvas.mpl_connect('key_press_event', self.keypress)
 def disconnect(self):
 self.fig.canvas.mpl_disconnect(self.cidkeypress)
 pyplot.close(self.fig)
 def keypress(self,event):
 if event.key == 'enter':
 self.disconnect()
 else:
 self.x = rand(self.x.size)
 pyplot.plot(self.x)
 self.fig.canvas.draw()
pyplot.figure()
obj = myGUI(rand(10))

On Mon, May 18, 2009 at 7:56 AM, John Hunter <jd...@gm...> wrote:
> I have uploaded the source and OSX binaries for the bugfix release of
> matplotlib-0.98.5.3 to
>
> http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
>
> The windows binaries are not yet ready, so I'll followup to this email
> when they are up. Below is a summary of the bugfixes in this release
The windows binaries are now uploaded and ready. We had a problem due
to a binary incompatibility in numpy which was difficult to track
down. The solution was to build the matplotlib binaries against older
versions of numpy. According to my tests, the installers should work
with numpy 1.1 or later, but if you have trouble (eg an unexplained
segfault), try wiping your matplotlib and numpy installations, upgrade
numpy to the latest for your python version, and reinstall matplotlib.
Thanks to Charlie Moad for the windows builds.
JDH

On Wednesday 20 May 2009, John Hunter said something like:
> On Wed, May 20, 2009 at 9:36 PM, Joshua J. Kugler 
<jo...@ee...> wrote:
> > So, my code has been running without flaw for quite some time now,
> > and thanks to the help of some folks here a few months back, I'm
> > learning more about matplotlib. But today I hit a wall.
> >
> > Under matplotlib 0.91.2/Py2.5, I'm getting this graph:
> > http://joshuakugler.com/images/good_graph.png
> >.. .snip
> > No, I haven't assembled a minimal test case (this is quite a
> > complex system, I spent several hours on this thinking I had broken
> > my code until it occurred to me to run it on an old Py2.5/mpl
> > 0.91.2 setup), and no I haven't trolled the changelogs to see what
> > change in behavior I might have hit, but I was wondering if anyone
> > any ideas of what I need to be checking off the top of their heads.
>
> You are running a really old mpl -- the last 0.91 release was about
> 16 months ago. If you want resolution against the latest tree, you
> will need to post an updated script exhibiting the problem.
I realize I was running an old MPL. Hmm...how does MPL define major 
releases? I didn't think there would be API or functionality breakage 
going from 0.91 to 0.98. So, does that mean if I update my program to 
run with 0.98, it will no longer work correctly under 0.91?
> > P.S. Oh, and there is also a nice traceback I'm getting on other
> > graphs that seems to be related to this glitch, but I'll wait until
> > I have the first glitch fixed as the second glitch may get fixed in
> > the process.
>
> Ahh, this is a tantalizing morsel. If only we had the traceback, we
> might be able to help...
Yeah, I know...but I didn't how related it was. For those who care, 
here it is, but I haven't been able to track down what's causing it, 
other than somewhere along the line my start/end points are getting set 
to inf and my code isn't doing it.
Traceback (most recent call last):
 File "./photizo_legacy_graph.py", line 187, in <module>
 'graphs', out_filename ))
 
File "/home/jkugler/programming/photizo/trunk/photizo/legacy/BaseFigure.py", 
line 69, in createImage
 self.layout()
 
File "/home/jkugler/programming/photizo/trunk/photizo/legacy/GWSFigures.py", 
line 31, in layout
 graph1.plotDate()
 
File "/home/jkugler/programming/photizo/trunk/photizo/legacy/BaseGraph.py", 
line 400, in plotDate
 line = self.main_axes.plot_date(g[:,0], g[:,1])
 File "/usr/lib/python2.6/dist-packages/matplotlib/axes.py", line 3348, 
in plot_date
 self.xaxis_date(tz)
 File "/usr/lib/python2.6/dist-packages/matplotlib/axes.py", line 2175, 
in xaxis_date
 locator.refresh()
 File "/usr/lib/python2.6/dist-packages/matplotlib/dates.py", line 559, 
in refresh
 dmin, dmax = self.viewlim_to_dt()
 File "/usr/lib/python2.6/dist-packages/matplotlib/dates.py", line 454, 
in viewlim_to_dt
 return num2date(vmin, self.tz), num2date(vmax, self.tz)
 File "/usr/lib/python2.6/dist-packages/matplotlib/dates.py", line 249, 
in num2date
 if not cbook.iterable(x): return _from_ordinalf(x, tz)
 File "/usr/lib/python2.6/dist-packages/matplotlib/dates.py", line 169, 
in _from_ordinalf
 ix = int(x)
OverflowError: cannot convert float infinity to integer
-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ ID 0xDB26D7CE

On Wed, May 20, 2009 at 9:36 PM, Joshua J. Kugler <jo...@ee...> wrote:
> So, my code has been running without flaw for quite some time now, and
> thanks to the help of some folks here a few months back, I'm learning
> more about matplotlib. But today I hit a wall.
>
> Under matplotlib 0.91.2/Py2.5, I'm getting this graph:
> http://joshuakugler.com/images/good_graph.png
>.. .snip
> No, I haven't assembled a minimal test case (this is quite a complex
> system, I spent several hours on this thinking I had broken my code
> until it occurred to me to run it on an old Py2.5/mpl 0.91.2 setup),
> and no I haven't trolled the changelogs to see what change in behavior
> I might have hit, but I was wondering if anyone any ideas of what I
> need to be checking off the top of their heads.
You are running a really old mpl -- the last 0.91 release was about 16
months ago. If you want resolution against the latest tree, you will
need to post an updated script exhibiting the problem.
> P.S. Oh, and there is also a nice traceback I'm getting on other graphs
> that seems to be related to this glitch, but I'll wait until I have the
> first glitch fixed as the second glitch may get fixed in the process.
Ahh, this is a tantalizing morsel. If only we had the traceback, we
might be able to help...
JDH
JDH

So, my code has been running without flaw for quite some time now, and 
thanks to the help of some folks here a few months back, I'm learning 
more about matplotlib. But today I hit a wall.
Under matplotlib 0.91.2/Py2.5, I'm getting this graph:
http://joshuakugler.com/images/good_graph.png
Very nice, that's what I want!
But when I started running under matplotlib 0.98.5.2/Py2.6, I started 
getting this:
http://joshuakugler.com/images/bad_scale.png
Not happy. I finally realized that autoscaling was enable for the 
secondary y axis (right side), even though it's explicitly turned off 
for the primar y axis (left side). So, I turn autoscaling off for the 
secondary axis and got this:
http://joshuakugler.com/images/bad_noscale.png
Better (proper range) but I have numbers instead of dates.
No, I haven't assembled a minimal test case (this is quite a complex 
system, I spent several hours on this thinking I had broken my code 
until it occurred to me to run it on an old Py2.5/mpl 0.91.2 setup), 
and no I haven't trolled the changelogs to see what change in behavior 
I might have hit, but I was wondering if anyone any ideas of what I 
need to be checking off the top of their heads.
I can tell you: the problem only occurrs on graphs that have a secondary 
y axis, as you can see, the humidity graph is just fine.
Ideas? Sections of the manual I need to read?
I'm frustrated and burnt out from trying to figure this out, so I'm done 
for the night...hopefully I'll have fresh insights and/or ideas come 
morning.
j
P.S. Oh, and there is also a nice traceback I'm getting on other graphs 
that seems to be related to this glitch, but I'll wait until I have the 
first glitch fixed as the second glitch may get fixed in the process.
-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ ID 0xDB26D7CE

On Mon, May 18, 2009 at 5:34 PM, Adam Mercer <ram...@gm...> wrote:
> On Mon, May 18, 2009 at 07:56, John Hunter <jd...@gm...> wrote:
>> I have uploaded the source and OSX binaries for the bugfix release of
>> matplotlib-0.98.5.3 to
>>
>> http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
>
> The homepage is saying that the latest release is 0.98.6svn, can this
> be corrected?
The problem here is that I built the site docs from svn, not the last
release. 0.98.6svn is the version stamp from svn. I have mixed
feelings about fixing this. On the one hand, there is merit to having
the site docs reflect the current stable release. On the other hand,
I like pushing people onto svn HEAD, because this is where all the
latest features and bugfixes are. By building the site docs from svn,
viewers of the gallery and examples directories, as well as the
plain-ol-docs, get a peak at what is possible from svn. If they try
it and find their latest installation doesn't support it, after
complaining on the mailing list they may try installing svn. And that
is a plus for mpl, because we have more testers on svn HEAD and more
potential developers.
We are endeavoring to get a regular buildbot process going, with
regular builds and possibly nightly binaries for multiple platforms.
That way, the site can stay on svn HEAD, and users who want to the
latest can be pointed to ready-built installers from the buildbots.
In the meantime, if you want your local installation to match the
version on the website, try installing from svn <wink>
 http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-svn
JDH