matplotlib-devel Mailing List for matplotlib

On Tue, Aug 31, 2010 at 1:55 PM, Ondrej Certik <on...@ce...> wrote:
> Ok, I'll give it a shot then.
As I mentioned elsewhere, getting it going is a bit rough right now.
So unless you really want to play with real bleeding edge code, give
us a couple of weeks. It will be much nicer then.
Cheers,
f

On Tue, Aug 31, 2010 at 1:25 PM, Fernando Perez <fpe...@gm...> wrote:
> On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik <on...@ce...> wrote:
>>
>> That'd be great. I think I either want to use regular terminal, or a
>> worksheet in the browser.
>
> You may change your mind when you start playing with the new Qt
> terminal :) It feels very much like a terminal, except with a ton of
> little useful touches that make it very effective. It still has a lot
> of rough edges, but Evan has done a phenomenal job there. I'm now
> using it as my regular ipython instead of the normal one, dogfooding
> enough that we hit all the key usability quirks quickly, and act on
> them.
Ok, I'll give it a shot then.
Ondrej

On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik <on...@ce...> wrote:
>
> That'd be great. I think I either want to use regular terminal, or a
> worksheet in the browser.
You may change your mind when you start playing with the new Qt
terminal :) It feels very much like a terminal, except with a ton of
little useful touches that make it very effective. It still has a lot
of rough edges, but Evan has done a phenomenal job there. I'm now
using it as my regular ipython instead of the normal one, dogfooding
enough that we hit all the key usability quirks quickly, and act on
them.
Cheers,
f

On Mon, Aug 30, 2010 at 9:59 PM, Fernando Perez <fpe...@gm...> wrote:
> On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root <ben...@ou...> wrote:
>> Dude, that just blew my mind!
>>
>
> Glad you like it :)
>
> And needless to say, once the dust settles and someone is willing, the
> obvious thing to do is to put a zeromq-http bridge and make a web
> browser-based client, so you can use ipython/matplotlib from your
> android/iphone/netbook/whatever.
>
> We've been scrupulously careful not to introduce any python
> assumptions client-side, so that in principle frontends can be written
> in any language or toolkit (e.g. html/javascript), the entire system
> is specified by its messaging protocol:
>
> http://ipython.scipy.org/doc/nightly/html/development/messaging.html
That'd be great. I think I either want to use regular terminal, or a
worksheet in the browser.
Ondrej

> 1. Our networking event loop that is based on zeromq/pyzmq
> 2. A single GUI event loop from wx, qt4, etc.
> 
> We do this by triggering an iteration of our networking
> event loop on a periodic GUI timer.
So right now you're in a loop in which you let qt4 (or wx) watch the file descriptors qt4 needs, then zeromq the file descriptors that zeromq needs, and so on?
Just use the qt4 event loop to watch both the file descriptors zeromq wants to watch, in addition to whatever events qt4 needs. Qt4 already has the API that allows you to do this (QSocketNotifier et al.). I am not familiar with zeromq, but if there is a way to determine which file descriptors it wants to watch then you're almost done. If not, you could discuss this with the zeromq developers. Then you won't need to poll, you'll get better response times, and the code will be scalable too.
Best,
--Michiel.
 

On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root <ben...@ou...> wrote:
> Dude, that just blew my mind!
>
> Awesome idea!
By the way, I don't know if it was clear, but this wasn't just an
idea, it's already implemented:
http://fperez.org/tmp/ip-multiclient.png
The two windows are talking to the same kernel, the one at the top
issues the plot command, and the one at the bottom then just does
'show()' and it gets the same figure. Notice how they share a global
prompt counter, since that number lives kernel-side.
They're both on the same computer, but it makes no difference if they
run on different hosts.
This isn't anywhere near production-quality yet, but it does work.
We're busy finishing the core pieces so we can spend some time
polishing it for user testing.
Cheers,
f

Is there any development in this project. I was searching for the ways to
change the subplot sizes, but could not find any easy or nicer way. 
-- 
View this message in context: http://old.nabble.com/Custom-sized-and-spanning-subplots-tp20485188p29580203.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root <ben...@ou...> wrote:
> Dude, that just blew my mind!
>
Glad you like it :)
And needless to say, once the dust settles and someone is willing, the
obvious thing to do is to put a zeromq-http bridge and make a web
browser-based client, so you can use ipython/matplotlib from your
android/iphone/netbook/whatever.
We've been scrupulously careful not to introduce any python
assumptions client-side, so that in principle frontends can be written
in any language or toolkit (e.g. html/javascript), the entire system
is specified by its messaging protocol:
http://ipython.scipy.org/doc/nightly/html/development/messaging.html
Regards,
f

import matplotlib.pyplot as plt
fig = plt.figure()
txt = fig.text(0.5, 0.5, 'sometext', ha='center', va='center', 
 family='Liberation Sans')
fig.savefig('mpl-eps-liberation-nospace.eps')
txt.set_text('some text')
fig.savefig('mpl-eps-liberation-space.eps')
txt.set_text(u'some\u00A0text')
fig.savefig('mpl-eps-liberation-nbspace.eps')

On Mon, Aug 30, 2010 at 7:10 AM, Michiel de Hoon <mjl...@ya...> wrote:
> Hi Brian,
> Thanks for your reply. I agree that integrating multiple event loops is not essential for most users. But if you are not integrating multiple event loops, then why do you need poll?
In the two process kernel we do currently integrate two event loops:
1. Our networking event loop that is based on zeromq/pyzmq
2. A single GUI event loop from wx, qt4, etc.
We do this by triggering an iteration of our networking event loop on
a periodic GUI timer. So we definitely have to face multiple event
loop integration, but it is much simpler when you only have 1 GUi
event loop involved.
Cheers,
Brian
> Best,
> --Michiel.
>
>
> --- On Sun, 8/29/10, Brian Granger <ell...@gm...> wrote:
>
>> From: Brian Granger <ell...@gm...>
>> Subject: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
>> To: "Michiel de Hoon" <mjl...@ya...>
>> Cc: mat...@li..., "IPython Development list" <ipy...@sc...>, ent...@en..., "Evan Patterson" <epa...@en...>
>> Date: Sunday, August 29, 2010, 3:24 PM
>> On Sat, Aug 28, 2010 at 8:12 PM,
>> Michiel de Hoon <mjl...@ya...>
>> wrote:
>> > I implemented an event loop in the MacOSX backend and
>> the PyOS_ImportHook event loop in PyGTK, so I've been
>> interested in this topic.
>>
>> Yes, and you were quite helpful last summer when i was
>> trying to
>> understand the PyOS_InputHook logic. I appreciated that
>> greatly!
>>
>> > If I understand guisupport.py correctly, IPython runs
>> the backend-specific event loop. Have you considered to
>> implement an event loop in IPython and to run that instead
>> of a backend-specific event loop? Then you won't have to
>> iterate the event loop, and you can run multiple GUI
>> backends (PyGTK, PyQT, Tkinter, ...) at the same time. The
>> latter may work with the current guisupport.py, but is
>> fragile, because running one of the backend-specific event
>> loops may inadvertently run code from a different backend.
>>
>> Yes, we do run the native event loops of the GUI toolkit
>> requested.
>> There are a few reasons we haven't gone the direction you
>> are
>> mentioning (although it has crossed our minds):
>>
>> 1. We are not *that* passionate about GUI event
>> loops. I would say
>> our philosophy with event loops is "the simplest solution
>> possible
>> that is robust."
>> 2. While it might be nice to be able to run multiple
>> event loops, in
>> most cases users can survive fine without this
>> feature. This is
>> especially true with more and more people migrating to Qt
>> because of
>> the license change.
>> 3. We are just barely at the point of getting the new
>> PyOS_InputHook
>> and two process kernel GUI support working robustly with
>> matplotlib/traits/mayavi/etc. It is an 2xNxMxP
>> testing nightmare with
>> 2 ways IPython can run the event loop x N toolkits x M
>> projects x P
>> platforms. Simply installing all possible
>> combinations would probably
>> take a couple of weeks time, let alone debugging it
>> all. I envy
>> matlab developers that simple have to test their plotting
>> on a few
>> platforms. We will be lucky to cover
>> matplotlib/traits/mayavi on just
>> qt4/wx on Mac/Linux/windows for the 0.11 release.
>> 4. Integrating multiple event loops is either 1)
>> super subtle and
>> difficult (if you actually start all the event loops
>> involved) or 2)
>> tends to create solutions that busy poll or consume
>> non-trivial CPU
>> power. The wx based PyOS_Inputhook and our two
>> process GUI support
>> are already great examples of this. We have to work
>> pretty hard to
>> create things that are responsive but that don't consume
>> 100% of the
>> CPU. To reduce the CPU usage of the wx PyOS_InputHook
>> we actually
>> dynamically scale back the polling time depending on how
>> often the
>> user is triggering GUI events.
>> 5. It is not just about integrating GUI event
>> loops. We also have
>> multiple other event loops in our apps that handle
>> networking.
>>
>> Cheers,
>>
>> Brian
>>
>>
>> > --Michiel.
>> >
>> > --- On Sat, 8/28/10, Brian Granger <ell...@gm...>
>> wrote:
>> >
>> >> From: Brian Granger <ell...@gm...>
>> >> Subject: [matplotlib-devel] Uniform GUI support
>> across matplotlib, ets and ipython
>> >> To: mat...@li...,
>> "IPython Development list" <ipy...@sc...>,
>> ent...@en...,
>> "Evan Patterson" <epa...@en...>
>> >> Date: Saturday, August 28, 2010, 3:42 PM
>> >> Hi all,
>> >>
>> >> As you may know, this summer we have been
>> working on
>> >> a new two
>> >> process IPython that has a beautiful Qt frontend
>> GUI and a
>> >> ZMQ based
>> >> messaging layer between that GUI and the new
>> IPython
>> >> kernel. Many
>> >> thanks to Enthought for funding this effort!
>> >>
>> >> We are currently in the process of adding GUI
>> event loop
>> >> integration
>> >> to the ipython kernel so users can do interactive
>> plotting
>> >> like they
>> >> can with the regular ipython. You may also
>> remember
>> >> that last summer
>> >> we implemented a new PyOs_InputHook based GUI
>> integration
>> >> for the
>> >> regular ipython. This has not been released yet,
>> but
>> >> all of this will
>> >> be released in the upcoming 0.11 release.
>> >>
>> >> I am emailing everyone because we see that there
>> is a need
>> >> for all of
>> >> us to agree on two things:
>> >>
>> >> 1. How to detect if a GUI application object has
>> been
>> >> created by someone else.
>> >> 2. How to detect if a GUI event loop is
>> running.
>> >>
>> >> Currently there is code in both ETS and matplotlib
>> that
>> >> fails to
>> >> handle these things properly in certain cases.
>> With
>> >> IPython 0.10,
>> >> this was not a problem because we used to
>> >> hijack/monkeypatch the GUI
>> >> eventloops after we started them. In 0.11, we
>> will no
>> >> longer be doing
>> >> that. To address these issues, we have created
>> a
>> >> standalone module
>> >> that implements the needed logic:
>> >>
>> >> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
>> >>
>> >> This module is heavily commented and introduces a
>> new
>> >> informal
>> >> protocol that all of use can use to detect if
>> event
>> >> loops are
>> >> running. This informal protocol is inspired by
>> how
>> >> some of this is
>> >> handled inside ETS. Our idea is that all
>> projects
>> >> will simply copy
>> >> this module into their code and ship it. It is
>> >> lightweight and does
>> >> not depend on IPython or other top-level
>> imports. As
>> >> you will see, we
>> >> have implemented the logic for wx and qt4, we will
>> need
>> >> help with
>> >> other toolkits. An important point is that
>> matplotlib
>> >> and ets WILL
>> >> NOT WORK with the upcoming release of IPython
>> unless
>> >> changes are made
>> >> to their respective codebases. We consider this
>> a
>> >> draft and are more
>> >> than willing to modify the design or approach as
>> >> appropriate. One
>> >> thing that we have not thought about yet is how to
>> continue
>> >> to support
>> >> 0.10 within this model.
>> >>
>> >> The good news amidst all of this is that the
>> quality and
>> >> stability of
>> >> the GUI support in IPython is orders of magnitude
>> better
>> >> than that in
>> >> the 0.10 series.
>> >>
>> >> Cheers,
>> >>
>> >> Brian
>> >>
>> >> PS: If you are curious, here is a bit of
>> background
>> >> on the issues
>> >> related to the PyOS_Inputhook stuff:
>> >>
>> >> http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> Sell apps to millions through the Intel(R)
>> Atom(Tm)
>> >> Developer Program
>> >> Be part of this innovative community and reach
>> millions of
>> >> netbook users
>> >> worldwide. Take advantage of special opportunities
>> to
>> >> increase revenue and
>> >> speed time-to-market. Join now, and jumpstart your
>> future.
>> >> http://p.sf.net/sfu/intel-atom-d2d
>> >> _______________________________________________
>> >> Matplotlib-devel mailing list
>> >> Mat...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Brian E. Granger, Ph.D.
>> Assistant Professor of Physics
>> Cal Poly State University, San Luis Obispo
>> bgr...@ca...
>> ell...@gm...
>>
>
>
>
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

On Mon, Aug 30, 2010 at 2:21 AM, Fernando Perez <fpe...@gm...>wrote:
> Hi Eric,
>
> On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing <ef...@ha...> wrote:
> >
> > Impressive--but I don't think I understand why one would want plots
> rendered
> > inline rather than in separate windows.
>
> It's not 'rather than', it's 'in addition to' :) Imagine you and I
> are working on a problem together, you have IPython open and you get
> the plot windows on your desk. You'd like to discuss something about
> the data with me (I'm away in California, not at your desk), so I open
> an IPython client that connects to your kernel, and start getting on
> my frontend the static versions of all the plots. You have the full
> windows on your desktop which zoom and pan, but with a simple 'show()'
> I can get static snapshots of all the figures on my desk, while we
> both work with and control the same kernel.
>
> That could be useful, no?
>
> Regards,
>
> f
>
>
Dude, that just blew my mind!
Awesome idea!
Ben Root

Hi Brian,
Thanks for your reply. I agree that integrating multiple event loops is not essential for most users. But if you are not integrating multiple event loops, then why do you need poll?
Best,
--Michiel.
--- On Sun, 8/29/10, Brian Granger <ell...@gm...> wrote:
> From: Brian Granger <ell...@gm...>
> Subject: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: mat...@li..., "IPython Development list" <ipy...@sc...>, ent...@en..., "Evan Patterson" <epa...@en...>
> Date: Sunday, August 29, 2010, 3:24 PM
> On Sat, Aug 28, 2010 at 8:12 PM,
> Michiel de Hoon <mjl...@ya...>
> wrote:
> > I implemented an event loop in the MacOSX backend and
> the PyOS_ImportHook event loop in PyGTK, so I've been
> interested in this topic.
> 
> Yes, and you were quite helpful last summer when i was
> trying to
> understand the PyOS_InputHook logic. I appreciated that
> greatly!
> 
> > If I understand guisupport.py correctly, IPython runs
> the backend-specific event loop. Have you considered to
> implement an event loop in IPython and to run that instead
> of a backend-specific event loop? Then you won't have to
> iterate the event loop, and you can run multiple GUI
> backends (PyGTK, PyQT, Tkinter, ...) at the same time. The
> latter may work with the current guisupport.py, but is
> fragile, because running one of the backend-specific event
> loops may inadvertently run code from a different backend.
> 
> Yes, we do run the native event loops of the GUI toolkit
> requested.
> There are a few reasons we haven't gone the direction you
> are
> mentioning (although it has crossed our minds):
> 
> 1. We are not *that* passionate about GUI event
> loops. I would say
> our philosophy with event loops is "the simplest solution
> possible
> that is robust."
> 2. While it might be nice to be able to run multiple
> event loops, in
> most cases users can survive fine without this
> feature. This is
> especially true with more and more people migrating to Qt
> because of
> the license change.
> 3. We are just barely at the point of getting the new
> PyOS_InputHook
> and two process kernel GUI support working robustly with
> matplotlib/traits/mayavi/etc. It is an 2xNxMxP
> testing nightmare with
> 2 ways IPython can run the event loop x N toolkits x M
> projects x P
> platforms. Simply installing all possible
> combinations would probably
> take a couple of weeks time, let alone debugging it
> all. I envy
> matlab developers that simple have to test their plotting
> on a few
> platforms. We will be lucky to cover
> matplotlib/traits/mayavi on just
> qt4/wx on Mac/Linux/windows for the 0.11 release.
> 4. Integrating multiple event loops is either 1)
> super subtle and
> difficult (if you actually start all the event loops
> involved) or 2)
> tends to create solutions that busy poll or consume
> non-trivial CPU
> power. The wx based PyOS_Inputhook and our two
> process GUI support
> are already great examples of this. We have to work
> pretty hard to
> create things that are responsive but that don't consume
> 100% of the
> CPU. To reduce the CPU usage of the wx PyOS_InputHook
> we actually
> dynamically scale back the polling time depending on how
> often the
> user is triggering GUI events.
> 5. It is not just about integrating GUI event
> loops. We also have
> multiple other event loops in our apps that handle
> networking.
> 
> Cheers,
> 
> Brian
> 
> 
> > --Michiel.
> >
> > --- On Sat, 8/28/10, Brian Granger <ell...@gm...>
> wrote:
> >
> >> From: Brian Granger <ell...@gm...>
> >> Subject: [matplotlib-devel] Uniform GUI support
> across matplotlib, ets and ipython
> >> To: mat...@li...,
> "IPython Development list" <ipy...@sc...>,
> ent...@en...,
> "Evan Patterson" <epa...@en...>
> >> Date: Saturday, August 28, 2010, 3:42 PM
> >> Hi all,
> >>
> >> As you may know, this summer we have been
> working on
> >> a new two
> >> process IPython that has a beautiful Qt frontend
> GUI and a
> >> ZMQ based
> >> messaging layer between that GUI and the new
> IPython
> >> kernel. Many
> >> thanks to Enthought for funding this effort!
> >>
> >> We are currently in the process of adding GUI
> event loop
> >> integration
> >> to the ipython kernel so users can do interactive
> plotting
> >> like they
> >> can with the regular ipython. You may also
> remember
> >> that last summer
> >> we implemented a new PyOs_InputHook based GUI
> integration
> >> for the
> >> regular ipython. This has not been released yet,
> but
> >> all of this will
> >> be released in the upcoming 0.11 release.
> >>
> >> I am emailing everyone because we see that there
> is a need
> >> for all of
> >> us to agree on two things:
> >>
> >> 1. How to detect if a GUI application object has
> been
> >> created by someone else.
> >> 2. How to detect if a GUI event loop is
> running.
> >>
> >> Currently there is code in both ETS and matplotlib
> that
> >> fails to
> >> handle these things properly in certain cases. 
> With
> >> IPython 0.10,
> >> this was not a problem because we used to
> >> hijack/monkeypatch the GUI
> >> eventloops after we started them. In 0.11, we
> will no
> >> longer be doing
> >> that. To address these issues, we have created
> a
> >> standalone module
> >> that implements the needed logic:
> >>
> >> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
> >>
> >> This module is heavily commented and introduces a
> new
> >> informal
> >> protocol that all of use can use to detect if
> event
> >> loops are
> >> running. This informal protocol is inspired by
> how
> >> some of this is
> >> handled inside ETS. Our idea is that all
> projects
> >> will simply copy
> >> this module into their code and ship it. It is
> >> lightweight and does
> >> not depend on IPython or other top-level
> imports. As
> >> you will see, we
> >> have implemented the logic for wx and qt4, we will
> need
> >> help with
> >> other toolkits. An important point is that
> matplotlib
> >> and ets WILL
> >> NOT WORK with the upcoming release of IPython
> unless
> >> changes are made
> >> to their respective codebases. We consider this
> a
> >> draft and are more
> >> than willing to modify the design or approach as
> >> appropriate. One
> >> thing that we have not thought about yet is how to
> continue
> >> to support
> >> 0.10 within this model.
> >>
> >> The good news amidst all of this is that the
> quality and
> >> stability of
> >> the GUI support in IPython is orders of magnitude
> better
> >> than that in
> >> the 0.10 series.
> >>
> >> Cheers,
> >>
> >> Brian
> >>
> >> PS: If you are curious, here is a bit of
> background
> >> on the issues
> >> related to the PyOS_Inputhook stuff:
> >>
> >> http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html
> >>
> >>
> ------------------------------------------------------------------------------
> >> Sell apps to millions through the Intel(R)
> Atom(Tm)
> >> Developer Program
> >> Be part of this innovative community and reach
> millions of
> >> netbook users
> >> worldwide. Take advantage of special opportunities
> to
> >> increase revenue and
> >> speed time-to-market. Join now, and jumpstart your
> future.
> >> http://p.sf.net/sfu/intel-atom-d2d
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >
> >
> >
> >
> 
> 
> 
> -- 
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgr...@ca...
> ell...@gm...
> 
 

