matplotlib-devel Mailing List for matplotlib (Page 2)

Yes. IPython certainly has what looks like a reasonable "recipe" to 
support PySide and PyQt4. I would much prefer this approach. Anything 
to keep the number of code paths down in the different backends is well 
worth the effort.
Mike
________________________________________
From: Peter Butterworth [bu...@gm...]
Sent: Sunday, March 27, 2011 1:10 PM
To: matplotlib-devel
Subject: Re: [matplotlib-devel] Backend for Pyside
Wouldn't it be possible to use a single backend compatible with both
PyQt and Pyside ?
Other projects (enthought, ipython, spyderlib) seem to be able to
handle the issue by importing from a proxy qt module that does the
right imports and handles the incompatibilities. The preferred backend
is set through an environment variable.
>>> Re: Backend for Pyside
by Gerald Storer Mar 23, 2011; 08:33am :: Rate this Message: - Use
ratings to moderate (?)
I've just noticed that its possible to use an external package as a
back end so I moved my changes into their own package. This is
sufficient for my own use but I'm guessing others may find is useful
as well (and it might speed official support).
Attached is the package. (pysidempl)
Regards,
Gerald.
--
thanks,
peter butterworth
------------------------------------------------------------------------------
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-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello all,
I managed to merge my docfix/improve_description branch over to v1.0.x, but
I am having trouble merging correctly over to master. It appears that the
README.osx and make.osx files were changed in v1.0.x, but not in master. So
my merge wants me to resolve these differences -- which I am not about ready
to do. There is also some sort of conflict with doc/faq/installing_faq.rst,
but that conflict is easy to resolve (change build_dep to build-dep).
Maybe we need to cherry-pick the changes to README.osx and make.osx from
v1.0.x to master first?
Thanks,
Ben Root

I have been able to get pygtk installed on OSX by following these
instructions, and it works fine:
http://kedeligdata.blogspot.com/2011/03/building-pygtk-for-mac.html
I would really like to get GTK working on OSX since I have done some app
development using GTK and Glade, and I can get GTK and Glade working without
problems on both Windows and Linux machines. OSX is the thorn in my side at
the moment.
FYI: In make.osx, the path for the libpng install is no longer any good, the
correct full path should be
http://sourceforge.net/projects/libpng/files/libpng12/1.2.44/libpng-1.2.44.tar.gz/download
The linpng folks seem to have relocated their installation files on the
sourceforge server.
When altering the paths for GTK, what modifications are required? How can I
help the matplotlib install find the GTK files?
Regards,
Ian
----
Ian Bell
Graduate Research Assistant
Herrick Labs
Purdue University
email: ib...@pu...
cell: (607)227-7626

Wouldn't it be possible to use a single backend compatible with both
PyQt and Pyside ?
Other projects (enthought, ipython, spyderlib) seem to be able to
handle the issue by importing from a proxy qt module that does the
right imports and handles the incompatibilities. The preferred backend
is set through an environment variable.
>>> Re: Backend for Pyside
by Gerald Storer Mar 23, 2011; 08:33am :: Rate this Message: - Use
ratings to moderate (?)
I've just noticed that its possible to use an external package as a
back end so I moved my changes into their own package. This is
sufficient for my own use but I'm guessing others may find is useful
as well (and it might speed official support).
Attached is the package. (pysidempl)
Regards,
Gerald.
-- 
thanks,
peter butterworth

Eric Firing <ef...@ha...> writes:
> Will you commit the new "expected" png file? Sorry I did not catch this.
Done.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 03/26/2011 11:12 AM, Jouni K. Seppänen wrote:
> The test lib/matplotlib/tests/test_axes.py:test_polar_annotations is
> failing on master. It passes in 0a9e86a but fails in the next commit
> 8506c33 "Merge branch 'colorcycle' of git://github.com/faucon/matplotlib".
>
> In the image diff, the text and arrow have shifted a little, but
> that's probably due to ftfont differences and is allowed by the
> comparison. The failing part is the color of the marker, which has
> changed from green to blue.
>
> Is this an intended consequence of the color-cycle change?
Yes, it is consistent with the idea behind the change, which is that 
generating a plot element with an explicit color specified should not 
advance the color cycle. The marker is the first plot element with no 
explicit color, so it should start at the beginning of the cycle, which 
is blue, not green.
Will you commit the new "expected" png file? Sorry I did not catch this.
Eric

The test lib/matplotlib/tests/test_axes.py:test_polar_annotations is
failing on master. It passes in 0a9e86a but fails in the next commit
8506c33 "Merge branch 'colorcycle' of git://github.com/faucon/matplotlib".
In the image diff, the text and arrow have shifted a little, but
that's probably due to ftfont differences and is allowed by the
comparison. The failing part is the color of the marker, which has
changed from green to blue.
Is this an intended consequence of the color-cycle change?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I found that
def set_sort_zpos(self,val):
 '''Set the position to use for z-sorting.'''
 self._sort_zpos = val
was missing from
class Line3DCollection(LineCollection) (in matplotlib 1.0.1):
Now, with the above method added, add_collection3d works as it should with line 
segments, and the following will work as expected :-)
'''
 Purpose: Waterfall plot using LineCollection
 Author: V.P.S. (2011年03月26日)
'''
from mpl_toolkits.mplot3d import Axes3D
from matplotlib.collections import LineCollection
from matplotlib.colors import colorConverter
import matplotlib.pyplot as plt
import numpy as np
np.random.seed(40040157) # Used to allow repeatable experiments (plots)
fig = plt.figure()
ax = fig.gca(projection='3d')
cc = [colorConverter.to_rgba(c,alpha=0.6) for c in ('r','g','b','c','y','m','k')]
ncc = len(cc)
nxs = 5 # Num of points to connect (nxs-1 line segments)
# Generate X values
xs = np.arange(1, nxs+1, 1)
# Create array of Y values (to be updated)
ys = np.zeros(nxs)
# Create list of Z values
nzs = 4 # Num of Z-planes
zs = [zs+1 for zs in range(nzs)]
# Create list of colors (cyclic) for lines
colorlist = [cc[j%ncc] for j in range(nzs)]
segs = []
# Generate line segments in each Z-plane
for j in zs:
 ys = np.random.rand(nxs)
 segs.append(zip(xs, ys))
curves = LineCollection(segs, colors = colorlist)
ax.add_collection3d(curves, zs=zs, zdir='y')
ax.set_xlabel('X') # points to right -- X
ax.set_xlim3d(0, nxs+1)
ax.set_ylabel('Y') # points into screen -- Y
ax.set_ylim3d(0, nzs+1)
ax.set_zlabel('Z') # points up -- Z
ax.set_zlim3d(0, 1)
plt.show()
Have a Good Day
--V

Blast from the past!
I just ran into this and it comes from the fact that
'matplotlib.tests.test_text' is not in the default_test_modules
variable inside matplotlib's __init__.py
Here's the necessary diff:
index 82633a5..649e4d8 100644
--- a/lib/matplotlib/__init__.py
+++ b/lib/matplotlib/__init__.py
@@ -968,7 +968,8 @@ default_test_modules =3D [
 'matplotlib.tests.test_spines',
 'matplotlib.tests.test_image',
 'matplotlib.tests.test_simplification',
- 'matplotlib.tests.test_mathtext'
+ 'matplotlib.tests.test_mathtext',
+ 'matplotlib.tests.test_text'
 ]
