From: phil r. <phi...@ya...> - 2013-02-21 15:31:55
|
I think there are a few complexities around when closing the final windows in wxWidgets. I don't know if you remember some months ago a user reporting memory leaks with the wxWidgets examples. I think this came down to the fact that wxWidgets ends the program when its final window is closed without passing control back to the example code meaning that memory allocated there was never released. Perhaps the issues are linked - something to do with wxwidgets have done all its cleaning up, but PLplot expecting to be able to reinitiate something? If you would like me to have a look into it then if you drop me the segfault example I'll see what it does on my (Windows) system. Phil |
From: phil r. <phi...@ya...> - 2013-02-21 23:14:28
|
Thanks for the report Fulvio In that case I will download a clean version of plplot tomorrow and check how it works with that. Unfortunately I do almost all my coding on a windows environment - mostly because the debugging tools are so good. Speak soon Phil ________________________________ From: fulvio ciriaco <ful...@un...> To: phi...@ya... Cc: plp...@li...; ful...@us... Sent: Thursday, 21 February 2013, 20:41 Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Hallo, thank you, but the patch does not work here, i.e. debian. I applied it to plplot latest from sourceforge: a. it still segfaults as soon as drawing after calling plinit second time b. does not correctly tidy up, i.e. close the window after plend Fulvio From: phil rosenberg <phi...@ya...> Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Date: Thu, 21 Feb 2013 09:52:51 -0800 (PST) > I just tweaked example 00c so that after plend() the gui the plot creation is repeated starting with plinit(). > The segfault problem is caused by the static install_buffer function in wxwidgets.cpp. There is a static bool called initApp which is set to true on the first call to plinit(). Because the variable is local it can't be reset to false by plend() so wxWidgets does its tidying, destroys the wxApp but on the second call to plinit the wxApp is not recreated giving a segfault when the top level frame tries to access it. > > I've move initApp into wxPLDevBase and the segfault is now avoided. > > I've attached a patch, but my copy of PLplot currently has a few modifications and isn't quite up to date so if it won't apply please let me know and I'll download a fresh copy to patch instead. > > Phil > > > ________________________________ > From: phil rosenberg <phi...@ya...> > To: "plp...@li..." <plp...@li...>; "ful...@us..." <ful...@us...> > Sent: Thursday, 21 February 2013, 15:31 > Subject: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window > > > I think there are a few complexities around when closing the final windows in wxWidgets. I don't know if you remember some months ago a user reporting memory leaks with the wxWidgets examples. I think this came down to the fact that wxWidgets ends the program when its final window is closed without passing control back to the example code meaning that memory allocated there was never released. Perhaps the issues are linked - something to do with wxwidgets have done all its cleaning up, but PLplot expecting to be able to reinitiate something? > If you would like me to have a look into it then if you drop me the segfault example I'll see what it does on my (Windows) system. > > Phil |
From: phil r. <phi...@ya...> - 2013-02-23 00:19:26
|
Hi All I've just tested the situation with a fresh download of the latest plplot source using the test from Fulvio. As I'm on Windows I had to replace sleep(3) with Sleep(3000) and #include<windows.h>, but that should make no difference to the behaviour. Without the patch the plot appears fine the first time, closes immediately if I right click off a plot and then fails when trying to access a null pointer when I try to display the plots again. With the patch the plot appears fine the first time, closes immediately if I right click the plot. It then appears fine the second time, closes immediately when I right click off a plot - there is then a 3 second wait at the command line before the example exits. As far as I can tell this is exactly the expected behaviour. I've tested both release and debug builds. I'm not really sure where to go next. It's not easy to fix a bug that I can't reproduced. Unfortunately I don't have the time at the moment to set up plplot on a linux machine. Does someone happen to be able to run the test in a debugger e.g. by using Eclipse? In this case the debugger should catch the segfault and show the exact line where it occurs, and be able to see the call stack (you may need the development version of wxWidgets with source code). On Windows it is in a wxwidgets file called toplevel in the CreateFrame member of a class called wxTopLevelWindowMSW. I guess it's not surprising the bug is slightly different on Linux then :-). This was called by wxFrame::Create() which was in turn called by the wxFrame constructor. Fundamentally it's caused by the wxTheApp macro or wxApp::GetInstance() returning NULL because wxWidgets isn't initialised. Knowing where the crash occurs in linux and if it's for the same reason would be a good start at least. Some possible lines of enquirey though if no one has access to a debugger. Maybe you could try these Fulvio 1) Which version of wxWidgets are you using? I have 2.8.10. 2) What is the behaviour if you close the first plot by clicking the x of selecting exit from the menu? For me this exits the entire application. 3) Try comment out lines 1396 and 1397 of wxwidgets.cpp - these should be wxPLGetApp().OnExit(); and plexit( "" );. Now what is the behaviour after closing the first window using the x or selecting Exit from the menu. 4) Finaly what is the behaviour for item 3 if the patch has been applied? Sorry we're not at the root cause yet Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: phil rosenberg <phi...@ya...> Cc: fulvio ciriaco <ful...@un...>; "plp...@li..." <plp...@li...>; "ful...@us..." <ful...@us...> Sent: Friday, 22 February 2013, 0:40 Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window On 2013-02-21 15:14-0800 phil rosenberg wrote: > Thanks for the report Fulvio > In that case I will download a clean version of plplot tomorrow and check how it works with that. Unfortunately I do almost all my coding on a windows environment - mostly because the debugging tools are so good. > > Speak soon > Phil Hi Phil: I confirm fulvio's results on my own Debian (wheezy) system. With Fulvio's test.c example the wxwidgets (wxGC) GUI from the first plinit does not disappear, and the second plinit segfaults. These (bad) results occur regardless of whether your wxwidgets patch is applied or not. So I suspect your wxwidgets patch (which, by the way, does apply cleanly to the svn trunk version of PLplot) addresses part of the issue but not all of it. Will you try test.c yourself for testing purposes rather than your modified x00c ? I have attached a slightly modified form of it here (plwid ==> plwidth is required for the trunk version) for your convenience. Note I have tried this test.c for a number of interactive devices and the only device where there are issues appears to be wxwidgets. Note, I normally run the default backend=2 (wxGC) but I also just now tried -drvopt backend=0 (basic) and got the same (bad) results with test.c. I have not tried backend=1 (AGG) for the wxwidgets device because the AGG library is not installed on my system. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: fulvio c. <oi...@gm...> - 2013-02-23 17:59:07
|
Hallo, it seems to me that the message coming from the ~wxPLDevGC was due to deleting wxPLDevGC after calling wxuninitialize. In fact, reverting the things the message disappears, but the ill behaviour is still there. The backtrace of segfault: #0 0x00007ff9b206c6ff in _L_unlock_532 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ff9b206c704 in _L_unlock_532 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007ff9b206c634 in __pthread_mutex_unlock_usercnt (mutex=0xd1b6f0, decr=<optimized out>) at pthread_mutex_unlock.c:52 #3 0x00007ff9b301f44e in wxMutexInternal::Unlock (this=0xd1b6f0) at ../src/unix/threadpsx.cpp:297 #4 0x00007ff9b3021c10 in wxMutex::Unlock (this=0xbfb280) at ../include/wx/thrimpl.cpp:60 #5 0x00007ff9b3021a34 in wxMutexGuiLeave () at ../src/unix/threadpsx.cpp:1737 #6 0x00007ff9b29e3116 in wxapp_poll_func (ufds=0xd29a60, nfds=2, timeout=0) at ../src/gtk/app.cpp:263 ...............174600 equal calls of wxapp_poll_func #174608 0x00007ff9b29e3136 in wxapp_poll_func (ufds=0xd29a60, nfds=2, timeout=0) at ../src/gtk/app.cpp:266 #174609 0x00007ff9b0023624 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #174610 0x00007ff9b0023a82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #174611 0x00007ff9b1b5f797 in IA__gtk_main () at /tmp/buildd/gtk+2.0-2.24.10/gtk/gtkmain.c:1256 #174612 0x00007ff9b29ff02b in wxEventLoop::Run (this=0xc5a690) at ../src/gtk/evtloop.cpp:76 #174613 0x00007ff9b2a971d3 in wxAppBase::MainLoop (this=0xd25e40) at ../src/common/appcmn.cpp:312 #174614 0x00007ff9b2a9734a in wxAppBase::OnRun (this=0xd25e40) at ../src/common/appcmn.cpp:367 #174615 0x00007ff9b32f03f9 in wxRunApp (pls=0x7ff9b4ec17e0, runonce=false) at /home/fc/Downloads/plplot-5.9.9/drivers/wxwidgets.cpp:1371 #174616 0x00007ff9b32ef042 in plD_eop_wxwidgets (pls=0x7ff9b4ec17e0) at /home/fc/Downloads/plplot-5.9.9/drivers/wxwidgets.cpp:685 #174617 0x00007ff9b4c65fcf in plP_eop () at /home/fc/Downloads/plplot-5.9.9/src/plcore.c:174 #174618 0x00007ff9b4c6bed7 in c_plend1 () at /home/fc/Downloads/plplot-5.9.9/src/plcore.c:2427 #174619 0x00007ff9b4c6ba1c in c_plend () at /home/fc/Downloads/plplot-5.9.9/src/plcore.c:2377 #174620 0x0000000000400f19 in do_it_once () #174621 0x0000000000400f6a in main () Fulvio From: phil rosenberg <phi...@ya...> Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Date: Fri, 22 Feb 2013 16:19:18 -0800 (PST) > Hi All > I've just tested the situation with a fresh download of the latest plplot source using the test from Fulvio. As I'm on Windows I had to replace sleep(3) with Sleep(3000) and #include<windows.h>, but that should make no difference to the behaviour. > > Without the patch the plot appears fine the first time, closes immediately if I right click off a plot and then fails when trying to access a null pointer when I try to display the plots again. > > With the patch the plot appears fine the first time, closes immediately if I right click the plot. It then appears fine the second time, closes immediately when I right click off a plot - there is then a 3 second wait at the command line before the example exits. As far as I can tell this is exactly the expected behaviour. I've tested both release and debug builds. > > I'm not really sure where to go next. It's not easy to fix a bug that I can't reproduced. Unfortunately I don't have the time at the moment to set up plplot on a linux machine. > Does someone happen to be able to run the test in a debugger e.g. by using Eclipse? In this case the debugger should catch the segfault and show the exact line where it occurs, and be able to see the call stack (you may need the development version of wxWidgets with source code). On Windows it is in a wxwidgets file called toplevel in the CreateFrame member of a class called wxTopLevelWindowMSW. I guess it's not surprising the bug is slightly different on Linux then :-). > This was called by wxFrame::Create() which was in turn called by the wxFrame constructor. Fundamentally it's caused by the wxTheApp macro or wxApp::GetInstance() returning NULL because wxWidgets isn't initialised. Knowing where the crash occurs in linux and if it's for the same reason would be a good start at least. > > Some possible lines of enquirey though if no one has access to a debugger. Maybe you could try these Fulvio > 1) Which version of wxWidgets are you using? I have 2.8.10. > 2) What is the behaviour if you close the first plot by clicking the x of selecting exit from the menu? For me this exits the entire application. > 3) Try comment out lines 1396 and 1397 of wxwidgets.cpp - these should be wxPLGetApp().OnExit(); and plexit( "" );. Now what is the behaviour after closing the first window using the x or selecting Exit from the menu. > 4) Finaly what is the behaviour for item 3 if the patch has been applied? > > Sorry we're not at the root cause yet > > Phil > > > > ________________________________ > From: Alan W. Irwin <ir...@be...> > To: phil rosenberg <phi...@ya...> > Cc: fulvio ciriaco <ful...@un...>; "plp...@li..." <plp...@li...>; "ful...@us..." <ful...@us...> > Sent: Friday, 22 February 2013, 0:40 > Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window > > On 2013-02-21 15:14-0800 phil rosenberg wrote: > >> Thanks for the report Fulvio >> In that case I will download a clean version of plplot tomorrow and check how it works with that. Unfortunately I do almost all my coding on a windows environment - mostly because the debugging tools are so good. >> >> Speak soon >> Phil > > Hi Phil: > > I confirm fulvio's results on my own Debian (wheezy) system. With > Fulvio's test.c example the wxwidgets (wxGC) GUI from the first plinit > does not disappear, and the second plinit segfaults. These (bad) > results occur regardless of whether your wxwidgets patch is applied > or not. > > So I suspect your wxwidgets patch (which, by the way, does apply > cleanly to the svn trunk version of PLplot) addresses part of the > issue but not all of it. > > Will you try test.c yourself for testing purposes rather than your > modified x00c ? I have attached a slightly modified form of it here > (plwid ==> plwidth is required for the trunk version) for your > convenience. Note I have tried this test.c for a number of interactive > devices and the only device where there are issues appears to be > wxwidgets. > > Note, I normally run the default backend=2 (wxGC) but I also just now > tried -drvopt backend=0 (basic) and got the same (bad) results with > test.c. I have not tried backend=1 (AGG) for the wxwidgets device > because the AGG library is not installed on my system. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ |
From: phil r. <phi...@ya...> - 2013-02-24 01:03:04
|
Okay, well I've got plplot roughly setup on my Linux box at home - the reason why it's not easy is that this box is a media centre connected to my TV (no proper monitor) running Ubuntu 10.04 (which has a version of CMAKE too old to build plplot). Anyway I've made a bit of progress. The Eclipse debugger (not sure what it uses) shows the segfault occurring at wxWindow::SetLayoutDirection which is the same place I saw the fault occurring on my windows system. Applying the patch cures this fault, but another still exists. My system sees similar symptoms - first window doesn't close, segfault when second window tries to open. The error seems to occur when the wxApp::OnRun function is called which starts the event loop I think. I don't have wxWidget sources on my system to dive too deep. My first port of call was that the window seems to be "orphaned" - meaning thewindow was still there but with no event loop passing it messages leaving it unresponsive. I can get the first winow to disappear at the correct time by Destroy()ing it in wxPlPlotApp::OnIdle before calling ExitMainLoop(). I guess under windows wxUninitialize or ExitMainLoop() dealt with orphaned windows automatically. However when I create the second widow it fails to render then after a few seconds I still get a segfault. The segfault occurs sometime after starting the event loop, but I haven't been able to work out where. I should now be able to supply a patch that give correct operation and closure of a single window and allows the console to continue running without the orphaned window. Would you like that as a patch now with possibly more to follow? Phil ________________________________ From: fulvio ciriaco <oi...@gm...> To: phi...@ya... Cc: ir...@be...; plp...@li...; ful...@us... Sent: Saturday, 23 February 2013, 17:58 Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Hallo, it seems to me that the message coming from the ~wxPLDevGC was due to deleting wxPLDevGC after calling wxuninitialize. In fact, reverting the things the message disappears, but the ill behaviour is still there. The backtrace of segfault: #0 0x00007ff9b206c6ff in _L_unlock_532 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ff9b206c704 in _L_unlock_532 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007ff9b206c634 in __pthread_mutex_unlock_usercnt (mutex=0xd1b6f0, decr=<optimized out>) at pthread_mutex_unlock.c:52 #3 0x00007ff9b301f44e in wxMutexInternal::Unlock (this=0xd1b6f0) at ../src/unix/threadpsx.cpp:297 #4 0x00007ff9b3021c10 in wxMutex::Unlock (this=0xbfb280) at ../include/wx/thrimpl.cpp:60 #5 0x00007ff9b3021a34 in wxMutexGuiLeave () at ../src/unix/threadpsx.cpp:1737 #6 0x00007ff9b29e3116 in wxapp_poll_func (ufds=0xd29a60, nfds=2, timeout=0) at ../src/gtk/app.cpp:263 ...............174600 equal calls of wxapp_poll_func #174608 0x00007ff9b29e3136 in wxapp_poll_func (ufds=0xd29a60, nfds=2, timeout=0) at ../src/gtk/app.cpp:266 #174609 0x00007ff9b0023624 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #174610 0x00007ff9b0023a82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #174611 0x00007ff9b1b5f797 in IA__gtk_main () at /tmp/buildd/gtk+2.0-2.24.10/gtk/gtkmain.c:1256 #174612 0x00007ff9b29ff02b in wxEventLoop::Run (this=0xc5a690) at ../src/gtk/evtloop.cpp:76 #174613 0x00007ff9b2a971d3 in wxAppBase::MainLoop (this=0xd25e40) at ../src/common/appcmn.cpp:312 #174614 0x00007ff9b2a9734a in wxAppBase::OnRun (this=0xd25e40) at ../src/common/appcmn.cpp:367 #174615 0x00007ff9b32f03f9 in wxRunApp (pls=0x7ff9b4ec17e0, runonce=false) at /home/fc/Downloads/plplot-5.9.9/drivers/wxwidgets.cpp:1371 #174616 0x00007ff9b32ef042 in plD_eop_wxwidgets (pls=0x7ff9b4ec17e0) at /home/fc/Downloads/plplot-5.9.9/drivers/wxwidgets.cpp:685 #174617 0x00007ff9b4c65fcf in plP_eop () at /home/fc/Downloads/plplot-5.9.9/src/plcore.c:174 #174618 0x00007ff9b4c6bed7 in c_plend1 () at /home/fc/Downloads/plplot-5.9.9/src/plcore.c:2427 #174619 0x00007ff9b4c6ba1c in c_plend () at /home/fc/Downloads/plplot-5.9.9/src/plcore.c:2377 #174620 0x0000000000400f19 in do_it_once () #174621 0x0000000000400f6a in main () Fulvio From: phil rosenberg <phi...@ya...> Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Date: Fri, 22 Feb 2013 16:19:18 -0800 (PST) > Hi All > I've just tested the situation with a fresh download of the latest plplot source using the test from Fulvio. As I'm on Windows I had to replace sleep(3) with Sleep(3000) and #include<windows.h>, but that should make no difference to the behaviour. > > Without the patch the plot appears fine the first time, closes immediately if I right click off a plot and then fails when trying to access a null pointer when I try to display the plots again. > > With the patch the plot appears fine the first time, closes immediately if I right click the plot. It then appears fine the second time, closes immediately when I right click off a plot - there is then a 3 second wait at the command line before the example exits. As far as I can tell this is exactly the expected behaviour. I've tested both release and debug builds. > > I'm not really sure where to go next. It's not easy to fix a bug that I can't reproduced. Unfortunately I don't have the time at the moment to set up plplot on a linux machine. > Does someone happen to be able to run the test in a debugger e.g. by using Eclipse? In this case the debugger should catch the segfault and show the exact line where it occurs, and be able to see the call stack (you may need the development version of wxWidgets with source code). On Windows it is in a wxwidgets file called toplevel in the CreateFrame member of a class called wxTopLevelWindowMSW. I guess it's not surprising the bug is slightly different on Linux then :-). > This was called by wxFrame::Create() which was in turn called by the wxFrame constructor. Fundamentally it's caused by the wxTheApp macro or wxApp::GetInstance() returning NULL because wxWidgets isn't initialised. Knowing where the crash occurs in linux and if it's for the same reason would be a good start at least. > > Some possible lines of enquirey though if no one has access to a debugger. Maybe you could try these Fulvio > 1) Which version of wxWidgets are you using? I have 2.8.10. > 2) What is the behaviour if you close the first plot by clicking the x of selecting exit from the menu? For me this exits the entire application. > 3) Try comment out lines 1396 and 1397 of wxwidgets.cpp - these should be wxPLGetApp().OnExit(); and plexit( "" );. Now what is the behaviour after closing the first window using the x or selecting Exit from the menu. > 4) Finaly what is the behaviour for item 3 if the patch has been applied? > > Sorry we're not at the root cause yet > > Phil > > > > ________________________________ > From: Alan W. Irwin <ir...@be...> > To: phil rosenberg <phi...@ya...> > Cc: fulvio ciriaco <ful...@un...>; "plp...@li..." <plp...@li...>; "ful...@us..." <ful...@us...> > Sent: Friday, 22 February 2013, 0:40 > Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window > > On 2013-02-21 15:14-0800 phil rosenberg wrote: > >> Thanks for the report Fulvio >> In that case I will download a clean version of plplot tomorrow and check how it works with that. Unfortunately I do almost all my coding on a windows environment - mostly because the debugging tools are so good. >> >> Speak soon >> Phil > > Hi Phil: > > I confirm fulvio's results on my own Debian (wheezy) system. With > Fulvio's test.c example the wxwidgets (wxGC) GUI from the first plinit > does not disappear, and the second plinit segfaults. These (bad) > results occur regardless of whether your wxwidgets patch is applied > or not. > > So I suspect your wxwidgets patch (which, by the way, does apply > cleanly to the svn trunk version of PLplot) addresses part of the > issue but not all of it. > > Will you try test.c yourself for testing purposes rather than your > modified x00c ? I have attached a slightly modified form of it here > (plwid ==> plwidth is required for the trunk version) for your > convenience. Note I have tried this test.c for a number of interactive > devices and the only device where there are issues appears to be > wxwidgets. > > Note, I normally run the default backend=2 (wxGC) but I also just now > tried -drvopt backend=0 (basic) and got the same (bad) results with > test.c. I have not tried backend=1 (AGG) for the wxwidgets device > because the AGG library is not installed on my system. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ |
From: phil r. <phi...@ya...> - 2013-02-24 22:55:47
|
Hi All Sorry, but I've done some more testing today and unfortunately my current patch causes problems if the user creates two streams running alongside each other. Currently I don't think wxPLPlotApp has sufficient awareness of the streams and frames to deal with all this correctly. This is going to require some restructuring work I think to get right. Also unfortunately, despite installing wxWidgets from source on my Ubuntu box I'm still not able to step throught he wxWidgets code in the debugger in Eclipse. If anyone else on the list knows how I can set this up I'd be happy to listen. I'm jus too used to Windows I guess. Fulvio - If you need to get PLplot working with wxWidgets in a hurry you can still create a wxWidgets application initialize plplot with one of the wxWidget drivers to get a wxBitmap or wxImage and use OnPaint to paint this to screen - it's how I usually use PLplot. It doesn't suffer the same problems as there is no mixing of console and gui elements. Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: phil rosenberg <phi...@ya...> Cc: Werner Smekal <wer...@mi...>; Werner Smekal <sm...@ia...>; fulvio ciriaco <oi...@gm...>; "plp...@li..." <plp...@li...>; "ful...@us..." <ful...@us...> Sent: Sunday, 24 February 2013, 5:48 Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window On 2013-02-23 17:02-0800 phil rosenberg wrote: > I should now be able to supply a patch that give correct operation and closure of a single window and allows the console to continue running without the orphaned window. Would you like that as a patch now with possibly more to follow? Hi Phil: Please go ahead and send your proposed patch as an attachment to this list. I don't understand the wxwidgets device driver that well, but if I find here that your patch builds and runs using all our standard C examples without issues on Linux (using the test_c_wxwidgets target) as well as reducing the test.c issues like you describe, then I would be strongly inclined to apply it. Of course, I would also follow the advice of Werner (who is familiar with the wxwidgets code since he is its original implementer) concerning your proposed patch _if_ he gets in touch. There has been no response to my first attempt to contact him, and in fact it appears that the SourceForge mailer filtered out the CC to him for some reason. So this time, I am CCing to the last two known addresses for him to see if that will get a response. But meanwhile, Phil, please send your patch so I can try the test_c_wxwidgets target with it (and you may want to try that target yourself on Linux first (using "make test_c_wxwidgets" if you have first run cmake with the -DBUILD_TEST=ON option). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: fulvio c. <oi...@gm...> - 2013-02-25 21:07:20
|
Thank you phil, I am in a hurry, actually but plplot offers so many drivers! I think I will stick with tk for the moment, because it offers (like wx) the students the capability to take a hardcopy of their preferred pictures. Fulvio From: phil rosenberg <phi...@ya...> Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Date: Sun, 24 Feb 2013 14:55:07 -0800 (PST) > Hi All > Sorry, but I've done some more testing today and unfortunately my current patch causes problems if the user creates two streams running alongside each other. Currently I don't think wxPLPlotApp has sufficient awareness of the streams and frames to deal with all this correctly. This is going to require some restructuring work I think to get right. > > Also unfortunately, despite installing wxWidgets from source on my Ubuntu box I'm still not able to step throught he wxWidgets code in the debugger in Eclipse. If anyone else on the list knows how I can set this up I'd be happy to listen. I'm jus too used to Windows I guess. > > Fulvio - If you need to get PLplot working with wxWidgets in a hurry you can still create a wxWidgets application initialize plplot with one of the wxWidget drivers to get a wxBitmap or wxImage and use OnPaint to paint this to screen - it's how I usually use PLplot. It doesn't suffer the same problems as there is no mixing of console and gui elements. > > Phil > > > ________________________________ > From: Alan W. Irwin <ir...@be...> > To: phil rosenberg <phi...@ya...> > Cc: Werner Smekal <wer...@mi...>; Werner Smekal <sm...@ia...>; fulvio ciriaco <oi...@gm...>; "plp...@li..." <plp...@li...>; "ful...@us..." <ful...@us...> > Sent: Sunday, 24 February 2013, 5:48 > Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window > > On 2013-02-23 17:02-0800 phil rosenberg wrote: > >> I should now be able to supply a patch that give correct operation > and closure of a single window and allows the console to continue > running without the orphaned window. Would you like that as a patch > now with possibly more to follow? > > Hi Phil: > > Please go ahead and send your proposed patch as an attachment to this > list. I don't understand the wxwidgets device driver that well, but if > I find here that your patch builds and runs using all our standard C > examples without issues on Linux (using the test_c_wxwidgets target) > as well as reducing the test.c issues like you describe, then I would > be strongly inclined to apply it. > > Of course, I would also follow the advice of Werner (who is familiar > with the wxwidgets code since he is its original implementer) > concerning your proposed patch _if_ he gets in touch. There has been > no response to my first attempt to contact him, and in fact it appears > that the SourceForge mailer filtered out the CC to him for some > reason. So this time, I am CCing to the last two known addresses for > him to see if that will get a response. But meanwhile, Phil, please > send your patch so I can try the test_c_wxwidgets target with it (and > you may want to try that target yourself on Linux first (using "make > test_c_wxwidgets" if you have first run cmake with the -DBUILD_TEST=ON > option). > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ |
From: Alan W. I. <ir...@be...> - 2013-02-24 05:48:32
|
On 2013-02-23 17:02-0800 phil rosenberg wrote: > I should now be able to supply a patch that give correct operation and closure of a single window and allows the console to continue running without the orphaned window. Would you like that as a patch now with possibly more to follow? Hi Phil: Please go ahead and send your proposed patch as an attachment to this list. I don't understand the wxwidgets device driver that well, but if I find here that your patch builds and runs using all our standard C examples without issues on Linux (using the test_c_wxwidgets target) as well as reducing the test.c issues like you describe, then I would be strongly inclined to apply it. Of course, I would also follow the advice of Werner (who is familiar with the wxwidgets code since he is its original implementer) concerning your proposed patch _if_ he gets in touch. There has been no response to my first attempt to contact him, and in fact it appears that the SourceForge mailer filtered out the CC to him for some reason. So this time, I am CCing to the last two known addresses for him to see if that will get a response. But meanwhile, Phil, please send your patch so I can try the test_c_wxwidgets target with it (and you may want to try that target yourself on Linux first (using "make test_c_wxwidgets" if you have first run cmake with the -DBUILD_TEST=ON option). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: phil r. <phi...@ya...> - 2013-02-24 10:04:08
|
Hi Alan I'll run the tests you suggest today some time (balancing kids and decorating at the moment) and send in the patch. I have also found that simply not calling wxUninitialize() when we destroy the first window allows the second window to work as normal. For some reason it seems that on Linix wxWidgets does not like being repeatedly initialise and uninitialized. If I can sort out a source code build of wxWidgets I will try to dig deeper. Looking through the source on Windows it looks like initializing multiple times does not cause problems as there is a check to avoid this. I'm not sure if failing to unitialize will cause a memory leak on exit - perhaps this is less bad than a segfault anyway? Alternatively is there a point in the plplot initialization/uninitialization which could allow wxWidgets to be initialized/uninitialized exactly once per application? I will post something on the wxWidgets forum to see if thereis something I'm missing. Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: phil rosenberg <phi...@ya...> Cc: Werner Smekal <wer...@mi...>; Werner Smekal <sm...@ia...>; fulvio ciriaco <oi...@gm...>; "plp...@li..." <plp...@li...>; "ful...@us..." <ful...@us...> Sent: Sunday, 24 February 2013, 5:48 Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window On 2013-02-23 17:02-0800 phil rosenberg wrote: > I should now be able to supply a patch that give correct operation and closure of a single window and allows the console to continue running without the orphaned window. Would you like that as a patch now with possibly more to follow? Hi Phil: Please go ahead and send your proposed patch as an attachment to this list. I don't understand the wxwidgets device driver that well, but if I find here that your patch builds and runs using all our standard C examples without issues on Linux (using the test_c_wxwidgets target) as well as reducing the test.c issues like you describe, then I would be strongly inclined to apply it. Of course, I would also follow the advice of Werner (who is familiar with the wxwidgets code since he is its original implementer) concerning your proposed patch _if_ he gets in touch. There has been no response to my first attempt to contact him, and in fact it appears that the SourceForge mailer filtered out the CC to him for some reason. So this time, I am CCing to the last two known addresses for him to see if that will get a response. But meanwhile, Phil, please send your patch so I can try the test_c_wxwidgets target with it (and you may want to try that target yourself on Linux first (using "make test_c_wxwidgets" if you have first run cmake with the -DBUILD_TEST=ON option). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2013-02-24 22:54:51
|
Hi Phil: Most of this is directed to you, but I also have a question for Andrew below. On 2013-02-24 02:03-0800 phil rosenberg wrote: > Hi Alan > I'll run the tests you suggest today some time (balancing kids and decorating at the moment) and send in the patch. I have also found that simply not calling wxUninitialize() when we destroy the first window allows the second window to work as normal. For some reason it seems that on Linix wxWidgets does not like being repeatedly initialise and uninitialized. If I can sort out a source code build of wxWidgets I will try to dig deeper. > Looking through the source on Windows it looks like initializing multiple times does not cause problems as there is a check to avoid this. I'm not sure if failing to unitialize will cause a memory leak on exit - perhaps this is less bad than a segfault anyway? @Phil: Having some left-over memory hanging around due to not closing libraries is far preferred to segfaults. See also my question to Andrew below concerning using lt_dlclose rather than lt_dlexit. > Alternatively is there a point in the plplot initialization/uninitialization which could allow wxWidgets to be initialized/uninitialized exactly once per application? I checked the code, and it appears (see additional background information below, but you should double-check me) that initialization of the wxwidgets library should only happen once, and it should never be uninitialized (until that happens automatically when the whole app exits). > I will post something on the wxWidgets forum to see if thereis something I'm missing. Just to give you some more background, we handle device driver DLL's at run time using calls to lt_dlinit, lt_dlopenext, lt_dlmakeresident, lt_dlerror, lt_dlsym, and lt_dlexit. On Unix systems those are calls to the ltdl library API documented at http://www.delorie.com/gnu/docs/libtool/libtool_46.html. Note, for example, that the call to lt_dlmakeresident (which happens for all our device drivers that depend on external libraries) should make sure that the wxwidgets library remains resident, i.e., it should not be be closed and then reopened on each call to plend followed by a call to plinit. This call to lt_dlmakeresident greatly improves behaviour for the plend/plinit case (e.g. as used in test.c) for the Qt and Cairo external libraries and _should_ improve the behaviour for that case for the wxwidgets external library as well, i.e., the wxwidgets library should never be uninitialized. But that is relying on some interpretation of the ltdl documentation and the improved results we got for the Qt and Cairo cases. For example, I am concerned we call lt_dlexit (to exit the entire libltdl library) rather than lt_dlclose, and I don't really see how lt_dlmakeresident survives that. Perhaps the combination of lt_dlmakeresident and lt_dlexit works because of special ways that the Qt and Cairo libraries are linked on Linux, and wxwidgets does not have this linking? @Andrew: Can you comment on the possibility of using lt_dlclose rather than lt_dlexit? My feeling is we used lt_dlexit in the past to reduce leftover memory reported by valgrind, but I don't care about that if it makes run-time dlopening of our device drivers more reliable. @Phil: In stark contrast to the Unix case, on Windows these lt_* calls are calls to routines defined in src/ltdl_win32.c. So this difference may be the source of the differences between the behaviours of the wxwidgets device driver on Linux and Windows, but the confusing thing is I would have expected problems to show up for the Windows case (since lt_dlmakeresident is a no-op for this case) rather than the Linux case. Hope this background helps you to sort out the issues, and I look forward to your patch. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: phil r. <phi...@ya...> - 2013-02-24 23:13:02
|
Hi Alan I think our emails just crossed. Thanks for the comments - in particular about the memory vs segfault issues and wxWidgets initialization. It seems like a minefield - I write regular GUI apps normally so don't delve into the guts of wxWidgets that's needed for writing amalgamations of console and GUI apps. I will try to shuffle the code round this week so that we can avoid uninitializing wxWidgets and also effectively keep track of the frames as we go. It's not a massive task, it's just finding the time (a problem we all have). Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: phil rosenberg <phi...@ya...>; Andrew Ross <and...@us...> Cc: Werner Smekal <wer...@mi...>; Werner Smekal <sm...@ia...>; fulvio ciriaco <oi...@gm...>; "plp...@li..." <plp...@li...>; "ful...@us..." <ful...@us...> Sent: Sunday, 24 February 2013, 22:54 Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Hi Phil: Most of this is directed to you, but I also have a question for Andrew below. On 2013-02-24 02:03-0800 phil rosenberg wrote: > Hi Alan > I'll run the tests you suggest today some time (balancing kids and decorating at the moment) and send in the patch. I have also found that simply not calling wxUninitialize() when we destroy the first window allows the second window to work as normal. For some reason it seems that on Linix wxWidgets does not like being repeatedly initialise and uninitialized. If I can sort out a source code build of wxWidgets I will try to dig deeper. > Looking through the source on Windows it looks like initializing multiple times does not cause problems as there is a check to avoid this. I'm not sure if failing to unitialize will cause a memory leak on exit - perhaps this is less bad than a segfault anyway? @Phil: Having some left-over memory hanging around due to not closing libraries is far preferred to segfaults. See also my question to Andrew below concerning using lt_dlclose rather than lt_dlexit. > Alternatively is there a point in the plplot initialization/uninitialization which could allow wxWidgets to be initialized/uninitialized exactly once per application? I checked the code, and it appears (see additional background information below, but you should double-check me) that initialization of the wxwidgets library should only happen once, and it should never be uninitialized (until that happens automatically when the whole app exits). > I will post something on the wxWidgets forum to see if thereis something I'm missing. Just to give you some more background, we handle device driver DLL's at run time using calls to lt_dlinit, lt_dlopenext, lt_dlmakeresident, lt_dlerror, lt_dlsym, and lt_dlexit. On Unix systems those are calls to the ltdl library API documented at http://www.delorie.com/gnu/docs/libtool/libtool_46.html. Note, for example, that the call to lt_dlmakeresident (which happens for all our device drivers that depend on external libraries) should make sure that the wxwidgets library remains resident, i.e., it should not be be closed and then reopened on each call to plend followed by a call to plinit. This call to lt_dlmakeresident greatly improves behaviour for the plend/plinit case (e.g. as used in test.c) for the Qt and Cairo external libraries and _should_ improve the behaviour for that case for the wxwidgets external library as well, i.e., the wxwidgets library should never be uninitialized. But that is relying on some interpretation of the ltdl documentation and the improved results we got for the Qt and Cairo cases. For example, I am concerned we call lt_dlexit (to exit the entire libltdl library) rather than lt_dlclose, and I don't really see how lt_dlmakeresident survives that. Perhaps the combination of lt_dlmakeresident and lt_dlexit works because of special ways that the Qt and Cairo libraries are linked on Linux, and wxwidgets does not have this linking? @Andrew: Can you comment on the possibility of using lt_dlclose rather than lt_dlexit? My feeling is we used lt_dlexit in the past to reduce leftover memory reported by valgrind, but I don't care about that if it makes run-time dlopening of our device drivers more reliable. @Phil: In stark contrast to the Unix case, on Windows these lt_* calls are calls to routines defined in src/ltdl_win32.c. So this difference may be the source of the differences between the behaviours of the wxwidgets device driver on Linux and Windows, but the confusing thing is I would have expected problems to show up for the Windows case (since lt_dlmakeresident is a no-op for this case) rather than the Linux case. Hope this background helps you to sort out the issues, and I look forward to your patch. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: phil r. <phi...@ya...> - 2013-02-28 11:00:23
|
Hi Alan I've made a bit of progress on add ing threading to the wxWidgets driver - there is still some work to do however. Currently I've got to a point where I can start a new thread, begin the event loop and create frames. However there is some Windows specific code in there. The reason is that the cross platform wxThread cannot be used until after we call wxInitialize - however the event loop must be started in the same thread that we use to call wxInitialize. You can see the issue. I'm sure there are equivalent threading functions on the various operating systems we might want to support. I can find out how to do this on Linux, but I don't have access to a mac. I'm not sure what other OSs we should be supporting - but it could be a long list. The possible saviour here is that C++11 includes std::thread which would give support to any compliant compiler. Could CMake check for apropriate compliance at build time? Perhaps including code for C++11 std::threads with fallbacks to Windows and Linux (and OSX if someone can do it) specific code would be the best solution. Phil ________________________________ From: Alan W. Irwin <ir...@be...> To: phil rosenberg <phi...@ya...> Cc: PLplot development list <Plp...@li...>; Andrew Ross <and...@us...> Sent: Tuesday, 26 February 2013, 23:41 Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window On 2013-02-26 14:19-0800 phil rosenberg wrote: > Hi Alan > Okay, well to impliment that behaviour (CR or right click causes page advance) with wxWidgets is going to require us to go down the multithreading route - quickly glancing at the Qt code I can see mutexes mentioned right up near the top of the source so I guess that's what Qt does too. Hi Phil: Whatever you decide to do is fine with me so long as you preserve present behaviour (the page advance with CR or right click continues, the present pause behaviour continues (see below), and the test_c_wxwidgets comprehensive test of the wxwidgets device continues to pass) while solving the issues shown by test.c. > Again just to make sure I get this behaviour correct, in the current wxWidgets driver program flow stops with the wxWidgets window when pleop() is called and only returns when the plot page is advanced with a right click or enter press. Is this the correct behaviour? Yes. After all, the user normally wants a chance to look at the page being displayed rather than skipping through all the pages. > I've spotted the plspause() function in the documentation, when set to false should the driver return from a pleop() call immediately and just skip through all the pages? That seems to be the implication. Yes. For that special case (also with the -np command line option which ends up calling plspause(0) in plargs.c) the pages just should skip by with no pauses. Note, that the test_c_qtwidgets actually uses the -np command-line option by design so that whoever runs that test doesn't have to go crazy clicking on all the windows to get through the plots. But normally users do not use the -np command-line option so that the user can study the results for each plotted page. Note my run-time tests show that the page pause logic is already correctly implemented for wxwidgets (see also the pls->nopause logic in drivers/wxwidgets.cpp) so your changes should insure that logic is preserved. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2013-02-28 18:35:30
|
Phil, Sorry I'm coming to this thread rather late. Thanks for picking this up. On Linux you probably want to use the pthreads library (POSIX thread, as used by e.g. the xwin driver). pthreads are also available on Mac-OSX so it may well be that you can get OSX threading for little extra work, though someone would need to test it for you. Andrew On Thu, Feb 28, 2013 at 01:57:56AM -0800, phil rosenberg wrote: > Hi Alan > I've made a bit of progress on add ing threading to the wxWidgets driver - there is still some work to do however. > ? > Currently I've got to a point where I can start a new thread, begin the event loop and create frames. However there is some Windows specific code in there. The reason is that the cross platform wxThread cannot be used until after we call wxInitialize - however the event loop must be started in the same thread that we use to call wxInitialize. You can see the issue. > ? > I'm sure there are equivalent threading functions on the various operating systems we might want to support. I can find out how to do this on Linux, but I don't have access to a mac. I'm not sure what other OSs we should be supporting - but it could be a long list. > ? > The possible saviour here is that C++11 includes std::thread which would give support to any compliant compiler. Could CMake check for apropriate compliance at build time? Perhaps including code for C++11 std::threads with fallbacks to Windows and Linux (and OSX if someone can do it) specific code would be the best solution. > ? > Phil > > > ________________________________ > From: Alan W. Irwin <ir...@be...> > To: phil rosenberg <phi...@ya...> > Cc: PLplot development list <Plp...@li...>; Andrew Ross <and...@us...> > Sent: Tuesday, 26 February 2013, 23:41 > Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window > > On 2013-02-26 14:19-0800 phil rosenberg wrote: > > > Hi Alan > > > Okay, well to impliment that behaviour (CR or right click causes > page advance) with wxWidgets is going to > require us to go down the multithreading route - quickly glancing at > the Qt code I can see mutexes mentioned right up near the top of the > source so I guess that's what Qt does too. > > Hi Phil: > > Whatever you decide to do is fine with me so long as you preserve > present behaviour (the page advance with CR or right click continues, > the present pause behaviour continues (see below), and the > test_c_wxwidgets comprehensive test of the wxwidgets device continues > to pass) while solving the issues shown by test.c. > > > Again just to make sure I get this behaviour correct, in the current > wxWidgets driver program flow stops with the wxWidgets window when > pleop() is called and only returns when the plot page is advanced with > a right click or enter press. Is this the correct behaviour? > > Yes.? After all, the user normally wants a chance to look at the page > being displayed rather than skipping through all the pages. > > > I've spotted the plspause() function in the documentation, when set > to false should the driver return from a pleop() call immediately and > just skip through all the pages? That seems to be the implication. > > Yes. For that special case (also with the -np command line option > which ends up calling plspause(0) in plargs.c) the pages just should > skip by with no pauses. Note, that the test_c_qtwidgets actually uses > the -np command-line option by design so that whoever runs that test > doesn't have to go crazy clicking on all the windows to get through > the plots. But normally users do not use the -np command-line option so that the user can study the results for each plotted page. > > Note my run-time tests show that the page pause logic is already > correctly implemented for wxwidgets (see also the pls->nopause logic > in drivers/wxwidgets.cpp) so your changes should insure that logic is > preserved. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2013-02-26 23:42:56
|
On 2013-02-26 14:19-0800 phil rosenberg wrote: > Hi Alan > Okay, well to impliment that behaviour (CR or right click causes page advance) with wxWidgets is going to require us to go down the multithreading route - quickly glancing at the Qt code I can see mutexes mentioned right up near the top of the source so I guess that's what Qt does too. Hi Phil: Whatever you decide to do is fine with me so long as you preserve present behaviour (the page advance with CR or right click continues, the present pause behaviour continues (see below), and the test_c_wxwidgets comprehensive test of the wxwidgets device continues to pass) while solving the issues shown by test.c. > Again just to make sure I get this behaviour correct, in the current wxWidgets driver program flow stops with the wxWidgets window when pleop() is called and only returns when the plot page is advanced with a right click or enter press. Is this the correct behaviour? Yes. After all, the user normally wants a chance to look at the page being displayed rather than skipping through all the pages. > I've spotted the plspause() function in the documentation, when set to false should the driver return from a pleop() call immediately and just skip through all the pages? That seems to be the implication. Yes. For that special case (also with the -np command line option which ends up calling plspause(0) in plargs.c) the pages just should skip by with no pauses. Note, that the test_c_qtwidgets actually uses the -np command-line option by design so that whoever runs that test doesn't have to go crazy clicking on all the windows to get through the plots. But normally users do not use the -np command-line option so that the user can study the results for each plotted page. Note my run-time tests show that the page pause logic is already correctly implemented for wxwidgets (see also the pls->nopause logic in drivers/wxwidgets.cpp) so your changes should insure that logic is preserved. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: phil r. <phi...@ya...> - 2013-03-11 11:13:57
|
Hi All I'm still working through the wxWidgets bug, implementing multithreading. I already reported a possible snag with race conditions with users setting specific keyboard actions. However i've come accross a rather larger snag. Calling plRemakePlot also generates a race condition, perhaps in some very complicated ways. From a quick look at the code there is some attempt to protect the buffer from being written to while it is being read. However a number of problems can occur. If the main thread calls plbuf_save while the GUI thread is running plRemakePlot then the plbuf_write and plbuf_read flags will be set in both functions causing them to be reset before one function has finished - i guess it's quite likely that a segfault can occur in such a situation. Also if the main thread attempts to draw while the GUI thread is running plRemakePlot then it looks to me as though various functions in plcore.c will check plbuf_write, find it is false and not write their commands to the buffer. This will presumably cause odd rendering bugs. There is even a comment in the plRemakePlot source saying // Change the status of the flags before checking for a buffer. // Actually, more thought is needed if we want to support multithreaded // code correctly, specifically the case where two threads are using // the same plot stream (e.g. one thread is drawing the plot and another // thread is processing window manager messages). If we want to have multithreading work correctly then this is the time for more thought. Does anyone have any suggestions? There are a few ways I can imagine making things work - I don't know how well each wil function or which will be best but i thought I'd throw them out as ideas for comment. 1) Try to threadsafe the plstream and/or the plbuf_buffer. Probably a good solution, but a lot of work and difficult to do in a cross platform way. 2) Create a function that creates a snapshot of the plbuf_buffer in a threadsafe way. This is also not very easy as the buffer could get reallocated during the copy or commands without data could be included without some sort of mutex. Again cross platform multithreading becomes an issue. 3)The wxWidgets device maintains its own version of plbuf_buffer. Could this be done by having the wxWidgets device have a local PLStream that it can use to call the functions in plbuf? This would allow code reuse. There is increased memory use here but it could be that this is the least work. Any other suggestions or comments? Phil |
From: phil r. <phi...@ya...> - 2013-05-07 15:50:50
|
Hi I've spent a little time again working on this wxwidgets bug. I have pretty much done the bulk of it now. However, I had a question that people on the list might be able to help with. It seems that the wxWidget driver is set up to enable it to receive col0, col1 and width commands ahead of initialisation of the driver. Is this actually possible? I thought that the initialisation should be the first thing to be done? I'd like to remove some of this code if possible as it adds additional complications to dealing with changing page that are a pain to work around so I thought I'd check if they were necessary. Cheers Phil ________________________________ From: phil rosenberg <phi...@ya...> To: Alan W. Irwin <ir...@be...> Cc: PLplot development list <Plp...@li...>; Andrew Ross <and...@us...> Sent: Monday, 11 March 2013, 11:13 Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Hi All I'm still working through the wxWidgets bug, implementing multithreading. I already reported a possible snag with race conditions with users setting specific keyboard actions. However i've come accross a rather larger snag. Calling plRemakePlot also generates a race condition, perhaps in some very complicated ways. From a quick look at the code there is some attempt to protect the buffer from being written to while it is being read. However a number of problems can occur. If the main thread calls plbuf_save while the GUI thread is running plRemakePlot then the plbuf_write and plbuf_read flags will be set in both functions causing them to be reset before one function has finished - i guess it's quite likely that a segfault can occur in such a situation. Also if the main thread attempts to draw while the GUI thread is running plRemakePlot then it looks to me as though various functions in plcore.c will check plbuf_write, find it is false and not write their commands to the buffer. This will presumably cause odd rendering bugs. There is even a comment in the plRemakePlot source saying // Change the status of the flags before checking for a buffer. // Actually, more thought is needed if we want to support multithreaded // code correctly, specifically the case where two threads are using // the same plot stream (e.g. one thread is drawing the plot and another // thread is processing window manager messages). If we want to have multithreading work correctly then this is the time for more thought. Does anyone have any suggestions? There are a few ways I can imagine making things work - I don't know how well each wil function or which will be best but i thought I'd throw them out as ideas for comment. 1) Try to threadsafe the plstream and/or the plbuf_buffer. Probably a good solution, but a lot of work and difficult to do in a cross platform way. 2) Create a function that creates a snapshot of the plbuf_buffer in a threadsafe way. This is also not very easy as the buffer could get reallocated during the copy or commands without data could be included without some sort of mutex. Again cross platform multithreading becomes an issue. 3)The wxWidgets device maintains its own version of plbuf_buffer. Could this be done by having the wxWidgets device have a local PLStream that it can use to call the functions in plbuf? This would allow code reuse. There is increased memory use here but it could be that this is the least work. Any other suggestions or comments? Phil |
From: Alan W. I. <ir...@be...> - 2013-05-07 17:11:48
|
On 2013-05-07 08:50-0700 phil rosenberg wrote: > Hi > I've spent a little time again working on this wxwidgets bug. I have pretty much done the bulk of it now. However, I had a question that people on the list might be able to help with. > > It seems that the wxWidget driver is set up to enable it to receive col0, col1 and width commands ahead of initialisation of the driver. Is this actually possible? I thought that the initialisation should be the first thing to be done? I'd like to remove some of this code if possible as it adds additional complications to dealing with changing page that are a pain to work around so I thought I'd check if they were necessary. I am not familiar with the innermost details of our driver paradigm, but I do know that command-line options are parsed before plinit is called to do the rest of the device driver initialization. So if you look in src/plargs.c, you will see that the -bg option corresponds to a call to plscolbga before plinit is called. See also, http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.9/color.html where it is emphasized that plscolbg (a similar call to plscolbga but with alpha = 1 for completely opaque) must be called before plinit. Thus, there are definitely bits of the driver initialization (such as background colour) that are meant to be done before plinit is called. Thus, I am pretty sure that what you observed above for -dev wxwidgets and colour and width commands implemented before plinit is called is the right thing to do and should not be changed. To confirm that, I suggest you also look at a well-maintained but fairly simple (since there are no external dependencies) device driver such as -dev svg to see what it does with regard to col0, col1 and width commands. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: phil r. <phi...@ya...> - 2013-05-08 11:14:59
|
Thanks Alan I've hunted through the code and found that although some properties appear to be able to be set before initialisation they are saved in the plstream and the commands don't make it to the drivers until after plinit is called at least (because until this point the driver doesn't even exist). plwidth() had the following comment though: // // Set pen width. Can be done any time, but before calling plinit is best // since otherwise it may be volatile (i.e. reset on next page advance). // If width < 0 or is unchanged by the call, nothing is done. // Is the implication that if the user sets the pen width before initialisation that this pen width should be used at the beginning of each page? I've scanned through the svg and cairo code and this doesn't appear to be the case for these drivers and such functionality is not documented in the manual. In case anyone is interested in the progress of this work, I've modified the wxwidgets driver so that the wxWidgets window runs in a seaparate thread to the main thread where calls to the plplot functions occur. This is now functioning for the three backends on Windows, however freetype is not yet running. It has beens uch a large job because event driven functions in the wxFrame must not access the plstreams while the main thread is doing so. This either requires protecting the plstreams with mutexes or simply not accessing the plstream from the window. I've gone for the second option as I think the first is a huge job, especially given the use of the global plsc pointer. It turns out that plfreetype.c makes use of the plstream a lot so that's the next big task. There are some more minor items that i haven't yet tackled, such as setting custom keypress behaviour. I think the best (maybe only) way to do this would be to add extra options to the escape function calls so that when some options are set they can be sent from the plstream to the driver where it is easy to control communication, rather than have a window event have to poll the plstream, which can cause race conditions. Unless someone on the list tells me that this shouldn't be done I'll go ahead with this approach. Alan - off topic, that sounds like some very interesting work, I guess we won't hear from you much in the near future then. Phil |
From: Maurice L. <mj...@br...> - 2013-05-09 04:20:45
|
On Wednesday, May 8, 2013 at 04:14:45 (-0700) phil rosenberg writes: > Thanks Alan > I've hunted through the code and found that although some properties appear to be able to be set before initialisation they are saved in the plstream and the commands don't make it to the drivers until after plinit is called at least (because until this point the driver doesn't even exist). plwidth() had the following comment though: > // > // Set pen width. Can be done any time, but before calling plinit is best > // since otherwise it may be volatile (i.e. reset on next page advance). > // If width < 0 or is unchanged by the call, nothing is done. > // > > Is the implication that if the user sets the pen width before initialisation that this pen width should be used at the beginning of each page? I've scanned through the svg and cairo code and this doesn't appear to be the case for these drivers and such functionality is not documented in the manual. I wouldn't be surprised if that comment is no longer of relevance. I think postscript was one of the guilty parties, though that has been fixed for a long time. Probably more likely that there are options _ignored_ after the driver has been initialized (window geometry etc). So before the plinit still preferred. -- Maurice LeBrun |
From: Alan W. I. <ir...@be...> - 2013-02-22 00:40:53
Attachments:
test.c
|
On 2013-02-21 15:14-0800 phil rosenberg wrote: > Thanks for the report Fulvio > In that case I will download a clean version of plplot tomorrow and check how it works with that. Unfortunately I do almost all my coding on a windows environment - mostly because the debugging tools are so good. > > Speak soon > Phil Hi Phil: I confirm fulvio's results on my own Debian (wheezy) system. With Fulvio's test.c example the wxwidgets (wxGC) GUI from the first plinit does not disappear, and the second plinit segfaults. These (bad) results occur regardless of whether your wxwidgets patch is applied or not. So I suspect your wxwidgets patch (which, by the way, does apply cleanly to the svn trunk version of PLplot) addresses part of the issue but not all of it. Will you try test.c yourself for testing purposes rather than your modified x00c ? I have attached a slightly modified form of it here (plwid ==> plwidth is required for the trunk version) for your convenience. Note I have tried this test.c for a number of interactive devices and the only device where there are issues appears to be wxwidgets. Note, I normally run the default backend=2 (wxGC) but I also just now tried -drvopt backend=0 (basic) and got the same (bad) results with test.c. I have not tried backend=1 (AGG) for the wxwidgets device because the AGG library is not installed on my system. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: phil r. <phi...@ya...> - 2013-02-23 00:25:37
|
Hi Fulvio Yes wxWidgets immediately aborts in this circumstance. Looking at the source code this feature appears to have been added by design, although I don't know the reason. I'm not sure it is necessarilly what we want to occur. It can also cause memory leaks during exit because control never returns to the main function. Alan what do you think? Changing this behaviour should only be a matter of removing a few lines of code. Phil ________________________________ From: fulvio ciriaco <oi...@gm...> To: ir...@be... Cc: phi...@ya...; plp...@li...; ful...@us... Sent: Friday, 22 February 2013, 17:39 Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Hallo, since my students keep to compulsively hit all kind of buttons, I reviewed also what the different plotting drivers do on hitting the window close button or menu exit where existant, of course when the application is meant to survive the window, e.g. in test.c xwin: exits with fpe wxwidgets: immediate abort wxwidgets,menu:immediate abort xcairo: does not close the first but opens a new window where all works correctly. Xcairo has refreshing problems, but this is another story. tk: closes the window and pauses indefinitely tk, menu: aborts application qtwidget: works correctly It seems only qtwidget has an high probability to survive the efforts of my students to break things. Fulvio From: "Alan W. Irwin" <ir...@be...> Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Date: Thu, 21 Feb 2013 16:40:45 -0800 (PST) > On 2013-02-21 15:14-0800 phil rosenberg wrote: > >> Thanks for the report Fulvio >> In that case I will download a clean version of plplot tomorrow and >> check how it works with that. Unfortunately I do almost all my coding >> on a windows environment - mostly because the debugging tools are so >> good. >> >> Speak soon >> Phil > > Hi Phil: > > I confirm fulvio's results on my own Debian (wheezy) system. With > Fulvio's test.c example the wxwidgets (wxGC) GUI from the first plinit > does not disappear, and the second plinit segfaults. These (bad) > results occur regardless of whether your wxwidgets patch is applied > or not. > > So I suspect your wxwidgets patch (which, by the way, does apply > cleanly to the svn trunk version of PLplot) addresses part of the > issue but not all of it. > > Will you try test.c yourself for testing purposes rather than your > modified x00c ? I have attached a slightly modified form of it here > (plwid ==> plwidth is required for the trunk version) for your > convenience. Note I have tried this test.c for a number of interactive > devices and the only device where there are issues appears to be > wxwidgets. > > Note, I normally run the default backend=2 (wxGC) but I also just now > tried -drvopt backend=0 (basic) and got the same (bad) results with > test.c. I have not tried backend=1 (AGG) for the wxwidgets device > because the AGG library is not installed on my system. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ |
From: Alan W. I. <ir...@be...> - 2013-02-23 02:53:56
|
On 2013-02-22 16:25-0800 phil rosenberg wrote: > Hi Fulvio > Yes wxWidgets immediately aborts in this circumstance. Looking at the source code this feature appears to have been added by design, although I don't know the reason. I'm not sure it is necessarilly what we want to occur. It can also cause memory leaks during exit because control never returns to the main function. > > Alan what do you think? Changing this behaviour should only be a matter of removing a few lines of code. Hi Phil (with CC to Werner and Fulvio): To me it appears this windows close issue is a separate issue which extends to a number of devices according to Fulvio's tests. While the test.c and right-click (or CR) issue only occurs for wxwidgets. So I think we should wait to deal with the windows close issue until the right-click issue is fixed. What concerns me about the right-click issue is the big difference between Windows and Linux. I (and Fulvio if he is using Debian wheezy) use the same version (2.8.12.1-12) of wxwidgets as you do, Phil. Yet from your just previous e-mail you get perfect results on Windows and we don't on Linux. So this right-click issue should obviously be debugged on Linux, but I am really short of time at the moment and not that familiar with the wxwidgets code. Werner (who I have Cc'd and who I hope takes this opportunity to look at the full thread including the test.c attachment to my last post) is the guy who originally implemented the wxwidgets device driver so I am hoping he will have some insight. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: fulvio c. <oi...@gm...> - 2013-02-23 12:09:51
|
Hallo, so I compiled plplot with wxwidgets debug enabled, a message is delivered as soon as I right click the first window appearing: ../src/gtk/dcclient.cpp(248): assert "wxAssertFailure" failed in wxFreePoolGC(): Wrong GC I opened gdb and returned from wxwidgets, until I landed back in plplot at position #0 plD_tidy_wxwidgets (pls=0x7ffd3bf647e0) at /home/fc/Downloads/plplot-5.9.9/drivers/wxwidgets.cpp:773 773 pls->dev = NULL; // since in plcore.c pls->dev is free_mem'd i.e. after delete dev; In one of my mails above, I have already noticed that commenting // delete dev; the window does not close but another simply opens. Fulvio From: phil rosenberg <phi...@ya...> Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Date: Fri, 22 Feb 2013 16:25:29 -0800 (PST) > Hi Fulvio > Yes wxWidgets immediately aborts in this circumstance. Looking at the source code this feature appears to have been added by design, although I don't know the reason. I'm not sure it is necessarilly what we want to occur. It can also cause memory leaks during exit because control never returns to the main function. > > Alan what do you think? Changing this behaviour should only be a matter of removing a few lines of code. > > Phil > > > ________________________________ > From: fulvio ciriaco <oi...@gm...> > To: ir...@be... > Cc: phi...@ya...; plp...@li...; ful...@us... > Sent: Friday, 22 February 2013, 17:39 > Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window > > Hallo, > since my students keep to compulsively hit all kind of buttons, > I reviewed also what the different plotting drivers do on hitting > the window close button or menu exit where existant, of course when > the application is meant to survive the window, e.g. in test.c > xwin: exits with fpe > wxwidgets: immediate abort > wxwidgets,menu:immediate abort > xcairo: does not close the first but opens a new window where all > works correctly. Xcairo has refreshing problems, but this > is another story. > tk: closes the window and pauses indefinitely > tk, menu: aborts application > qtwidget: works correctly > > It seems only qtwidget has an high probability to survive the efforts > of my students to break things. > > Fulvio > > > From: "Alan W. Irwin" <ir...@be...> > Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window > Date: Thu, 21 Feb 2013 16:40:45 -0800 (PST) > >> On 2013-02-21 15:14-0800 phil rosenberg wrote: >> >>> Thanks for the report Fulvio >>> In that case I will download a clean version of plplot tomorrow and >>> check how it works with that. Unfortunately I do almost all my coding >>> on a windows environment - mostly because the debugging tools are so >>> good. >>> >>> Speak soon >>> Phil >> >> Hi Phil: >> >> I confirm fulvio's results on my own Debian (wheezy) system. With >> Fulvio's test.c example the wxwidgets (wxGC) GUI from the first plinit >> does not disappear, and the second plinit segfaults. These (bad) >> results occur regardless of whether your wxwidgets patch is applied >> or not. >> >> So I suspect your wxwidgets patch (which, by the way, does apply >> cleanly to the svn trunk version of PLplot) addresses part of the >> issue but not all of it. >> >> Will you try test.c yourself for testing purposes rather than your >> modified x00c ? I have attached a slightly modified form of it here >> (plwid ==> plwidth is required for the trunk version) for your >> convenience. Note I have tried this test.c for a number of interactive >> devices and the only device where there are issues appears to be >> wxwidgets. >> >> Note, I normally run the default backend=2 (wxGC) but I also just now >> tried -drvopt backend=0 (basic) and got the same (bad) results with >> test.c. I have not tried backend=1 (AGG) for the wxwidgets device >> because the AGG library is not installed on my system. >> >> Alan >> __________________________ >> Alan W. Irwin >> >> Astronomical research affiliation with Department of Physics and >> Astronomy, >> University of Victoria (astrowww.phys.uvic.ca). >> >> Programming affiliations with the FreeEOS equation-of-state >> implementation for stellar interiors (freeeos.sf.net); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.sf.net); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); >> and the Linux Brochure Project (lbproject.sf.net). >> __________________________ >> >> Linux-powered Science >> __________________________ |
From: fulvio c. <oi...@gm...> - 2013-02-23 14:48:27
|
Hallo, restricted somewhat the problem, it happens in the destructor, where indicated by >>>>>>>>>> wxPLDevGC::~wxPLDevGC() { // Log_Verbose( "%s", __FUNCTION__ ); if ( ownGUI ) { if ( m_dc ) { >>>>>>>>>>>> ( (wxMemoryDC *) m_dc )->SelectObject( wxNullBitmap ); delete m_dc; } if ( m_bitmap ) delete m_bitmap; } delete m_font; delete m_context; } Fulvio |
From: fulvio c. <oi...@gm...> - 2013-02-22 17:39:39
|
Hallo, since my students keep to compulsively hit all kind of buttons, I reviewed also what the different plotting drivers do on hitting the window close button or menu exit where existant, of course when the application is meant to survive the window, e.g. in test.c xwin: exits with fpe wxwidgets: immediate abort wxwidgets,menu:immediate abort xcairo: does not close the first but opens a new window where all works correctly. Xcairo has refreshing problems, but this is another story. tk: closes the window and pauses indefinitely tk, menu: aborts application qtwidget: works correctly It seems only qtwidget has an high probability to survive the efforts of my students to break things. Fulvio From: "Alan W. Irwin" <ir...@be...> Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window Date: Thu, 21 Feb 2013 16:40:45 -0800 (PST) > On 2013-02-21 15:14-0800 phil rosenberg wrote: > >> Thanks for the report Fulvio >> In that case I will download a clean version of plplot tomorrow and >> check how it works with that. Unfortunately I do almost all my coding >> on a windows environment - mostly because the debugging tools are so >> good. >> >> Speak soon >> Phil > > Hi Phil: > > I confirm fulvio's results on my own Debian (wheezy) system. With > Fulvio's test.c example the wxwidgets (wxGC) GUI from the first plinit > does not disappear, and the second plinit segfaults. These (bad) > results occur regardless of whether your wxwidgets patch is applied > or not. > > So I suspect your wxwidgets patch (which, by the way, does apply > cleanly to the svn trunk version of PLplot) addresses part of the > issue but not all of it. > > Will you try test.c yourself for testing purposes rather than your > modified x00c ? I have attached a slightly modified form of it here > (plwid ==> plwidth is required for the trunk version) for your > convenience. Note I have tried this test.c for a number of interactive > devices and the only device where there are issues appears to be > wxwidgets. > > Note, I normally run the default backend=2 (wxGC) but I also just now > tried -drvopt backend=0 (basic) and got the same (bad) results with > test.c. I have not tried backend=1 (AGG) for the wxwidgets device > because the AGG library is not installed on my system. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ |