matplotlib-devel Mailing List for matplotlib (Page 13)

Jeff Whitaker wrote:
> Ryan May wrote:
>> Hi,
>>
>> I've got (what seems to me) a nice clean, self-contained 
>> implementation of wind barbs plots. I'd like to see if I can get this 
>> into matplotlib, as it would be very useful to the meteorology 
>> community. I've borrowed heavily from Quiver for rounding out rough 
>> edges (like multiple calling signatures) as for templates for 
>> documentation. The base implementation, though, seems much simpler 
>> (thanks to Mike's transforms) and is based more on scatter.
>>
>> Right now it monkey-patches Axes so that it can be a stand-alone file. 
>> Just running the file should give a good example of the expected output.
>>
>> My only concern up front is if a new axes method is appropriate, since 
>> this is somewhat domain specific. But I'd like to at least get the 
>> new Collections class included, since otherwise, I have no idea how to 
>> get this distributed to the community at large.
>>
>> I welcome any comments/criticism to help improve this.
>>
>> Ryan
>>
> Ryan: This looks great! I fixed one typo (the "length" keyword was 
> mis-identified as "scale" in the docstring) and replace your example 
> with an adaption of the quiver_demo.py basemap example.
Thanks. When this finally lands in matplotlib svn, do you need me to do 
the patch to add it to basemap? If so, anything I should know? Or will 
you just take care of it?
> I noticed that ticks on the barbs are so close that they are hard to 
> discern unless the linewidth is reduced. I wonder if the spacing of the 
> ticks could be added as a keyword, perhaps as a fraction of the wind 
> barb length?
It's already coded up as such, it's just a matter of exposing it as a 
keyword. I didn't do it already because I didn't want the alphabet 
soup. But I guess since I'm already parsing the **kw dictionary, 
popping off a few more values isn't too bad...
> 
> This will be a wonderful addition to matplotlib. Thanks!
> 
> -Jeff
> 
> P.S. eagerly awaiting your Skew-T implementation ....
You and every other met I know...It's a good thing I want this so badly, 
because having struggled with it I understand why there's so few 
implementations out there. Wind barbs actually came as a nice little 
distraction to learn a bit of the matplotlib API before trying to get 
the Skew-T right again.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

John Hunter wrote:
> On Tue, Jul 15, 2008 at 5:37 PM, Ryan May <rm...@gm...> wrote:
> 
>> I welcome any comments/criticism to help improve this.
> 
> Hey Ryan,
> 
> I have looked at this code briefly and have a few minor comments. I
> think Eric, who did the bulk of the current quiver implementation, and
> as an oceanographer is in a field much closer to yours than mine, will
> provide more useful feedback and should ultimately handle the patch
> submission.
> 
> My first comment is that the code looks very good -- it is well
> thought out and commented, and t is definitely suitable for inclusion
> in the main line. Certainly the Barbs class can live in the
> collections module. You note in the driver code that you are worried
> about pollution of the axes namespace by including a domain specific
> method, and this is a reasonable worry, but the axes namespace is
> currently so polluted with plotting methods that it is a small worry.
> I think it would be fine for you to rework your code into a patch
> which provides the Barbs collection in matplotlib.collections, an Axes
> method, and a pyplot interface function (with a pylab module level
> docstring entry). The overloading of the Axes namespace is not ideal,
> but it's what we've got.
Thanks. My question then is how do I add a pyplot interface, since it 
appears from the comments that many of those are just generated boilerplate?
> My second comment has to do with your comment at the end of the example:
> 
> #Showing colormapping with uniform grid. Unfortunately, only the flags
> #on barbs get colormapped this way.
> 
> On a cursory read of the code, it looks like you have implemented
> everything as a single poly collection, and the reason the flags only
> get colored is that the varicolored is black. It seems like there are
> two solutions: write your class as a combination of poly collection
> (for the flags) and line collection (for the barbs) and colormap both
> (there are some line collection colormapping examples in the examples
> subdir courtesy of Eric). The 2nd alternative, which I haven't
> explored, is to set the edgecolor equal to the facecolor and support
> colormapping of the edgecolors.
Yeah, the comment went more to explain expected results. There was no 
mystery to me why the edgecolors didn't get colormapped, it was pretty 
clear from the collections code. I had started down the road of 
combining lines and polygons in a PatchCollection, but that created a 
bunch of separate objects for each wind barb that had to each be 
transformed and have an offset applied. I took the lazy way out and 
created (admittedly) degenerate polygons. :) I hadn't actually thought 
(call it a brain fart) about actually going ahead and adding 
colormapping for the edgecolors. Should I follow Mike's suggestion and 
possibly take a go at adding it to the general Collections class? 
(Granted, if someone else took a stab at it, it might land in SVN 
sooner, I'm sure I still have a learning curve to go here).
> Overall this is very promising, and I wish you the best trying to make
> mpl serviceble to the meteorology community. Jeff Whitaker has done a
> phenomenal job with basemap providing extensions for those needing
> cartographic projections as a toolkit. Depending on how far you want
> to go with meteorological support, we can include the changes in the
> mainline or fold them into a toolkit if they become hyper-specialized.
I still have a few more things to add (on top of what Whitaker already 
fixed for me):
* Need to plot something (empty circle) for vector magnitude < 5. (I 
did a plot the other day and was befuddled for a bit by seeing only 6 barbs)
* Need to fix support for masked arrays. The way the iteration goes 
right now, masked values end up being iterated over, which is bad.
* Probably should add a set_uv(c) method, like quiver
We'll see about the possibility of a toolkit. If I can keep up the 
momentum, I might end up with significant functionality. I'd also have 
to see how much of it really ends up being more than just simple example 
scripts. And I agree, huge props to Whitaker for Basemap. Hopefully I 
can get more people around me to use it instead of the abominations used 
now. :)
(I'd have things sooner if it weren't for the stupid Google CodeJam :) )
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Jul 17, 2008 at 10:35 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Has anyone ever noticed weirdness with translucent polygons on win32
> (using GTKAgg)? I had the occasion to actually do something on windows
> and noticed that, having drawn some polygons with alpha < 1, if I
> resized the window or panned, the alpha channel seemed to disappear and
> leave solid-colored polygons.
gtkagg on win32 is a very unusual combination -- one I used a lot in
the day myself but it seems noone else did. It is really hard to
understand how something like this can happen from the way the code is
written, but yes, if you can get any insight into it, we'd certainly
like to understand and fix it. I have at least one fairly significant
piece of code that requires gtkagg on windows....
For starters, just posting the output of a script run with
--verbose-helpful so we can get some version info for the archives
will be useful.
JDH

Hi,
Has anyone ever noticed weirdness with translucent polygons on win32 
(using GTKAgg)? I had the occasion to actually do something on windows 
and noticed that, having drawn some polygons with alpha < 1, if I 
resized the window or panned, the alpha channel seemed to disappear and 
leave solid-colored polygons.
I was unable just now to replicate this on linux.
Not a huge deal for me at all (as a linux guy), but I thought I'd give 
the heads up. I might be able to investigate a little further if 
there's any interest.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Jul 17, 2008 at 09:44:48PM +0200, David M. Kaplan wrote:
> Another option would be to create a start_event_loop function like Paul
> suggested and overload that function in those backends that aren't
> interactive so that it returns an error, but this requires writing one
> such function for each non-interactive backend.
Either create a deeper hierarchy:
 FigureCanvasBase:
 def start_event_loop(self, ...): 
 raise NotImplemented
 FigureCanvasInteractive:
 def start_event_loop(self, ...):
 generic interactive using time.sleep
 MyInteractiveBackend(FigureCanvasInteractive):
 def start_event_loop(self, ...):
 specialized interactive code using GUI 
or a mix-in class:
 FigureCanvasBase:
 def start_event_loop(self, ...): 
 raise NotImplemented
 FigureCanvasEventLoopMixin:
 def start_event_loop(self, ...):
 generic interactive using time.sleep
 MyInteractiveBackend(FigureCanvasBase,FigureCanvasEventLoopMixin):
 ... no start_event_loop since using the generic mixin ...
I prefer the latter, particularly since it won't be needed once the
existing interactive backends are implemented.
> Also, is there any case
> where an event loop would be useful for a graphically non-interactive
> backend? If so, this would again mean that this problem would be easier
> to deal with once in the Blocking* classes.
No reason to. While you could prompt for graph coordinates at the 
command line on a call to ginput, you could also simply prompt for
the coordinates without bothering with ginput.
 - Paul

On Thu, Jul 17, 2008 at 3:44 PM, Vineet Kumar <vi...@go...> wrote:
> It's a pretty trivial 2-line patch to make this work, which I've
> tested internally. It doesn't affect any case where the user has
> already specified their own Formatter.
>
> Please let me know if there's any other information or assistance I can provide.
Thanks Vineet -- committed to svn r5784, so it will be included in
our next bug fix release due out soon.
JDH

Hello,
In working with matplotlib to render some time-based data series, I
noticed that specifying a timezone as a kwarg to plot_date doesn't
affect the rendering of tick labels as I expected.
I've submitted a patch on sourceforge:
http://sourceforge.net/tracker/index.php?func=detail&aid=2020934&group_id=80706&atid=560722
It's a pretty trivial 2-line patch to make this work, which I've
tested internally. It doesn't affect any case where the user has
already specified their own Formatter.
Please let me know if there's any other information or assistance I can provide.
Thanks,
Vineet
-- 
Vineet Kumar <vi...@go...>

On Thu, Jul 17, 2008 at 2:44 PM, David M. Kaplan <Dav...@ir...> wrote:
> Hi all,
>
> I committed to svn (revision 5782) a version of the patch for clabel and
> waitforbuttonpress. I haven't perfected label rotation yet, but it
> works at the moment. I also haven't yet followed Paul Kienzle's
> suggestions (though I think they are a good idea), as I wanted to get a
> bit more information in relation to one of Gael's comments below.
Just reading through the blocking_inpu with comments mostly unrelated
to those you are raising here, and I was just reading for style rather
than logic. Some of this stuff may not be your code but here is what
I found:
 def __init__(self, fig, eventslist=()):
 self.fig = fig
 assert isinstance(eventslist, tuple), "Requires a tuple of
event name strings"
 self.eventslist = eventslist
It is rarely necessary to require *a tuple* though in some cases it
might be. Wouldn't a list work here? We use duck typing in mpl: eg
if you want to make sure the input is iterable and it contains strings
 import matplotlib.cbook
 if not cbook.iterable(eventslist):
 raise ValueError('events list must be iterable')
 if cbook.is_string_like(eventslist):
 raise ValueError('eventslist cannot be a string')
 for event in eventslist:
 if not cbook.is_string_like(event):
 raise ValueError('events list must be a list of strings')
I would probably write a cbook method is_sequence_of_strings and just
call that since it will be more readable and reusable...
I notice there are some residual print statements in the code -- these
should be replaced by the verbose handler in matplotlib/__init__.py,
eg in
 if timeout > 0 and counter > timeout/0.01:
 print "Timeout reached";
 break;
and
 if self.verbose:
 print "input %i: %f,%f" % (len(self.clicks),
 event.xdata, event.ydata)
and others in contour.py
You can replace these with
 import matplotlib
 matplotlib.verbose.report('something')
and
 matplotlib.verbose.report('some nitty gritty details', 'debug')
There should be no prints in mpl.
In contour.py, we have
 xmax = np.amax(np.array(linecontour)[:,0])
 xmin = np.amin(np.array(linecontour)[:,0])
 ymax = np.amax(np.array(linecontour)[:,1])
 ymin = np.amin(np.array(linecontour)[:,1])
which needlessly repears the array creation. I would create it once
and reuse it.
That's all for now. Thanks.
JDH

Hi all,
I committed to svn (revision 5782) a version of the patch for clabel and
waitforbuttonpress. I haven't perfected label rotation yet, but it
works at the moment. I also haven't yet followed Paul Kienzle's
suggestions (though I think they are a good idea), as I wanted to get a
bit more information in relation to one of Gael's comments below.
My responses to Gael's comments are mixed in below.
Cheers,
David 
On Thu, 2008年07月17日 at 17:19 +0200, Gael Varoquaux wrote:
> OK, a few comment from quickly glancing at the patch:
> 
> * What happens if twe are in a non interactive terminal, such as
> postscript? If this thing is running on a headless server, we don't
> want to hang the script because the manual option has been selected.
> 
The current answer is don't do that. In my opinion, all of these
functions should probably return an error if not in an interactive
terminal or graphical backend. I looked around a bit for a backend
neutral way to ask that question, but didn't find anything.
isinteractive seems like it should be relevant, but for Agg backend,
which doesn't display a graphical window, it was true, so this doesn't
seem to fit the bill. I imagine there is a way and one of you can tell
me what it is. If so, I will add it in the right place.
Another option would be to create a start_event_loop function like Paul
suggested and overload that function in those backends that aren't
interactive so that it returns an error, but this requires writing one
such function for each non-interactive backend. Also, is there any case
where an event loop would be useful for a graphically non-interactive
backend? If so, this would again mean that this problem would be easier
to deal with once in the Blocking* classes.
> * Putting this argument in "*args" seems like a bad style (it looks like
> matlab). Why don't you use a "label_pos='auto'" keyword argument. This
> would be much more robust to the addition of other options, and more in
> agreement with the rest of the style of pylab's arguments.
> 
Originally I intended to allow either the v argument or manual, but both
ended up hanging around - think of it as a comfort food for matlab
users. But you're right and I have now placed it in a keyword argument
"manual".
> I have to run. I haven't reviewed the patch very well. I think you should
> address those two comments and send it again to the list for review.
> You'll probably get useful advice and maybe learn more about Python.
> 
> Thanks,
> 
> Gaël
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