I added a pull request for this two line change just in case
there was a specific reason to *exclude* test_text from the test
modules?=20
For instance, right now, I get one failure in the test suite if I
include it. The failure is in test_text:test_font_styles, but
this has been the case for a while, it's just that these tests
weren't running before.
Any developers want to chime in on this?
best,
--
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
Michael Droettboom, on 2010年07月27日 11:19, wrote:
> Hmm... surprisingly, I am actually able to reproduce this sort of=20
> behaviour here. I'll look into it further.
>=20
> Mike
>=20
> On 07/27/2010 09:49 AM, Michael Droettboom wrote:
> > Of course, we'll prefer to see all of the tests pass...
> >
> > I'm surprised the two modes of running the tests gives different
> > results. Are you sure they are running the same python? Does
> >
> > python `which nosetests` matplotlib.tests
> >
> > give you the same result as
> >
> > nosetests matplotlib.tests
> >
> > ?
> >
> > There must be some environmental difference between the two to cause the
> > different results.
> >
> > Mike
> >
> > On 07/24/2010 05:09 PM, Adam wrote:
> > =20
> >> Hello, I have just updated to v1.0.0 and am trying to run the test
> >> suite to make sure everything is ok. There seems to be two different
> >> suites and I am not sure which is correct/current:
> >>
> >> $python -c 'import matplotlib; matplotlib.test()'
> >> [...snipped output...]
> >> Ran 138 tests in 390.991s
> >> OK (KNOWNFAIL=3D2)
> >>
> >> $nosetests matplotlib.tests I get:
> >> [...snipped output]
> >> Ran 144 tests in 380.165s
> >> FAILED (errors=3D4, failures=3D1)
> >>
> >> Two of these errors are the known failures from above, and the other
> >> two are in "matplotlib.tests.test_text.test_font_styles":
> >> ImageComparisonFailure: images not close:
> >> /home/adam/result_images/test_text/font_styles.png vs.
> >> /home/adam/result_images/test_text/expected-font_styles.png (RMS
> >> 23.833)
> >> ImageComparisonFailure: images not close:
> >> /home/adam/result_images/test_text/font_styles_svg.png vs.
> >> /home/adam/result_images/test_text/expected-font_styles_svg.png (RMS
> >> 12.961)
> >>
> >> The module that fails is:
> >>
> >> FAIL: matplotlib.tests.test_mlab.test_recarray_csv_roundtrip
> >> ----------------------------------------------------------------------
> >> Traceback (most recent call last):
> >> File "/usr/local/lib/python2.6/dist-packages/nose-0.11.4-py2.6.egg/=
nose/case.py",
> >> line 186, in runTest
> >> self.test(*self.arg)
> >> File "/usr/local/lib/python2.6/dist-packages/matplotlib/tests/test_=
mlab.py",
> >> line 24, in test_recarray_csv_roundtrip
> >> assert np.allclose( expected['x'], actual['x'] )
> >> AssertionError
> >>
> >>
> >>
> >> I am not sure of the importance level of these - but I wanted to ask
> >> to see if I should do anything or if they can safely be ignored.
> >>
> >> Thanks,
> >> Adam.

Blast from the past!
I just ran into this and it comes from the fact that
'matplotlib.tests.test_text' is not in the default_test_modules
variable inside matplotlib's __init__.py
Here's the necessary diff:
index 82633a5..649e4d8 100644
--- a/lib/matplotlib/__init__.py
+++ b/lib/matplotlib/__init__.py
@@ -968,7 +968,8 @@ default_test_modules = [
 'matplotlib.tests.test_spines',
 'matplotlib.tests.test_image',
 'matplotlib.tests.test_simplification',
- 'matplotlib.tests.test_mathtext'
+ 'matplotlib.tests.test_mathtext',
+ 'matplotlib.tests.test_text'
 ]
I added a pull request for this two line change just in case
there was a specific reason to *exclude* test_text from the test
modules? 
For instance, right now, I get one failure in the test suite if I
include it. The failure is in test_text:test_font_styles, but
this has been the case for a while, it's just that these tests
weren't running before.
Any developers want to chime in on this?
best,
-- 
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
Michael Droettboom, on 2010年07月27日 11:19, wrote:
> Hmm... surprisingly, I am actually able to reproduce this sort of 
> behaviour here. I'll look into it further.
> 
> Mike
> 
> On 07/27/2010 09:49 AM, Michael Droettboom wrote:
> > Of course, we'll prefer to see all of the tests pass...
> >
> > I'm surprised the two modes of running the tests gives different
> > results. Are you sure they are running the same python? Does
> >
> > python `which nosetests` matplotlib.tests
> >
> > give you the same result as
> >
> > nosetests matplotlib.tests
> >
> > ?
> >
> > There must be some environmental difference between the two to cause the
> > different results.
> >
> > Mike
> >
> > On 07/24/2010 05:09 PM, Adam wrote:
> > 
> >> Hello, I have just updated to v1.0.0 and am trying to run the test
> >> suite to make sure everything is ok. There seems to be two different
> >> suites and I am not sure which is correct/current:
> >>
> >> $python -c 'import matplotlib; matplotlib.test()'
> >> [...snipped output...]
> >> Ran 138 tests in 390.991s
> >> OK (KNOWNFAIL=2)
> >>
> >> $nosetests matplotlib.tests I get:
> >> [...snipped output]
> >> Ran 144 tests in 380.165s
> >> FAILED (errors=4, failures=1)
> >>
> >> Two of these errors are the known failures from above, and the other
> >> two are in "matplotlib.tests.test_text.test_font_styles":
> >> ImageComparisonFailure: images not close:
> >> /home/adam/result_images/test_text/font_styles.png vs.
> >> /home/adam/result_images/test_text/expected-font_styles.png (RMS
> >> 23.833)
> >> ImageComparisonFailure: images not close:
> >> /home/adam/result_images/test_text/font_styles_svg.png vs.
> >> /home/adam/result_images/test_text/expected-font_styles_svg.png (RMS
> >> 12.961)
> >>
> >> The module that fails is:
> >>
> >> FAIL: matplotlib.tests.test_mlab.test_recarray_csv_roundtrip
> >> ----------------------------------------------------------------------
> >> Traceback (most recent call last):
> >> File "/usr/local/lib/python2.6/dist-packages/nose-0.11.4-py2.6.egg/nose/case.py",
> >> line 186, in runTest
> >> self.test(*self.arg)
> >> File "/usr/local/lib/python2.6/dist-packages/matplotlib/tests/test_mlab.py",
> >> line 24, in test_recarray_csv_roundtrip
> >> assert np.allclose( expected['x'], actual['x'] )
> >> AssertionError
> >>
> >>
> >>
> >> I am not sure of the importance level of these - but I wanted to ask
> >> to see if I should do anything or if they can safely be ignored.
> >>
> >> Thanks,
> >> Adam.

On 16 Mar 2011, at 09:48, Georges Arsouze wrote:
> I'am working with Python3.1 under Mac Os Snow Leopard
> I download matplotlib with http://www.cgl.ucsf.edu/Outreach/pc204/matplotlib.html
>
> It doesn't work
> Can you help me ?
>
That package, as the site states (though maybe not clearly enough),
has been built for Snow Leopard's system Python 2.6.2, so it cannot
work with Python3.1. If you call python2.6 or /usr/bin/python, you 
should
be able to use matplotlib. But if you need Python3.1, I am afraid you
are stuck for the moment, since the latest release does not support
Python3 yet. I think support is in the works, and may be partly 
available
in the development version, but unless you have considerable experience
in building your own installation, I would not recommend that road.
HTH,
						Derek

Georges Arsouze, on 2011年03月16日 09:48, wrote:
> Hello
> I'am working with Python3.1 under Mac Os Snow Leopard
> I download matplotlib with
> http://www.cgl.ucsf.edu/Outreach/pc204/matplotlib.html
> 
> It doesn't work
> Can you help me ?
Hi Georges,
What version of matplotlib are you trying to run? At the moment,
there isn't a "stable" release which is compatible with Python 3,
and you have to grab it from:
https://github.com/matplotlib/matplotlib-py3
Not all of the backends work in -py3, mostly because the underlying toolkits
have not been ported to Python 3. You can notes about the work in
progress, what's been completed, and what's left to do here:
https://github.com/matplotlib/matplotlib-py3/wiki
(Also, this is more of a matplotlib-users question, so I'm replying
to that list)
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

All,
This is due to the fact that you have nothing to plot and the axes range
defaults to 0->1. Unfortunately 0 cannot map to a valid datetime. I
thought that I had fixed this so that using datetimes would cause the axes
to initialize to a valid datetime value. Once I get up to speed with the
whole 'git' thing and figure out how to make submissions again, etc. 
A quick work-around is to manually set the bounds for our datetime axis and
turn off autoscaling until you have some data to display.
I can probably take another look at it, but I am pretty busy and learning
the git model of doing things is only slowing things down. :(
--James
> -----Original Message-----
> From: Benjamin Root [mailto:ben...@ou...]
> Sent: Friday, March 25, 2011 6:34 AM
> To: Gerrit Kuhlmann
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Bug: plot numpy.nans vs. datetime objects
> 
> On Friday, March 25, 2011, Gerrit Kuhlmann
> <ger...@st...> wrote:
> > On Fri, 2011年03月25日 at 01:08 -0700, Paul Ivanov wrote:
> >> Gerrit Kuhlmann, on 2011年03月25日 14:26, wrote:
> >> > Hi all,
> >> >
> >> > I get a ValueError, if I try to plot a list of numpy.nans against
> >> > datetime objects. I'm using Python 2.6.5 and Matplotlib 1.0.1 on
> >> > Ubuntu Linux 10.04. Code and traceback are below.
> >> >
> >> > Best regards,
> >> > Gerrit
> >> >
> >> >
> >> >
> >> > Code
> >> > """"
> >> > import matplotlib.pyplot as plt
> >> > import numpy as np
> >> > from datetime import datetime as DateTime
> >> >
> >> > t = [DateTime(2011,1,day) for day in xrange(1,20)] x = [np.nan for
> >> > i in xrange(1,20)]
> >> >
> >> > plt.plot(t,x)
> >> > plt.show()
> >>
> >> Hi Gerrit,
> >>
> >> Thanks for the report, though I'm not sure what you expect to happen
> >> here?
> >>
> >> Changing at least one of the elements of x to be something other than
> >> nan does not cause the error.
> >>
> >> There is an inconsistency, though, in that plt.plot(x,x) when x is
> >> full of nans does not cause any errors.
> >>
> >> best,
> >
> > Hi Paul,
> >
> > thanks for your answer. I would expect similar behaviour as for
> > "plot([0,1,2], [nan,nan,nan])", which creates an empty plot. A passed
> > through exceptions from the datetime module seems a bit odd.
> >
> > Regards,
> > Gerrit
> >
> 
> Agreed, I just came across this yesterday while working on my general exam
> project. I have no clue why the behavior would be different because we
are
> using datetime objects.
> 
> Ben Root
> 
> 
> >
> > ----------------------------------------------------------------------
> > -------- 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-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> 
>
----------------------------------------------------------------------------
--
> 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-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Friday, March 25, 2011, Gerrit Kuhlmann
<ger...@st...> wrote:
> On Fri, 2011年03月25日 at 01:08 -0700, Paul Ivanov wrote:
>> Gerrit Kuhlmann, on 2011年03月25日 14:26, wrote:
>> > Hi all,
>> >
>> > I get a ValueError, if I try to plot a list of numpy.nans against
>> > datetime objects. I'm using Python 2.6.5 and Matplotlib 1.0.1 on Ubuntu
>> > Linux 10.04. Code and traceback are below.
>> >
>> > Best regards,
>> > Gerrit
>> >
>> >
>> >
>> > Code
>> > """"
>> > import matplotlib.pyplot as plt
>> > import numpy as np
>> > from datetime import datetime as DateTime
>> >
>> > t = [DateTime(2011,1,day) for day in xrange(1,20)]
>> > x = [np.nan for i in xrange(1,20)]
>> >
>> > plt.plot(t,x)
>> > plt.show()
>>
>> Hi Gerrit,
>>
>> Thanks for the report, though I'm not sure what you expect to
>> happen here?
>>
>> Changing at least one of the elements of x to be something other
>> than nan does not cause the error.
>>
>> There is an inconsistency, though, in that plt.plot(x,x) when x
>> is full of nans does not cause any errors.
>>
>> best,
>
> Hi Paul,
>
> thanks for your answer. I would expect similar behaviour as for
> "plot([0,1,2], [nan,nan,nan])", which creates an empty plot. A passed
> through exceptions from the datetime module seems a bit odd.
>
> Regards,
> Gerrit
>
Agreed, I just came across this yesterday while working on my general
exam project. I have no clue why the behavior would be different
because we are using datetime objects.
Ben Root
>
> ------------------------------------------------------------------------------
> 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-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Fri, 2011年03月25日 at 01:08 -0700, Paul Ivanov wrote: 
> Gerrit Kuhlmann, on 2011年03月25日 14:26, wrote:
> > Hi all,
> > 
> > I get a ValueError, if I try to plot a list of numpy.nans against
> > datetime objects. I'm using Python 2.6.5 and Matplotlib 1.0.1 on Ubuntu
> > Linux 10.04. Code and traceback are below.
> > 
> > Best regards,
> > Gerrit
> > 
> > 
> > 
> > Code
> > """"
> > import matplotlib.pyplot as plt
> > import numpy as np
> > from datetime import datetime as DateTime
> > 
> > t = [DateTime(2011,1,day) for day in xrange(1,20)]
> > x = [np.nan for i in xrange(1,20)]
> > 
> > plt.plot(t,x)
> > plt.show()
> 
> Hi Gerrit,
> 
> Thanks for the report, though I'm not sure what you expect to
> happen here?
> 
> Changing at least one of the elements of x to be something other
> than nan does not cause the error.
> 
> There is an inconsistency, though, in that plt.plot(x,x) when x
> is full of nans does not cause any errors.
> 
> best,
Hi Paul,
thanks for your answer. I would expect similar behaviour as for
"plot([0,1,2], [nan,nan,nan])", which creates an empty plot. A passed
through exceptions from the datetime module seems a bit odd. 
Regards,
Gerrit

Gerrit Kuhlmann, on 2011年03月25日 14:26, wrote:
> Hi all,
> 
> I get a ValueError, if I try to plot a list of numpy.nans against
> datetime objects. I'm using Python 2.6.5 and Matplotlib 1.0.1 on Ubuntu
> Linux 10.04. Code and traceback are below.
> 
> Best regards,
> Gerrit
> 
> 
> 
> Code
> """"
> import matplotlib.pyplot as plt
> import numpy as np
> from datetime import datetime as DateTime
> 
> t = [DateTime(2011,1,day) for day in xrange(1,20)]
> x = [np.nan for i in xrange(1,20)]
> 
> plt.plot(t,x)
> plt.show()
Hi Gerrit,
Thanks for the report, though I'm not sure what you expect to
happen here?
Changing at least one of the elements of x to be something other
than nan does not cause the error.
There is an inconsistency, though, in that plt.plot(x,x) when x
is full of nans does not cause any errors.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Hi all,
I get a ValueError, if I try to plot a list of numpy.nans against
datetime objects. I'm using Python 2.6.5 and Matplotlib 1.0.1 on Ubuntu
Linux 10.04. Code and traceback are below.
Best regards,
Gerrit
Code
""""
import matplotlib.pyplot as plt
import numpy as np
from datetime import datetime as DateTime
t = [DateTime(2011,1,day) for day in xrange(1,20)]
x = [np.nan for i in xrange(1,20)]
plt.plot(t,x)
plt.show()
Traceback
"""""""""
Exception in Tkinter callback
Traceback (most recent call last):
 File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1413, in __call__
 return self.func(*args)
 File
"/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_tkagg.py", line 245, in resize
 self.show()
 File
"/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_tkagg.py", line 248, in draw
 FigureCanvasAgg.draw(self)
 File
"/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_agg.py", line 394, in draw
 self.figure.draw(self.renderer)
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/artist.py",
line 55, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/figure.py",
line 798, in draw
 func(*args)
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/artist.py",
line 55, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
1946, in draw
 a.draw(renderer)
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/artist.py",
line 55, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/axis.py", line
971, in draw
 tick_tups = [ t for t in self.iter_ticks()]
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/axis.py", line
904, in iter_ticks
 majorLocs = self.major.locator()
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/dates.py",
line 743, in __call__
 self.refresh()
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/dates.py",
line 752, in refresh
 dmin, dmax = self.viewlim_to_dt()
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/dates.py",
line 524, in viewlim_to_dt
 return num2date(vmin, self.tz), num2date(vmax, self.tz)
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/dates.py",
line 289, in num2date
 if not cbook.iterable(x): return _from_ordinalf(x, tz)
 File "/usr/local/lib/python2.6/dist-packages/matplotlib/dates.py",
line 203, in _from_ordinalf
 dt = datetime.datetime.fromordinal(ix)
ValueError: ordinal must be >= 1

Matthew Brett, on 2011年03月24日 16:37, wrote:
> Welcome to the wonderful world of git and DVCS!
Thanks, I wish I could claim that I only started using git
recently, but I've just sort of been uncomfortably trying my best
to not cause too much trouble for the past year and a half...
> 
> I think you could have solved this one by:
> 
> git reset --hard 8506c33c811e970c6aa73a446d3ed223ac48f989
> 
> and pushing that. Assuming you had that commit, which I guess you would have.
This actually wasn't the case - I hadn't pulled from
matplotlib/master for a few days, hence the stale commit become a
head after my push.
 
> The way I try and avoid doing that very easy thing is
> 
> 1) Having a moderately frightening name for the upstream remote like
> 'upstream-rw'.
> 2) Having a moderately frightening name for the tracking branch like:
> 
> git co -b main-master --track upstream-rw/master
good tips, thanks.
> 
> 3) Making sure I've got the git-completion bash command line
> completion tools working, so I can always see my branch name
This was actually the case for me - I wasn't working on master,
but a seperate branch called 'one-figure' which didn't have a
remote branch affiliated with it (or a wrong one). I had
previously pushed it using 'git push ivanov one-figure', and
*wrongly* assumed that this state was preserved somewhere
16:46@matplotlib(one-figure)$ 
> 4) Never working on main-master, always branching, and merging when I'm sure.
> 5) Deleting my own master branch to avoid confusion. This involves:
> 
> Going to your github fork, choosing Admin, set default branch to be
> something other than 'master'
> 
> git co that-other-branch
> git branch -D master # delete locally
> git push origin :master # delete on github
> 
> Every error, is a jewel.
Wise words, but if that were true, De Beers and Tiffany's
couldn't hope to compete with me.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Hi Paul,
On Thu, Mar 24, 2011 at 2:55 AM, Paul Ivanov <piv...@gm...> wrote:
> Paul Ivanov, on 2011年03月24日 01:30, wrote:
>> I offer my sincerest apologies, I royally screwed up and thought
>> that I was pushing out to one of my own branches and somehow
>> ended up pushing a 2 day old copy of master out to
>> matplotlib/master with 'git push -f'. Assuming Mike's work from
>> today is also in his own master branch, I think the damage can be
>> undone by just pulling from
>> https://github.com/mdboom/matplotlib/master and pushing that to
>> https://matplotlib/matplotlib/master, but at this point I don't
>> trust myself and just want to not cause any more damage than I've
>> already done.
>>
>> I realize that people get their commit right revoked for such
>> careless shenanigans, but I will be grateful if you'd all allow
>> me the opportunity always run any push commands with the
>> --dry-run flag from now on.
>
> I can't figure out a way to pull it from there, but I think Eric
> was the last to commit to trunk before I (destructively) pushed
> my stale copy. Eric's last commit hash was:
> 8506c33c811e970c6aa73a446d3ed223ac48f989
>
> At least that's what I see on https://github.com/organizations/matplotlib
>
> hopefully this will help someone who get git better than I do.
Welcome to the wonderful world of git and DVCS!
I think you could have solved this one by:
git reset --hard 8506c33c811e970c6aa73a446d3ed223ac48f989
and pushing that. Assuming you had that commit, which I guess you would have.
The way I try and avoid doing that very easy thing is
1) Having a moderately frightening name for the upstream remote like
'upstream-rw'.
2) Having a moderately frightening name for the tracking branch like:
git co -b main-master --track upstream-rw/master
3) Making sure I've got the git-completion bash command line
completion tools working, so I can always see my branch name
4) Never working on main-master, always branching, and merging when I'm sure.
5) Deleting my own master branch to avoid confusion. This involves:
Going to your github fork, choosing Admin, set default branch to be
something other than 'master'
git co that-other-branch
git branch -D master # delete locally
git push origin :master # delete on github
Every error, is a jewel.
See you,
Matthew

On Thu, Mar 24, 2011 at 7:28 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Paul Ivanov <piv...@gm...> writes:
>
>> I can't figure out a way to pull it from there, but I think Eric
>> was the last to commit to trunk before I (destructively) pushed
>> my stale copy. Eric's last commit hash was:
>> 8506c33c811e970c6aa73a446d3ed223ac48f989
>
> The git and ssh transports will only fetch branches and tags, but I was
> able to get this commit with git http-fetch. I pushed it to master, so
> it should be fine now.
>
> Avoid using git push -f from now on, OK? :-)
Thanks Jouni. "git push -f" does not exist to me when pushing upstream.

Paul Ivanov <piv...@gm...> writes:
> I can't figure out a way to pull it from there, but I think Eric
> was the last to commit to trunk before I (destructively) pushed
> my stale copy. Eric's last commit hash was:
> 8506c33c811e970c6aa73a446d3ed223ac48f989
The git and ssh transports will only fetch branches and tags, but I was
able to get this commit with git http-fetch. I pushed it to master, so
it should be fine now.
Avoid using git push -f from now on, OK? :-)
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Mar 24, 2011, at 4:59 AM, John Hunter <jd...@gm...> wrote:
> 
> With git you can clean up bad commits by simply changing the reference to master, or reorder and edit commits with rebase. Darren, can you take a look and see what should be done? It may be more complicated when you have multiple forks and branches, this part I'm less clear on so perhaps Darren you can comment on this too. 
> 
Paul, just an FYI, the section "to reset, or not to reset" on page 24 of "git from the bottom up" discusses resetting the head to prior commits. 
http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
But we should let Darren (or someone with comparable git foo) make the call about the right way to repair the tree. 
JDH

On Mar 24, 2011, at 3:30 AM, Paul Ivanov <piv...@gm...> wrote:
> I offer my sincerest apologies, I royally screwed up and thought
> that I was pushing out to one of my own branches and somehow
> ended up pushing a 2 day old copy of master out to
> matplotlib/master with 'git push -f'. Assuming Mike's work from
> today is also in his own master branch, I think the damage can be
> undone by just pulling from
> https://github.com/mdboom/matplotlib/master and pushing that to
> https://matplotlib/matplotlib/master, but at this point I don't
> trust myself and just want to not cause any more damage than I've
> already done.
> 
> I realize that people get their commit right revoked for such
> careless shenanigans, but I will be grateful if you'd all allow
> me the opportunity always run any push commands with the
> --dry-run flag from now on.
With git you can clean up bad commits by simply changing the reference to master, or reorder and edit commits with rebase. Darren, can you take a look and see what should be done? It may be more complicated when you have multiple forks and branches, this part I'm less clear on so perhaps Darren you can comment on this too. 
Anyhow Paul, just an accident. Pales in comparison to my losing all of the ancient commit history in a CVS reorganization. 
> 

Paul Ivanov, on 2011年03月24日 01:30, wrote:
> I offer my sincerest apologies, I royally screwed up and thought
> that I was pushing out to one of my own branches and somehow
> ended up pushing a 2 day old copy of master out to
> matplotlib/master with 'git push -f'. Assuming Mike's work from
> today is also in his own master branch, I think the damage can be
> undone by just pulling from
> https://github.com/mdboom/matplotlib/master and pushing that to
> https://matplotlib/matplotlib/master, but at this point I don't
> trust myself and just want to not cause any more damage than I've
> already done.
> 
> I realize that people get their commit right revoked for such
> careless shenanigans, but I will be grateful if you'd all allow
> me the opportunity always run any push commands with the
> --dry-run flag from now on.
I can't figure out a way to pull it from there, but I think Eric
was the last to commit to trunk before I (destructively) pushed
my stale copy. Eric's last commit hash was:
8506c33c811e970c6aa73a446d3ed223ac48f989
At least that's what I see on https://github.com/organizations/matplotlib
hopefully this will help someone who get git better than I do.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

I offer my sincerest apologies, I royally screwed up and thought
that I was pushing out to one of my own branches and somehow
ended up pushing a 2 day old copy of master out to
matplotlib/master with 'git push -f'. Assuming Mike's work from
today is also in his own master branch, I think the damage can be
undone by just pulling from
https://github.com/mdboom/matplotlib/master and pushing that to
https://matplotlib/matplotlib/master, but at this point I don't
trust myself and just want to not cause any more damage than I've
already done.
I realize that people get their commit right revoked for such
careless shenanigans, but I will be grateful if you'd all allow
me the opportunity always run any push commands with the
--dry-run flag from now on.
very sorry,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7