On 2016-12-17 00:38-0800 Alan W. Irwin wrote: [...] > So if that is a good summary of the problem (the timing for when the > OnCreate event fires is not deterministic which your debug output > seems to have proved again and again) doesn't wxwidgets have a decent > way to wait for that event to fire in the Plot routine before > proceeding with defining pls? That would be the definitive fix for > this nondeterministic event timing issue (assuming that is the issue). > > In fact I just did a google search for the terms <wxwidgets wait > event> and there did seem to be a lot of help given on that topic > right in the first reference found > <https://forums.wxwidgets.org/viewtopic.php?t=22893>. Could you adapt > one of those ideas? Or if that reference is too old (2009) so not > wxwidgets-3.x relevant, perhaps one of the other hits you get with the > above search terms might give you the one-liner you need to > efficiently wait for the onCreate event before proceeding with > defining pls in Plot(). And that one-liner would allow you to remove > the changes you made in the present workaround bug fix. Anyhow, if > you can come up with that one-liner + dropping the changes in commit > e5b7485 (your workaround fix) I would be very happy to push that > commit.
To Pedro and Phil: I am still not convinced we have the definitive fix for this issue (as I indicated in my other post about freeze date and release status). The present Linux debug output results (from the recent git log) from building the test_wxPLplotDemo target are the following: Pedro: 15:33:46: Debug: wxPLplotwindow::wxPLplotwindow 15:33:46: Debug: frame->Create 15:33:46: Debug: wxPLplotwindow::Show 15:33:46: Debug: wxPLplotwindow::CreateStream 15:33:46: Debug: Plot() 15:33:46: Debug: wxPLplotwindow::OnCreate 15:33:46: Debug: wxPLplotwindow::CreateStream Me: 22:45:01: Debug: wxPLplotwindow::wxPLplotwindow 22:45:01: Debug: frame->Create 22:45:01: Debug: wxPLplotwindow::Show 22:45:01: Debug: wxPLplotwindow::CreateStream 22:45:01: Debug: wxPLplotwindow::OnCreate 22:45:01: Debug: wxPLplotwindow::CreateStream 22:45:01: Debug: Plot() What bothers me about these results is there seems to be two CreateStream calls in both cases where I suspect (although I don't know since I am not that familiar with wxwidgets) one is essentially ignored. So is Pedro's current fix simply one method of inserting a small timing wait before you get to Plot()? If so, that is pretty ad hoc. So wouldn't it be better to do a proper wait in Plot() instead for the needed event to occur before you define pls? @Pedro: One thing I dislike about the present debug output is the time stamp resolution of 1 second is so coarse when Linux is typically capable of nanosec resolution for times and the wxWidgets library is generally capable of millisec resolution. Furthermore, the documentation at <http://docs.wxwidgets.org/3.0/overview_log.html> says: "Additionally, you can customize the way full log messages are constructed from the components (such as time stamp, source file information, logging thread ID and so on). This task is performed by wxLogFormatter class so you need to derive a custom class from it and override its Format() method to build the log messages in desired way. Notice that if you just need to modify (or suppress) the time stamp display, overriding FormatTime() is enough." Do you know how to trivially override FormatTime to give us at least millisecond resolution here? If that is not a trivial change, another alternative I am thinking of is (strictly for the Linux case) is to call clock_gettime which will help give us a nanosecond time stamp. The reason I am concerned about this topic of time resolution is I think knowing the intervals between the various events with much higher accuracy is going to give us some added insight as to what is going on here with the above event order that is clearly not deterministic on Linux from these two examples (and many others). For example, if the two CreateStream calls and the Plot() call are all within a few nanoseconds of each other, that tells you one thing, but if they are separated by a much larger time interval or at some exact multiple of some fairly large interval (such as 50 ms) that tells you a very different story. Anyhow, if you don't want to fiddle with time resolution, let me know, and I will play with the clock_gettime solution. 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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
