John Hunter schrieb:
>>>>>>"Fernando" =3D=3D Fernando Perez <Fernando.Perez@...> writ=
> Fernando> I think we're doing pretty good, except that people can
> Fernando> always kill themselves by running true WX/GTK apps via
> Fernando> @run. IPython is really not made for this, it can only
> Fernando> handle gracefully show() calls from pure matplotlib
> Fernando> scripts, not full-blown GUI apps. But I think we have a
> Fernando> very reasonable environment at this point for most usage
> Fernando> 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 whi=
traps invalid switches, so it's not a problem if a use() call is made. C=
you add such a call to this one please? :
// OK with GTKAgg backend. It needs a use('GTKAgg') call to be safe for o=
It's only when native GUI examples are run that things crash badly. Note=
some of the segfaults occur from plain python:
// these are OK with gtkagg, but they segfault wxagg. The segfault happe=
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 =
I suspect these two are messing something up badly enough that if python =
right away, you don't see the problem, but since ipython continues to run=
interpreter, the problem appears. Since these are segfaults, I'm very mu=
willing to blame the wx code in there, and not ipython (which is 100% pur=
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
> 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=20
combination is going to be a common one in the future for scientists, it =
be worth protecting the examples against disaster (given they tend to be =
people run to first). If you are willing to pay the price of 12 lines of=
per example, you could put this snippet at the beginning of _every_ embed=
# 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 =3D ("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 scr=
This will make sure that users get a meaningful error message inside ipyt=
instead of a bizarre lockup or segfault.
> I'll comment on some of the non cross-GUI problems below....
> Fernando> // These don't run with LANG=3D=3Dde_DE.UTF-8, but are OK
> Fernando> with en_US.UTF-8 run date_demo_convert.py run
> Fernando> date_demo1.py run date_demo2.py run date_demo_rrule.py
> Fernando> run finance_demo.py
> Do they run from the shell with LANG=3D=3Dde_DE.UTF-8? Any idea what i=
> going wrong?
Yes, the problem has nothing to do with ipython, it also happens with pla=
python. Note that the broken ones are:
// These don't run with LANG=3D=3Dde_DE.UTF-8, but are OK with en_US.UTF-=
I think my original list had more by mistake. Here's a traceback (form=20
ipython, so you get better details):
In : run date_demo1.py
ValueError Traceback (most recent call las=
26 yearsFmt =3D DateFormatter('%Y')
---> 28 quotes =3D quotes_historical_yahoo(
29 'INTC', date1, date2)
30 if not quotes:
quotes_historical_yahoo(ticker, date1, date2)
61 if len(vals)!=3D7: continue
62 datestr =3D vals
---> 63 dt =3D datetime.date(*time.strptime(datestr, '%d-%b-%y')[=
64 d =3D date2num(dt)
65 open, high, low, close =3D [float(val) for val in vals[=
422 found =3D format_regex.match(data_string)
423 if not found:
--> 424 raise ValueError("time data did not match format: data=3D=
425 (data_string, format))
426 if len(data_string) !=3D found.end():
ValueError: time data did not match format: data=3D31-Mar-04 fmt=3D%d-%=
WARNING: Failure executing file: <date_demo1.py>
The problem is that under different locales, dates come out formatted=20
differently. You seem to have hardcoded format expectations which break =
the face of non-US locales.
> Fernando> 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):
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 mainloo=
File "/home/fperez/code/python/IPython/iplib.py", line 1036, in intera=
line =3D self.raw_input(prompt)
File "/home/fperez/code/python/IPython/iplib.py", line 1263, in raw_in=
IOError: [Errno 9] Ung=FCltiger Dateideskriptor
Pehaps you could add (if you decide that you like that idea) the __IPYTHO=
trap code to this as well, so that all examples are made ipython-friendly=
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 u=
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 matpl=
with ipython :)