matplotlib-devel Mailing List for matplotlib (Page 2)

On Mon, Oct 25, 2010 at 6:53 AM, Kynn Jones <ky...@gm...> wrote:
>> diff -u figure.py.orig figure.py > patchname.diff
>
> OK, got that part. Thanks. But where do I send the patch?
Actually, we recommend submitting an svn diff. Details at:
 http://matplotlib.sourceforge.net/faq/howto_faq.html#submit-a-patch
JDH

Ben, JJ, thanks for your suggestions. I'll look into what you proposed.
~kj

On Sat, Oct 23, 2010 at 3:13 PM, Ryan May <rm...@gm...> wrote:
> On Sat, Oct 23, 2010 at 1:37 PM, Kynn Jones <ky...@gm...> wrote:
> > I came across this Python syntax bug in matplotlib.figure.add_subplot:
> > raise ValueError(
> > "polar=True, yet projection='%s'. " +
> > "Only one of these arguments should be supplied."
> %
> > projection)
> > If that code ever executes it will fail with "TypeError: not all
> arguments
> > converted during string formatting".
> > It's trivial to fix, of course, (just delete the '+') but I don't know
> how
> > to submit a patch. Could someone please show me?
>
> Good catch. I can make the change if you want. However, if you want to
> use as a learning experience, first make a copy of the original file,
> say figure.py.orig. Then make the changes to your figure.py. Then you
> need to run diff:
>
> diff -u figure.py.orig figure.py > patchname.diff
>
OK, got that part. Thanks. But where do I send the patch?
~kj

On Sat, Oct 23, 2010 at 7:09 AM, Kynn Jones <ky...@gm...> wrote:
> Without knowing much about the internals of matplotlib, it seems to me that
> the best way to do this would be to define a container class that can have
> itself as one of the contained elements. In this way, a containment
> hierarchy of arbitrary depth could be defined. But it is my understanding
> that there is no immediate way to do this in matplotlib now, so I'd have to
> implement it myself.
Matplotlib has a simple hierachy of Figure-Axes-Artists (this is not
100% correct description as a matter of fact, see
http://matplotlib.sourceforge.net/users/artists.html for more
details).
All Axes instances have associated positions within a figure instance.
If you want to have a hierarchy of multiple axes, what you can do
basically is to make those positions in hierarchical manner.
This can be very trivial depending on what exactly you want (e.g., how
you want the axes sizes (and the gaps inbetween) specified). However,
there are a few ways to ease this process.
http://github.com/astraw/mplsizer
mpl v1.0 has gridspec.
http://matplotlib.sourceforge.net/users/gridspec.html#gridspec-using-subplotspec
For example, you may do something like
import matplotlib.gridspec as gridspec
fig = gcf()
gs0 = gridspec.GridSpec(2, 2)
ax = fig.add_subplot(gs0[0, 0])
gs00 = gridspec.GridSpecFromSubplotSpec(2, 2, subplot_spec=gs0[1])
ax2 = fig.add_subplot(gs00[0])
gs000 = gridspec.GridSpecFromSubplotSpec(2, 2, subplot_spec=gs00[1])
ax3 = fig.add_subplot(gs000[0])
Or, you can use axes_grid toolkit as mentioned above.
Regards,
-JJ

--- On Sun, 10/24/10, Ryan May <rm...@gm...> wrote:
> > One solution is to add an .animation attribute to the
> > Figure class, which is None by default (for non-animated
> > drawing).
> I'm not completely wild about it, because it just feels
> wrong to put something specific to animation inside figure.
OK I see your point.
> The problem we're trying to solve here is biltting, so is 
> there some way we can improve how blitting is handled?
For a general API for blitting (something that is not restricted to animations), we need two functions: one that tells matplotlib that we want to blit something, and one that does the actual blitting. Right now we only have the latter. Let me point out also that there is nothing peculiar about blitting in Quartz. It's just that in Quartz all drawing operations should be performed from inside the event loop.
For comparison, this is roughly what happens if you draw a line:
plot(x,y)
# tells matplotlib that we want to draw a line
# this triggers a call to
draw_if_interactive()
# this marks the canvas as invalid
# the event loop then calls a callback function to redraw the canvas
# the callback function calls
figure.draw(renderer)
# which calls
renderer.draw_path
# which does the actual drawing
For a general blitting API, we need the equivalent of the plot function; something that informs matplotlib that we want to blit but doesn't do the actual blitting. The actual blitting should then be done from inside figure.draw.
If you just want to implement blitting for animations, one option is to add a draw() method to TimedAnimation, and to set fig.draw = self.draw in the __init__.py of TimedAnimation. Then when a figure needs to be redrawn, TimedAnimation.draw will be called from inside the event loop. Such a TimedAnimation.draw function should then be roughly the same as the current _draw_next_frame function.
Best,
--Michiel.
 

