Menu
▾
▴
matplotlib-users
|
From: <and...@ti...> - 2005-04-09 13:35:54
|
Hello NGs, I probably found where the problem resides. As it is a wxPython+Matplo= tlib issue, I will send the mail to both newsgroups. The reason why my application does not terminates correctly on Windows 20= 00 while it terminates correctly on Windows XP does not depend on Windows ve= rsion, but on Matplotlib. I am not 100% sure, because here I only have (at the moment) Windows XP, but I found a difference between 2 Matplotlib install= ations I have. On XP, I have Matplotlib 0.73 prerelease (that WAS a prerelease 1 months ago, nearly), while on Windows 2000 I have Matplotlib 0.74. Well, I am using the WXAgg backend. By looking at backend_wx.py in 0.73pr= e (XP), I see that lines 116-117 are commented. These lines are: # wxapp =3D wxPySimpleApp() # wxapp.SetExitOnFrameDelete(True) While on Matplotlib 0.74 (2000) they are NOT commented. Well, in my app I don't need to initialize the wx.App() when calling plot/figure/Matplotl= ib things, because my app has ALREADY initialized the wx.App(). If I use Matplotlib (without wxPython) I will just add: import wx MyApp =3D wx.PySimpleApp() Before using any Matplotlib command. Is there a reason why these lines were commented on 0.73pre and now they are not? Robin/John, could it be that the reason for which my application= does not return under Windows 2000? Thanks to you all. Andrea. >and...@ti... wrote: >> Hello NG, >> >> It's incredible... after having found that my application correctl= y >> terminates if I add the line: >> >> self.MyTaskBarIcon.Destroy() >> >> on Windows XP, I am UNABLE to terminate it on Windows 2000. The main frame >> is correctly destroyed, together with its children, but there is still= >something >> alive that prevents Python to correctly finish and returning to me the= >control >> of the DOS console. >> The wxPython version is the same, the Python version is the same... th= e >> only differences between the 2 PC is the Windows version (XP=3Dwork, 2= 000=3Ddon't >> work) and the PC performances (XP=3D1GB RAM, 2000=3D528MB RAM). >> I used Spy++ and its friends and, after my app terminates, on 2000 the= re >> is still a window opened. This window has no class information, no par= ticular >> ID, only a size and position elements. There is no reason why the appl= ication >> behavior should be different. >> I don't even know which question I would formulate to you NG, it is a pain >> this continuous error-checking for a window/frame/panel that I didn't create >> and that wxPython thinks is still alive (only on Windows 2000). > >If you can create a small sample that shows the problem I can run it >under the debugger to see if I can spot what's going on. > >-- >Robin Dunn >Software Craftsman >http://wxPython.org Java give you jitters? Relax with wxPython! |
|
From: Robin D. <ro...@al...> - 2005-04-09 17:30:26
|
and...@ti... wrote: > On XP, I have Matplotlib 0.73 prerelease (that WAS a prerelease 1 months > ago, nearly), while on Windows 2000 I have Matplotlib 0.74. > Well, I am using the WXAgg backend. By looking at backend_wx.py in 0.73pre > (XP), I see that lines 116-117 are commented. These lines are: > > # wxapp = wxPySimpleApp() > # wxapp.SetExitOnFrameDelete(True) > > While on Matplotlib 0.74 (2000) they are NOT commented. Well, in my app > I don't need to initialize the wx.App() when calling plot/figure/Matplotlib > things, because my app has ALREADY initialized the wx.App(). > If I use Matplotlib (without wxPython) I will just add: > > import wx > MyApp = wx.PySimpleApp() > > Before using any Matplotlib command. > Is there a reason why these lines were commented on 0.73pre and now they > are not? Robin/John, could it be that the reason for which my application > does not return under Windows 2000? Yes. Having two app objects can certainly cause problems, although I wouldn't have expected it to manifest this way. Probably what is happening is that when the spashscreen is closed it is being added to the pending delete list but then the new app is being created and the pending delete list is reinitialized and so the splash screen never gets destroyed for real so the app's MainLoop keeps running waiting for it to be destroyed. To find out for sure you could try uncommenting those lines on your XP box and see if you then have the same problem. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! |
|
From: Chris B. <Chr...@no...> - 2005-04-10 05:29:07
|
>> (XP), I see that lines 116-117 are commented. These lines are:
>>
>> # wxapp = wxPySimpleApp()
>> # wxapp.SetExitOnFrameDelete(True)
The wxApp should NOT be created here! However, if there seems to be a
reason that it has to be, perhaps these lines could be surrounded by a
check to see if there is already a wxApp running.
Robin, is there a call to do that? Maybe:
if not wxGetApp():
wxapp = wxPySimpleApp()
wxapp.SetExitOnFrameDelete(True)
I just tested this quickly, and wxGetApp() returns None before app
creation, and a wxApp instance after, which returns True, so it should work.
For that matter, maybe wx.PySimpleApp() should check itself, and never
create a duplicate app.
By the way, it really should be:
import wx
wx.PySimpleApp()
etc.
Maybe I'll get around to cleaning up that code some day!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
|
|
From: Werner F. B. <wer...@fr...> - 2005-04-10 09:08:33
|
Hi Chris, Attached are three patches to convert things to the new wx namespace. I am very new to matplotlib, so it might be a good idea if someone with more matplotlib and wxPython experience checks these out. See you Werner Chris Barker wrote: > >>> (XP), I see that lines 116-117 are commented. These lines are: >>> >>> # wxapp = wxPySimpleApp() >>> # wxapp.SetExitOnFrameDelete(True) > > > The wxApp should NOT be created here! However, if there seems to be a > reason that it has to be, perhaps these lines could be surrounded by a > check to see if there is already a wxApp running. > > Robin, is there a call to do that? Maybe: > > if not wxGetApp(): > wxapp = wxPySimpleApp() > wxapp.SetExitOnFrameDelete(True) > > I just tested this quickly, and wxGetApp() returns None before app > creation, and a wxApp instance after, which returns True, so it should > work. > > For that matter, maybe wx.PySimpleApp() should check itself, and never > create a duplicate app. > > By the way, it really should be: > > import wx > > wx.PySimpleApp() > > etc. > > Maybe I'll get around to cleaning up that code some day! > > -Chris > > |
|
From: Werner F. B. <wer...@fr...> - 2005-04-10 17:00:22
|
Hi Chris, A small correction to the patch for backend_wx.py. if wxPlatform == '__WXMSW__': on line 638 or there abouts needs to be changed See you Werner Werner F. Bruhin wrote: > Hi Chris, > > Attached are three patches to convert things to the new wx namespace. I > am very new to matplotlib, so it might be a good idea if someone with > more matplotlib and wxPython experience checks these out. > > See you > Werner > > Chris Barker wrote: > >> >>>> (XP), I see that lines 116-117 are commented. These lines are: >>>> >>>> # wxapp = wxPySimpleApp() >>>> # wxapp.SetExitOnFrameDelete(True) >> >> >> >> The wxApp should NOT be created here! However, if there seems to be a >> reason that it has to be, perhaps these lines could be surrounded by a >> check to see if there is already a wxApp running. >> >> Robin, is there a call to do that? Maybe: >> >> if not wxGetApp(): >> wxapp = wxPySimpleApp() >> wxapp.SetExitOnFrameDelete(True) >> >> I just tested this quickly, and wxGetApp() returns None before app >> creation, and a wxApp instance after, which returns True, so it should >> work. >> >> For that matter, maybe wx.PySimpleApp() should check itself, and never >> create a duplicate app. >> >> By the way, it really should be: >> >> import wx >> >> wx.PySimpleApp() >> >> etc. >> >> Maybe I'll get around to cleaning up that code some day! >> >> -Chris >> >> > |
|
From: <and...@ti...> - 2005-04-10 20:36:13
|
Hello NGs, >and...@ti... wrote: > >> On XP, I have Matplotlib 0.73 prerelease (that WAS a prerelease 1 mont= hs >> ago, nearly), while on Windows 2000 I have Matplotlib 0.74. >> Well, I am using the WXAgg backend. By looking at backend_wx.py in 0.7= 3pre >> (XP), I see that lines 116-117 are commented. These lines are: >> >> # wxapp =3D wxPySimpleApp() >> # wxapp.SetExitOnFrameDelete(True) >> >Yes. Having two app objects can certainly cause problems, although I >wouldn't have expected it to manifest this way. Probably what is >happening is that when the spashscreen is closed it is being added to >the pending delete list but then the new app is being created and the >pending delete list is reinitialized and so the splash screen never gets= > >destroyed for real so the app's MainLoop keeps running waiting for it to= > >be destroyed. > >To find out for sure you could try uncommenting those lines on your XP >box and see if you then have the same problem. > Ok Robin, I've done what you suggested: on my XP box I uncommented the 2 lines, and the application does NOT returns. So I found where the problem= resides. It is not a wxPython nor a Windows issue, but a Matplotlib one. Now I will probably leave them commented or I will add the Chris patch (c= hecking if a wx.App is already started or not). Finding this inconsistency in Matplotlib was a 2 weeks nightmare. Thanks for all your suggestions, NGs. Andrea. |
|
From: John H. <jdh...@ac...> - 2005-04-11 14:45:40
|
OK, I spent some time looking at this morning and think I have a fix
that works for matplotlib wx API users as well as pylab users. For
the record, a little background.
The module matplotlib.backends.backend_wx contains all the classes to
enable matplotlib to be embedded in a wx application. There are two
modes this module is used in: application developers who want to
control the wx windows, panels, frames, etc, themselves, and pylab
users who want a matlab like environment in which all the figure
window, creation, etc, is managed for them.
To support the latter, all the matplotlib GUI backends are required to
define two functions
new_figure_manager - creates a new wxFrame
show - realizes/shows all frames
Jeremy O'Donoghue, who wrote the wx backend, and latter Matt Newville
who has been helping maintain it of late, tried putting the wxapp
instantiation in the show function, but this caused a segfault on some
platforms with some versions of wxpython (win32 with 2.4.x). We never
figured out the root cause of this since often times the person
developing/maintaining wx didn't have access to the buggy combination
of platform + version. So we left wxapp creation at the module level
which was ugly, hacky, and buggy, but at least it didn't seg fault.
Today I spent some time tracking down where and why the segfault was
occurring, and it was
new_figure_manager -> FigureFrameWx -> wxPanel.__init__
The call to wxPanel.__init__ trigged the segfault.
It appears the cause of this problem is that the wxapp must be created
before the wxPanel is init'ed. The solution is to put the wxapp
creation in new_figure_manager, not show, so that the app will be
created before the wxpanel. This appears to work. Here is what I am
currently doing
wxapp = None # module level
def new_figure_manager(num, *args, **kwargs):
global wxapp
if wxapp is None:
wxapp = wx.PySimpleApp()
wxapp.SetExitOnFrameDelete(True)
...snipsnip...
def show():
...snipsnip...
if show._needmain and not matplotlib.is_interactive():
if wxapp is not None: wxapp.MainLoop()
show._needmain = False
And this seems to work for pylab and wx apps. Since apps will never
call new_figure_manager or show, there should be no problem
If there is a better / more elegant / more wxlike way to do this, let
me know.
Thanks,
JDH
|
|
From: Matt N. <new...@ca...> - 2005-04-11 15:13:19
|
John, > It appears the cause of this problem is that the wxapp must be > created before the wxPanel is init'ed. The solution is to put > the wxapp creation in new_figure_manager, not show, so that > the app will be created before the wxpanel. This appears to > work. Here is what I am currently doing Yep, I think this is exactly the problem (though I could never reproduce it), and, like you say, creating wxapp in new_figure_manager() sounds like the right solution to me. I think this was part of the discussion with Marcin W. a month ago, no?? Anyway, in backend_tkagg (the closest analogy I'm familar with), Tk.Tk() is created in new_figure_manager. It seems that with other windowing systems, it's ok to create the mainApp (ie, who will run the event loop) if needed in show()??? Perhaps it would make sense to have this be more uniform across the different backends? Thanks, --Matt |
|
From: John H. <jdh...@ac...> - 2005-04-11 15:25:35
|
>>>>> "Matt" == Matt Newville <new...@ca...> writes:
Matt> Yep, I think this is exactly the problem (though I could
Matt> never reproduce it), and, like you say, creating wxapp in
Matt> new_figure_manager() sounds like the right solution to me.
Matt> I think this was part of the discussion with Marcin W. a
Matt> month ago, no?? Anyway, in backend_tkagg (the closest
Matt> analogy I'm familar with), Tk.Tk() is created in
Matt> new_figure_manager. It seems that with other windowing
Matt> systems, it's ok to create the mainApp (ie, who will run the
Matt> event loop) if needed in show()??? Perhaps it would make
Matt> sense to have this be more uniform across the different
Matt> backends?
I just committed the changes to CVS, and I'm going to attach them
here. Because I find these kinds of things sensitive to platform and
version, ex users should test these with wx and wxagg for both pylab
and the embedding_in_wx*.py examples and let me know if there are any
troubles.
As for making this more uniform, I'm inclined to leave this it up to
the various backends to handle gui instantiation in the way that they
see fit. I don't know enough about the various GUIs (and potential
GUIs we haven't encountered yet) to enforce a single policy. I did add
some guidance in the backend_template.py new_figure_manager function
along these lines
# if a main-level app must be created, this is the usual place to
# do it -- see backend_wx, backend_wxagg and backend_tkagg for
# examples. Not all GUIs require explicit instantiation of a
# main-level app (egg backend_gtk, backend_gtkagg) for pylab
Does this look helpful?
JDH
|
|
From: Matt N. <new...@ca...> - 2005-04-11 17:09:24
|
Hi John, These changes to backend_wx(agg).py seem ok to me. Trying to be conservative, I'm not entirely sure whether having the SetExitonFrameDelete() call is necessary (or perhaps more settings for the wxapp should be set....). What's pylab supposed to do in interactive mode if the user closes the plot window after show() but then wants to create and show() another figure? Is pylab supposed to automatically create another window and plot to that new window? This doesn't work for WX. > As for making this more uniform, I'm inclined to leave this it up to > the various backends to handle gui instantiation in the way that they > see fit. I don't know enough about the various GUIs (and potential > GUIs we haven't encountered yet) to enforce a single policy. I did add > some guidance in the backend_template.py new_figure_manager function > along these lines > > # if a main-level app must be created, this is the usual place to > # do it -- see backend_wx, backend_wxagg and backend_tkagg for > # examples. Not all GUIs require explicit instantiation of a > # main-level app (egg backend_gtk, backend_gtkagg) for pylab > > Does this look helpful? Yep, that seems useful. Thanks, --Matt |
|
From: John H. <jdh...@ac...> - 2005-04-11 17:19:19
|
>>>>> "Matt" == Matt Newville <new...@ca...> writes:
Matt> Hi John, These changes to backend_wx(agg).py seem ok to me.
Matt> Trying to be conservative, I'm not entirely sure whether
Matt> having the SetExitonFrameDelete() call is necessary (or
Matt> perhaps more settings for the wxapp should be set....).
Matt> What's pylab supposed to do in interactive mode if the user
Matt> closes the plot window after show() but then wants to create
Matt> and show() another figure? Is pylab supposed to
Matt> automatically create another window and plot to that new
Matt> window? This doesn't work for WX.
In interactive mode the user shouldn't call show --
http://matplotlib.sourceforge.net/faq.html#SHOW because the figures
will be automatically realized in interactive mode.
Using ipython pylab mode with WX or WXAgg as my default backend,
everything works as expected (eg I can close the window and the next
plot command creates a new one). If you ware testing interactively in
a standard python shell w/o proper threading support for wx, I'm not
sure what will happen but it's not officially a supported mode of
working. Some people do use show in this mode to try and make things
work, but I don't have much experience with it.
I also just tested backend : WX with interactive : True in pycrust and
it also worked (new windows created after close, no use of show)
JDH
|
|
From: Robin D. <ro...@al...> - 2005-04-11 19:01:41
|
John Hunter wrote: > wxapp = None # module level > > def new_figure_manager(num, *args, **kwargs): > global wxapp > if wxapp is None: > wxapp = wx.PySimpleApp() > wxapp.SetExitOnFrameDelete(True) > ...snipsnip... > > > > def show(): > ...snipsnip... > if show._needmain and not matplotlib.is_interactive(): > if wxapp is not None: wxapp.MainLoop() > show._needmain = False > > > And this seems to work for pylab and wx apps. Since apps will never > call new_figure_manager or show, there should be no problem > > > If there is a better / more elegant / more wxlike way to do this, let > me know. You should check wx.GetApp() to ensure that the app hasn't already been created in some other module. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! |
|
From: Matt N. <new...@ca...> - 2005-04-10 04:14:27
|
Andrea, > # wxapp =3D wxPySimpleApp() > # wxapp.SetExitOnFrameDelete(True) I commented out these lines in backend_wx.py and moved them into the show() function so that a wxPySimpleApp was not created when importing backend_wx.py. This was done to avoid the problem you saw, reported by someone else (I never saw this problem -- it seems to also to depend on wxPython version??). A few days later, John put it back the way it was (create wxPySimpleApp in the main portion of backend_wx.py). If I remember correctly, this was because *not* having these lines in the main section of backend_wx.py caused problems for some people using pylab. I cannot explain or defend why wxapp=3DwxPySimpleApp() should be run when importing backend_wx.py: it makes no sense to me. I can't see why it's a problem to create a wxPySimpleApp() only as a last resort, and only for interactive use. But I don't use the pylab interface much, so maybe I'm missing something. Sorry for the confusion. If you're not using the pylab interface, just comment out these lines from backend_wx.py. --Matt On Sat, 9 Apr 2005 and...@ti... wrote: > Hello NGs, >=20 > I probably found where the problem resides. As it is a wxPython+Matp= lotlib > issue, I will send the mail to both newsgroups. > The reason why my application does not terminates correctly on Windows = 2000 > while it terminates correctly on Windows XP does not depend on Windows = version, > but on Matplotlib. I am not 100% sure, because here I only have (at the > moment) Windows XP, but I found a difference between 2 Matplotlib insta= llations > I have. > On XP, I have Matplotlib 0.73 prerelease (that WAS a prerelease 1 month= s > ago, nearly), while on Windows 2000 I have Matplotlib 0.74. > Well, I am using the WXAgg backend. By looking at backend_wx.py in 0.73= pre > (XP), I see that lines 116-117 are commented. These lines are: >=20 > # wxapp =3D wxPySimpleApp() > # wxapp.SetExitOnFrameDelete(True) >=20 > While on Matplotlib 0.74 (2000) they are NOT commented. Well, in my app > I don't need to initialize the wx.App() when calling plot/figure/Matplo= tlib > things, because my app has ALREADY initialized the wx.App(). > If I use Matplotlib (without wxPython) I will just add: >=20 > import wx > MyApp =3D wx.PySimpleApp() >=20 > Before using any Matplotlib command. > Is there a reason why these lines were commented on 0.73pre and now the= y > are not? Robin/John, could it be that the reason for which my applicati= on > does not return under Windows 2000? >=20 > Thanks to you all. >=20 > Andrea. >=20 > >and...@ti... wrote: > >> Hello NG, > >>=20 > >> It's incredible... after having found that my application correc= tly > >> terminates if I add the line: > >>=20 > >> self.MyTaskBarIcon.Destroy() > >>=20 > >> on Windows XP, I am UNABLE to terminate it on Windows 2000. The main > frame > >> is correctly destroyed, together with its children, but there is sti= ll > >something > >> alive that prevents Python to correctly finish and returning to me t= he > >control > >> of the DOS console. > >> The wxPython version is the same, the Python version is the same... = the > >> only differences between the 2 PC is the Windows version (XP=3Dwork,= 2000=3Ddon't > >> work) and the PC performances (XP=3D1GB RAM, 2000=3D528MB RAM). > >> I used Spy++ and its friends and, after my app terminates, on 2000 t= here > >> is still a window opened. This window has no class information, no p= articular > >> ID, only a size and position elements. There is no reason why the ap= plication > >> behavior should be different. > >> I don't even know which question I would formulate to you NG, it is = a > pain > >> this continuous error-checking for a window/frame/panel that I didn'= t > create > >> and that wxPython thinks is still alive (only on Windows 2000). > > > >If you can create a small sample that shows the problem I can run it=20 > >under the debugger to see if I can spot what's going on. > > > >--=20 > >Robin Dunn > >Software Craftsman > >http://wxPython.org Java give you jitters? Relax with wxPython! >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >=20 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X