[IPython-user] pysh is in CVS
vivainio at kolumbus.fi
Mon Jun 28 16:31:35 CDT 2004
Fernando Perez wrote:
> Seriously, the current pysh functionality is about as far as I can
> afford to push it myself. It works great for me,
Fair enough. I imagine other people might want to help too, esp. after
you do that codebase cleanup you've been talking about so that the
modifications don't need to be rewritten for the new architecture. And
you should really post a PR article on c.l.py about the newfound shell
> My next item is a multithreaded ipython so I can use matplotlib
> interactively with a GTK frontend. This will allow anyone to run
> GTK/Wx apps from within ipython without the GUI loop blocking ipython
> itself. I had a stab at it Saturday evening but I failed, I'll try
> again over the next few weeks. Since I've never written a line of
> multithreaded code, it will take me a bit of effort I'm sure.
Well, in some toolkits at least all the drawing commands need to be done
from the same thread (since X is single-threaded). I imagine you
weren't trying to execute actual GUI code from the ipython thread?
> my field) that I envision and which we discussed a while back with
> Ero's Texmacs example. Since that's the direction _I_ will be pushing
> things in, fancy shell functionality will have to be done by others.
> I already broke my
As long as you see shell functionality as desirable (and will accept
patches to implement that), it's all well and good.
>> Yup, pysh seemed to work alright. One thing that is still noticeably
>> slower than on bash is changing the directory with "cd" - on a slow
>> machine you have enough time to type "ls" and blink an eye before
>> ipython shows
> I'm afraid there's not much I can do here. All the niceties of
> ipython come at a price: the inner loop is a very complicated piece of
> code, with string analysis, regexp checks, multiple try/excepts, etc.
> None of this is
I could almost swear the delay was because of i/o. Executing normal
statements was instantaneous even on the slow machine, so I wouldn't be
so quick to blame the inner loop. I took a look at magic_cd, and the
call to parse_options catches my eye. Apparently parse_options does lots
of nasty stuff (like starts another python interpreter in a new shell).
That's a big hit on slow machines. IMO magic_cd should just do trivial
option parsing completely in python (current process), shell expansion
is not really needed .
I changed line 1865 of Magic.py (in cvs) to:
i.e. I added use_shell = False. It might break something, but boy, does
it speed it up on my slow machine.
More information about the IPython-user