@Alan
>Does that seem like a reasonable plan for dealing with the fairly >large release uncertainties created by this issue? yes this is the response from the developer > This is not completely unexpected, the window is only really created when > it's "realized" in GTK+/X11 terms, which can take quite some time, in > particular if a remote X server is used. But why should it matter? Just > run > the event loop until the "create" event is received and do whatever > initialization you need to do once it happens, you don't have to (and > won't > be able to) do it directly in OnInit(). he says we cannot expect a timely response from the "create" event in wxApp::OnInit(), which is the way wxPLplotDemo has. so, we have to change that, it just cannot be like it is now. @Phil several options 1) remove the frame creation from wxApp::OnInit(), I don't know where to move it to (or even if it is possible) , but the wxApp methods could provide some insight. http://docs.wxwidgets.org/3.1/classwx_app_console.html 2) leave the frame creation in wxApp::OnInit(), this requires that the "create" event must not be triggered, so we cannot call for OnCreate(). Since the frame creation must be done in the "create" functions (either in Create() or OnCreate()) that leaves only the Create() function. But , like Phil mentioned , the class that eventually creates the plot could not be a wxFrame, so the Create() function cannot be overriden. But maybe we can do the template valid only for classes that have similar Create() functions to wxFrame, and where it is possible to override Create() ? I don't know wich classes are the intended targets of the plot, maybe also dialogs? 3) other option would be not to do the templated plot window, and do a version only for wxFrame, and override the Create() function, and make the frame in wxApp::OnInit(). But this would probably break existing applications. but at the moment this is the only solution that we know has no potencial issues. > However, that might be the wrong thing to do since the issue is we > don't really understand what is going on here. So I think we really need a > fundamental solution for this issue that > you guys understand before we release PLplot. yes, no point in switching to another commit version that could have or not the same problem. > But finding > a fundamental solution to this issue is important enough that I think > we should put off that commit (if necessary) until 5 days from now > (Tuesday,December 27th when I was planning to make the release). ok -Pedro ----- Original Message ----- From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "PLplot development list" <Plplot-devel@lists.sourceforge.net> Sent: Thursday, December 22, 2016 5:07 PM Subject: RE: [Plplot-devel] Infinite Yielding issue > On 2016-12-22 09:48-0500 Pedro Vicente wrote: > >> Hi Phil >> >> there is a response from a developer >> >> https://groups.google.com/forum/#!topic/wx-dev/wsk--AlQNzU > > To Pedro and Phil: > > I hope that developer is responsive to Pedro's supplementary question, > but so far he hasn't been. Therefore, Pedro, I suggest you follow > Phil's advice to try other wxwidgets help avenues as well such as the > "wxWidgets trac system" he mentioned for getting help. > > Meanwhile, I discovered just this morning that I now > have the infinite Yielding loop when attempting to build the > test_wxPLplotDemo target. I believe that is the first time > that anybody other than Pedro has encountered this issue. > > And if I use > > git checkout master^ > > the test_wxPLplotDemo infinite Yielding loop goes away, i.e., I get > > 12:43:03: Debug: nanosecs since epoch = 2131058112372533: > wxPLplotwindow::wxPLplotwindow > 12:43:03: Debug: nanosecs since epoch = 2131058122107520: frame->Create > 12:43:03: Debug: nanosecs since epoch = 2131058129943746: > wxPLplotwindow::OnCreate > 12:43:03: Debug: nanosecs since epoch = 2131058145174385: > plD_init_wxwidgets(): enter > 12:43:03: Debug: nanosecs since epoch = 2131058145277524: wxPLDevice(): > enter > 12:43:03: Debug: nanosecs since epoch = 2131058145349163: wxPLDevice(): gc > done > 12:43:03: Debug: nanosecs since epoch = 2131058145447089: wxPLDevice(): > m_interactiveTextGcdc done > 12:43:03: Debug: nanosecs since epoch = 2131058145489262: wxPLDevice(): > SetDC done > 12:43:03: Debug: nanosecs since epoch = 2131058145596088: wxPLDevice(): > leave > 12:43:03: Debug: nanosecs since epoch = 2131058145629197: > plD_init_wxwidgets(): leave > 12:43:03: Debug: nanosecs since epoch = 2131058166078403: Plot() > > But the infinite loop comes back again if I use > > git checkout master > > where to be clear master = > > 995e75e Made some items clearer in the wxWigdets Demo > > I am pretty sure I tested 995e75e previously by building the > test_wxPLplotDemo target without encountering the infinite loop. So > it is possible the infinite loop depends on delicate timing conditions > that come and go.... However, I also tried Pedro's simple example > again, and that does not have an infinite loop this morning. > > My instincts as release manager are to make another commit that > reverses the effect of 995e75e which I believe was also Pedro's plan > with a deadline of tomorrow (Friday) if he could not get advice > on a definitive fix. > > However, that might be the wrong thing to do since the issue is we > don't really understand what is going on here. For example, making > another commit that puts us back to the equivalent of > > 65e7b3c Fix bug with plotting in wxPLplotDemo > > may still leave some users out there that experience the infinite > loop even when all of Pedro's tests of 65e7b3c and mine seem fine. > > So I think we really need a fundamental solution for this issue that > you guys understand before we release PLplot. So I appreciate you > both spending some time on this issue by, e.g., exploring all avenues > such as the "wxWidgets trac system" that Phil mentioned for getting > help and also reading through wxwidgets documentation and tutorials > to try and figure out for yourselves what is going on. > > In sum, I believe Pedro's plan was to suggest I make that commit to > return us to the equivalent of 65e7b3c tomorrow (Friday) if he or Phil > got no useful responses to their questions on wxwidgets forums > concerning Pedro's simple example of the problem by then. But finding > a fundamental solution to this issue is important enough that I think > we should put off that commit (if necessary) until 5 days from now > (Tuesday,December 27th when I was planning to make the release). And > at that point we should decide whether to release using the equivalent > of 65e7b3c or delay the release for several more days (and maybe into > the first week in 2017) until we do get a fundamental fix that you > guys understand. > > Does that seem like a reasonable plan for dealing with the fairly > large release uncertainties created by this issue? > > 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 > __________________________ > ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