Hi Eric,
On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing <ef...@ha...> wrote:
>
> Impressive--but I don't think I understand why one would want plots rendered
> inline rather than in separate windows.
It's not 'rather than', it's 'in addition to' :) Imagine you and I
are working on a problem together, you have IPython open and you get
the plot windows on your desk. You'd like to discuss something about
the data with me (I'm away in California, not at your desk), so I open
an IPython client that connects to your kernel, and start getting on
my frontend the static versions of all the plots. You have the full
windows on your desktop which zoom and pan, but with a simple 'show()'
I can get static snapshots of all the figures on my desk, while we
both work with and control the same kernel.
That could be useful, no?
Regards,
f

On Sat, Aug 28, 2010 at 8:12 PM, Michiel de Hoon <mjl...@ya...> wrote:
> I implemented an event loop in the MacOSX backend and the PyOS_ImportHook event loop in PyGTK, so I've been interested in this topic.
Yes, and you were quite helpful last summer when i was trying to
understand the PyOS_InputHook logic. I appreciated that greatly!
> If I understand guisupport.py correctly, IPython runs the backend-specific event loop. Have you considered to implement an event loop in IPython and to run that instead of a backend-specific event loop? Then you won't have to iterate the event loop, and you can run multiple GUI backends (PyGTK, PyQT, Tkinter, ...) at the same time. The latter may work with the current guisupport.py, but is fragile, because running one of the backend-specific event loops may inadvertently run code from a different backend.
Yes, we do run the native event loops of the GUI toolkit requested.
There are a few reasons we haven't gone the direction you are
mentioning (although it has crossed our minds):
1. We are not *that* passionate about GUI event loops. I would say
our philosophy with event loops is "the simplest solution possible
that is robust."
2. While it might be nice to be able to run multiple event loops, in
most cases users can survive fine without this feature. This is
especially true with more and more people migrating to Qt because of
the license change.
3. We are just barely at the point of getting the new PyOS_InputHook
and two process kernel GUI support working robustly with
matplotlib/traits/mayavi/etc. It is an 2xNxMxP testing nightmare with
2 ways IPython can run the event loop x N toolkits x M projects x P
platforms. Simply installing all possible combinations would probably
take a couple of weeks time, let alone debugging it all. I envy
matlab developers that simple have to test their plotting on a few
platforms. We will be lucky to cover matplotlib/traits/mayavi on just
qt4/wx on Mac/Linux/windows for the 0.11 release.
4. Integrating multiple event loops is either 1) super subtle and
difficult (if you actually start all the event loops involved) or 2)
tends to create solutions that busy poll or consume non-trivial CPU
power. The wx based PyOS_Inputhook and our two process GUI support
are already great examples of this. We have to work pretty hard to
create things that are responsive but that don't consume 100% of the
CPU. To reduce the CPU usage of the wx PyOS_InputHook we actually
dynamically scale back the polling time depending on how often the
user is triggering GUI events.
5. It is not just about integrating GUI event loops. We also have
multiple other event loops in our apps that handle networking.
Cheers,
Brian
> --Michiel.
>
> --- On Sat, 8/28/10, Brian Granger <ell...@gm...> wrote:
>
>> From: Brian Granger <ell...@gm...>
>> Subject: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
>> To: mat...@li..., "IPython Development list" <ipy...@sc...>, ent...@en..., "Evan Patterson" <epa...@en...>
>> Date: Saturday, August 28, 2010, 3:42 PM
>> Hi all,
>>
>> As you may know, this summer we have been working on
>> a new two
>> process IPython that has a beautiful Qt frontend GUI and a
>> ZMQ based
>> messaging layer between that GUI and the new IPython
>> kernel. Many
>> thanks to Enthought for funding this effort!
>>
>> We are currently in the process of adding GUI event loop
>> integration
>> to the ipython kernel so users can do interactive plotting
>> like they
>> can with the regular ipython. You may also remember
>> that last summer
>> we implemented a new PyOs_InputHook based GUI integration
>> for the
>> regular ipython. This has not been released yet, but
>> all of this will
>> be released in the upcoming 0.11 release.
>>
>> I am emailing everyone because we see that there is a need
>> for all of
>> us to agree on two things:
>>
>> 1. How to detect if a GUI application object has been
>> created by someone else.
>> 2. How to detect if a GUI event loop is running.
>>
>> Currently there is code in both ETS and matplotlib that
>> fails to
>> handle these things properly in certain cases. With
>> IPython 0.10,
>> this was not a problem because we used to
>> hijack/monkeypatch the GUI
>> eventloops after we started them. In 0.11, we will no
>> longer be doing
>> that. To address these issues, we have created a
>> standalone module
>> that implements the needed logic:
>>
>> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
>>
>> This module is heavily commented and introduces a new
>> informal
>> protocol that all of use can use to detect if event
>> loops are
>> running. This informal protocol is inspired by how
>> some of this is
>> handled inside ETS. Our idea is that all projects
>> will simply copy
>> this module into their code and ship it. It is
>> lightweight and does
>> not depend on IPython or other top-level imports. As
>> you will see, we
>> have implemented the logic for wx and qt4, we will need
>> help with
>> other toolkits. An important point is that matplotlib
>> and ets WILL
>> NOT WORK with the upcoming release of IPython unless
>> changes are made
>> to their respective codebases. We consider this a
>> draft and are more
>> than willing to modify the design or approach as
>> appropriate. One
>> thing that we have not thought about yet is how to continue
>> to support
>> 0.10 within this model.
>>
>> The good news amidst all of this is that the quality and
>> stability of
>> the GUI support in IPython is orders of magnitude better
>> than that in
>> the 0.10 series.
>>
>> Cheers,
>>
>> Brian
>>
>> PS: If you are curious, here is a bit of background
>> on the issues
>> related to the PyOS_Inputhook stuff:
>>
>> http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm)
>> Developer Program
>> Be part of this innovative community and reach millions of
>> netbook users
>> worldwide. Take advantage of special opportunities to
>> increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

I implemented an event loop in the MacOSX backend and the PyOS_ImportHook event loop in PyGTK, so I've been interested in this topic.
If I understand guisupport.py correctly, IPython runs the backend-specific event loop. Have you considered to implement an event loop in IPython and to run that instead of a backend-specific event loop? Then you won't have to iterate the event loop, and you can run multiple GUI backends (PyGTK, PyQT, Tkinter, ...) at the same time. The latter may work with the current guisupport.py, but is fragile, because running one of the backend-specific event loops may inadvertently run code from a different backend.
--Michiel.
--- On Sat, 8/28/10, Brian Granger <ell...@gm...> wrote:
> From: Brian Granger <ell...@gm...>
> Subject: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
> To: mat...@li..., "IPython Development list" <ipy...@sc...>, ent...@en..., "Evan Patterson" <epa...@en...>
> Date: Saturday, August 28, 2010, 3:42 PM
> Hi all,
> 
> As you may know, this summer we have been working on
> a new two
> process IPython that has a beautiful Qt frontend GUI and a
> ZMQ based
> messaging layer between that GUI and the new IPython
> kernel. Many
> thanks to Enthought for funding this effort!
> 
> We are currently in the process of adding GUI event loop
> integration
> to the ipython kernel so users can do interactive plotting
> like they
> can with the regular ipython. You may also remember
> that last summer
> we implemented a new PyOs_InputHook based GUI integration
> for the
> regular ipython. This has not been released yet, but
> all of this will
> be released in the upcoming 0.11 release.
> 
> I am emailing everyone because we see that there is a need
> for all of
> us to agree on two things:
> 
> 1. How to detect if a GUI application object has been
> created by someone else.
> 2. How to detect if a GUI event loop is running.
> 
> Currently there is code in both ETS and matplotlib that
> fails to
> handle these things properly in certain cases. With
> IPython 0.10,
> this was not a problem because we used to
> hijack/monkeypatch the GUI
> eventloops after we started them. In 0.11, we will no
> longer be doing
> that. To address these issues, we have created a
> standalone module
> that implements the needed logic:
> 
> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
> 
> This module is heavily commented and introduces a new
> informal
> protocol that all of use can use to detect if event
> loops are
> running. This informal protocol is inspired by how
> some of this is
> handled inside ETS. Our idea is that all projects
> will simply copy
> this module into their code and ship it. It is
> lightweight and does
> not depend on IPython or other top-level imports. As
> you will see, we
> have implemented the logic for wx and qt4, we will need
> help with
> other toolkits. An important point is that matplotlib
> and ets WILL
> NOT WORK with the upcoming release of IPython unless
> changes are made
> to their respective codebases. We consider this a
> draft and are more
> than willing to modify the design or approach as
> appropriate. One
> thing that we have not thought about yet is how to continue
> to support
> 0.10 within this model.
> 
> The good news amidst all of this is that the quality and
> stability of
> the GUI support in IPython is orders of magnitude better
> than that in
> the 0.10 series.
> 
> Cheers,
> 
> Brian
> 
> PS: If you are curious, here is a bit of background
> on the issues
> related to the PyOS_Inputhook stuff:
> 
> http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm)
> Developer Program
> Be part of this innovative community and reach millions of
> netbook users 
> worldwide. Take advantage of special opportunities to
> increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
 

On 08/28/2010 09:38 AM, Fernando Perez wrote:
> On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing<ef...@ha...> wrote:
>> I committed it.
>>
>
> Many thanks Eric, for being so responsive!
Fernando,
I'm glad to help; ipython is a crucial part of the tool set.
>
> Some eye candy to give you an idea of what we're getting from this work:
>
> http://fperez.org/tmp/multiplot.png
> http://fperez.org/tmp/multiplot2.png
>
> The second is the MPL contours example, pasted straight into the new
> ipython frontend, and all plots are correctly rendered inline.
Impressive--but I don't think I understand why one would want plots 
rendered inline rather than in separate windows.
Eric
>
> All this should be ready for adventurous users to begin testing in a
> few weeks (it's still a bit alpha right now, so really
> 'hardhat-only'). But we're very happy with how things are
> progressing, and it's fabulous to have your rapid response rate on the
> MPL side.
>
> Best regards,
>
> f

Hi all,
As you may know, this summer we have been working on a new two
process IPython that has a beautiful Qt frontend GUI and a ZMQ based
messaging layer between that GUI and the new IPython kernel. Many
thanks to Enthought for funding this effort!
We are currently in the process of adding GUI event loop integration
to the ipython kernel so users can do interactive plotting like they
can with the regular ipython. You may also remember that last summer
we implemented a new PyOs_InputHook based GUI integration for the
regular ipython. This has not been released yet, but all of this will
be released in the upcoming 0.11 release.
I am emailing everyone because we see that there is a need for all of
us to agree on two things:
1. How to detect if a GUI application object has been created by someone else.
2. How to detect if a GUI event loop is running.
Currently there is code in both ETS and matplotlib that fails to
handle these things properly in certain cases. With IPython 0.10,
this was not a problem because we used to hijack/monkeypatch the GUI
eventloops after we started them. In 0.11, we will no longer be doing
that. To address these issues, we have created a standalone module
that implements the needed logic:
http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
This module is heavily commented and introduces a new informal
protocol that all of use can use to detect if event loops are
running. This informal protocol is inspired by how some of this is
handled inside ETS. Our idea is that all projects will simply copy
this module into their code and ship it. It is lightweight and does
not depend on IPython or other top-level imports. As you will see, we
have implemented the logic for wx and qt4, we will need help with
other toolkits. An important point is that matplotlib and ets WILL
NOT WORK with the upcoming release of IPython unless changes are made
to their respective codebases. We consider this a draft and are more
than willing to modify the design or approach as appropriate. One
thing that we have not thought about yet is how to continue to support
0.10 within this model.
The good news amidst all of this is that the quality and stability of
the GUI support in IPython is orders of magnitude better than that in
the 0.10 series.
Cheers,
Brian
PS: If you are curious, here is a bit of background on the issues
related to the PyOS_Inputhook stuff:
http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html

On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing <ef...@ha...> wrote:
> I committed it.
>
Many thanks Eric, for being so responsive!
Some eye candy to give you an idea of what we're getting from this work:
http://fperez.org/tmp/multiplot.png
http://fperez.org/tmp/multiplot2.png
The second is the MPL contours example, pasted straight into the new
ipython frontend, and all plots are correctly rendered inline.
All this should be ready for adventurous users to begin testing in a
few weeks (it's still a bit alpha right now, so really
'hardhat-only'). But we're very happy with how things are
progressing, and it's fabulous to have your rapid response rate on the
MPL side.
Best regards,
f

Eric,
On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing <ef...@ha...> wrote:
> On 08/26/2010 05:13 PM, Brian Granger wrote:
>> Hi,
>>
>> We are in the process of getting our new Qt IPython GUI working with
>> matplotlib. One problem we have found is that the matplotlib qt4
>> backend always creates a QApplication. This is problematic in
>> situations where another part of an application has already created a
>> QApplication. The fix is to have matplotlib first see if a
>> QApplication already exists and then use that one. The attached patch
>> implements this fix. If needed, Fernando can help test this, but I
>> think the change is minor enough that it should be good to go.
>
> I committed it.
Thanks! I am going to post another msg soon about our thoughts on a
new and consistent way of detecting existing apps and running event
loops.
> I suspect the most recent changes to ipython may require changes to
> show, but they can wait until things settle down a bit.
Very likely, we will be in touch.
Brian
> Eric
>
>>
>> Cheers,
>>
>> Brian
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I also completely agree that, ideally, hist/bar/box would get a full
re-write... A re-write of the hist side of things would be very
useful for me, and something that I might end up doing myself, if I
can find the time. I haven't really done anything with the bar or box
plots, though, so I'm not sure what needs to be changed there.
But presumably we're stuck with backwards-compatibility for the
existing function... and as it stands now, it's clearly bugged, so I
still think the patch should be applied in the interm.
To address the True/1.0 issue, though: The reason I did it here is not
because True is really a special case - this was just a performance
tweak... The whole code snippet is as follows:
if log is True:
 minimum = 1.0
elif log:
 minimum = float(log)
else:
 minimum = 0.0
You'll note that if I change the "elif log:" to "if log" and remove
the first case completely, the behavior is unchanged, because
float(True) = 1.0 ... that was the reason for the choice of 1 as the
default. The only reason I'm special-casing "log is True" is because
the default is False, so all other things being equal, the most likely
thing someone would assume who didn't read the docs closely would
assume is that it should be "True" - so it's only a tiny performance
boost for those cases. Honestly, it's not a big deal - I did it out
of habit due to other projects where you get significant performance
gains by special-casing the default argument.
>>  I realize API changes are a pain, but this seems error-prone from a
>>  user's point of view. If they accidentally use 1 instead of "True" -
>>  common among C or old Python users - suddenly the function does
>>  something startling. (There's also an ambiguity between zero and
>>  False, but that's probably not so serious here.) If I were designing
>>  an API from scratch I'd probably go with a separate parameter for the
>>  minimum (or not, if ylim can fix it after the fact) and a dedicated
>>  one for "should we use a log scale". Failing that, maybe the string
>>  "auto" to indicate automatic minimum values and None for a default?
On Wed, Aug 25, 2010 at 10:06 AM, Eric Firing <ef...@ha...> wrote:
> On 08/25/2010 04:50 AM, Benjamin Root wrote:
>>
>> On Wed, Aug 25, 2010 at 12:00 AM, Anne Archibald
>> <aar...@ph... <mailto:aar...@ph...>> wrote:
>>
>>  On 24 August 2010 22:22, Benjamin Root <ben...@ou...
>>  <mailto:ben...@ou...>> wrote:
>>   > On Tue, Aug 24, 2010 at 9:01 PM, Anne Archibald
>>  <aar...@ph... <mailto:aar...@ph...>>
>>   > wrote:
>>   >>
>>   >> On 24 August 2010 19:16, Erik Tollerud <eri...@gm...
>>  <mailto:eri...@gm...>> wrote:
>>   >> > Whoops, yes, that should be True... Also realized a slight
>>  error in
>>   >> > the description of how the mimum is set - both of those are
>>  fixed in
>>   >> > the attached diff.
>>   >>
>>   >> Um, this is a kind of important point of style: it is much better
>> to
>>   >> use "if foo:" than "if foo is True:" or even "if foo == True:".
>>   >> Long-standing python convention allows things like 1, 7.0, numpy
>>   >> booleans that are true, and nonempty lists to have a value of True.
>>   >> Using "if foo:", this works. Using "if foo is True:", this cannot
>>   >> possibly work; even though 1==True, it is not true that 1 is True.
>>   >> "is" has a very specific meaning that should be used only when
>>   >> appropriate (generally, for None or for mutable objects).
>>
>>  [snip]
>>
>>   > While it probably could be better done, the logic of the entire
>>  if statement
>>   > is to first check to see if someone explicitly set a True value
>>  (default is
>>   > False), and that sets the minimum to 1.0. Then, if it isn't
>>  explicitly
>>   > True, then it checks to see if it is a numerical value and uses
>>  that value
>>   > to indicate the minimum. Only if it is None or False does it
>>  then go to the
>>   > last branch which would set minimum to zero.
>>   >
>>   > Maybe it should use a cbook function that test for a numerical value
>>   > explicitly instead and do that first, then have a check for the
>>  Truthiness
>>   > of log?
>>
>>  I realize API changes are a pain, but this seems error-prone from a
>>  user's point of view. If they accidentally use 1 instead of "True" -
>>  common among C or old Python users - suddenly the function does
>>  something startling. (There's also an ambiguity between zero and
>>  False, but that's probably not so serious here.) If I were designing
>>  an API from scratch I'd probably go with a separate parameter for the
>>  minimum (or not, if ylim can fix it after the fact) and a dedicated
>>  one for "should we use a log scale". Failing that, maybe the string
>>  "auto" to indicate automatic minimum values and None for a default?
>>
>>  If you're going to use True to mean something different from 1,
>>  though, I'd make sure to put a warning in the docstring. Unfortunately
>>  you can't just rely on duck typing to tell numeric values from
>>  booleans, since float(True) is 1.0. On the other hand, "is True" fails
>>  for numpy booleans, and "== True" passes for 1.0. So if this is your
>>  constraint, I'm not sure you can do better than "is True", but it's a
>>  huge UI wart.
>>
>>  Anne
>>
>>  P.S. keep in mind that the values users pass are not always directly
>>  visible to users - they might be passing a value output from someone
>>  else's routine that is described as returning a boolean value but
>>  actually returns an integer. This is particularly common among C or
>>  Fortran routines, which are in turn very common in the numerical
>>  world. From the other direction, if you pull a value out of a boolean
>>  numpy array, you get a numpy boolean which will never "is True". -A
>>
>>
>> I agree. After thinking about it further, I realized a few other ways
>> that this will silently fail. Quite personally, I feel that the
>> hist/bar family of functions ought to be nuked from orbit. It is
>> absolutely amazing just how convoluted those functions are. We seem to
>> be acquiescing to every single feature request rather than thinking
>> about how one could use the existing matplotlib tools. For example, if
>> one wants error bars on their histograms/bar plots, then they should be
>> able to call hist() and then errorbars() to achieve their needs.
>
> Ben,
>
> "Me, too!" regarding dismay over the hist/bar family (including box plots).
> They need to be rethought and re-implemented in their own module. Dealing
> with the transition may be a pain, but so is every experience with trying to
> maintain them.
>
> Eric
>
>
>>
>> For logarithmic hist(), I am not exactly sure why we should have a
>> keyword argument to indicate a mode of operation. We have loglog(),
>> semilogx(), semilogy(). A user could also call set_xscale() or
>> set_yscale() and the limits accordingly. I am not saying they are the
>> best examples/approaches, merely pointing out the different ways we have
>> for log plotting.
>>
>> Should we have histlog() and barlog() functions? Are we willing to make
>> an effort to look at some of these plotting functions and clean them up?
>>
>> Ben Root
>
>
-- 
Erik Tollerud

Hi,
It seems that the match_original=True option in PatchCollection does not preserve line style. Is this deliberate? If not, here is a patch for collections.py:
Index: collections.py
===================================================================
--- collections.py	(revision 8664)
+++ collections.py	(working copy)
@@ -1041,6 +1041,7 @@
 facecolors = [determine_facecolor(p) for p in patches]
 edgecolors = [p.get_edgecolor() for p in patches]
 linewidths = [p.get_linewidth() for p in patches]
+ linestyles = [p.get_linestyle() for p in patches]
 antialiaseds = [p.get_antialiased() for p in patches]
 
 Collection.__init__(
@@ -1048,7 +1049,7 @@
 edgecolors=edgecolors,
 facecolors=facecolors,
 linewidths=linewidths,
- linestyles='solid',
+ linestyles=linestyles,
 antialiaseds = antialiaseds)
 else:
 Collection.__init__(self, **kwargs)
Cheers,
Tom

On 08/27/2010 09:09 AM, Ryan May wrote:
> On Fri, Aug 27, 2010 at 12:20 PM, Thomas Robitaille
> <tho...@gm...> wrote:
>> Hi,
>>
>> The following code:
>>
>> from matplotlib.patches import Ellipse
>> from matplotlib.collections import PatchCollection
>> p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
>>
>> raises the following exception:
>>
>> Traceback (most recent call last):
>> File "test_patches.py", line 5, in<module>
>> p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
>> File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 1041, in __init__
>> facecolors = [determine_facecolor(p) for p in patches]
>> File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 1037, in determine_facecolor
>> if patch.fill:
>> AttributeError: 'Ellipse' object has no attribute 'fill'
>>
>> I have submitted a ticket: https://sourceforge.net/tracker/?group_id=80706&atid=560720
>
> The obvious fix would be to change from patch.fill to
> patch.get_fill(). However, I'm curious how this code got broken.
I broke it here: 
http://currents.soest.hawaii.edu/hgstage/hgwebdir.cgi/mpl_hg/diff/799df584a8df/matplotlib/lib/matplotlib/patches.py
The safest way to fix it--that is, preserving the old behavior of 
patch.fill--would be to make it a property. I can do that later today 
or tomorrow, or you can go ahead with it. It would be something of an 
inconsistency, in that for partly historical reasons mpl is based on an 
endless procession of getters and setters, but I don't think it would do 
any harm, and it does preserve the earlier API. At the same time, it 
would be OK to use get_fill in the PatchCollection--it will work, and it 
is more consistent with typical mpl usage. So, I think the best fix is 
to make both changes, with a comment in patches.py as to why fill is a 
property.
Eric
>
> Eric, any ideas? SVN claims that the last change to that line was done
> by you (based on a bug *I* reported)? It apparently worked then:
>
> http://sourceforge.net/mailarchive/message.php?msg_name=487A5AE3.5070500%40gmail.com
>
> Ryan
>

On Fri, Aug 27, 2010 at 12:20 PM, Thomas Robitaille
<tho...@gm...> wrote:
> Hi,
>
> The following code:
>
> from matplotlib.patches import Ellipse
> from matplotlib.collections import PatchCollection
> p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
>
> raises the following exception:
>
> Traceback (most recent call last):
> File "test_patches.py", line 5, in <module>
>  p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
> File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 1041, in __init__
>  facecolors  = [determine_facecolor(p) for p in patches]
> File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 1037, in determine_facecolor
>  if patch.fill:
> AttributeError: 'Ellipse' object has no attribute 'fill'
>
> I have submitted a ticket: https://sourceforge.net/tracker/?group_id=80706&atid=560720
The obvious fix would be to change from patch.fill to
patch.get_fill(). However, I'm curious how this code got broken.
Eric, any ideas? SVN claims that the last change to that line was done
by you (based on a bug *I* reported)? It apparently worked then:
http://sourceforge.net/mailarchive/message.php?msg_name=487A5AE3.5070500%40gmail.com
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
The following code:
from matplotlib.patches import Ellipse
from matplotlib.collections import PatchCollection
p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
raises the following exception:
Traceback (most recent call last):
 File "test_patches.py", line 5, in <module>
 p = PatchCollection([Ellipse((0.5,0.5),0.2,0.1)], match_original=True)
 File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 1041, in __init__
 facecolors = [determine_facecolor(p) for p in patches]
 File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 1037, in determine_facecolor
 if patch.fill:
AttributeError: 'Ellipse' object has no attribute 'fill'
I have submitted a ticket: https://sourceforge.net/tracker/?group_id=80706&atid=560720
Cheers,
Tom

On Fri, Aug 27, 2010 at 7:21 AM, Stan Schymanski <ss...@bg...>wrote:
> Dear all,
>
> I don't know which update it was that broke it, but this used to work:
>
> import numpy
> import pylab
> pylab.clf()
> fig = pylab.figure(1,figsize=(8,5))
> ax = fig.add_subplot(111, autoscale_on=False, xlim=(-1,5),
> ylim=(-4,3))
>
> t = numpy.arange(0.0, 5.0, 0.01)
> s = numpy.cos(2*numpy.pi*t)
> line, = ax.plot(t, s, lw=3, color='purple')
> pylab.text(-0.5,3.2,'no data',ha='center')
>
> pylab.annotate('',(-1,3.1),(0,3.1),va='center',ha='center',arrowprops=dict(arrowstyle='<->'))
> pylab.savefig('blah.png')
>
> This used to plot an arrow under the text 'no data' but above the main
> plot. Now this arrow does not appear unless at least part of it is within
> the plotting area. Change one of the '3.1' in the code above to, say, 3.0
> and the whole arrow is displayed. Is this a bug or is there a new way of
> achieving what I want?
>
> Thanks for your help already!
>
> Cheers
> Stan
>
>
I wonder if it was one of the fixes to the clipping code. If I plot this to
the screen and then move the plot so that the "no data" text is in the plot
area, the arrow shows up.
So, the question is... was plotting arrows outside the plot area a bug or a
feature? And, if it was a bug, what about being able to annotate outside the
plot area?
Lastly, whatever the outcome, this example should probably become a test
because it would be a great way to test for obscure broken behavior.
Ben Root
P.S. - cc'ing the devel mailing list here...