On Fri, Oct 22, 2010 at 5:09 PM, Kynn Jones <ky...@gm...> wrote:
> I need to generate a fairly complex chart, for which I need the ability to
> specify not only subplots, but also sub-subplots, and even
> sub-sub-sub-plots. (Our group has found such charts useful in the past, but
> they were generated using horrific MATLAB code.)
>
> I'll try to describe what I want to do in a bit more detail (it's messy).
>
> First imagine a simple plot (just a simple X-Y line graph connecting 3-4
> datapoints). I'll call this a level-0 plot. Now, join ~10 of these level-0
> plots side-by-side (with no space between the plots). This new aggregate is
> a level-1 plot. Next stack ~10 level-1 plots vertically, again, with no
> space between them. The resulting aggregate is a level-2 plot. Finally
> arrange ~10 of these level-2 plots side-by-side, with some spacing between
> them. The desired final product is this level-3 plot.
>
> Without knowing much about the internals of matplotlib, it seems to me that
> the best way to do this would be to define a container class that can have
> itself as one of the contained elements. In this way, a containment
> hierarchy of arbitrary depth could be defined. But it is my understanding
> that there is no immediate way to do this in matplotlib now, so I'd have to
> implement it myself.
>
> I could use some guidance to the source code.
>
> What I need to clarify is the following. First consider some simple plot
> A: it has axes, data points, tick marks, labels, etc., and for all these
> elements there are associated absolute x-y coordinates on the canvas. If
> now we make this plot A one of the subplots in a collection of, say, 12
> subplots, arranged as 3 rows of 4 subplots each, all the x-y coordinates
> associated with the original plot A will have to be translated and scaled,
> so that the subplot lands in the right place on the canvas, and has the
> appropriate size. This process of translation and scaling is what I want to
> pinpoint: What exactly is the connection between running the add_subplot
> method and the translation+scaling that it entails?
>
> What would be a good entry point for me to answer the questions above by
> reading the source code?
>
> TIA!
>
> ~kj
>
>
Looks like you are talking about an arbitrarily deep hierarchical
subplotting feature. I am not exactly sure how feasible/unfeasible this is,
but a good place to start might be to take a look at the axes_grid toolkit
that does a lot of very advanced axes organizational tricks.
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/index.html
I hope this proves useful, or at least inspires you for ideas on how to
accomplish what you are looking for cleanly. And, as always, patches are
always welcome!
Ben Root

On Sun, Oct 24, 2010 at 10:35:03AM -0500, Ryan May wrote:
> On Sat, Oct 23, 2010 at 5:05 PM, David Carmean <dl...@ha...> wrote:
[snip]
> > I've spent a few hours this weekend doing some meta-monkey-patching--
> > using __getattribute__ to decorate the setters on-the-fly to invoke
> > callbacks.process(*args) after the changes.  I have a few more quick
> > hacks to try before I'm ready to decide on a production-ready strategy.
> >
> > So my question today is: is anyone interested in discussing these
> > ideas and how to implement them?
> 
> I'm interested. I was just noticing a need for the signals to simplify
> some interactive stuff I was doing. I'm not wild about using the
> current incarnation of the CallbackRegistry, since it doesn't allow
> you to add signals after you create the object. Also, there are only
> global signals, you can't connect to a specific object (unless you
> were planning on each object having its own registry?). When I was
> considering this yesterday, I was looking at these:
> 
> http://code.activestate.com/recipes/87056/
> http://pydispatcher.sourceforge.net/
> 
> Also, had you given any thought to using decorators to note methods
> that emit a certain signal, or to connect one method to a given
> signal?
I've gone through the same thought process. I do plan to add a 
CallbackRegistry.add_signals method; I am giving each instance 
it's own registry instance (axes.Axes already does this); and I 
am using decorators. 