I am trying to do a clean rebuild of the docs, and am seeing warnings
from dot/digraph when I do the latex part. Looks like this is coming
from the inheritance diagram support:
jdhunter@bic128:doc> dot -V
dot - Graphviz version 2.14.1 (Fri Sep 7 12:22:15 UTC 2007)
# here is the build output
dumping search index...
build succeeded, 4 warnings.
Sphinx v0.3, building latex
trying to load pickled env... done
building [latex]: all documents
updating environment: 0 added, 0 changed, 0 removed
processing Matplotlib.tex... index users/index users/intro
users/installing users/pyplot_tutorial users/navigation_toolbar
users/customizing users/index_text users/text_intro users/text_props
users/mathtext users/usetex users/annotations users/artists
users/event_handling faq/index faq/installing_faq
faq/troubleshooting_faq faq/howto_faq faq/environment_variables_faq
devel/index devel/coding_guide devel/documenting_mpl
devel/release_guide devel/transformations devel/add_new_projection
devel/outline api/index api/matplotlib_configuration_api api/afm_api
api/artist_api api/figure_api api/axes_api api/axis_api api/cbook_api
api/cm_api api/collections_api api/colorbar_api api/colors_api
api/pyplot_api api/index_backend_api api/backend_bases_api
api/backend_gtkagg_api api/backend_qt4agg_api api/backend_wxagg_api
glossary/index
resolving references...
writing... Error: <stdin>:1: syntax error near line 1
context: digraph >>> inheritance <<< s {
WARNING: /home/jdhunter/mpl/doc/index.rst:None: (WARNING/2) 'dot'
returned the errorcode 1
WARNING: unusable reference target found:
https://sourceforge.net/project/admin/?group_id=80706
Error: <stdin>:1: syntax error near line 1
context: digraph >>> inheritance <<< s {
WARNING: /home/jdhunter/mpl/doc/index.rst:None: (WARNING/2) 'dot'
returned the errorcode 1
Error: <stdin>:1: syntax error near line 1
context: digraph >>> inheritance <<< s {
WARNING: /home/jdhunter/mpl/doc/index.rst:None: (WARNING/2) 'dot'
returned the errorcode 1
Error: <stdin>:1: syntax error near line 1
context: digraph >>> inheritance <<< s {
WARNING: /home/jdhunter/mpl/doc/index.rst:None: (WARNING/2) 'dot'
returned the errorcode 1
done
finishing...

Michael Droettboom wrote:
> Should be fixed in r5775.
> 
> It seems Agg doesn't like MOVETO commands and the end of a path. Since
> the update is in a C++ header file, you will need to force a full
> rebuild (by removing your build directory, for instance.)
Thanks, I tested and this fixes the issue for me.
-Andrew

It seems one of the static JavaScript files changed. Deleting my 
installation of Sphinx in site-packages and reinstalling fixed the problem.
Cheers,
Mike
Darren Dale wrote:
> On Thursday 17 July 2008 01:07:27 pm Michael Droettboom wrote:
> 
>> I'm preparing for my Scipy talk about our Sphinx docs, and I seem to be
>> having trouble with the search functionality. The links that searching
>> generates do not have an .html extension, so they don't actually work.
>> For example this:
>>
>>
>> file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists?highlight
>> =histogram
>>
>> When it should be this:
>>
>>
>> file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists.html?high
>> light=histogram
>>
>> I don't see this problem with the docs at matplotlib.sf.net/doc/html/,
>> only the ones I'm generating locally. Before I take this to the Sphinx
>> list, are others seeing this (with a SVN Sphinx updated today?)
>> 
>
> Yep, I see it too.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thursday 17 July 2008 01:07:27 pm Michael Droettboom wrote:
> I'm preparing for my Scipy talk about our Sphinx docs, and I seem to be
> having trouble with the search functionality. The links that searching
> generates do not have an .html extension, so they don't actually work.
> For example this:
>
>
> file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists?highlight
>=histogram
>
> When it should be this:
>
>
> file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists.html?high
>light=histogram
>
> I don't see this problem with the docs at matplotlib.sf.net/doc/html/,
> only the ones I'm generating locally. Before I take this to the Sphinx
> list, are others seeing this (with a SVN Sphinx updated today?)
Yep, I see it too.

Should be fixed in r5775.
It seems Agg doesn't like MOVETO commands and the end of a path. Since 
the update is in a C++ header file, you will need to force a full 
rebuild (by removing your build directory, for instance.)
Cheers,
Mike
Michael Droettboom wrote:
> I'm looking into it.
>
> Cheers,
> Mike
>
> Andrew Straw wrote:
> 
>> John Hunter wrote:
>> 
>> 
>>> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> wrote:
>>> 
>>> 
>>> 
>>>> Hi All,
>>>> I'd like to "resubmit" the request below: any new version to be
>>>> released soon? in the process to generate the doc in Debian, something
>>>> got fixed upstream, so a new release would be really helpful to have
>>>> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
>>>> strange chars in it).
>>>> 
>>>> 
>>>> 
>>> I think we could do a 0.98.3 release. There have been several bugs
>>> fixed. Could you do me a favor and check svn r5722 and see if it
>>> meets all your requirements for debian before we actually do the
>>> release?
>>> 
>>> 
>>> 
>> I just checked r5772 and found that a problem when plotting nans. I know
>> that masked arrays are preferred to nans, but considering that this used
>> to work in 0.91 and earlier, this is a regression.
>>
>> I've modified nan_test.py in examples/pylab_examples to illustrate the
>> bug in r5773 (also attached), but I think Eric would probably be vastly
>> more efficient than I when it comes to fixing properly.
>>
>> -Andrew
>> 
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm looking into it.
Cheers,
Mike
Andrew Straw wrote:
> John Hunter wrote:
> 
>> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> wrote:
>> 
>> 
>>> Hi All,
>>> I'd like to "resubmit" the request below: any new version to be
>>> released soon? in the process to generate the doc in Debian, something
>>> got fixed upstream, so a new release would be really helpful to have
>>> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
>>> strange chars in it).
>>> 
>>> 
>> I think we could do a 0.98.3 release. There have been several bugs
>> fixed. Could you do me a favor and check svn r5722 and see if it
>> meets all your requirements for debian before we actually do the
>> release?
>> 
>> 
> I just checked r5772 and found that a problem when plotting nans. I know
> that masked arrays are preferred to nans, but considering that this used
> to work in 0.91 and earlier, this is a regression.
>
> I've modified nan_test.py in examples/pylab_examples to illustrate the
> bug in r5773 (also attached), but I think Eric would probably be vastly
> more efficient than I when it comes to fixing properly.
>
> -Andrew
> 
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Sorry. That's my bad. I accidentally committed some testing code for 
log-scaled quad meshes (which works for Agg, but not for other 
backends). I'll revert the example, and see what's breaking.
Cheers,
Mike
John Hunter wrote:
> Anyone have any idea what changes may be causing this new bug in
> quadmesh on non agg backends?
>
> jdhunter@bic128:mpl> python examples/pylab_examples/quadmesh_demo.py -dPS
> Traceback (most recent call last):
> File "examples/pylab_examples/quadmesh_demo.py", line 47, in <module>
> savefig("quadmesh_demo")
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py",
> line 306, in savefig
> return fig.savefig(*args, **kwargs)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py",
> line 1043, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py",
> line 1301, in print_figure
> **kwargs)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
> line 840, in print_ps
> return self._print_ps(outfile, 'ps', *args, **kwargs)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
> line 869, in _print_ps
> orientation, isLandscape, papertype)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
> line 943, in _print_figure
> self.figure.draw(renderer)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py",
> line 842, in draw
> for a in self.axes: a.draw(renderer)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py",
> line 1549, in draw
> a.draw(renderer)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/collections.py",
> line 533, in draw
> self._showedges)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py",
> line 153, in draw_quad_mesh
> meshWidth, meshHeight, coordinates)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/collections.py",
> line 484, in convert_mesh_to_paths
> ), axis=2)
> File "/home/jdhunter/dev/lib64/python2.5/site-packages/numpy/ma/core.py",
> line 1307, in __array_finalize__
> self._mask.shape = self.shape
> AttributeError: incompatible shape for a non-contiguous array
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Thu, Jul 17, 2008 at 7:48 AM, Sandro Tosi <mat...@gm...> wrote:
> 
>> Hi All,
>> I'd like to "resubmit" the request below: any new version to be
>> released soon? in the process to generate the doc in Debian, something
>> got fixed upstream, so a new release would be really helpful to have
>> 0.98.2+ in Debian (current 0.98.2 can't be uploaded due to a file with
>> strange chars in it).
>> 
>
> I think we could do a 0.98.3 release. There have been several bugs
> fixed. Could you do me a favor and check svn r5722 and see if it
> meets all your requirements for debian before we actually do the
> release?
> 
I just checked r5772 and found that a problem when plotting nans. I know
that masked arrays are preferred to nans, but considering that this used
to work in 0.91 and earlier, this is a regression.
I've modified nan_test.py in examples/pylab_examples to illustrate the
bug in r5773 (also attached), but I think Eric would probably be vastly
more efficient than I when it comes to fixing properly.
-Andrew

I'm preparing for my Scipy talk about our Sphinx docs, and I seem to be 
having trouble with the search functionality. The links that searching 
generates do not have an .html extension, so they don't actually work. 
For example this:
 
file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists?highlight=histogram
When it should be this:
 
file:///home/mdroe/builds/matplotlib/doc/build/html/users/artists.html?highlight=histogram
I don't see this problem with the docs at matplotlib.sf.net/doc/html/, 
only the ones I'm generating locally. Before I take this to the Sphinx 
list, are others seeing this (with a SVN Sphinx updated today?)
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Anyone have any idea what changes may be causing this new bug in
quadmesh on non agg backends?
jdhunter@bic128:mpl> python examples/pylab_examples/quadmesh_demo.py -dPS
Traceback (most recent call last):
 File "examples/pylab_examples/quadmesh_demo.py", line 47, in <module>
 savefig("quadmesh_demo")
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/pyplot.py",
line 306, in savefig
 return fig.savefig(*args, **kwargs)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py",
line 1043, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py",
line 1301, in print_figure
 **kwargs)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
line 840, in print_ps
 return self._print_ps(outfile, 'ps', *args, **kwargs)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
line 869, in _print_ps
 orientation, isLandscape, papertype)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backends/backend_ps.py",
line 943, in _print_figure
 self.figure.draw(renderer)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/figure.py",
