matplotlib-devel Mailing List for matplotlib (Page 3)

Hi all,
I thought we have a "v1.0.x" branch on the github repo, but no more.
https://github.com/matplotlib/matplotlib/branches
Hmm...
Is it (accidentally?) removed or do we now use another branch for
maintenance (although I don't see any alternative)?
Regards,
-JJ

I've read the status page for py3k and stumbled upon the cleanup tasks, 
especially the version checks. I agree that calling sys.version_info[0] is not a 
smart choice.
Why not use a new variable in __init__.py, something like a boolean __is_py3k__. 
Every module which needs a choice between py2.x and 3.x can simply:
from matplotlib import __is_py3k__
and use:
if __is_py3k__:
Greetz, Tobi

On 04/11/2011 11:19 AM, Darren Dale wrote:
> On Mon, Apr 11, 2011 at 3:40 PM, Michael Droettboom<md...@st...> wrote:
>> (Hmm... git doesn't use its own issue tracker for tracking its own
>> issues... what does that say?<wink>)
>
> Brilliant, whatever they use allows uploading attachments.
They are using this: http://tenderapp.com/

On Mon, Apr 11, 2011 at 4:19 PM, Darren Dale <dsd...@gm...> wrote:
> On Mon, Apr 11, 2011 at 3:40 PM, Michael Droettboom <md...@st...>
> wrote:
> > (Hmm... git doesn't use its own issue tracker for tracking its own
> > issues... what does that say? <wink>)
>
> Brilliant, whatever they use allows uploading attachments.
>
>
Maybe it would be made available for "Issues: Deep Space Nine", or do I have
to wait until "Voyager"?
Ben Root

On Mon, Apr 11, 2011 at 3:40 PM, Michael Droettboom <md...@st...> wrote:
> (Hmm... git doesn't use its own issue tracker for tracking its own
> issues... what does that say? <wink>)
Brilliant, whatever they use allows uploading attachments.

On 04/11/2011 03:51 PM, Eric Firing wrote:
> On 04/11/2011 07:24 AM, Darren Dale wrote:
> 
>> On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom<md...@st...> wrote:
>> 
>>> I couldn't find the old thread about Sourceforge bug tracker vs. the
>>> Github issue tracker, but maybe we should reevaluate based on the new
>>> Github issue tracker announced on Saturday:
>>>
>>> https://github.com/blog/831-issues-2-0-the-next-generation
>>>
>>> The integration with git commits (closing issues by mentioning them in
>>> the commit message) is particularly compelling.
>>> 
>> The new issue tracker is a really big improvement over the old github
>> tracker, and I prefer it to the one at sourceforge since it integrates
>> so nicely with github version control. The github tracker is still
>> missing some features that we may want to consider: prioritize issues,
>> add attachments, and perhaps report issues without opening a github
>> account.
>> 
> It is better, but to my eye, still not good.
>
> Prioritization can be handled via labels or milestones, but the lack of
> a simple, obvious attachment facility is a huge omission. As far as I
> know there is also no simple set of categories for closed status--maybe
> that would also be done with labels.
Labels could be used for that purpose -- but it would be "by 
convention", so I can imagine we'd forget to do that from time to time.
> (I'm not positive; I have not
> closed an item, and nothing happens when I click the "60 closed issues"
> tab, expecting to see the closed issues. Similarly, nothing happens
> when I click the "submitted" "updated", and "comments" buttons.
I see this too. And I think we're not the only ones -- there's a bug 
filed about it:
http://support.github.com/discussions/issues-issues/608-closed-tickets-do-not-show-up-in-the-list-firefox-3615
(Hmm... git doesn't use its own issue tracker for tracking its own 
issues... what does that say? <wink>)
> Maybe
> all these things are bugs that show up if one does not have Firefox 4 or
> Chrome?) The automatic, compulsory, irrevocable Markdown parsing of all
> comments is a horrible design,
The Wikis on github support a handful of formatting languages, including 
reStructuredText (which is what my fingers know best) -- so they "have 
the technology" to do something else. But honestly, for short issue 
comments, I think plain text is the best choice.
> and all the more so in the absence of
> file up/download facility.
> 
They've got gist, of course, but it is neither easy or intuitive for 
casual use.
Mike
> It's being used; I think we are stuck with it. I have no objection to
> getting the migration over with, if you have the machinery to do it, Dale.
>
> Eric
>
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and minutes
> not days. Key insights are discussed in the 2010 Forrester Wave Report as
> part of an in-depth evaluation of disaster recovery service providers.
> Forrester found the best-in-class provider in terms of services and vision.
> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 04/11/2011 07:24 AM, Darren Dale wrote:
> On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom<md...@st...> wrote:
>> I couldn't find the old thread about Sourceforge bug tracker vs. the
>> Github issue tracker, but maybe we should reevaluate based on the new
>> Github issue tracker announced on Saturday:
>>
>> https://github.com/blog/831-issues-2-0-the-next-generation
>>
>> The integration with git commits (closing issues by mentioning them in
>> the commit message) is particularly compelling.
>
> The new issue tracker is a really big improvement over the old github
> tracker, and I prefer it to the one at sourceforge since it integrates
> so nicely with github version control. The github tracker is still
> missing some features that we may want to consider: prioritize issues,
> add attachments, and perhaps report issues without opening a github
> account.
It is better, but to my eye, still not good.
Prioritization can be handled via labels or milestones, but the lack of 
a simple, obvious attachment facility is a huge omission. As far as I 
know there is also no simple set of categories for closed status--maybe 
that would also be done with labels. (I'm not positive; I have not 
closed an item, and nothing happens when I click the "60 closed issues" 
tab, expecting to see the closed issues. Similarly, nothing happens 
when I click the "submitted" "updated", and "comments" buttons. Maybe 
all these things are bugs that show up if one does not have Firefox 4 or 
Chrome?) The automatic, compulsory, irrevocable Markdown parsing of all 
comments is a horrible design, and all the more so in the absence of 
file up/download facility.
It's being used; I think we are stuck with it. I have no objection to 
getting the migration over with, if you have the machinery to do it, Dale.
Eric

On Mon, Apr 11, 2011 at 3:02 PM, Paul Ivanov <piv...@gm...> wrote:
> Darren Dale, on 2011年04月11日 13:24, wrote:
>> On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom <md...@st...> wrote:
>> > I couldn't find the old thread about Sourceforge bug tracker vs. the
>> > Github issue tracker, but maybe we should reevaluate based on the new
>> > Github issue tracker announced on Saturday:
>> >
>> > https://github.com/blog/831-issues-2-0-the-next-generation
>> >
>> > The integration with git commits (closing issues by mentioning them in
>> > the commit message) is particularly compelling.
>>
>> The new issue tracker is a really big improvement over the old github
>> tracker, and I prefer it to the one at sourceforge since it integrates
>> so nicely with github version control. The github tracker is still
>> missing some features that we may want to consider: prioritize issues,
>> add attachments, and perhaps report issues without opening a github
>> account.
>
> I'm fine either way - though moving to GitHub certainly makes
> sense as it has momentum - whereas SF.net has been stagnating and
> not getting any faster for quite some time now.
>
> My only concern / request is that we transfer and/or clean up
> (wholesale) the sf.net bug tracker before we move to GH. It'd be
> a disservice to our users if we just ignored or mass-closed those
> issues in the transition to GH.
I spent a weekend working on porting the issues to github.
https://github.com/ddale/mpl-issues contains an xml dump of the
sourceforge tracker, along with the script I used to parse the dump
file, filter it, and upload the issues to that repo. It could be
improved to add labels, assign to developers, assign milestones, once
github provides API access to issues-2.0.

Darren Dale, on 2011年04月11日 13:24, wrote:
> On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom <md...@st...> wrote:
> > I couldn't find the old thread about Sourceforge bug tracker vs. the
> > Github issue tracker, but maybe we should reevaluate based on the new
> > Github issue tracker announced on Saturday:
> >
> > https://github.com/blog/831-issues-2-0-the-next-generation
> >
> > The integration with git commits (closing issues by mentioning them in
> > the commit message) is particularly compelling.
> 
> The new issue tracker is a really big improvement over the old github
> tracker, and I prefer it to the one at sourceforge since it integrates
> so nicely with github version control. The github tracker is still
> missing some features that we may want to consider: prioritize issues,
> add attachments, and perhaps report issues without opening a github
> account.
I'm fine either way - though moving to GitHub certainly makes
sense as it has momentum - whereas SF.net has been stagnating and
not getting any faster for quite some time now.
My only concern / request is that we transfer and/or clean up
(wholesale) the sf.net bug tracker before we move to GH. It'd be
a disservice to our users if we just ignored or mass-closed those
issues in the transition to GH.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom <md...@st...> wrote:
> I couldn't find the old thread about Sourceforge bug tracker vs. the
> Github issue tracker, but maybe we should reevaluate based on the new
> Github issue tracker announced on Saturday:
>
> https://github.com/blog/831-issues-2-0-the-next-generation
>
> The integration with git commits (closing issues by mentioning them in
> the commit message) is particularly compelling.
The new issue tracker is a really big improvement over the old github
tracker, and I prefer it to the one at sourceforge since it integrates
so nicely with github version control. The github tracker is still
missing some features that we may want to consider: prioritize issues,
add attachments, and perhaps report issues without opening a github
account.

I couldn't find the old thread about Sourceforge bug tracker vs. the 
Github issue tracker, but maybe we should reevaluate based on the new 
Github issue tracker announced on Saturday:
https://github.com/blog/831-issues-2-0-the-next-generation
The integration with git commits (closing issues by mentioning them in 
the commit message) is particularly compelling.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Ok, forwarding it to the matplotlib-devel list.
Best wishes,
Konrad (on behalf of our workgroup)
-------- Original Message --------
Subject: Source of inaccuracies in the matplotlib library
Date: Fri, 8 Apr 2011 18:12:47 +0200
From: Bartkowski, Konrad <k.b...@fz...><mailto:k.b...@fz...>
To: dd...@co...<mailto:dd...@co...> <dd...@co...><mailto:dd...@co...>, md...@st...<mailto:md...@st...> <md...@st...><mailto:md...@st...>, ef...@ha...<mailto:ef...@ha...> <ef...@ha...><mailto:ef...@ha...>, jdh...@ac...<mailto:jdh...@ac...> <jdh...@ac...><mailto:jdh...@ac...>, jd...@gm...<mailto:jd...@gm...> <jd...@gm...><mailto:jd...@gm...>
CC: Bartkowski, Konrad <k.b...@fz...><mailto:k.b...@fz...>, el...@in...<mailto:el...@in...> <el...@in...><mailto:el...@in...>, Matthias Bolten <bo...@ma...><mailto:bo...@ma...>, Grotendorst, Johannes <j.g...@fz...><mailto:j.g...@fz...>, Steffen, Bernhard <b.s...@fz...><mailto:b.s...@fz...>
Dear Matplotlib developers,
I am writing about the matplotlib library with the mpl_toolkits. First
of all let me emphasize how great software it is. Recently, in one of
our projects we were rendering big surfaces and encountered the
following problem:
http://www.mail-archive.com/mat...@li.../msg06869.html
It's not a bug (which all in all is a natural and unavoidable ingredient
of the software, and especially in such a big and complex system like
matplotlib would be fully natural), since the software does exactly the
projection mathematics that it is expected to do, but a source of the
inaccuracies, which is especially visible in the critical examples. For
the profit of the Python community we are sending You a proposition of a
modification of the surface plotting rendering system, in case You find
it interesting enough to include in the consecutive version of the
library. In the source code from the attachment we redesigned a little
bit the computation process – since the computations are especially
sensible to numerical errors, that are for example amplified while
norming or processing the quaterions in the various stages (for example
division over coordinate in the perspective projection). Therefore the
computational focus can be shifted from the Polygon collection to the
polygons itself. In the example from the above forum or the slightly
modified one, one can observe a big difference in the numerical
precision while the speed of the computations does not decrease (at
least visibly). While instead of the surfaces from the forum, the
following surfaces are rendered:
u = np.linspace(0, 2 * np.pi, 100)
v = np.linspace(0, np.pi, 100)
x = 10 * np.outer(np.cos(u), np.sin(v))
y = 10 * np.outer(np.sin(u), np.sin(v))
z = 10 * np.outer(np.ones(np.size(u)), np.cos(v))
ax.plot_surface(x, y, z, rstride=8, cstride=8, color='y', alpha=0.5)
shiftX=28
shiftY=28
X,Y=np.meshgrid(range(-20+shiftX,20+shiftX),range(-20+shiftY,20+shiftY))
Z=np.ones((X.shape[0], Y.shape[1]))
ax.plot_surface(X, Y, Z, color='r', rstride=10, cstride=10, alpha=1.0)
the issue is visible for example at the azimuth=40 , elevation=70 – with
those parameters the mentioned case is visible on the red surface, while
with elevation=68 not. Moreover, now also the stride is big (in the new
approach the influence of increasing stride on the numerical precision
grows).
So again let me use this opportunity to thank You for empowering the
Python community worldwide in a great, powerful scientific visualization
tool.
Best wishes,
Konrad Bartkowski
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de

