matplotlib-users

[Matplotlib-users] Windows defaults and the first example in the tutorial

[Darren D. <dd...@co...>]

I was thinking about the first example in the tutorial. On windows, TkAgg 
is the default backend, at least for the precompiled windows version. If 
Idle is run with -n, the show() command must be omitted, or the window will 
not render. Interactive2.py will try to render the window and then hang, as 
will pycrust. I think the first thing a newbie to matplotlib wants to do is 
open their favorite shell interface and make sure they can reproduce the 
first example in the tutorial.

Darren



Darren S. Dale
dd...@co...

PGP public key available 

Re: [Matplotlib-users] Windows defaults and the first example in the tutorial

[Todd M. <jm...@st...>]

On Wed, 2004-04-28 at 11:50, Darren Dale wrote:
> I was thinking about the first example in the tutorial. On windows, TkAgg 
> is the default backend, at least for the precompiled windows version. If 
> Idle is run with -n, the show() command must be omitted, or the window will 
> not render. 

Not in my experience.  What's the command sequence you're executing?

> Interactive2.py will try to render the window and then hang, 

I think interactive2.py is for GTK.  It's a bad idea to use it with
TkAgg since TkAgg is Tcl/Tk based.

> as will pycrust. 

I think PyCrust is WxWindows based.  It's also a bad idea to use with
TkAgg.  In general, multiple GUIs in the same process is a bad idea.  

> I think the first thing a newbie to matplotlib wants to do is 
> open their favorite shell interface and make sure they can reproduce the 
> first example in the tutorial.

I gotta admit,  shell confusion/compatibility is out of hand.   For
TkAgg, the only windows shells I recommend are python (not pythonwin!),
idle -n, and IPython.  Anything else either doesn't work or hasn't been
tested.

Regards,
Todd

Re: [Matplotlib-users] Windows defaults and the first example in the tutorial

[John H. <jdh...@ac...>]

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I was thinking about the first example in the tutorial. On
    Darren> windows, TkAgg is the default backend, at least for the
    Darren> precompiled windows version. If Idle is run with -n, the
    Darren> show() command must be omitted, or the window will not
    Darren> render. Interactive2.py will try to render the window and
    Darren> then hang, as will pycrust. I think the first thing a
    Darren> newbie to matplotlib wants to do is open their favorite
    Darren> shell interface and make sure they can reproduce the first
    Darren> example in the tutorial.

Hi Darren,

This is a problem.  It may be time to look into Pearu Peterson's
gui_thread which was developed for chaco but is easily decoupled from
scipy.  It would be nice if the various backends played nicely with
the various IDEs.  (One for the priorities list, Perry?)

In the meantime, I've added this warning to the win32 section of the
installing page

  Important: There are known conflicts with some of the backends with
  some python IDEs such as pycrust, idle. If you want to use
  matplotlib from an IDE, please consult the backends documentaion for
  compatibility information. You will have the greatest likelihood of
  success if you run the examples from the command shell or by double
  clicking on them, rather than from an IDE. If you are interactively
  generating plots, your best bet is TkAgg from the standard python
  shell.

JDH

RE: [Matplotlib-users] Windows defaults and the first example in the tutorial

[Perry G. <pe...@st...>]

>     Darren> I was thinking about the first example in the tutorial. On
>     Darren> windows, TkAgg is the default backend, at least for the
>     Darren> precompiled windows version. If Idle is run with -n, the
>     Darren> show() command must be omitted, or the window will not
>     Darren> render. Interactive2.py will try to render the window and
>     Darren> then hang, as will pycrust. I think the first thing a
>     Darren> newbie to matplotlib wants to do is open their favorite
>     Darren> shell interface and make sure they can reproduce the first
>     Darren> example in the tutorial.
> 
> Hi Darren,
> 
> This is a problem.  It may be time to look into Pearu Peterson's
> gui_thread which was developed for chaco but is easily decoupled from
> scipy.  It would be nice if the various backends played nicely with
> the various IDEs.  (One for the priorities list, Perry?)
> 
Sure. But my recollection was that gui_thread needed a lot of work
(Eric Jones told me at least a month!), and it could well be that
one is needed for each gui (it does mapping of gui requests from
one thread to another or something like that so that a thread
running the mainloop allows the python interactive loop to run
separately. It would be nice if gui's played well with each other,
but I don't know if that is easy to do (or even workable for
all combinations). If someone knows how to do this sort of thing
that would be great, but we don't (neither the resources or expertise).
At the moment I take the position that it is simplest not to mix
gui's. The current rule of thumb should be that if you want to
use a shell that runs under a gui, you need the back end in matplotlib
to go with that gui.

I hope someone can make me a liar on that.

Perry 

RE: [Matplotlib-users] Windows defaults and the first example in the tutorial

[John N S G. <jn...@eu...>]

 

> Sure. But my recollection was that gui_thread needed a lot of work
> (Eric Jones told me at least a month!), and it could well be that
> one is needed for each gui (it does mapping of gui requests from
> one thread to another or something like that so that a thread
> running the mainloop allows the python interactive loop to run
> separately. It would be nice if gui's played well with each other,
> but I don't know if that is easy to do (or even workable for
> all combinations). If someone knows how to do this sort of thing
> that would be great, but we don't (neither the resources or expertise).
> At the moment I take the position that it is simplest not to mix
> gui's. The current rule of thumb should be that if you want to
> use a shell that runs under a gui, you need the back end in matplotlib
> to go with that gui.
> 
> I hope someone can make me a liar on that.
> 
> Perry 

 
Some time back I experimented with gui_thread.  

One fairly serious problem with gui_thread is that it is important which
thread wxpython gets imported into.  

Eric worked around this by printing a message once gui_thread had been
imported which, interactively was a signal that it was ok to start using
it.   There is a README in the gui_thread package which has more details
on this problem.

Now I was interested in gui_thread for two reasons:  interactive
plotting with chaco and creating python COM objects which fired up
wxPython gui's.   

The latter is a bit challenging + the solution was to run the gui in a
different thread.   So I started off using gui_thread.  I had to re-work
the gui_thread code a bit, the trick was to do a bit less work when
importing gui_thread so that I had better control of when wxpython was
imported and hence could make sure it all happened in the right
threads.  I fed the fixes back to Eric, but I don't think he wanted to
change the semantics of gui_thread + as he seems to say it really needs
a good re-think.

Meanwhile, Richard Emslie, who works with me took these ideas and has
created a robust system for running this stuff in another thread.   

Richard's stuff works with a package called earthenware that we're
intending to release as open source.  Earthenware contains a lot of our
generic code that it really makes no sense for us to keep proprietary.  
Now one thing we are doing in earthenware is creating objects which
separate the description of a GUI from its actual implementation.   The
description side is not toolkit specific.  This helps a lot with the two
thread problem, since the gui descriptions can be created in one thread
and implemented in the other thread + you only need to import wx in the
thread that does the implementation.

One other nice thing with this approach is you can build servers which
create the gui descriptions, pickle up the objects and send them down a
socket to a remote client which turns them into a GUI.   

Currently, the only toolkit we have gui code for is wxpython + the set
of 'gui components' we have are a bit limited + some need a little
re-thinking, but the basic framework is proving powerful.   We keep
threatening to look at a pygtk version, which i suspect wouldn't be huge
amounts of work.

We're planning on going to Europython in June + would be happy to meet
up with anyone interested in this stuff.

The earthenware site is here:
http://www.earthenware-services.org/earthenwarewiki/.

As yet we haven't put the code I'm describing above, we really need to
pull our fingers out and get the code out there -- will try and get some
sort of tarball out there very soon.   For now all you will find is a
python package which writes gnumeric spreadsheets.

John

RE: [Matplotlib-users] Windows defaults and the first example in the tutorial

[Perry G. <pe...@st...>]

One more thought along this line. Perhaps it's possible for
matplotlib to inspect whether or not any of the supported gui's 
has already been imported and make that the default. It seems
like a sensible rule to me. If none are found, then all the
other mechanisms apply.

Perry

Re: [Matplotlib-users] Windows defaults and the first example in the tutorial

[John H. <jdh...@ac...>]

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> One more thought along this line. Perhaps it's possible for
    Perry> matplotlib to inspect whether or not any of the supported
    Perry> gui's has already been imported and make that the
    Perry> default. It seems like a sensible rule to me. If none are
    Perry> found, then all the other mechanisms apply.

I've given a little thought to this and it is certainly possible.  In
the backend selection code we can detect the case when the backend has
not been *explicity* set by either -d or matplotlib.use.  In the case
that we are using the default from matplotlib rc, and the default is a
GUI, we could do two things to help prevent mistakes

  * make sure no conflicting gui is loaded in sys.modules.  If another
    is, go with that (issue a warning)

  * if no other is loaded, try and load the required GUI lib in a
    try/except block.  If the load fails, look for an alternative and
    use that instead (issue a warning)

I don't see a major problem with this approach.  I want to avoid the
microsoft approach of doing too much behind the scenes to try and
accommodate the careless user, since this often runs afoul of the
power user, and often leads to situations that are difficult to debug.
I think if we issue warnings we can at least make clear what is
happening which should satisfy both potential problems.

Any forseeable problems with this approach?

JDH

 

RE: [Matplotlib-users] Windows defaults and the first example in the tutorial

[Perry G. <pe...@st...>]

John Hunter writes:
> >>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
> 
>     Perry> One more thought along this line. Perhaps it's possible for
>     Perry> matplotlib to inspect whether or not any of the supported
>     Perry> gui's has already been imported and make that the
>     Perry> default. It seems like a sensible rule to me. If none are
>     Perry> found, then all the other mechanisms apply.
> 
> I've given a little thought to this and it is certainly possible.  In
> the backend selection code we can detect the case when the backend has
> not been *explicity* set by either -d or matplotlib.use.  In the case
> that we are using the default from matplotlib rc, and the default is a
> GUI, we could do two things to help prevent mistakes
> 
>   * make sure no conflicting gui is loaded in sys.modules.  If another
>     is, go with that (issue a warning)
> 
>   * if no other is loaded, try and load the required GUI lib in a
>     try/except block.  If the load fails, look for an alternative and
>     use that instead (issue a warning)
> 
> I don't see a major problem with this approach.  I want to avoid the
> microsoft approach of doing too much behind the scenes to try and
> accommodate the careless user, since this often runs afoul of the
> power user, and often leads to situations that are difficult to debug.
> I think if we issue warnings we can at least make clear what is
> happening which should satisfy both potential problems.
> 
> Any forseeable problems with this approach?
> 
It sounds like a good thing to try. As time goes on, perhaps
ways of making different gui's coexist may be found and implemented.
But that may take some time even if possible. This proposal
seems the best short term solution.

Perry

RE: [Matplotlib-users] Windows defaults and the first example in the tutorial

[Darren D. <dd...@co...>]

> >   * make sure no conflicting gui is loaded in sys.modules.  If another
> >     is, go with that (issue a warning)
> >
> >   * if no other is loaded, try and load the required GUI lib in a
> >     try/except block.  If the load fails, look for an alternative and
> >     use that instead (issue a warning)

John, you are right, too much behind the scenes work is not justified, but 
the uninitiated user should have as easy an "entry" as is reasonable. So 
this seems like a good solution. If a shell wont play nice with the 
backend, a warning stating as much is better than a frozen window. 

Re: [Matplotlib-users] Windows defaults and the first example in the tutorial

[Darren D. <dd...@co...>]

>Darren Dale wrote:
> > I was thinking about the first example in the tutorial. On windows, TkAgg
> > is the default backend, at least for the precompiled windows version. If
> > Idle is run with -n, the show() command must be omitted, or the window 
> will
> > not render.

>Todd Miller wrote:
>Not in my experience.  What's the command sequence you're executing?

Sorry guys, I made a mistake here. I was pasting

from matplotlib.matlab import *
plot([1,2,3,4])
show()

as a block right into Idle -n. Running the commands one at a time does work.

I've maybe posted too many times today (:-/), but I have one last comment 
before I settle in to look at all the nice demos that you awesome dudes 
have put together. I didnt know these demos existed, I didnt find them on 
my file system when I searched through the folders that the windows .exe 
had installed. I downloaded the .zip package and extracted the samples from 
there, then did a windows search to see if i just hadnt been looking in the 
right place. The results: it found the examples from the zip file in 
C:\[path]\examples, and it found another set of examples in 
matplotlib-0.53.1/examples. But note: there is no mention of C:\... for 
this set of files, and they dont show up in windows explorer. 

Re: [Matplotlib-users] Windows defaults and the first example in the tutorial

[John H. <jdh...@ac...>]

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I've maybe posted too many times today (:-/), but I have
    Darren> one last comment before I settle in to look at all the
    Darren> nice demos that you awesome dudes have put together. I
    Darren> didnt know these demos existed, I didnt find them on my
    Darren> file system when I searched through the folders that the
    Darren> windows .exe had installed. I downloaded the .zip package
    Darren> and extracted the samples from there, then did a windows
    Darren> search to see if i just hadnt been looking in the right
    Darren> place. The results: it found the examples from the zip
    Darren> file in C:\[path]\examples, and it found another set of
    Darren> examples in matplotlib-0.53.1/examples. But note: there is
    Darren> no mention of C:\... for this set of files, and they dont
    Darren> show up in windows

It's a good point - the demos don't exist in the exe distro; I think
this is typical for binary distributions.  I think a note on the win32
installing section pointing out that there is an examples dir in the
zip file might be helpful.  But if there is a standard way for
including examples in a bdist_wininst and I'm missing it, please let
me know.

I'm adding to the win32 installing section

  The windows installer *.exe on the download page contains all the
  code you need to get up and tunning.  But if you want to try the
  many demos that come in the matplotlib src distribution, download
  the zip file and look in the examples subdir.

It's very helpful of you to let us know all the confusions you
experience in the beginning and where the web site isn't too
enlightening.  All of us veterans have forgotten what we didn't know
already, so keep it up.

JDH

Re: [Matplotlib-users] Windows defaults and the first example in the tutorial

[Darren D. <dd...@co...>]

>It's a good point - the demos don't exist in the exe distro; I think
>this is typical for binary distributions.  I think a note on the win32
>installing section pointing out that there is an examples dir in the
>zip file might be helpful.  But if there is a standard way for
>including examples in a bdist_wininst and I'm missing it, please let
>me know.

How about a .zip of just the examples? Then they will not be overlooked.