[Putting this back on list after I mistakenly took it off.]
On Fri, Oct 22, 2010 at 11:45 PM, Michiel de Hoon <mjl...@ya...> wrote:
> Hi Ryan,
>
> Thanks for your reply.
>
> --- On Mon, 10/18/10, Ryan May <rm...@gm...> wrote:
>> In the course of adding the animations, I also
>> added a "close_event" to the other backends, so that the
>> timers would stop on figure close and the users wouldn't
>> get weird messages. Did you happen to add this?
>
> I added the close_event to the Mac OS X backend today.
>
>> I'm not sure you can move this to figure.draw(renderer),
>> since that's going to draw *everything*.
>
> One solution is to add an .animation attribute to the Figure class, which is None by default (for non-animated drawing).
>
> Roughly, the code should then look as follows:
>
> In the Animation class, the _step method sets Figure.animation and lets the canvas know that it should redraw itself:
>
>  def _step(self, *args):
>    try:
>      framedata = self.frame_seq.next()
>      self.figure.animation = self, framedata
>      self.figure.canvas.draw_idle()
>      return True
>    except StopIteration:
>      return False
>
> Note that no actual drawing is done here.
>
> In the Figure class, the draw method should then become:
>
>  def draw(self, renderer):
>    if self.animation:
>      animation, framedata = self.animation
>      animation._draw_next_frame(framedata, animation._blit)
>      return
>    # otherwise, draw as usual.
>
> Then all actual drawing is done from inside Figure.draw, which is what the Mac OS X backend needs.
>
> How does this look? If this looks OK, I can try to work out the details and send you the modified code so you can check it out.
I'm not completely wild about it, because it just feels wrong to put
something specific to animation inside figure. The problem we're
trying to solve here is biltting, so is there some way we can improve
how blitting is handled? This would also be a time where we could
(possibly) simplify/improve the blitting API. Do any of the current
uses of blitting work with the MacOSX backend? If those *do* work,
then I'm doing something wrong and need to rework animations. If not,
then we need to find a way to make it so blitting can work in general.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Sat, Oct 23, 2010 at 5:05 PM, David Carmean <dl...@ha...> wrote:
>
> As I blurted on -users, I'm thinking lately about callbacks in the
> non-GUI portions of the libraries--mostly Artist and subclasses.
> I'm curious if anybody else has been thinking about them?
>
> Ideally, I'd like to see the following:
>
>  All of the Artist subclasses, and anything else that might belong to
> a Figure, would be updated to use/add cbook.CallbackRegistry callbacks
> (weakref = good thing).
>
>  In addition to emulating/replacing the simplistic 'pchanged' callback
> with a signal of that same name, there would be a signal named after each
> setter method, and said methods fire off their eponymous signal after they
> modify the property.
>
>  There should be some way to rate-limit or temporarily block individual
> signals or callback connections.
>
>  The various constructors, etc, would be modified to "subscribe" to
> the 'pchanged' signal of all children, such that even if a particular
> object in the "middle" of a figure heirarchy does nothing with the
> signal, a sort of a global 'pchanged' signal propagates up to the top
> object (FigureManager, Canvas, Figure, something).
>
> My current Use Case for these features is in experimenting with different
> Artist styles (Text styles/fonts, marker styles/sizes, etc), and I'm tired
> of calling canvas.draw() all the time :)  But also, I'm working on a
> GUI to do the same (traits UI), and want to tie both layers of the model
> together with callbacks to speed up the experimenting.
>
> I've spent a few hours this weekend doing some meta-monkey-patching--
> using __getattribute__ to decorate the setters on-the-fly to invoke
> callbacks.process(*args) after the changes.  I have a few more quick
> hacks to try before I'm ready to decide on a production-ready strategy.
>
> So my question today is: is anyone interested in discussing these
> ideas and how to implement them?
I'm interested. I was just noticing a need for the signals to simplify
some interactive stuff I was doing. I'm not wild about using the
current incarnation of the CallbackRegistry, since it doesn't allow
you to add signals after you create the object. Also, there are only
global signals, you can't connect to a specific object (unless you
were planning on each object having its own registry?). When I was
considering this yesterday, I was looking at these:
http://code.activestate.com/recipes/87056/
http://pydispatcher.sourceforge.net/
Also, had you given any thought to using decorators to note methods
that emit a certain signal, or to connect one method to a given
signal?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On 10/22/10 7:16 PM, Michael Droettboom wrote:
> On 10/22/2010 05:45 PM, Russell E. Owen wrote:
>> I'm curious when the next release of matplotlib is due.
>>
>> My application is suffering badly from the issue that an incorrect font
>> cache will cause matplotlib to fail (the application mysteriously exits
>> partway through startup until the user deletes the font cache).
>>
>> That problem is allegedly fixed on the trunk and I'm trying to decide
>> how best to deal with it. Depending on the timing of 1.0.1 I can decide
>> whether it's worth putting in my own workaround, bundling a prerelease
>> version of matplotlib or just waiting for the official release.
> I'm not sure what the timeframe is on 1.0.1.
>
> What problem with the cache are you referring to? I'm aware of a
> problem where if some fonts are moved or removed after the cache is
> created matplotlib will crash (and this problem is fixed in the trunk),
> but is that really a problem in everyday practice? I'm just curious --
> if there's another issue with the cache that I'm not aware of, I'd like
> to fix it.
>'
We've been running into problems in Sage that seem to occur because font 
caches from 1.0.0 make old versions of matplotlib die. I haven't seen 
the problem myself, but several Sage developers have put in quite a bit 
of time in diagnosing the problem. In the end, I think they wrote a 
patch to do custom MPLCONFIGDIR for different versions of matplotlib in 
different versions of Sage.
I'm CCing sage-devel, in case one of the sage devs that ran into 
problems wants to comment.
Thanks,
Jason
--
Jason Grout

As I blurted on -users, I'm thinking lately about callbacks in the 
non-GUI portions of the libraries--mostly Artist and subclasses. 
I'm curious if anybody else has been thinking about them?
Ideally, I'd like to see the following:
 All of the Artist subclasses, and anything else that might belong to
a Figure, would be updated to use/add cbook.CallbackRegistry callbacks
(weakref = good thing).
 In addition to emulating/replacing the simplistic 'pchanged' callback 
with a signal of that same name, there would be a signal named after each 
setter method, and said methods fire off their eponymous signal after they 
modify the property.
 There should be some way to rate-limit or temporarily block individual 
signals or callback connections.
 The various constructors, etc, would be modified to "subscribe" to 
the 'pchanged' signal of all children, such that even if a particular 
object in the "middle" of a figure heirarchy does nothing with the 
signal, a sort of a global 'pchanged' signal propagates up to the top 
object (FigureManager, Canvas, Figure, something).
My current Use Case for these features is in experimenting with different 
Artist styles (Text styles/fonts, marker styles/sizes, etc), and I'm tired 
of calling canvas.draw() all the time :) But also, I'm working on a 
GUI to do the same (traits UI), and want to tie both layers of the model 
together with callbacks to speed up the experimenting.
I've spent a few hours this weekend doing some meta-monkey-patching--
using __getattribute__ to decorate the setters on-the-fly to invoke 
callbacks.process(*args) after the changes. I have a few more quick 
hacks to try before I'm ready to decide on a production-ready strategy.
So my question today is: is anyone interested in discussing these 
ideas and how to implement them?
Thanks...

On Sat, Oct 23, 2010 at 1:37 PM, Kynn Jones <ky...@gm...> wrote:
> I came across this Python syntax bug in matplotlib.figure.add_subplot:
>           raise ValueError(
>             "polar=True, yet projection='%s'. " +
>             "Only one of these arguments should be supplied." %
>             projection)
> If that code ever executes it will fail with "TypeError: not all arguments
> converted during string formatting".
> It's trivial to fix, of course, (just delete the '+') but I don't know how
> to submit a patch. Could someone please show me?
Good catch. I can make the change if you want. However, if you want to
use as a learning experience, first make a copy of the original file,
say figure.py.orig. Then make the changes to your figure.py. Then you
need to run diff:
diff -u figure.py.orig figure.py > patchname.diff
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

The Sage developers have found two issues with MPLCONFIGDIR:
 - First, when upgrading from version 0.99.3 to 1.0.0, the contents of
that directory seem to cause compatibility problems. That is, once
you upgrade to a version of Sage using 1.0.0, it overwrites whatever
was in that directory, and then you get errors when using an older
version of Sage which still uses 0.99.3. See
<http://trac.sagemath.org/sage_trac/ticket/9221#comment:82> for an
example of the sort of error which arises, and see
<http://trac.sagemath.org/sage_trac/ticket/6235> for our fix: in Sage,
we set MPLCONFIGDIR to different directories based on the version of
matplotlib.
 - Second, the following code in matplotlib/texmanager.py can cause a
race condition when creating MPLCONFIGDIR:
 if not os.path.exists(texcache):
 os.mkdir(texcache)
In particular, when running doctests for Sage, if MPLCONFIGDIR doesn't
exist, two different doctests can try to create it at the same time,
causing a problem. (I've also heard people suggest that these sort of
race conditions can be security issues, but I don't know about the
validity of this.) See
<http://trac.sagemath.org/sage_trac/ticket/10159> for our fix: we
replace those lines by
 try:
 os.mkdir(texcache)
 except OSError, e:
 assert e.errno==errno.EEXIST, 'Cannot create %s.' % texcache
(and also add "import errno" at the beginning of the file).
I'd be happy to hear any comments you might have about these.
-- 
John Palmieri

I came across this Python syntax bug in matplotlib.figure.add_subplot:
 raise ValueError(
 "polar=True, yet projection='%s'. " +
 "Only one of these arguments should be supplied." %
 projection)
If that code ever executes it will fail with "TypeError: not all arguments
converted during string formatting".
It's trivial to fix, of course, (just delete the '+') but I don't know how
to submit a patch. Could someone please show me?
TIA!
~kj

On Fri, Oct 22, 2010 at 7:16 PM, Michael Droettboom <md...@st...> wrote:
> On 10/22/2010 05:45 PM, Russell E. Owen wrote:
>> I'm curious when the next release of matplotlib is due.
>>
>> My application is suffering badly from the issue that an incorrect font
>> cache will cause matplotlib to fail (the application mysteriously exits
>> partway through startup until the user deletes the font cache).
>>
>> That problem is allegedly fixed on the trunk and I'm trying to decide
>> how best to deal with it. Depending on the timing of 1.0.1 I can decide
>> whether it's worth putting in my own workaround, bundling a prerelease
>> version of matplotlib or just waiting for the official release.
> I'm not sure what the timeframe is on 1.0.1.
I would be happy to do a release early next week. Is anyone aware of
any show stopper bugs that need to be fixed first? I had hoped to do
it last week ahead of the ETS release, but simply did not get to it.
> What problem with the cache are you referring to? I'm aware of a
> problem where if some fonts are moved or removed after the cache is
> created matplotlib will crash (and this problem is fixed in the trunk),
> but is that really a problem in everyday practice? I'm just curious --
> if there's another issue with the cache that I'm not aware of, I'd like
> to fix it.
I used to see font cache problems when testing and/or doc building for
a 0.99 branch release on a machine which had been running 1.0svn
trunk. I can't replicate it now, so perhaps it is fixed (though I
have only tried reverting the install and making plots, not doing full
doc builds). The only commit related to the cache since the 1.0
release that I see is
 r8712 | mdboom | 2010年09月21日 16:13:25 -0400 (2010年9月21日) | 2 lines
 If a font file is looked up in the cache, but that font file no longer exists
 on disk, rebuild the cache.
Not sure why this would caused a failure in the case of going from 1.0
to 0.99 ...
Russell, a good solution for you, not just for this particular
problem, but in general, is to use MPLCONFIGDIR in your application.
This will give you a custom location for your rc file, font cache,
etc.... We use it on the buildbots which are running multiple
installations of mpl to avoid clashes.
Hope this helps,
JDH

 On 10/22/2010 05:45 PM, Russell E. Owen wrote:
> I'm curious when the next release of matplotlib is due.
>
> My application is suffering badly from the issue that an incorrect font
> cache will cause matplotlib to fail (the application mysteriously exits
> partway through startup until the user deletes the font cache).
>
> That problem is allegedly fixed on the trunk and I'm trying to decide
> how best to deal with it. Depending on the timing of 1.0.1 I can decide
> whether it's worth putting in my own workaround, bundling a prerelease
> version of matplotlib or just waiting for the official release.
I'm not sure what the timeframe is on 1.0.1.
What problem with the cache are you referring to? I'm aware of a 
problem where if some fonts are moved or removed after the cache is 
created matplotlib will crash (and this problem is fixed in the trunk), 
but is that really a problem in everyday practice? I'm just curious -- 
if there's another issue with the cache that I'm not aware of, I'd like 
to fix it.
Mike
> Regards,
>
> -- Russell
>
> P.S. does anyone know a way to get maplotlib to either not use its font
> cache or to use a version in mpl-data instead of ~/.matplotlib? When
> matplotlib is bundled into an application it seems dangerous for it to
> be sharing cached files with potentially older or newer versions that
> are installed or are bundled with other applications.
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps& games for the Nokia N8 for consumers in U.S. and Canada
> 10ドル million total in prizes - 4ドルM cash, 500 devices, nearly 6ドルM in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I need to generate a fairly complex chart, for which I need the ability to
specify not only subplots, but also sub-subplots, and even
sub-sub-sub-plots. (Our group has found such charts useful in the past, but
they were generated using horrific MATLAB code.)
I'll try to describe what I want to do in a bit more detail (it's messy).
First imagine a simple plot (just a simple X-Y line graph connecting 3-4
datapoints). I'll call this a level-0 plot. Now, join ~10 of these level-0
plots side-by-side (with no space between the plots). This new aggregate is
a level-1 plot. Next stack ~10 level-1 plots vertically, again, with no
space between them. The resulting aggregate is a level-2 plot. Finally
arrange ~10 of these level-2 plots side-by-side, with some spacing between
them. The desired final product is this level-3 plot.
Without knowing much about the internals of matplotlib, it seems to me that
the best way to do this would be to define a container class that can have
itself as one of the contained elements. In this way, a containment
hierarchy of arbitrary depth could be defined. But it is my understanding
that there is no immediate way to do this in matplotlib now, so I'd have to
implement it myself.
I could use some guidance to the source code.
What I need to clarify is the following. First consider some simple plot A:
it has axes, data points, tick marks, labels, etc., and for all these
elements there are associated absolute x-y coordinates on the canvas. If
now we make this plot A one of the subplots in a collection of, say, 12
subplots, arranged as 3 rows of 4 subplots each, all the x-y coordinates
associated with the original plot A will have to be translated and scaled,
so that the subplot lands in the right place on the canvas, and has the
appropriate size. This process of translation and scaling is what I want to
pinpoint: What exactly is the connection between running the add_subplot
method and the translation+scaling that it entails?
What would be a good entry point for me to answer the questions above by
reading the source code?
TIA!
~kj

I'm curious when the next release of matplotlib is due.
My application is suffering badly from the issue that an incorrect font 
cache will cause matplotlib to fail (the application mysteriously exits 
partway through startup until the user deletes the font cache).
That problem is allegedly fixed on the trunk and I'm trying to decide 
how best to deal with it. Depending on the timing of 1.0.1 I can decide 
whether it's worth putting in my own workaround, bundling a prerelease 
version of matplotlib or just waiting for the official release.
Regards,
-- Russell
P.S. does anyone know a way to get maplotlib to either not use its font 
cache or to use a version in mpl-data instead of ~/.matplotlib? When 
matplotlib is bundled into an application it seems dangerous for it to 
be sharing cached files with potentially older or newer versions that 
are installed or are bundled with other applications.

In article <1A0...@ni...>,
 Paul Kienzle <pau...@ni...> wrote:
> Note a small issue on the install of matplotlib-1.0.0 python 2.6 mac 
> dmg.
> 
> The files in mpl-data/images were not installed with read permissions 
> for all.
> 
> This resulted in an error that _cidgcf was not a valid attribute in 
> FigureManager.
> 
> This affected one 10.5 machine but not another --- we have no idea why.
> 
> - Paul
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
I produced these binaries and unfortunately ran into a number of 
problems including:
- Incorrect file permissions (an odd bug in bdist_mpkg) subsequently 
fixed with a new binary
- The binary was not compatible with Mac OS X 10.3.9 and 10.4 for 
reasons I still have not worked out.
- The Python 2.5 binary is not compatible with 3rd party Tkinter (which 
is also true of the python.org Python 2.5). I no longer make binaries 
for Python 2.5 because of this.
I finally built binaries on Mac OS X 10.4 (fixing the file permissions 
along the way) and these are available here:
<http://www.astro.washington.edu/users/rowen/python/>
they are not yet being served at the official site.
I have done some testing of TkAgg on 10.3.9 PPC, and 10.4-10.6 Intel, 
but after all the problems I would appreciate any testing. The 2.6 
version should become the official binary, but only after more 
verification.
The 2.7 is quite experimental because I don't yet have any idea if WxAgg 
works (it all depends on whether the wxPython installer for Mac Python 
2.7 is compatible with the 32-bit version of Python 2.7).
-- Russell

On Thu, Oct 21, 2010 at 11:43 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Gökhan Sever <gok...@gm...> writes:
>
>> Please see the screenshot at
>> http://img225.imageshack.us/img225/1052/legendposition.png
>
> Can you make a self-contained test case?
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
Hi Jouni,
I have 4 simple test cases now. Please see
http://gandalf.aero.und.edu/~gsever/pdf_tests/ for the script and
saved png-pdf files.
Using Qt4Agg and xpdf as distiller as I previously noted.
Case 1:
With legend frame. Legend position is slightly different on screen and
saved files.
Note also I adjust subplot positions.
Case 2:
Without legend frame. Same as Case 1. (Using default adjustment)
Case 3:
With legend frame. Using "Test Data1" and "Test Data2" as legend text.
Case 1 results still hold. Plus relative text position within legend
frame is different in png and pdf files. (Subplots adjusted)
Case 4:
Using "Test Data1" and "Test Data2" as legend text. Case 1 results
apply. Again there is minute difference between text positions in PDF
and PNG files.
Hope these are all clear, and reproducible on your side. Let me know
how it goes on your side.
Thanks.
-- 
Gökhan

On Fri, Oct 22, 2010 at 6:07 AM, Patrick Sauer <pat...@gm...> wrote:
> Hi,
>
> I am using matplotlib in a pyqt application, in which I am displaying an
> image on a FigureCanvas. My installation is Ubuntu 10.04-64bit.
> This has been working like a charm for several months but recently my
> application has started crashing with the following trace:
>
> File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_qt4agg.py",
> line 83, in paintEvent
>   FigureCanvasAgg.draw(self)
>  File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_agg.py",
> line 314, in draw
>   self.figure.draw(self.renderer)
>  File "/usr/lib/pymodules/python2.6/matplotlib/artist.py", line 46, in
> draw_wrapper
>   draw(artist, renderer, *kl)
>  File "/usr/lib/pymodules/python2.6/matplotlib/figure.py", line 773, in
> draw
>   for a in self.axes: a.draw(renderer)
>  File "/usr/lib/pymodules/python2.6/matplotlib/artist.py", line 46, in
> draw_wrapper
>   draw(artist, renderer, *kl)
>  File "/usr/lib/pymodules/python2.6/matplotlib/axes.py", line 1701, in draw
>   im.draw(renderer)
>  File "/usr/lib/pymodules/python2.6/matplotlib/artist.py", line 46, in
> draw_wrapper
>   draw(artist, renderer, *kl)
>  File "/usr/lib/pymodules/python2.6/matplotlib/image.py", line 237, in draw
>   im = self.make_image(renderer.get_image_magnification())
>  File "/usr/lib/pymodules/python2.6/matplotlib/image.py", line 182, in
> make_image
>   x = self.to_rgba(self._A, self._alpha)
>  File "/usr/lib/pymodules/python2.6/matplotlib/cm.py", line 166, in to_rgba
>   x = self.norm(x)
>  File "/usr/lib/pymodules/python2.6/matplotlib/colors.py", line 763, in
> __call__
>   elif vmin==vmax:
>  File "/usr/lib/python2.6/dist-packages/numpy/ma/core.py", line 3119, in
> __eq__
>   check._mask = mask
> AttributeError: 'numpy.bool_' object has no attribute '_mask'
>
>
> Strangely the bug seems to be intermittent, i.e. rebooting seems to
> temporarily fix the issue, but it always returns.
> Is this a known issue? Could I somehow fix this by reverting some of the
> Ubuntu packages to older versions?
No idea, but if you post a complete, minimal example that reproduces
the problem, the odds of a developer fixing it are much higher.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
I am using matplotlib in a pyqt application, in which I am displaying an
image on a FigureCanvas. My installation is Ubuntu 10.04-64bit.
This has been working like a charm for several months but recently my
application has started crashing with the following trace:
 File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_qt4agg.py",
line 83, in paintEvent
 FigureCanvasAgg.draw(self)
 File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_agg.py",
line 314, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/pymodules/python2.6/matplotlib/artist.py", line 46, in
draw_wrapper
 draw(artist, renderer, *kl)
 File "/usr/lib/pymodules/python2.6/matplotlib/figure.py", line 773, in
draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/pymodules/python2.6/matplotlib/artist.py", line 46, in
draw_wrapper
 draw(artist, renderer, *kl)
 File "/usr/lib/pymodules/python2.6/matplotlib/axes.py", line 1701, in draw
 im.draw(renderer)
 File "/usr/lib/pymodules/python2.6/matplotlib/artist.py", line 46, in
draw_wrapper
 draw(artist, renderer, *kl)
 File "/usr/lib/pymodules/python2.6/matplotlib/image.py", line 237, in draw
 im = self.make_image(renderer.get_image_magnification())
 File "/usr/lib/pymodules/python2.6/matplotlib/image.py", line 182, in
make_image
 x = self.to_rgba(self._A, self._alpha)
 File "/usr/lib/pymodules/python2.6/matplotlib/cm.py", line 166, in to_rgba
 x = self.norm(x)
 File "/usr/lib/pymodules/python2.6/matplotlib/colors.py", line 763, in
__call__
 elif vmin==vmax:
 File "/usr/lib/python2.6/dist-packages/numpy/ma/core.py", line 3119, in
__eq__
 check._mask = mask
AttributeError: 'numpy.bool_' object has no attribute '_mask'
Strangely the bug seems to be intermittent, i.e. rebooting seems to
temporarily fix the issue, but it always returns.
Is this a known issue? Could I somehow fix this by reverting some of the
Ubuntu packages to older versions?
Thanks.
Patrick

Gökhan Sever <gok...@gm...> writes:
> Please see the screenshot at
> http://img225.imageshack.us/img225/1052/legendposition.png
Can you make a self-contained test case?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hello,
Please see the screenshot at
http://img225.imageshack.us/img225/1052/legendposition.png
Although the visible difference is minor, I get slightly shifted
legend positions on screen
 (and saving as png) and in pdf file. This required me to make manual
adjustments (change
axes vertical distance to position the legend) to look good on both
screen and in the pdf.
You can also see my ultra-fine precision legend positioning on these lines:
f06leg = f06.legend((l1, l2), ("Air", "Dew Point"), loc='lower
center', ncol=2, columnspacing=1.0,\
 handletextpad=0.3, handlelength=2.3,
bbox_to_anchor = (0.243, 0.785))
Using qt4agg and xpdf as pdfdistiller on rev8757.
-- 
Gökhan

I checked the data (I can't send it, sorry), and it seems that the problem is given by the presence of not-a-numbers in the array. In the workaraound version, the nan are at the end, and that solves the problem.
Shouldn't fill_between get rid of the nans?
----- Start Original Message -----
Sent: 2010年10月20日 09:03:36 -0500
From: John Hunter <jd...@gm...>
To: g.p...@ru...
Subject: Re: [matplotlib-devel] Bug (?) in fill_between
> On Wed, Oct 20, 2010 at 8:43 AM, Giovanni Plantageneto
> <g.p...@ru...> wrote:
> > Hi,
> >
> > I think I found a bug in the command fill_between().
> > If I try to make a fill_between plot on an x-axis that spans both negative and positive values (and only in that case), I have some funny results.
> > I attach the code that gives the wrong result, the workaround I use, and their output.
> 
> 
> Can you post a complete free-standing example that replicates the problem?
----- End Original Message -----