refactoring of show

All,

John noticed that my changes to show() prior to 1.0 had broken a use case with tkagg and ipython -pylab, so I fixed that yesterday in maintenance branch and trunk. Today, in 8562 and 8563, I did some refactoring to try to make show() behavior more understandable across backends, and easier to modify if necessary. Specifically, we need to work with the ipython people to make sure the ipython 0.11 refactoring of interactive support works as intended. I haven't done any testing with the development version of 0.11 yet.

At present, all interactive backends start a blocking mainloop only if ipython has not attached a _needmain flag to show(), and if mpl is not in interactive mode.

Under all script and ipython conditions, multiple calls to show in a session or script are permitted.

All interactive backends behave the same when run with ipython -pylab, version 0.10: show is non-blocking, regardless of whether it is executed on the command line (completely unnecessary) or is found in a script.

Under raw ipython (no -pylab or other threading flags provided), with mpl in non-interactive mode, all backends behave the same: show() is needed and blocks, but may be called multiple times. With mpl in interactive mode, there are two categories: tkagg, fltkagg, gtk*, and qt4agg behave the same as in -pylab mode, so there so no longer any real need for the special threading modes; but wx* and qtagg do not behave in a useful way, so they still need the special threading.

All of the above is based on quick tests with my own system, ubuntu 10.04. I expect it will be the same for other supported systems, with the exception that behavior in raw ipython mode, with mpl in interactive mode, may not work with some earlier versions of gui toolkits--but I suspect we will not actually encounter this for supported versions.

I have not built or tested anything under Windows or OS X. For the latter, testing of the macosx backend is needed. I expect cocoaagg to behave differently than the others, but no differently than it did before my changes.

Eric

Wing IDE recently added support for matplotlib, specifically non blocking show(). It might be worth also to test the 4.0 beta release.

http://www.wingware.com/wingide/beta

Christoph

···

On 7/16/2010 2:26 PM, Eric Firing wrote:

All,

John noticed that my changes to show() prior to 1.0 had broken a use
case with tkagg and ipython -pylab, so I fixed that yesterday in
maintenance branch and trunk. Today, in 8562 and 8563, I did some
refactoring to try to make show() behavior more understandable across
backends, and easier to modify if necessary. Specifically, we need to
work with the ipython people to make sure the ipython 0.11 refactoring
of interactive support works as intended. I haven't done any testing
with the development version of 0.11 yet.

At present, all interactive backends start a blocking mainloop only if
ipython has not attached a _needmain flag to show(), and if mpl is not
in interactive mode.

Under all script and ipython conditions, multiple calls to show in a
session or script are permitted.

All interactive backends behave the same when run with ipython -pylab,
version 0.10: show is non-blocking, regardless of whether it is executed
on the command line (completely unnecessary) or is found in a script.

Under raw ipython (no -pylab or other threading flags provided), with
mpl in non-interactive mode, all backends behave the same: show() is
needed and blocks, but may be called multiple times. With mpl in
interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
qt4agg behave the same as in -pylab mode, so there so no longer any real
need for the special threading modes; but wx* and qtagg do not behave in
a useful way, so they still need the special threading.

All of the above is based on quick tests with my own system, ubuntu
10.04. I expect it will be the same for other supported systems, with
the exception that behavior in raw ipython mode, with mpl in interactive
mode, may not work with some earlier versions of gui toolkits--but I
suspect we will not actually encounter this for supported versions.

I have not built or tested anything under Windows or OS X. For the
latter, testing of the macosx backend is needed. I expect cocoaagg to
behave differently than the others, but no differently than it did
before my changes.

Eric

I've been keeping more or less up on the .11 development ipython,
under Ubuntu 9.10 (10.4 when I get around to it...). For each of the
backends I do the following in an interactive session that starts with
no profile or -pylab or anything::

import matplotlib
matplotlib.interactive(True)
matplotlib.use('whateverbackend')

from matplotlib.pyplot import scatter,show
from numpy.random import randn

%gui -a whateverguiname

scatter(*randn(2,100))
show()

that "%gui" bit is the new trick in ipython .11 that you use to
initiate the event loop, so that the --pylab flag is superfluous. I
try it both with, and without that line. Below are my results for the
various backends:

*wx:
w/o %gui: nothing appears until show(), show() correctly blocks until
the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes.

*qt4:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() does NOT block.

*gtk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.
w/ %gui: identical behavior

*tk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.

So it seems the interactive case of using the %gui magic works in all
cases for interactive mode, but show is still not consistent in
ipython .11 ...

···

On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing <efiring@...229...> wrote:

All,

John noticed that my changes to show() prior to 1.0 had broken a use
case with tkagg and ipython -pylab, so I fixed that yesterday in
maintenance branch and trunk. Today, in 8562 and 8563, I did some
refactoring to try to make show() behavior more understandable across
backends, and easier to modify if necessary. Specifically, we need to
work with the ipython people to make sure the ipython 0.11 refactoring
of interactive support works as intended. I haven't done any testing
with the development version of 0.11 yet.

At present, all interactive backends start a blocking mainloop only if
ipython has not attached a _needmain flag to show(), and if mpl is not
in interactive mode.

Under all script and ipython conditions, multiple calls to show in a
session or script are permitted.

All interactive backends behave the same when run with ipython -pylab,
version 0.10: show is non-blocking, regardless of whether it is executed
on the command line (completely unnecessary) or is found in a script.

Under raw ipython (no -pylab or other threading flags provided), with
mpl in non-interactive mode, all backends behave the same: show() is
needed and blocks, but may be called multiple times. With mpl in
interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
qt4agg behave the same as in -pylab mode, so there so no longer any real
need for the special threading modes; but wx* and qtagg do not behave in
a useful way, so they still need the special threading.

All of the above is based on quick tests with my own system, ubuntu
10.04. I expect it will be the same for other supported systems, with
the exception that behavior in raw ipython mode, with mpl in interactive
mode, may not work with some earlier versions of gui toolkits--but I
suspect we will not actually encounter this for supported versions.

I have not built or tested anything under Windows or OS X. For the
latter, testing of the macosx backend is needed. I expect cocoaagg to
behave differently than the others, but no differently than it did
before my changes.

Eric

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I've been keeping more or less up on the .11 development ipython,
under Ubuntu 9.10 (10.4 when I get around to it...). For each of the
backends I do the following in an interactive session that starts with
no profile or -pylab or anything::

import matplotlib
matplotlib.interactive(True)
matplotlib.use('whateverbackend')

from matplotlib.pyplot import scatter,show
from numpy.random import randn

%gui -a whateverguiname

scatter(*randn(2,100))
show()

that "%gui" bit is the new trick in ipython .11 that you use to
initiate the event loop, so that the --pylab flag is superfluous. I
try it both with, and without that line. Below are my results for the
various backends:

*wx:
w/o %gui: nothing appears until show(), show() correctly blocks until
the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes.

*qt4:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() does NOT block.

*gtk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.
w/ %gui: identical behavior

*tk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.

So it seems the interactive case of using the %gui magic works in all
cases for interactive mode, but show is still not consistent in
ipython .11 ...

Erik,

Thanks for the testing. I was also starting to test with ipython 0.11 yesterday, and had reached the opposite conclusion--but I was using a different procedure. So I will track down the difference. My results were quite different...

Please verify: were you using the latest mpl from svn?

Eric

···

On 07/19/2010 10:34 AM, Erik Tollerud wrote:

On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing<efiring@...229...> wrote:

All,

John noticed that my changes to show() prior to 1.0 had broken a use
case with tkagg and ipython -pylab, so I fixed that yesterday in
maintenance branch and trunk. Today, in 8562 and 8563, I did some
refactoring to try to make show() behavior more understandable across
backends, and easier to modify if necessary. Specifically, we need to
work with the ipython people to make sure the ipython 0.11 refactoring
of interactive support works as intended. I haven't done any testing
with the development version of 0.11 yet.

At present, all interactive backends start a blocking mainloop only if
ipython has not attached a _needmain flag to show(), and if mpl is not
in interactive mode.

Under all script and ipython conditions, multiple calls to show in a
session or script are permitted.

All interactive backends behave the same when run with ipython -pylab,
version 0.10: show is non-blocking, regardless of whether it is executed
on the command line (completely unnecessary) or is found in a script.

Under raw ipython (no -pylab or other threading flags provided), with
mpl in non-interactive mode, all backends behave the same: show() is
needed and blocks, but may be called multiple times. With mpl in
interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
qt4agg behave the same as in -pylab mode, so there so no longer any real
need for the special threading modes; but wx* and qtagg do not behave in
a useful way, so they still need the special threading.

All of the above is based on quick tests with my own system, ubuntu
10.04. I expect it will be the same for other supported systems, with
the exception that behavior in raw ipython mode, with mpl in interactive
mode, may not work with some earlier versions of gui toolkits--but I
suspect we will not actually encounter this for supported versions.

I have not built or tested anything under Windows or OS X. For the
latter, testing of the macosx backend is needed. I expect cocoaagg to
behave differently than the others, but no differently than it did
before my changes.

Eric

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I've been keeping more or less up on the .11 development ipython,
under Ubuntu 9.10 (10.4 when I get around to it...). For each of the
backends I do the following in an interactive session that starts with
no profile or -pylab or anything::

import matplotlib
matplotlib.interactive(True)
matplotlib.use('whateverbackend')

from matplotlib.pyplot import scatter,show
from numpy.random import randn

%gui -a whateverguiname

Aha!

Please leave out the -a. It is harmful, not helpful, for mpl. This may mean we need to change mpl and/or ipython, or the documentation, to prevent problems with the -a option; but I think you will find that if you leave out that option, the behavior will be more consistent and the need for Ctrl-C will go away. Without %gui, there will still be an inconsistency between wx and the others--but that's what the %gui magic is for, to make wx use PyOS_InputHook like the others.

Eric

···

On 07/19/2010 10:34 AM, Erik Tollerud wrote:

scatter(*randn(2,100))
show()

that "%gui" bit is the new trick in ipython .11 that you use to
initiate the event loop, so that the --pylab flag is superfluous. I
try it both with, and without that line. Below are my results for the
various backends:

*wx:
w/o %gui: nothing appears until show(), show() correctly blocks until
the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes.

*qt4:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() does NOT block.

*gtk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.
w/ %gui: identical behavior

*tk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.

So it seems the interactive case of using the %gui magic works in all
cases for interactive mode, but show is still not consistent in
ipython .11 ...

On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing<efiring@...229...> wrote:

All,

John noticed that my changes to show() prior to 1.0 had broken a use
case with tkagg and ipython -pylab, so I fixed that yesterday in
maintenance branch and trunk. Today, in 8562 and 8563, I did some
refactoring to try to make show() behavior more understandable across
backends, and easier to modify if necessary. Specifically, we need to
work with the ipython people to make sure the ipython 0.11 refactoring
of interactive support works as intended. I haven't done any testing
with the development version of 0.11 yet.

At present, all interactive backends start a blocking mainloop only if
ipython has not attached a _needmain flag to show(), and if mpl is not
in interactive mode.

Under all script and ipython conditions, multiple calls to show in a
session or script are permitted.

All interactive backends behave the same when run with ipython -pylab,
version 0.10: show is non-blocking, regardless of whether it is executed
on the command line (completely unnecessary) or is found in a script.

Under raw ipython (no -pylab or other threading flags provided), with
mpl in non-interactive mode, all backends behave the same: show() is
needed and blocks, but may be called multiple times. With mpl in
interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
qt4agg behave the same as in -pylab mode, so there so no longer any real
need for the special threading modes; but wx* and qtagg do not behave in
a useful way, so they still need the special threading.

All of the above is based on quick tests with my own system, ubuntu
10.04. I expect it will be the same for other supported systems, with
the exception that behavior in raw ipython mode, with mpl in interactive
mode, may not work with some earlier versions of gui toolkits--but I
suspect we will not actually encounter this for supported versions.

I have not built or tested anything under Windows or OS X. For the
latter, testing of the macosx backend is needed. I expect cocoaagg to
behave differently than the others, but no differently than it did
before my changes.

Eric

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hey guys,

Please leave out the -a. It is harmful, not helpful, for mpl. This may
mean we need to change mpl and/or ipython, or the documentation, to
prevent problems with the -a option; but I think you will find that if
you leave out that option, the behavior will be more consistent and the
need for Ctrl-C will go away. Without %gui, there will still be an
inconsistency between wx and the others--but that's what the %gui magic
is for, to make wx use PyOS_InputHook like the others.

I just wanted to say thanks a LOT for this testing. Right now we're
not quite in the gui code, but it's *very* useful for us to have this
information. And please keep in mind that if you find out that from
the ipython side we're doing something silly/backwards regarding this,
we're more than happy to change it. We ultimately want the gui
integration to be as painless as possible.

One extra twist to consider: we're moving to a 2-process model for
most of ipython, so that user interface and code execution live in
separate processes. It will continue to be possible to use a
one-process ipython, but we think most users will prefer the
two-process model. One quirk there will be that %gui now uses
PyOSInputHook to talk to the GUI event loop, but this is only called
by Python if stdin is waiting for input. In a server process (like we
are starting to develop), there is no interactive input (the input
comes over a socket) so we'll need to worry about letting the GUI
event loop work while keeping the network event loop also responsive.

As our picture becomes clearer we'll make sure to update you folks as
well, so we can work from both ends (ipython/mpl) to ensure a good
end-user experience with minimal fuss and all relevant backends.

Cheers,

f

···

On Mon, Jul 19, 2010 at 4:07 PM, Eric Firing <efiring@...229...> wrote: