[SciPy-dev] New implementation for gui_thread

[Pearu Peterson]

Hi,

On Fri, 10 Oct 2003, Prabhu Ramachandran wrote:

> >>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:
> 
>     PP> I have succesfully finished implementing new hooks for
>     PP> importing wxPython to its own thread. The working idea is that
>     PP> all wxPython extension modules (that contain only low-level
>     PP> functions) are transparently replaced with wrappers that
>     PP> direct wx execution to a different thread so that Python
>     PP> prompt will be available for interactive work even when a
>     PP> wxPython application is running.
> 
> Nice!  I briefly looked at the code and from what I can see you
> transparently wrap the builtin functions used inside all the wxPython
> functions.  This means apply is wrapped and therefore everything works
> correctly?

Note that apply is not depreciated in Python and, I guess, because of 
this there were no apply usages in my installation of wxPython (Debian, 
unstable, Python 2.3). So, your idea simply replacing apply function
could not work, at least literally. 

But your observations what wxPython_thread does are correct. Wrapping
built-in functions are *much* simpler and robust than wrapping Python
classes (as it was done in old gui_thread) with all its methods and
implementation changes between various versions of Python etc. 

At first I worried that there will be a performance hit for another
function layer between Python and wxWindows but it turned out to be not
too bad.

Btw, a nice way to see how all these wx built-in functions are called is
to add the following line

      print 'In %(func_name)s [THREAD=',get_ident(),']'

just after

  def %(func_name)s(*args,**kws):

in wxPython_thread.py ;-)

> I've managed to work around the kiva_agg build problem by building the
> offending code with gcc-3.0.  How does one specify to python setup.py
> to choose gcc-3.0 instead of vanilla gcc?  Setting the environment
> variable CC does not appear to help.

I am using debian colorgcc hooks to achieve switching compilers:
I have the following files in my home directory:

# .colorgccrc-2.95.4
g++: /usr/bin/g++-2.95
gcc: /usr/bin/gcc-2.95
c++: /usr/bin/g++-2.95
cc:  /usr/bin/gcc-2.95

# ..colorgccrc-3.2
g++: /usr/bin/g++-3.2
gcc: /usr/bin/gcc-3.2
c++: /usr/bin/g++-3.2
cc:  /usr/bin/gcc-3.2

# .colorgccrc-3.3
g++: /usr/bin/g++-3.3
gcc: /usr/bin/gcc-3.3
c++: /usr/bin/g++-3.3
cc:  /usr/bin/gcc-3.3

and a link .colorgccrc to one of these files. Switching a compiler
means just changing this link.

> Anyway, the new gui_thread works really nicely.  I like the fact that
> you don't have to wait before you run the next statement since you
> wait while importing wxPython.  

Glad to here. I always considered this waiting part as a TODO item
in gui_thread..

> However, the new gui_thread appears to have trouble when quitting the
> interpreter:

> In [1]: from gui_thread import wxPython_thread; wxPython_thread()
> In [2]: from chaco.wxplt import *
> In [3]: p=plot([1,2])
> In [4]: close()
> In [5]: 
> Do you really want to exit ([y]/n)? 
> Exception in thread Thread-221:
> Traceback (most recent call last):
>   File "/usr/lib/python2.2/threading.py", line 408, in __bootstrap
>     self.run()
>   File "/usr/local/stow/scipy/lib/python2.2/site-packages/gui_thread/wxBackgroundApp.py", line 65, in run
>     exec self.cmd in self.globs,self.locs
>   File "<string>", line 1, in ?
> AttributeError: wxBackgroundApp instance has no attribute 'event_catcher'

This does not happen here with Python-2.3 (also tried ipython), so it 
could be due to Python-2.2.. I hope you can live with this until
I get a moment to rebuild scipy under Python-2.2 (and 2.1) and fix it.

Regards,
	Pearu