matplotlib 0.63 examples under pylab

Development matplotlib-devel
1

I think we're doing pretty good, except that people can

    > always kill themselves by running true WX/GTK apps via
    > @run. IPython is really not made for this, it can only
    > handle gracefully show() calls from pure matplotlib
    > scripts, not full-blown GUI apps. But I think we have a
    > very reasonable environment at this point for most usage
    > cases.

It's looks like about 90% of your problems result from trying to cross
GUI backends within IPython. Is this fair to say?

As far as I'm concerned I don't have a problem with these cases.
Caveat emptor -- the user should be forewarned and expect disaster if
they try and run GUI specific examples from ipython. Perhaps you
should say pylab only supports pure matlab interface matplotlib at
this point.

From your end I see why it's a concern - you don't want any run
command to break or freeze ipython. If you have any ideas on what we
should do I'll be happy to help on the matplotlib end, but I don't
have any off the top of my head.

I'll comment on some of the non cross-GUI problems below....

    > // These don't run with LANG==de_DE.UTF-8, but are OK
    > with en_US.UTF-8 run date_demo_convert.py run
    > date_demo1.py run date_demo2.py run date_demo_rrule.py
    > run finance_demo.py

Do they run from the shell with LANG==de_DE.UTF-8? Any idea what is
going wrong?

    > run print_stdout.py

This is an example script to show how to print png to stdout from agg.
Perhaps this fails because ipython doesn't really expect a png coming
in from stdout? The header of that file states

  # print png to standard out
  # usage: python print_stdout.py > somefile.png

    > ****run ftface_props.py
    ---> 71 font.jdh = 'hi'

I was testing to see if I could setattr on my extension class. I'll
just remove this line from the example

    > ****run movie_demo.py: with WX backend it doesn't make
    > the .png frames at all with WXAgg, it runs fine but
    > fails to make the movie: ... Saving frame _tmp049.png
    > Making movie animation.mpg - this make take a while sh:
    > line 1: mpeg2encode: command not found convert: Delegate
    > failed (mpeg2encode "%i" "%o"). convert: Delegate
    > failed (mpeg2encode "%i" "%o") [No such file or
    > directory].

    > Symlinking mpeg2encode to mpeg2enc (the real binary)
    > doesn't help, a different error comes back.

    > I got it to work by commenting out the convert call and
    > reverting to the mencoder one. Great!

Yes, this fails on my system too. This line works

  os.system("convert _tmp*.png animation.mpg")

but I wasn't able to get convert to make mpg. I'll fixed this in the
examples dir and made the mencoder line the default.

    > ****run vertical_ticklabels.py

    > ---------------------------------------------------------------------------
    > NameError Traceback (most recent call last)

    > /home/fperez/code/python/pylab/examples/vertical_ticklabels.py
    > 3 4 plot([1,2,3,4], [1,4,9,16]) 5 xticks([1,2,3,4],
    > ['Frogs', 'Hogs', 'Bogs', 'Slogs'])
    ----> 6 set(t, 'rotation', 'vertical')
    > 7 show()

    > NameError: name 't' is not defined WARNING: Failure
    > executing file: <vertical_ticklabels.py>

Fixed. This also pointed me a bug in the new commands xticks and
yticks; they weren't returning the things they claimed in the doc
string.

Thanks for the detailed notes.

JDH

2

John Hunter schrieb:

"Fernando" == Fernando Perez <Fernando.Perez@...76...> writes:

    > I think we're doing pretty good, except that people can
    > always kill themselves by running true WX/GTK apps via
    > @run. IPython is really not made for this, it can only
    > handle gracefully show() calls from pure matplotlib
    > scripts, not full-blown GUI apps. But I think we have a
    > very reasonable environment at this point for most usage
    > cases.

It's looks like about 90% of your problems result from trying to cross
GUI backends within IPython. Is this fair to say?

Well, not quite. As I mentioned, I put in a matplotlib.use() wrapper which traps invalid switches, so it's not a problem if a use() call is made. Could you add such a call to this one please? :

// OK with GTKAgg backend. It needs a use('GTKAgg') call to be safe for other
backends.
run dynamic_image_gtkagg.py

It's only when native GUI examples are run that things crash badly. Note that some of the segfaults occur from plain python:

// these are OK with gtkagg, but they segfault wxagg. The segfault happens
from a normal command line as well (no ipython).

run system_monitor.py
run dynamic_demo.py

And I also have these:
// these two run but segfault on exit under ipython. They run OK from a cmd line.
run dynamic_demo_wx.py
run dynamic_image_wxagg.py

I suspect these two are messing something up badly enough that if python quits right away, you don't see the problem, but since ipython continues to run the interpreter, the problem appears. Since these are segfaults, I'm very much willing to blame the wx code in there, and not ipython (which is 100% pure, unpolluted python :slight_smile:

As far as I'm concerned I don't have a problem with these cases.
Caveat emptor -- the user should be forewarned and expect disaster if
they try and run GUI specific examples from ipython. Perhaps you
should say pylab only supports pure matlab interface matplotlib at
this point.

From your end I see why it's a concern - you don't want any run

command to break or freeze ipython. If you have any ideas on what we
should do I'll be happy to help on the matplotlib end, but I don't
have any off the top of my head.

Yes, this is the real nasty. If you think that the ipython+matplotlib combination is going to be a common one in the future for scientists, it may be worth protecting the examples against disaster (given they tend to be what people run to first). If you are willing to pay the price of 12 lines of code per example, you could put this snippet at the beginning of _every_ embedded example:

# Detect if we are inside IPython and bail if so. Threading problems
# make it very difficult to safely run full GTK/WX apps inside IPython.
try:
     __IPYTHON__
     msg = ("This script can NOT be run inside IPython.\n\n"
            "It embeds matplotlib into a complete GUI application, and\n"
            "for a number of reasons this is (and probably will remain)\n"
            "unsupported from inside IPython.\n\n"
            "You can run it from the command line as a regular python script.\n")
     raise RuntimeError,msg
except NameError:
     pass

This will make sure that users get a meaningful error message inside ipython instead of a bizarre lockup or segfault.

I'll comment on some of the non cross-GUI problems below....

    > // These don't run with LANG==de_DE.UTF-8, but are OK
    > with en_US.UTF-8 run date_demo_convert.py run
    > date_demo1.py run date_demo2.py run date_demo_rrule.py
    > run finance_demo.py

Do they run from the shell with LANG==de_DE.UTF-8? Any idea what is
going wrong?

Yes, the problem has nothing to do with ipython, it also happens with plain python. Note that the broken ones are:

// These don't run with LANG==de_DE.UTF-8, but are OK with en_US.UTF-8
run date_demo1.py
run date_demo2.py
run finance_demo.py

I think my original list had more by mistake. Here's a traceback (form ipython, so you get better details):

In [5]: run date_demo1.py

···

---------------------------------------------------------------------------
ValueError Traceback (most recent call last)

/home/fperez/code/python/pylab/examples/date_demo1.py
      26 yearsFmt = DateFormatter('%Y')
      27
---> 28 quotes = quotes_historical_yahoo(
      29 'INTC', date1, date2)
      30 if not quotes:

/usr/local/lib/python2.3/site-packages/matplotlib/finance.py in quotes_historical_yahoo(ticker, date1, date2)
      61 if len(vals)!=7: continue
      62 datestr = vals[0]
---> 63 dt = datetime.date(*time.strptime(datestr, '%d-%b-%y')[:3])
      64 d = date2num(dt)
      65 open, high, low, close = [float(val) for val in vals[1:5]]

/usr/src/build/394694-i386/install/usr/lib/python2.3/_strptime.py in strptime(data_string, format)
     422 found = format_regex.match(data_string)
     423 if not found:
--> 424 raise ValueError("time data did not match format: data=%s fmt=%s" %
     425 (data_string, format))
     426 if len(data_string) != found.end():

ValueError: time data did not match format: data=31-Mar-04 fmt=%d-%b-%y
WARNING: Failure executing file: <date_demo1.py>

The problem is that under different locales, dates come out formatted differently. You seem to have hardcoded format expectations which break in the face of non-US locales.

    > run print_stdout.py

This is an example script to show how to print png to stdout from agg.
Perhaps this fails because ipython doesn't really expect a png coming
in from stdout? The header of that file states

Well, running it again I'm getting this:

Exception in thread Thread-1:
Traceback (most recent call last):
   File "/usr/src/build/394694-i386/install/usr/lib/python2.3/threading.py", line 436, in __bootstrap
     self.run()
   File "/home/fperez/code/python/IPython/Shell.py", line 527, in run
     self.IP.mainloop()
   File "/home/fperez/code/python/IPython/iplib.py", line 948, in mainloop
     self.interact(banner)
   File "/home/fperez/code/python/IPython/iplib.py", line 1036, in interact
     line = self.raw_input(prompt)
   File "/home/fperez/code/python/IPython/iplib.py", line 1263, in raw_input
     return self.prefilter(raw_input(prompt),
IOError: [Errno 9] Ungültiger Dateideskriptor

Pehaps you could add (if you decide that you like that idea) the __IPYTHON__ trap code to this as well, so that all examples are made ipython-friendly. In this one, the message could additionally show this:

   print png to standard out
   usage: python print_stdout.py > somefile.png

so users know what to do straight away.

Thanks for the detailed notes.

No prob. I'm a big believer that good examples are what helps most new users, so I'm trying to make sure that out-of-the-box, things run as smoothly as possible for all those scientists who are just dying to start using matplotlib with ipython :slight_smile:

Best,

f