matplotlib-users Mailing List for matplotlib

On 10/10/12 2:38 PM, klo uo wrote:
> Hi Rich,
>
> On Tue, Oct 9, 2012 at 10:38 PM, Rich Signell wrote:
>
> It look like there was a "wmsimage" method in Basemap that was folded
> into a "arcgisimage" method?
>
>
> IIRC, it was named like that in the test cycle, then renamed correctly 
> to arcgis
> I made my first step in adding WMS method: 
> https://gist.github.com/b05f1704127accc0a0da
>
> But I did not continue as, I saw no one interested and there were tons 
> of non-working WMS servers, and those that do work were only US
>
> You can install basemap with by adding that function, and provide 
> additional parameters options.
> It worked fine when I tested it
>
I wonder whether it would be better to use OWSlib 
(http://geopython.github.com/OWSLib/) for OGS/WMS support, instead of 
trying to roll our own solution. It only has ElementTree as a 
dependency. Klo - would you be interested in rewriting your wmsimage 
method using OWSlib? I bet it would simplify the code quite a bit.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Hi Rich,
On Tue, Oct 9, 2012 at 10:38 PM, Rich Signell wrote:
> It look like there was a "wmsimage" method in Basemap that was folded
> into a "arcgisimage" method?
>
>
IIRC, it was named like that in the test cycle, then renamed correctly to
arcgis
I made my first step in adding WMS method:
https://gist.github.com/b05f1704127accc0a0da
But I did not continue as, I saw no one interested and there were tons of
non-working WMS servers, and those that do work were only US
You can install basemap with by adding that function, and provide
additional parameters options.
It worked fine when I tested it

setupegg.py develop is the easiest way for me to install the latest mpl and
also ipython from the github repos.
I see that your suggested symlink fix also resolves this issue.
Thanks Mike for looking into this quickly.
On Wed, Oct 10, 2012 at 7:09 AM, Michael Droettboom <md...@st...> wrote:
> I filed an issue for this. We should try to get the fix into 1.2.x
>
> https://github.com/matplotlib/matplotlib/issues/1354
>
> Mike
>
>
> On 10/10/2012 09:00 AM, Michael Droettboom wrote:
>
> I think this stack overflow question [1] sort of sums up the problem --
> setuptools develop is kind of a hack and only really works if the source
> structure matches the installed structure. That used to be true of
> matplotlib, but installing different packages based on the Python version
> breaks that assumption.
>
> A suggestion in the Stack Overflow entry is to install symlinks to fix
> this, and indeed doing this works:
>
> cd lib
> ln -s dateutil_py2 dateutil
>
> We can probably automate this in the setupegg.py script, but I don't think
> I'll have a chance to get to this today. We can't just include the symlink
> in git, since it should point to the version that corresponds to the user's
> Python.
>
> [1]
> http://stackoverflow.com/questions/6019042/is-there-a-way-to-add-a-namespace-prefix-setuptools-package-distributions
>
> Mike
>
> On 10/10/2012 08:50 AM, Michael Droettboom wrote:
>
> This is related to using develop mode. I never use that (I use
> virtualenvs instead), so this doesn't get much testing. This seems to have
> broken when we started to ship separate versions of dateutil for python2
> and python3. setuptools doesn't seem to like the fact that we rename
> dateutil_py2 to dateutil when installing (since in develop mode it doesn't
> really install or move anything). That's problematic, of course. I'll
> have to see if there's another way to handle this.
>
> Mike
>
> On 10/09/2012 09:36 PM, Gökhan Sever wrote:
>
> Hello,
>
> With a fresh
>
> git clone git://github.com/matplotlib/matplotlib.git
> sudo python setupegg.py develop
>
> Starting ipython --pylab I get this error:
>
> .../matplotlib/lib/matplotlib/dates.py in <module>()
> 120 import matplotlib.ticker as ticker
> 121
> --> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU,
> YEARLY, \
> 123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
> 124 from dateutil.relativedelta import relativedelta
>
> ImportError: No module named dateutil.rrule
>
>
> Installing dateutil 1.5 fixes this.
>
> mpl install log shows the following:
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
> dateutil: matplotlib will provide
> pytz: matplotlib will provide
>
> Will dateutil be shipped with mpl or this line needs to be updated?
>
> Thanks.
>
>
> --
> Gökhan
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
-- 
Gökhan

On Wed, Oct 10, 2012 at 10:55 AM, Mark Lawrence <bre...@ya...>wrote:
> On 10/10/2012 15:41, Mark Lawrence wrote:
> > On 10/10/2012 14:29, Benjamin Root wrote:
> >>
> >> I know of a few people who have difficulties with matplotlib's datetime
> >> handling, but they are usually operating on the scale of milliseconds or
> >> less (lightning data), in which case, one is already at the edge of the
> >> resolution handled by python's datetime objects. However, we would
> >> certainly welcome any sort of examples of how matplotlib fails in
> handling
> >> seconds scale and lower plots.
> >>
> >> Cheers!
> >> Ben Root
> >>
> >>
> >
> > I'll assume that the milliseconds above is a typo. From
> > http://docs.python.org/library/datetime.html "class datetime.timedelta A
> > duration expressing the difference between two date, time, or datetime
> > instances to microsecond resolution." Still, what's a factor of 1000
> > amongst friends? :)
> >
>
> http://www.python.org/dev/peps/pep-0418/ has been implemented in Python
> 3.3 and talks about clocks with nanosecond resolutions. I've flagged it
> up here just in case people weren't aware.
>
>
Ah, you are right, I meant microseconds.
With apologies to Spaceballs:
"Prepare to go to microsecond resolution!"
"No, no, microsecond resolution is too slow"
"Microsecond resolution is too slow?"
"Yes, too slow. We must use nanosecond resolution!"
"Prep-- Prepare Python, for nanosecond resolution!"
Cheers!
Ben Root