Hi,
I've submitted a pull request with backend changes that (should) let all 
currently supported versions of PyQt work along side PySide. I've 
tested with PyQt 4.8.3 and PySide 1.0.0.
I haven't bothered chasing down old versions of PyQt as they seem elusive.
Gerald.
On 29/03/2011 3:25 AM, bu...@gm... wrote:
> Looking forward, supporting the Python 3 compatible PyQt API is likely 
> the way to go.
>
> Le , Gerald Storer <gd...@mr...> a écrit :
> > On 28/03/2011 1:10 AM, Peter Butterworth wrote:
> >
> >
> > Wouldn't it be possible to use a single backend compatible with both
> >
> > PyQt and Pyside ?
> >
> >
> > The current Qt mpl backend uses the old PyQt slots/signals API which 
> PySide doesn't really support (there are some macros but they don't 
> work 100% the same). From a quick glance at the IPython 
> implementation it looks like they are using the new API which means 
> older versions (<4.5) of PyQt won't be supported. This might be ok, I 
> don't know.
> >
> > If it isn't then, there will need to be some try...excepts around 
> the place or separate back ends. If you ignore the PySide bugs I had 
> to work around I've only changed ~4 lines in the main backend.
> >
> >
> >
> > Pierre's formlayout is also using an obsolete method that isn't 
> present in PySide. I've opted to emulate it, but it would be best to 
> change the code to use the alternative method available in both PyQt 
> and PySide. formlayout also uses the old QString implementation of 
> PyQt, PySide only supports the new implementation where QString is 
> transparently convert to/from str/unicode. Setting QString = unicode 
> seems to work though.
> >
> >
> >
> > Gerald.
> > 

Hi all,
we've just released IPython 0.10.2, full release notes are below.
Downloads in source and windows binary form are available in the usual location:
http://ipython.scipy.org/dist/
as well as on github:
http://github.com/ipython/ipython/archives/rel-0.10.2
and at the Python Package Index (which easy_install will use by default):
http://pypi.python.org/pypi/ipython
so at any time you should find a location with good download speeds.
You can find the full documentation at:
http://ipython.github.com/ipython-doc/rel-0.10.2/html/
http://ipython.github.com/ipython-doc/rel-0.10.2/ipython.pdf
Enjoy!
Fernando (on behalf of the whole IPython team)
Release 0.10.2
==============
IPython 0.10.2 was released April 9, 2011. This is a minor bugfix release that
preserves backward compatibility. At this point, all IPython development
resources are focused on the 0.11 series that includes a complete architectural
restructuring of the project as well as many new capabilities, so this is
likely to be the last release of the 0.10.x series. We have tried to fix all
major bugs in this series so that it remains a viable platform for those not
ready yet to transition to the 0.11 and newer codebase (since that will require
some porting effort, as a number of APIs have changed).
Thus, we are not opening a 0.10.3 active development branch yet, but if the
user community requires new patches and is willing to maintain/release such a
branch, we'll be happy to host it on the IPython github repositories.
Highlights of this release:
- The main one is the closing of github ticket #185, a major regression we had
 in 0.10.1 where pylab mode with GTK (or gthread) was not working correctly,
 hence plots were blocking with GTK. Since this is the default matplotlib
 backend on Unix systems, this was a major annoyance for many users. Many
 thanks to Paul Ivanov for helping resolve this issue.