line 842, in draw
 for a in self.axes: a.draw(renderer)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py",
line 1549, in draw
 a.draw(renderer)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/collections.py",
line 533, in draw
 self._showedges)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py",
line 153, in draw_quad_mesh
 meshWidth, meshHeight, coordinates)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/collections.py",
line 484, in convert_mesh_to_paths
 ), axis=2)
 File "/home/jdhunter/dev/lib64/python2.5/site-packages/numpy/ma/core.py",
line 1307, in __array_finalize__
 self._mask.shape = self.shape
AttributeError: incompatible shape for a non-contiguous array

Hi,
This sounds like a great idea. My trunk version of matplotlib does not
have these changes. I presume you would like me to commit them? If so,
let me know and it would be great if you could give your code a test
using the wx backend afterward.
Cheers,
David
On Thu, 2008年07月17日 at 12:13 -0400, Paul Kienzle wrote:
> On Thu, Jul 17, 2008 at 09:46:16AM +0200, David M. Kaplan wrote:
> > I don't think the blocking code will be that hard to maintain. It
> > basically just depends on events, callback functions and time.sleep. If
> > those are cross-platform, then it shouldn't be a problem. But only time
> > will tell. My ability and desire to test on multiple platforms is
> > limited - I use ubuntu/gnome-gtk/linux 100%.
> 
> In addition to your patch you can put start/stop_event_loop 
> methods into the the canvas. That way backends can specialize 
> their implementation so they don't need a busy loop while waiting
> for the event.
> 
> Then you can replace the termination notice in BlockingInput:
> 
> - self.done = True
> + self.fig.canvas.stop_event_loop()
> 
> and move the busy loop to the backend:
> 
> # wait for n clicks
> - counter = 0
> - while not self.done:
> - self.fig.canvas.flush_events()
> - time.sleep(0.01)
> - 
> - # check for a timeout
> - counter += 1
> - if timeout > 0 and counter > timeout/0.01:
> - print "ginput timeout";
> - break;
> + self.fig.canvas.start_event_loop(timeout=timeout)
> 
> 
> In backend_bases.py I have a generic interactive version 
> based on sleep:
> 
> class FigureCanvasBase:
> ...
> def start_event_loop(self, timeout=0):
> """
> Run the event loop.
> 
> This call blocks until an event callback triggers
> stop_event_loop() or the timeout interval is exceeded.
> """
> if timeout == 0: timeout = npy.inf
> timestep = 0.01
> counter = 0
> self._looping = True
> while self._looping and counter*timestep < timeout:
> self.flush_events()
> time.sleep(timestep)
> counter += 1
> 
> def stop_event_loop(self):
> """
> Stop the event loop.
> 
> The function which started the event loop can now run to completion.
> """
> self._looping = False
> 
> 
> In the wx canvas this is specialized as:
> 
> class FigureCanvasWx(FigureCanvasBase, wx.Panel):
> ...
> def start_event_loop(self, timeout=0):
> """
> Run the event loop.
> 
> This call blocks until an event callback triggers
> stop_event_loop() or the timeout interval is exceeded.
> """
> root = self.GetTopLevelParent()
> bind(root, wx.EVT_CLOSE, self.stop_event_loop)
> 
> id = wx.NewId()
> timer = wx.Timer(self, id=id)
> if timeout > 0:
> timer.Start(timeout*1000, oneShot=True)
> bind(self, wx.EVT_TIMER, self.stop_event_loop, id=id)
> self._event_loop.Run()
> timer.Stop()
> 
> def stop_event_loop(self, event=None):
> """
> Stop the event loop.
> 
> The function which started the event loop can now run to completion.
> """
> if self._event_loop.IsRunning(): 
> self._event_loop.Exit()
> 
> # Event binding code changed after version 2.5
> if wx.VERSION_STRING >= '2.5':
> def bind(actor,event,action,**kw):
> actor.Bind(event,action,**kw)
> else:
> def bind(actor,event,action,id=None):
> if id is not None:
> event(actor, id, action)
> else:
> event(actor,action)
> 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

On Thu, Jul 17, 2008 at 09:46:16AM +0200, David M. Kaplan wrote:
> I don't think the blocking code will be that hard to maintain. It
> basically just depends on events, callback functions and time.sleep. If
> those are cross-platform, then it shouldn't be a problem. But only time
> will tell. My ability and desire to test on multiple platforms is
> limited - I use ubuntu/gnome-gtk/linux 100%.
In addition to your patch you can put start/stop_event_loop 
methods into the the canvas. That way backends can specialize 
their implementation so they don't need a busy loop while waiting
for the event.
Then you can replace the termination notice in BlockingInput:
- self.done = True
+ self.fig.canvas.stop_event_loop()
and move the busy loop to the backend:
 # wait for n clicks
- counter = 0
- while not self.done:
- self.fig.canvas.flush_events()
- time.sleep(0.01)
- 
- # check for a timeout
- counter += 1
- if timeout > 0 and counter > timeout/0.01:
- print "ginput timeout";
- break;
+ self.fig.canvas.start_event_loop(timeout=timeout)
In backend_bases.py I have a generic interactive version 
based on sleep:
class FigureCanvasBase:
 ...
 def start_event_loop(self, timeout=0):
 """
 Run the event loop.
 This call blocks until an event callback triggers
 stop_event_loop() or the timeout interval is exceeded.
 """
 if timeout == 0: timeout = npy.inf
 timestep = 0.01
 counter = 0
 self._looping = True
 while self._looping and counter*timestep < timeout:
 self.flush_events()
 time.sleep(timestep)
 counter += 1
 def stop_event_loop(self):
 """
 Stop the event loop.
 The function which started the event loop can now run to completion.
 """
 self._looping = False
In the wx canvas this is specialized as:
class FigureCanvasWx(FigureCanvasBase, wx.Panel):
 ...
 def start_event_loop(self, timeout=0):
 """
 Run the event loop.
 This call blocks until an event callback triggers
 stop_event_loop() or the timeout interval is exceeded.
 """
 root = self.GetTopLevelParent()
 bind(root, wx.EVT_CLOSE, self.stop_event_loop)
 id = wx.NewId()
 timer = wx.Timer(self, id=id)
 if timeout > 0:
 timer.Start(timeout*1000, oneShot=True)
 bind(self, wx.EVT_TIMER, self.stop_event_loop, id=id)
 self._event_loop.Run()
 timer.Stop()
 def stop_event_loop(self, event=None):
 """
 Stop the event loop.
 The function which started the event loop can now run to completion.
 """
 if self._event_loop.IsRunning(): 
 self._event_loop.Exit()
