On 2016-12-16 13:30-0500 Pedro Vicente wrote: > Hi Alan > > the patch with the 2nd commit with fix is attached
Hi Pedro: Much thanks for your revised first commit and this second one. I applied them one at a time and for each case ran git commit --amend to massage each commit message (some more in the first case) before pushing them to the SF master branch. I assumed when massaging your second commit message, that your test debug sequence was on the same OS as you used in the commit message associated with your first commit. If I got that wrong, it is too late to change (because it is generally a bad idea to amend already published commits). However, it is reasonably well understood that sometimes commit messages don't reflect actual test conditions, but I was willing to accept that chance and make the most intelligent guess I could so I would not have to go through another iteration with you. You should see those two commits with massaged commit messages when you update your local master branch (using the cookbook in README.developers if you are not quite sure how to do that with an already existing git local repository). Also, it struck me when comparing your results with mine for each of those tested by: stanzas for each commit, that I have a 9-year-old box here that was fast for its era (2.4GHz, 2 cpu's), but its memory is limited so that slows it down, and two users (my wife and I) have KDE desktop software running on it simultaneously which also slows it down a bit (principally by consuming a lot of memory). So I suspect you have a much faster test setup there. So if this event order bug is all about hardware and general box conditions affecting the indeterminate time when the OnCreate event fires, this difference might explain the differences in when that event occurs between my results and yours both before and after your bug fix. 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. 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