- Fix IOError bug on Windows when used with -gthread.
- Work robustly if $HOME is missing from environment.
- Better POSIX support in ssh scripts (remove bash-specific idioms).
- Improved support for non-ascii characters in log files.
- Work correctly in environments where GTK can be imported but not started
 (such as a linux text console without X11).
For this release we merged 24 commits, contributed by the following people
(please let us know if we ommitted your name and we'll gladly fix this in the
notes for the future):
* Fernando Perez
* MinRK
* Paul Ivanov
* Pieter Cristiaan de Groot
* TvrtkoM

I didn't expect anything to be honest. In fact I just wanted to know if 
this problem is known or not.
Before I posted I crawled through earlier revisions of cbook.py on 
github. All revisions I found used the ominous os.path.walk().
In the next step I copied an older FontList.cache to the new name and 
tried reimporting pylab. That gave me an ValueError while unpickling.
I attached both tracebacks, without FontList.py3k.cache present and with it.
So I will try rewriting this part to get a FontList.py3k.cache using Py3k.
Greetz Tobi
------------------------------------
Following the traceback for importing pylab without a 
FontList.py3k.cache present:
Python 3.2 (unknown, Apr 6 2011, 18:44:52)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pylab
Traceback (most recent call last):
 File 
"/usr/local/lib/python3.2/site-packages/matplotlib/font_manager.py", 
line 1309, in <module>
 fontManager = pickle_load(_fmcache)
 File 
"/usr/local/lib/python3.2/site-packages/matplotlib/font_manager.py", 
line 922, in pickle_load
 fh = open(filename, 'rb')
IOError: [Errno 2] No such file or directory: 
'/home/erg/.matplotlib/fontList.py3k.cache'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/local/lib/python3.2/site-packages/pylab.py", line 1, in 
<module>
 from matplotlib.pylab import *
 File "/usr/local/lib/python3.2/site-packages/matplotlib/pylab.py", 
line 221, in <module>
 from matplotlib import mpl # pulls in most modules
 File "/usr/local/lib/python3.2/site-packages/matplotlib/mpl.py", line 
2, in <module>
 from matplotlib import axis
 File "/usr/local/lib/python3.2/site-packages/matplotlib/axis.py", 
line 10, in <module>
 import matplotlib.font_manager as font_manager
 File 
"/usr/local/lib/python3.2/site-packages/matplotlib/font_manager.py", 
line 1317, in <module>
 _rebuild()
 File 
"/usr/local/lib/python3.2/site-packages/matplotlib/font_manager.py", 
line 1304, in _rebuild
 fontManager = FontManager()
 File 
"/usr/local/lib/python3.2/site-packages/matplotlib/font_manager.py", 
line 967, in __init__
 self.ttffiles = findSystemFonts(paths) + findSystemFonts()
 File 
"/usr/local/lib/python3.2/site-packages/matplotlib/font_manager.py", 
line 317, in findSystemFonts
 files = list_fonts(path, fontexts)
 File 
"/usr/local/lib/python3.2/site-packages/matplotlib/font_manager.py", 
line 167, in list_fonts
 return cbook.listFiles(directory, pattern)
 File "/usr/local/lib/python3.2/site-packages/matplotlib/cbook.py", 
line 1069, in listFiles
 os.path.walk(root, visit, arg)
AttributeError: 'module' object has no attribute 'walk'
 >>>
------------------------
Traceback with a copy of an older FontList.cache:
Python 3.2 (unknown, Apr 6 2011, 18:44:52)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pylab
Traceback (most recent call last):
 File 
"/usr/local/lib/python3.2/site-packages/matplotlib/font_manager.py", 
line 1309, in <module>
 fontManager = pickle_load(_fmcache)
 File 
"/usr/local/lib/python3.2/site-packages/matplotlib/font_manager.py", 
line 924, in pickle_load
 data = pickle.load(fh)
ValueError: invalid literal for int() with base 10: 
"9\nNtRp173\n(dp174\ng12\ng13\nsg14\nS'Sarai'\np175\nsg16\nI400\nsg17\ng13\nsg18\ng13\nsg19\nS'/usr/share/fonts/truetype/ttf-devanagari-fonts/Sarai_07.ttf'\np176\nsg21\ng22\nsbag7\n(g8\ng9\nNtRp177\n(dp178\ng12\ng61\nsg14\nS'GFS"
During handling of the above exception, another exception occurred:
-- snip -- the same exception regaring os.path.walk()
On 04/08/2011 09:06 PM, Michael Droettboom wrote:
> Can you provide a traceback? I think this usage of os.path.walk may 
> have crept back in from a recent merge from master. It didn't get 
> noticed because it only runs if the user doesn't already have a font 
> cache file.
>
> I don't have a chance to look at this right now, but it you want to 
> submit a patch to convert this os.path.walk usage to os.walk, that 
> would of course be appreciated.
>
> In general, don't expect the Python 3.x branch to be terribly useful 
> for production work right now... There's probably lots of sharp edges 
> like this still lingering beneath the surface.
>
> Cheers,
> Mike
>
> On 04/08/2011 03:50 PM, Tobias Hoppe wrote:
>> Hi all,
>>
>> grepping matplotlib-py3k from github, configuring, compiling and 
>> installing with python3.2 under Ubuntu posed no problems. Firing up 
>> python and import matplotlib shows no errors in the first place. 
>> Importing pylab brings up errors in cbook.py, namely the call to 
>> os.path.walk() in line 1069 which is deprecated since python3.0.
>>
>> Without a proper replacement for os.path.walk() FontList.cache can't 
>> be generated. Is it just my fault at some point or is it still broken 
>> and needs fixing? If it needs fixing I will gladly look into it. What 
>> get's me wondering is that someone managed to get a simple plot out 
>> of mpl on python3.
>>
>> Please give me a hint, if I need to work on it.
>>
>> Greetz, Tobi
>>
>>
>> ------------------------------------------------------------------------------
>> Xperia(TM) PLAY
>> It's a major breakthrough. An authentic gaming
>> smartphone on the nation's most reliable network.
>> And it wants your games.
>> http://p.sf.net/sfu/verizon-sfdev
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
>
> -- 
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
> Baltimore, Maryland, USA
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Can you provide a traceback? I think this usage of os.path.walk may 
have crept back in from a recent merge from master. It didn't get 
noticed because it only runs if the user doesn't already have a font 
cache file.
I don't have a chance to look at this right now, but it you want to 
submit a patch to convert this os.path.walk usage to os.walk, that would 
of course be appreciated.
In general, don't expect the Python 3.x branch to be terribly useful for 
production work right now... There's probably lots of sharp edges like 
this still lingering beneath the surface.
Cheers,
Mike
On 04/08/2011 03:50 PM, Tobias Hoppe wrote:
> Hi all,
>
> grepping matplotlib-py3k from github, configuring, compiling and 
> installing with python3.2 under Ubuntu posed no problems. Firing up 
> python and import matplotlib shows no errors in the first place. 
> Importing pylab brings up errors in cbook.py, namely the call to 
> os.path.walk() in line 1069 which is deprecated since python3.0.
>
> Without a proper replacement for os.path.walk() FontList.cache can't 
> be generated. Is it just my fault at some point or is it still broken 
> and needs fixing? If it needs fixing I will gladly look into it. What 
> get's me wondering is that someone managed to get a simple plot out of 
> mpl on python3.
>
> Please give me a hint, if I need to work on it.
>
> Greetz, Tobi
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

<html><head></head><body bgcolor='#FFFFFF' style='font-size:12px;background-color:#FFFFFF;font-family:Verdana, Arial, sans-serif;'>Hi all,<br/><br/>grepping matplotlib-py3k from github, configuring, compiling and installing with python3.2 under Ubuntu posed no problems. Firing up python and import matplotlib shows no errors in the first place. Importing pylab brings up errors in cbook.py, namely the call to os.path.walk() in line 1069 which is deprecated since python3.0.<br/><br/>Without a proper replacement for os.path.walk() FontList.cache can't be generated. Is it just my fault at some point or is it still broken and needs fixing? If it needs fixing I will gladly look into it. What get's me wondering is that someone managed to get a simple plot out of mpl on python3.<br/><br/>Please give me a hint, if I need to work on it.<br/><br/>Greetz, Tobi</body></html>

Hi all,
sorry for the massive cross-post, but since all these projects were
highlighted with talks at this event, I figured there would be
interest... Hans-Petter Langtangen, Randy LeVeque and I organized a
set of Python-focused sessions at the recent SIAM Computational
Science and Engineering conference, with talks on numpy/scipy, cython,
matplotlib, ipython, sympy, as well as application-oriented talks on
astronomy and femhub. For those interested:
- The slides: http://fperez.org/events/2011_siam_cse/
- A blog post:
http://blog.fperez.org/2011/04/python-goes-to-reno-siam-cse-2011.html
- Some pictures: https://picasaweb.google.com/fdo.perez/SIAMCSE2011InReno#
Back to being quiet...
f

Tried the fix over a 1.0.0 installation a few months old and it works, but
there are issues with blocking, which I have encountered before. 
I will try on the current snapshot, and also adapt your fix to a 0.99
release which has a blocking behaviour that I understand better.
efiring wrote:
> 
> On 04/02/2011 02:48 PM, bdb112 wrote:
>>
>> Cannot pick markers '+','x' or others with zero area in plots made by
>> pyplot.scatter
>>
>> The example below
>> http://old.nabble.com/file/p31305303/picker_example_scatter.py
>> picker_example_scatter.py is from the matplotlib docs, but modified to
>> use
>> scatter instead of plot (which works fine).
>> http://matplotlib.sourceforge.net/users/event_handling.html#picking-exercise
>>
>> run picker_example_scatter.py
>> <will not respond to any picks>
>> edit code replace 'x' with 'o'
>> <Works, but only if click is inside marker - i.e. ignores picker value.>
>>
>> See also
>> http://old.nabble.com/Can't-pick-on-various-scatter-markers-tp19140977p19140977.html
>> which describes the same problem.
>>
>> Ububtu 10.04 LTS
>> matplotlib 0.99.1.1
>> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
>>
>>
> 
> See https://github.com/matplotlib/matplotlib/pull/72 for a possible 
> solution.
> 
> Eric
> 
> 
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself; 
> WebMatrix provides all the features you need to develop and 
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
-- 
View this message in context: http://old.nabble.com/picker-inpoerative-on-scatter-markers-x%2C-%2B-%28those-with-zero-area%29-tp31305303p31320598.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On 04/04/2011 12:35 PM, Darren Dale wrote:
> On Mon, Apr 4, 2011 at 5:57 PM, Eric Firing<ef...@ha...> wrote:
>> On 04/04/2011 10:24 AM, Darren Dale wrote:
>>> When I run some of the examples in pylab_examples, like
>>> simple_plot.py, the call to show() yields a window that immediately
>>> closes. This is with either the v1.0.x or master branches on OS X with
>>> python 2.7 and the qt4 backend, with interactive=True in matplotlibrc.
>>> When I change interactive to False, the window remains open until I
>>> close it.
>>>
>>> Is interactive=True not supported for scripts anymore?
>>
>> After testing and thinking a bit, I think the answer is that it never
>> was, unless you are in an environment like ipython. Certainly it hasn't
>> been any time recently. A script run from the command line exits when
>> it reaches the last line; if nothing blocks, then it will immediately
>> close the window and exit. This is not backend-dependent or
>> OS-dependent--it is just the way scripts work.
>
> I thought I remembered there being two separate issues: whether or not
> to block, and whether a plot is updated after each command or
> rendering is deferred until show() is called. Things may have changed
> when IPython pulled the threading monkeypatches, more likely my memory
> is bad. Your explanation makes sense. Thanks.
>
> Darren
Darren,
You are correct that interactive mode does have two effects, and I was 
only describing one--whether show blocks. The other effect of 
interactive mode is that pyplot commands, which include 
draw_if_interactive() calls, draw immediately when in interactive mode 
but draw only upon execution of show() when in non-interactive mode.
Eric