# Event binding code changed after version 2.5
if wx.VERSION_STRING >= '2.5':
 def bind(actor,event,action,**kw):
 actor.Bind(event,action,**kw)
else:
 def bind(actor,event,action,id=None):
 if id is not None:
 event(actor, id, action)
 else:
 event(actor,action)

Paul Kienzle wrote:
> On Thu, Jul 17, 2008 at 08:50:03AM +0200, Manuel Metz wrote:
>> Just because the discussion about clabel started, I want to post a short 
>> snipplet of code that I found useful. It was some sort of hack to get a 
>> nicer float formating for contours: contour lines represented confidence 
>> levels of 1, 2.5, 5 and 10 per cent, and I wanted a labeling exactly as 
>> I have written it here now. So, fmt='%.1f\%%' would have resulted in 
>> 1.0% 2.5% 5.0% ... but I wanted 1% 2.5% 5% ...
> 
> The %g format produces "nice" numbers.
> 
> For example:
> 
> >>> print " ".join(["%g%%"%v for v in [1.0,2.5,5.000001,10.03]])
> 1% 2.5% 5% 10.03%
> 
> - Paul
How *** **** did I miss that !? Can't believe it ...

On Thu, Jul 17, 2008 at 08:50:03AM +0200, Manuel Metz wrote:
> Just because the discussion about clabel started, I want to post a short 
> snipplet of code that I found useful. It was some sort of hack to get a 
> nicer float formating for contours: contour lines represented confidence 
> levels of 1, 2.5, 5 and 10 per cent, and I wanted a labeling exactly as 
> I have written it here now. So, fmt='%.1f\%%' would have resulted in 
> 1.0% 2.5% 5.0% ... but I wanted 1% 2.5% 5% ...
The %g format produces "nice" numbers.
For example:
 >>> print " ".join(["%g%%"%v for v in [1.0,2.5,5.000001,10.03]])
 1% 2.5% 5% 10.03%
- Paul

On Thu, Jul 17, 2008 at 04:41:36PM +0200, David M. Kaplan wrote:
> Attached is a new version of the patch that includes ginput,
> waitforbuttonpress and clabel changes. It is already quite functional,
> but there are a couple of issues that need improving that I would like
> to solicit comments on. I explain below after detailing what I have
> done.
OK, a few comment from quickly glancing at the patch:
* What happens if twe are in a non interactive terminal, such as
 postscript? If this thing is running on a headless server, we don't
 want to hang the script because the manual option has been selected.
* Putting this argument in "*args" seems like a bad style (it looks like
 matlab). Why don't you use a "label_pos='auto'" keyword argument. This
 would be much more robust to the addition of other options, and more in
 agreement with the rest of the style of pylab's arguments.
I have to run. I haven't reviewed the patch very well. I think you should
address those two comments and send it again to the list for review.
You'll probably get useful advice and maybe learn more about Python.
Thanks,
Gaël

Hi,
On Thu, 2008年07月17日 at 07:47 -0700,
mat...@li... wrote:
> Just because the discussion about clabel started, I want to post a
> short 
> snipplet of code that I found useful. It was some sort of hack to get
> a 
> nicer float formating for contours: contour lines represented
> confidence 
> levels of 1, 2.5, 5 and 10 per cent, and I wanted a labeling exactly
> as 
> I have written it here now. So, fmt='%.1f\%%' would have resulted in 
> 1.0% 2.5% 5.0% ... but I wanted 1% 2.5% 5% ...
> 
> So this was my solution:
> 
> 
> # some kind of hack: a nicer floating point formating
> class nf(float):
> def __repr__(self):
> str = '%.1f' % (self.__float__(),)
> if str[-1]=='0':
> return '%.0f' % self.__float__()
> else:
> return '%.1f' % self.__float__()
> 
> levels = [nf(val) for val in [1.0, 2.5,5.0,10.0] ]
> 
> pylab.clabel(cs, inline=True, fmt='%r \%%')
> 
> 
> As I said, it's sort of a hack but it works! It might not be worth to 
> add this to mpl, but probably as an example ...!?
> 
> Manuel
Along these lines, I have been thinking that it would be a simple
addition to allow fmt to be a dictionary (as an alternative to a string)
that matches contour levels with the desired text. This would allow
users to label contours with arbitrary strings, which is occasionally
useful. If there is interest, I will add this feature.
Cheers,
David
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************