On 10/10/2012 15:41, Mark Lawrence wrote:
> On 10/10/2012 14:29, Benjamin Root wrote:
>>
>> I know of a few people who have difficulties with matplotlib's datetime
>> handling, but they are usually operating on the scale of milliseconds or
>> less (lightning data), in which case, one is already at the edge of the
>> resolution handled by python's datetime objects. However, we would
>> certainly welcome any sort of examples of how matplotlib fails in handling
>> seconds scale and lower plots.
>>
>> Cheers!
>> Ben Root
>>
>>
>
> I'll assume that the milliseconds above is a typo. From
> http://docs.python.org/library/datetime.html "class datetime.timedelta A
> duration expressing the difference between two date, time, or datetime
> instances to microsecond resolution." Still, what's a factor of 1000
> amongst friends? :)
>
http://www.python.org/dev/peps/pep-0418/ has been implemented in Python 
3.3 and talks about clocks with nanosecond resolutions. I've flagged it 
up here just in case people weren't aware.
-- 
Cheers.
Mark Lawrence.

On 10/10/2012 14:29, Benjamin Root wrote:
>
> I know of a few people who have difficulties with matplotlib's datetime
> handling, but they are usually operating on the scale of milliseconds or
> less (lightning data), in which case, one is already at the edge of the
> resolution handled by python's datetime objects. However, we would
> certainly welcome any sort of examples of how matplotlib fails in handling
> seconds scale and lower plots.
>
> Cheers!
> Ben Root
>
>
I'll assume that the milliseconds above is a typo. From 
http://docs.python.org/library/datetime.html "class datetime.timedelta A 
duration expressing the difference between two date, time, or datetime 
instances to microsecond resolution." Still, what's a factor of 1000 
amongst friends? :)
-- 
Cheers.
Mark Lawrence.

On Wed, Oct 10, 2012 at 9:40 AM, rand0m <ra...@0x...> wrote:
> Hello,
>
> I'm new to matplotlib and I hope you can help me out with my question.
> When drawing for example a Rectangle() I have to specify it like the
> following:
> rect = Rectangle((1, 3), 2, 20, facecolor="#aaaaaa")
>
> Where 2 is the length and 20 is the height. (1,3) is for xy.
>
> Imagine a coordination system where x-axis should represent the value 0
> to 100. I would like to draw the rectangle from 50 to 60 on x-axis. So
> I would specify:
>
> rect = Rectangle((50, 3), 10, 20, facecolor="#aaaaaa")
>
> But this does not work as desired because at the xtick 50 the x-axis
> does not "hold" the value 50 but 5 because I made xticks 1-100 with step
> 10. So my x-axis "holds" the values 1-10. But I need 1-100.
>
> If anyone knows what Im missing I d be glad to hear about it :-).
>
> thank you
>
>
I am not quite sure I understand what you mean. Can you attach an image of
the plot you made so far?
Ben Root

On 10/10/2012 09:45 AM, Nikolaus Rath wrote:
> Michael Droettboom <mdr...@pu...> writes:
>>> For some reason, my matplotlib isn't able to print percent signs ('%')
>>> properly:
>> It's a known bug, fixed since 1.1.1.
>>
>> https://github.com/matplotlib/matplotlib/issues/1211
> Indeed. Luckily 1.2.0~rc2-1 is in experimental, and upgrading fixed the
> problem. Thanks!
>
> Now the only question that remains is: why doesn't github find this
> issue when I search for '%'?
Indeed - we should file a bug with github. I was able to find it 
because I knew the bug had to do with ttconv -- but there's no reason a 
user should have to know that.
>
>> BTW: If you're running the Debian package, how come the version is a
>> release candidate? (1.1.1rc2)
> Not sure what you mean, why shouldn't it?
>
I had just forgotten that Debian went with a release candidate -- 
ideally it would have been a final release, but the schedule didn't work 
out that way.
Mike

Michael Droettboom <mdr...@pu...> writes:
>> For some reason, my matplotlib isn't able to print percent signs ('%')
>> properly:
>
> It's a known bug, fixed since 1.1.1.
>
> https://github.com/matplotlib/matplotlib/issues/1211
Indeed. Luckily 1.2.0~rc2-1 is in experimental, and upgrading fixed the
problem. Thanks!
Now the only question that remains is: why doesn't github find this
issue when I search for '%'?
> BTW: If you're running the Debian package, how come the version is a
> release candidate? (1.1.1rc2)
Not sure what you mean, why shouldn't it?
Best,
 -Nikolaus
-- 
 »Time flies like an arrow, fruit flies like a Banana.«
 PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

Hello,
I'm new to matplotlib and I hope you can help me out with my question.
When drawing for example a Rectangle() I have to specify it like the
following:
rect = Rectangle((1, 3), 2, 20, facecolor="#aaaaaa")
Where 2 is the length and 20 is the height. (1,3) is for xy.
Imagine a coordination system where x-axis should represent the value 0
to 100. I would like to draw the rectangle from 50 to 60 on x-axis. So
I would specify:
rect = Rectangle((50, 3), 10, 20, facecolor="#aaaaaa")
But this does not work as desired because at the xtick 50 the x-axis
does not "hold" the value 50 but 5 because I made xticks 1-100 with step
10. So my x-axis "holds" the values 1-10. But I need 1-100.
If anyone knows what Im missing I d be glad to hear about it :-).
thank you

Benjamin Root <ben...@pu...> writes:
>> >>> For some reason, my matplotlib isn't able to print percent signs ('%')
>> >>> properly:
>> >>>
>> >>> [1] inspiron:~/tmp# cat mplbug.py
>> >>>
>> >>> import matplotlib
>> >>> import matplotlib.pyplot as plt
>> >>> import numpy as np
>> >>>
>> >>> print matplotlib.__version__
>> >>> plt.plot(np.arange(10), np.arange(10)**2)
>> >>> plt.xlabel('Percent [%]')
>> >>> plt.savefig('mplbug.pdf')
>> >>>
>> >>> [0] inspiron:~/tmp# python mplbug.py
>> >>> 1.1.1rc2
>> >>>
>> >>> I have attached the resulting PDF. For some reason, the slash in the
>> >>> percent sign becomes a triangle that partially covers the upper left
>> >>> circle.
>> >>>
>> >>> Known bug? Any workarounds that don't require upgrading (I'd like to
>> >>> stick with the Debian package)?
>> >>
>> >> I'm using the AGG backend and saving to a png file without any
>> >> problems, but I'm using the current git master branch. I'll try to see
>> >> if I can recreate on 1.1.1rc2. Watch this space.
>> >
>> > No dice. I still can't recreate your problem on OS X 10.7.4 with
>> > matplotlib version 1.1.1-rc2.
>> >
>> > What are your font/tex specifications in the matplotlib.rcParams
>> dictionary?
>>
>> For me the problem occurs with PDF files, not PNG files. Or was that
>> just a typo?
>>
>> Font specifications are all default.
>>
>> # python -c 'import matplotlib; import pprint;
>> # pprint.pprint(matplotlib.rcParams)' | egrep 'tex'
>> 'legend.handletextpad': 0.8,
>> 'mathtext.bf': 'serif:bold',
>> 'mathtext.cal': 'cursive',
>> 'mathtext.default': 'it',
>> 'mathtext.fallback_to_cm': True,
>> 'mathtext.fontset': 'cm',
>> 'mathtext.it': 'serif:italic',
>> 'mathtext.rm': 'serif',
>> 'mathtext.sf': 'sans\\-serif',
>> 'mathtext.tt': 'monospace',
>> 'text.antialiased': True,
>> 'text.color': 'k',
>> 'text.dvipnghack': None,
>> 'text.hinting': True,
>> 'text.latex.preamble': [''],
>> 'text.latex.preview': False,
>> 'text.latex.unicode': False,
>> 'text.usetex': False,
>>
> I think I know why this is happening. Iirc, we recently took on a patch to
> allow string formatting for labels. For most cases, it shouldn't effect
> anybody, but if there is a lonely percent sign, I would imagine it could
> cause issues. As a test, try a double percent sign '%%'. If that works,
> the my theory might be right.
Nope, using '%%' just results in two corrupted signs in the PDF.
Best,
 -Nikolaus
-- 
 »Time flies like an arrow, fruit flies like a Banana.«
 PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

On Mon, Oct 8, 2012 at 12:06 PM, Jianbao Tao <jia...@gm...> wrote:
> Thanks, Ben.
>
> Your fix works when the view interval is greater than 1 minute, but not so
> much when the view interval is less than one minute.
>
> BTW, what I am trying to accomplish is to use matplotlib to plot
> time-series data that can be as long as several days and as short as a few
> milliseconds. So, do you think I am better off to handle the format
> manually by myself instead of deriving the format from auto locator? I am
> skeptical about the auto locator now because it doesn't seem to be designed
> for intervals less than 1 second.
>
> Cheers,
> Jianbao
>
>
Jianbao, your smallest scale in your AutoDateFormatter dictionary is 1
second. The formatter is designed to find the smallest key that is still
greater than or equal to the scale of your axis. So, if your scale is less
than 1 second, then you will notice formatting issues. I would try adding
a few more entries to see if that would help.
I know of a few people who have difficulties with matplotlib's datetime
handling, but they are usually operating on the scale of milliseconds or
less (lightning data), in which case, one is already at the edge of the
resolution handled by python's datetime objects. However, we would
certainly welcome any sort of examples of how matplotlib fails in handling
seconds scale and lower plots.
Cheers!
Ben Root

I filed an issue for this. We should try to get the fix into 1.2.x
https://github.com/matplotlib/matplotlib/issues/1354
Mike
On 10/10/2012 09:00 AM, Michael Droettboom wrote:
> I think this stack overflow question [1] sort of sums up the problem 
> -- setuptools develop is kind of a hack and only really works if the 
> source structure matches the installed structure. That used to be 
> true of matplotlib, but installing different packages based on the 
> Python version breaks that assumption.
>
> A suggestion in the Stack Overflow entry is to install symlinks to fix 
> this, and indeed doing this works:
>
> cd lib
> ln -s dateutil_py2 dateutil
>
> We can probably automate this in the setupegg.py script, but I don't 
> think I'll have a chance to get to this today. We can't just include 
> the symlink in git, since it should point to the version that 
> corresponds to the user's Python.
>
> [1] 
> http://stackoverflow.com/questions/6019042/is-there-a-way-to-add-a-namespace-prefix-setuptools-package-distributions
>
> Mike
>
> On 10/10/2012 08:50 AM, Michael Droettboom wrote:
>> This is related to using develop mode. I never use that (I use 
>> virtualenvs instead), so this doesn't get much testing. This seems 
>> to have broken when we started to ship separate versions of dateutil 
>> for python2 and python3. setuptools doesn't seem to like the fact 
>> that we rename dateutil_py2 to dateutil when installing (since in 
>> develop mode it doesn't really install or move anything). That's 
>> problematic, of course. I'll have to see if there's another way to 
>> handle this.
>>
>> Mike
>>
>> On 10/09/2012 09:36 PM, Gökhan Sever wrote:
>>> Hello,
>>>
>>> With a fresh
>>>
>>> git clone git://github.com/matplotlib/matplotlib.git 
>>> <http://github.com/matplotlib/matplotlib.git>
>>> sudo python setupegg.py develop
>>>
>>> Starting ipython --pylab I get this error:
>>>
>>> .../matplotlib/lib/matplotlib/dates.py in <module>()
>>> 120 import matplotlib.ticker as ticker
>>> 121
>>> --> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, 
>>> SU, YEARLY, \
>>> 123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
>>> 124 from dateutil.relativedelta import relativedelta
>>>
>>> ImportError: No module named dateutil.rrule
>>>
>>>
>>> Installing dateutil 1.5 fixes this.
>>>
>>> mpl install log shows the following:
>>>
>>> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>>> dateutil: matplotlib will provide
>>> pytz: matplotlib will provide
>>>
>>> Will dateutil be shipped with mpl or this line needs to be updated?
>>>
>>> Thanks.
>>>
>>>
>>> -- 
>>> Gökhan
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>>
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Thanks for the many useful responses - I eventuallyfound by experiment that imshow( interpolation='nearest' works *if* I write a png file.
Saving a pdf file mushed up my crisp pixel boundaries. However, saving as png, then using (mac osx) preview to convert to pdf worked fine.
Go figure()!
I have solved this problem earlier using figimage(), but that was a lot of work (I had to create a pixel-by-pixel array with all greyscale values set myself, and then I was working in pixel coordinates rather than my data coordinates). Has anyone figured out how to get imshow to stop smoothing the image? Using imshow(... interpolation='none'...) or imshow(... interpolation=None...) raise exceptions.
I found NonUniformImage too hard to figure out from the documentation.
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Matplotlib-users mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I think this stack overflow question [1] sort of sums up the problem -- 
setuptools develop is kind of a hack and only really works if the source 
structure matches the installed structure. That used to be true of 
matplotlib, but installing different packages based on the Python 
version breaks that assumption.
A suggestion in the Stack Overflow entry is to install symlinks to fix 
this, and indeed doing this works:
 cd lib
 ln -s dateutil_py2 dateutil
We can probably automate this in the setupegg.py script, but I don't 
think I'll have a chance to get to this today. We can't just include 
the symlink in git, since it should point to the version that 
corresponds to the user's Python.
[1] 
http://stackoverflow.com/questions/6019042/is-there-a-way-to-add-a-namespace-prefix-setuptools-package-distributions
Mike
On 10/10/2012 08:50 AM, Michael Droettboom wrote:
> This is related to using develop mode. I never use that (I use 
> virtualenvs instead), so this doesn't get much testing. This seems to 
> have broken when we started to ship separate versions of dateutil for 
> python2 and python3. setuptools doesn't seem to like the fact that we 
> rename dateutil_py2 to dateutil when installing (since in develop mode 
> it doesn't really install or move anything). That's problematic, of 
> course. I'll have to see if there's another way to handle this.
>
> Mike
>
> On 10/09/2012 09:36 PM, Gökhan Sever wrote:
>> Hello,
>>
>> With a fresh
>>
>> git clone git://github.com/matplotlib/matplotlib.git 
>> <http://github.com/matplotlib/matplotlib.git>
>> sudo python setupegg.py develop
>>
>> Starting ipython --pylab I get this error:
>>
>> .../matplotlib/lib/matplotlib/dates.py in <module>()
>> 120 import matplotlib.ticker as ticker
>> 121
>> --> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU, 
>> YEARLY, \
>> 123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
>> 124 from dateutil.relativedelta import relativedelta
>>
>> ImportError: No module named dateutil.rrule
>>
>>
>> Installing dateutil 1.5 fixes this.
>>
>> mpl install log shows the following:
>>
>> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>> dateutil: matplotlib will provide
>> pytz: matplotlib will provide
>>
>> Will dateutil be shipped with mpl or this line needs to be updated?
>>
>> Thanks.
>>
>>
>> -- 
>> Gökhan
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>>
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Wed, Oct 10, 2012 at 8:23 AM, Michael Droettboom <md...@st...> wrote:
> It's a known bug, fixed since 1.1.1.
>
> https://github.com/matplotlib/matplotlib/issues/1211
>
> BTW: If you're running the Debian package, how come the version is a
> release candidate? (1.1.1rc2)
>
> Mike
>
>
Mike,
We didn't get the final release of v1.1.1 out in time for the Debian Freeze
back in the spring. Sandro Toshi could only get the rc2 into the
repositories.
Ben Root

This is related to using develop mode. I never use that (I use 
virtualenvs instead), so this doesn't get much testing. This seems to 
have broken when we started to ship separate versions of dateutil for 
python2 and python3. setuptools doesn't seem to like the fact that we 
rename dateutil_py2 to dateutil when installing (since in develop mode 
it doesn't really install or move anything). That's problematic, of 
course. I'll have to see if there's another way to handle this.
Mike
On 10/09/2012 09:36 PM, Gökhan Sever wrote:
> Hello,
>
> With a fresh
>
> git clone git://github.com/matplotlib/matplotlib.git 
> <http://github.com/matplotlib/matplotlib.git>
> sudo python setupegg.py develop
>
> Starting ipython --pylab I get this error:
>
> .../matplotlib/lib/matplotlib/dates.py in <module>()
> 120 import matplotlib.ticker as ticker
> 121
> --> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU, 
> YEARLY, \
> 123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
> 124 from dateutil.relativedelta import relativedelta
>
> ImportError: No module named dateutil.rrule
>
>
> Installing dateutil 1.5 fixes this.
>
> mpl install log shows the following:
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
> dateutil: matplotlib will provide
> pytz: matplotlib will provide
>
> Will dateutil be shipped with mpl or this line needs to be updated?
>
> Thanks.
>
>
> -- 
> Gökhan
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

It's a known bug, fixed since 1.1.1.
https://github.com/matplotlib/matplotlib/issues/1211
BTW: If you're running the Debian package, how come the version is a 
release candidate? (1.1.1rc2)
Mike
On 10/09/2012 04:32 PM, Nikolaus Rath wrote:
> Hello,
>
> For some reason, my matplotlib isn't able to print percent signs ('%')
> properly:
>
> [1] inspiron:~/tmp# cat mplbug.py
>
> import matplotlib
> import matplotlib.pyplot as plt
> import numpy as np
>
> print matplotlib.__version__
> plt.plot(np.arange(10), np.arange(10)**2)
> plt.xlabel('Percent [%]')
> plt.savefig('mplbug.pdf')
>
> [0] inspiron:~/tmp# python mplbug.py
> 1.1.1rc2
>
> I have attached the resulting PDF. For some reason, the slash in the
> percent sign becomes a triangle that partially covers the upper left
> circle.
>
> Known bug? Any workarounds that don't require upgrading (I'd like to
> stick with the Debian package)?
>
>
> Thanks,
>
> -Nikolaus
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 2012年10月09日 4:46 PM, Mike Kaufman wrote:
> On 10/9/12 10:03 PM, Jody Klymak wrote:
>> Hi Eric,
>>
>>> The pcolormesh docstring notes that it is
>>> much faster than pcolor; the pcolor docstring probably should refer
>>> people to pcolormesh, since matlab users are likely to go straight to
>>> pcolor without realizing that they should be using pcolormesh.
>>
>> I'd agree with this. pcolormesh is not even in the "See Also", and there is no warning about the effciency of pcolor.
>>
>> I'd even go so far as to suggest that pcolor be deprecated so new users are more likely to find pcolormesh.
>
> While we're on this subject, pcolorfast doesn't have a pyplot function
> and its documentation refers to pcolor rather than itself. Also pcolor
> and pcolormesh ought to See Also this (or is it still experimental?)
pcolorfast is a bit odd in that it uses one of three different 
mechanisms depending on its inputs, and it is not quite as flexible 
about input dimensions as pcolormesh, so the lack of a pyplot function 
for it is deliberate.
Thanks for pointing out the references to pcolor in the docstring--I 
don't know how that has passed apparently unnoticed so long!
Eric
>
> M
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 10/9/12 10:03 PM, Jody Klymak wrote:
> Hi Eric,
>
>> The pcolormesh docstring notes that it is
>> much faster than pcolor; the pcolor docstring probably should refer
>> people to pcolormesh, since matlab users are likely to go straight to
>> pcolor without realizing that they should be using pcolormesh.
>
> I'd agree with this. pcolormesh is not even in the "See Also", and there is no warning about the effciency of pcolor.
>
> I'd even go so far as to suggest that pcolor be deprecated so new users are more likely to find pcolormesh.
While we're on this subject, pcolorfast doesn't have a pyplot function 
and its documentation refers to pcolor rather than itself. Also pcolor 
and pcolormesh ought to See Also this (or is it still experimental?)
M

On Tuesday, October 9, 2012, Nikolaus Rath wrote:
> Damon McDougall <dam...@pu...<javascript:;>>
> writes:
> > On Tue, Oct 9, 2012 at 10:56 PM, Damon McDougall
> > <dam...@pu... <javascript:;>>
> wrote:
> >> On Tue, Oct 9, 2012 at 10:32 PM, Nikolaus Rath <
> Nik...@pu... <javascript:;>> wrote:
> >>> Hello,
> >>>
> >>> For some reason, my matplotlib isn't able to print percent signs ('%')
> >>> properly:
> >>>
> >>> [1] inspiron:~/tmp# cat mplbug.py
> >>>
> >>> import matplotlib
> >>> import matplotlib.pyplot as plt
> >>> import numpy as np
> >>>
> >>> print matplotlib.__version__
> >>> plt.plot(np.arange(10), np.arange(10)**2)
> >>> plt.xlabel('Percent [%]')
> >>> plt.savefig('mplbug.pdf')
> >>>
> >>> [0] inspiron:~/tmp# python mplbug.py
> >>> 1.1.1rc2
> >>>
> >>> I have attached the resulting PDF. For some reason, the slash in the
> >>> percent sign becomes a triangle that partially covers the upper left
> >>> circle.
> >>>
> >>> Known bug? Any workarounds that don't require upgrading (I'd like to
> >>> stick with the Debian package)?
> >>
> >> I'm using the AGG backend and saving to a png file without any
> >> problems, but I'm using the current git master branch. I'll try to see
> >> if I can recreate on 1.1.1rc2. Watch this space.
> >
> > No dice. I still can't recreate your problem on OS X 10.7.4 with
> > matplotlib version 1.1.1-rc2.
> >
> > What are your font/tex specifications in the matplotlib.rcParams
> dictionary?
>
> For me the problem occurs with PDF files, not PNG files. Or was that
> just a typo?
>
> Font specifications are all default.
>
> # python -c 'import matplotlib; import pprint;
> # pprint.pprint(matplotlib.rcParams)' | egrep 'tex'
> 'legend.handletextpad': 0.8,
> 'mathtext.bf': 'serif:bold',
> 'mathtext.cal': 'cursive',
> 'mathtext.default': 'it',
> 'mathtext.fallback_to_cm': True,
> 'mathtext.fontset': 'cm',
> 'mathtext.it': 'serif:italic',
> 'mathtext.rm': 'serif',
> 'mathtext.sf': 'sans\\-serif',
> 'mathtext.tt': 'monospace',
> 'text.antialiased': True,
> 'text.color': 'k',
> 'text.dvipnghack': None,
> 'text.hinting': True,
> 'text.latex.preamble': [''],
> 'text.latex.preview': False,
> 'text.latex.unicode': False,
> 'text.usetex': False,
>
> Best,
>
> -Nikolaus
>
>
I think I know why this is happening. Iirc, we recently took on a patch to
allow string formatting for labels. For most cases, it shouldn't effect
anybody, but if there is a lonely percent sign, I would imagine it could
cause issues. As a test, try a double percent sign '%%'. If that works,
the my theory might be right.
In addition, I think it is only in master, not v1.2.x.
Ben Root

Hi Eric,
> The pcolormesh docstring notes that it is 
> much faster than pcolor; the pcolor docstring probably should refer 
> people to pcolormesh, since matlab users are likely to go straight to 
> pcolor without realizing that they should be using pcolormesh.
I'd agree with this. pcolormesh is not even in the "See Also", and there is no warning about the effciency of pcolor. 
I'd even go so far as to suggest that pcolor be deprecated so new users are more likely to find pcolormesh. 
Anyway, thanks for the pointer!
Cheers, Jody
--
Jody Klymak 
http://web.uvic.ca/~jklymak/

Hello,
With a fresh
git clone git://github.com/matplotlib/matplotlib.git
sudo python setupegg.py develop
Starting ipython --pylab I get this error:
.../matplotlib/lib/matplotlib/dates.py in <module>()
 120 import matplotlib.ticker as ticker
 121
--> 122 from dateutil.rrule import rrule, MO, TU, WE, TH, FR, SA, SU,
YEARLY, \
 123 MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, SECONDLY
 124 from dateutil.relativedelta import relativedelta
ImportError: No module named dateutil.rrule
Installing dateutil 1.5 fixes this.
mpl install log shows the following:
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 dateutil: matplotlib will provide
 pytz: matplotlib will provide
Will dateutil be shipped with mpl or this line needs to be updated?
Thanks.
-- 
Gökhan