On Mon, Apr 4, 2011 at 5:57 PM, Eric Firing <ef...@ha...> wrote:
> On 04/04/2011 10:24 AM, Darren Dale wrote:
>> When I run some of the examples in pylab_examples, like
>> simple_plot.py, the call to show() yields a window that immediately
>> closes. This is with either the v1.0.x or master branches on OS X with
>> python 2.7 and the qt4 backend, with interactive=True in matplotlibrc.
>> When I change interactive to False, the window remains open until I
>> close it.
>>
>> Is interactive=True not supported for scripts anymore?
>
> After testing and thinking a bit, I think the answer is that it never
> was, unless you are in an environment like ipython. Certainly it hasn't
> been any time recently. A script run from the command line exits when
> it reaches the last line; if nothing blocks, then it will immediately
> close the window and exit. This is not backend-dependent or
> OS-dependent--it is just the way scripts work.
I thought I remembered there being two separate issues: whether or not
to block, and whether a plot is updated after each command or
rendering is deferred until show() is called. Things may have changed
when IPython pulled the threading monkeypatches, more likely my memory
is bad. Your explanation makes sense. Thanks.
Darren

On 04/04/2011 10:24 AM, Darren Dale wrote:
> When I run some of the examples in pylab_examples, like
> simple_plot.py, the call to show() yields a window that immediately
> closes. This is with either the v1.0.x or master branches on OS X with
> python 2.7 and the qt4 backend, with interactive=True in matplotlibrc.
> When I change interactive to False, the window remains open until I
> close it.
>
> Is interactive=True not supported for scripts anymore?
After testing and thinking a bit, I think the answer is that it never 
was, unless you are in an environment like ipython. Certainly it hasn't 
been any time recently. A script run from the command line exits when 
it reaches the last line; if nothing blocks, then it will immediately 
close the window and exit. This is not backend-dependent or 
OS-dependent--it is just the way scripts work.
Eric

On 04/04/2011 10:24 AM, Darren Dale wrote:
> When I run some of the examples in pylab_examples, like
> simple_plot.py, the call to show() yields a window that immediately
> closes. This is with either the v1.0.x or master branches on OS X with
> python 2.7 and the qt4 backend, with interactive=True in matplotlibrc.
> When I change interactive to False, the window remains open until I
> close it.
>
> Is interactive=True not supported for scripts anymore?
No, everything is supposed to work with both values of interactive. The 
difference is supposed to be that show blocks only in non-interactive mode.
I see the same problem with qt4agg backend on linux. I don't think it 
was doing that back when I was working on show, so I suspect something 
changed in qt4agg backend; either that, or this is something I thought I 
tested but didn't. It still works under ipython from git.
Eric

When I run some of the examples in pylab_examples, like
simple_plot.py, the call to show() yields a window that immediately
closes. This is with either the v1.0.x or master branches on OS X with
python 2.7 and the qt4 backend, with interactive=True in matplotlibrc.
When I change interactive to False, the window remains open until I
close it.
Is interactive=True not supported for scripts anymore?

Sorry, my question was not clear.
What you mention works, IF you know the last plotted object was a line
and not a text...
My question relates to trying to find this type of information automatically.
On Mon, Apr 4, 2011 at 7:15 AM, <bu...@gm...> wrote:
> Hi,
>
> Does matplotlib keep track of the last object added to the plot axes or its
> nature (line, text, collection, patch, etc.) ?
> If not, would it be feasible to implement something like this in matplotlib
> ?
>
> This could be useful for interactive plotting, as it would allow a simple
> undo feature based on commands such as del ax.lines[-1].
-- 
thanks,
peter butterworth