[SciPy-dev] gui_thread issue

[eric jones]

Fernando Perez wrote:

> eric jones wrote:
>
>> Do we still have the problem that gui_thread can't be started from an 
>> IPython resource file so that the user doesn't explicitly have to 
>> call gui_thread.start() (or whatever)?  My initial attempts failed.
>> I just tried something like:
>>
>>     import gui_thread
>>     gui_thread.start()
>>     import time
>>     time.sleep(1) # any value here fails.
>>     import enthought.chaco.wxplt as plt
>
>
> Well, I just ran in ipython:
>
> In [1]: import gui_thread
>
> In [2]: gui_thread.start()
> <Importing wxPython...  done.>
> >>>
>
> In [3]: import time
>
> In [4]: time.sleep(1)
>
> In [5]:
>
> and it looks just fine.  I can't test the enthought import, since I 
> don't have that code installed myself. Note, however, that upon exit 
> the follwing nasty gets printed on my laptop, which is running a 
> slightly outdated version of scipy:
>
> Exception wxPython.wxc.wxPyAssertionError: u'C++ assertion 
> "wxThread::IsMain()" failed in 
> /usr/src/redhat/BUILD/wxPythonSrc-2.4.2.4/src/unix/threadpsx.cpp(1618): 
> only main thread can be here' in <bound method __wxPyCleanup.__del__ 
> of <wxPython.wx.__wxPyCleanup instance at 0x9d60984>> ignored
>
> Things seem to quit normally, though.  On my office desktop, with 
> recent CVS scipy, it all seems to work perfectly (no ugly error on quit).
>
> I can also start the gui_thread from an ipython resource file without 
> any problems:
>
>
> [~]> ipython -p gui_thread
> Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.6.4.rc4 -- An enhanced Interactive Python.
> ?       -> Introduction to IPython's features.
> %magic  -> Information about IPython's 'magic' % functions.
> help    -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
>
> IPython profile: gui_thread
>
> *** Starting gui_thread...
> <Importing wxPython...  done.>
> >>>
> In [1]: import time
>
> In [2]: time.sleep(1)
>
> In [3]: 99+1
> Out[3]: 100
>
> where the gui_thread profile is:
>
>
> [~/.ipython]> cat ipythonrc-gui_thread
> # -*- Mode: Shell-Script -*-  Not really, but shows comments correctly
>
> # include base config and only add some extras
> include ipythonrc
>
> # import the gui_thread module first
> import_mod gui_thread
>
> # code to execute: activate gui_thread before the user gets a prompt
> execute print "*** Starting gui_thread..."
> execute gui_thread.start()
>
>
> So on linux, with reasonably recent CVS scipy, the gui_thread support 
> seems quite good.  The improvements recently discussed in this thread 
> would be a usability gain (import gui_thread.start & friends), but the 
> functionality seems to be there.
>
>> and I get an error that wxPython is already imported (by the wxplt 
>> call I'm sure).  This all brought dredged up unpleasant memories that 
>> are documented here:
>>
>>     
>> http://www.scipy.org/mailinglists/mailman?fn=scipy-cvs/2002-October/000593.html 
>>
>>
>> Fernando, did you figure out a way around all this import/thread 
>> madness when you were working with matplotlib?  The patch I had never 
>> made it into Python 1.5.2, and I haven't tried it anytime recently.  
>> I'm hoping Fernando has a less intrusive solution...
>
>
> Good grief, that thread made my head spin.  I never really got 
> anything fancy going.  The matplotlib hack is completely specific to 
> matplotlib, because ipython and matplotlib are basically cooperating.  
> John added a flag inside the matplotlib code to indicate who is in 
> control of the mainloop, and when ipython runs in -pylab mode, ipython 
> handles this.  So while the solution works quite well for the end user 
> (both with WX and with GTK), it is not a generic WX one, since it 
> hinges on specific cooperation between the two programs.
>
> As far as I could tell, the only way to obtain a generic solution for 
> arbitrary third-party WX code is the complex solution which gui_thread 
> implements.  But seeing how this can be encapsulated in an ipython 
> resource file, I don't think it's such a problem.  And with Prabhu and 
> Pearu's recent enhancements, gui_thread seems to be working extremely 
> well, as they can run the full gamut of WX demos.

Yes, to be clear, gui_thread.start() works fine in my resource files as 
well.  The problem comes up when you want to import gui_thread as well 
as a wxPython module (like enthought.chaco.wxplt) as well from within 
the resource file.  So, putting something like:

import_mod gui_thread
execute gui_thread.start()
import_some enthought.chaco wxplt

in a resource file results in the enthought.chaco.wxplt import happening 
before the gui_thread.start() import can get the background thread 
started up in the background.  Thus, the initial wx import happens on 
the may thread instead of the background thread (bad news).  The ideal 
solution is for gui_thread.start() not to return until the background 
thread is set up correctly, but, as I remember, the import lock 
discussed in the email thread I pointed at prevents this from working.  
It has been a while though since I've looked at this, so I'll have 
another look today.

Note that if I do the gui_thread import and start() in a resource file 
and then do the "from enthought.chaco.wxplt import plt" stuff from the 
command line after IPython starts up, all works fine.  I just want to 
get the plt import moved into the resource file so users don't have to 
type it... 

By the way, at least the simple examples I've tried (popping a few plots 
up) using gui_thread and IPython have worked fine with Python Enthought 
Edition (wx 2.4.1.4) and the latest CVS of gui_thread.

thanks,
eric

>
> Best,
>
> f
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev