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
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
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).
And I also have these:
// these two run but segfault on exit under ipython. They run OK from a cmd line.
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
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
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.
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")
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
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
I think my original list had more by mistake. Here's a traceback (form ipython, so you get better details):
In : run date_demo1.py
ValueError Traceback (most recent call last)
26 yearsFmt = DateFormatter('%Y')
---> 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
---> 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
File "/home/fperez/code/python/IPython/Shell.py", line 527, in run
File "/home/fperez/code/python/IPython/iplib.py", line 948, in mainloop
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
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