On 2015-03-13 10:59-0700 Alan W. Irwin wrote: > On 2015-03-13 11:10-0400 Jim Dishaw wrote: > >> Alan, >> > >> I noticed a bug that occurs when resizing a plot. Every time a plot > is resized, an extra key press is required to advance the page. The > problem appears to be a pop_eop() that was added in plRemakePlot() > during one of your fixes (afd73a98). If I comment that line out, the > bug goes way. There should already be an EOP (or at least in most > cases) at the end of the buffer because Does calling plP_eop() > internally cause problems if the application was not expecting it? > I've run through all the examples without the plP_eop() call and > cannot detect a problem. Example 17 had no issues and that does not > have an EOP. > >> >> If the plP_eop() is required, I propose two solutions: >> >> 1) Check for an EOP before putting another one. >> 2) Do not replay the plot buffer unless there is an EOP (which would prevent >> redraws until an EOP and break example 17). >> > > Hi Jim: > > I verify that bug here (using examples/c/x01c -dev xwin). > > However, you have to dig deeper to find out who to blame. In other > words, "It wasn't me". :-) > > Here is the git magic you need. > > software@raven> git blame src/plbuf.c |grep plP_eop > afd37a98 (Alan W. Irwin 2015-03-11 02:33:40 -0700 1222) plP_eop(); > > So far so good, but if you use git log to look up that commit, it was just a > whitespace > (style) change by me. So taking the search one step further > (afd37a98^ is the parent commit of afd37a98) > > software@raven> git blame afd37a98^ src/plbuf.c |grep plP_eop > 1e402417 (Phil Rosenberg 2015-02-27 17:12:03 +0000 1218) plP_eop(); > > and if you look up 1e402417 using git log the first line of the > commit message is > > Fixed bug in rdbuf_di. > > So that is a serious (non-style) commit, and Phil is the one to > ask about your possible solutions for this bug. > > So I have put this on the list and also added Phil to the recipients. > > @Phil: I have no objections to your pushing a simple, well-tested fix for > this bug, but if the fix is complicated or you don't have time to > thoroughly test it, you should probably wait until post-release.
Oops. It just sunk in that this is a plbuf change where we have at least one example (example 2.02) where there were unintended wide-spread consequences of a plbuf change for all devices. And also some plbuf change and a subsequent fix for that was the likely cause of the on-again/off-again -dev tk zoom issue. So my advice is to hold off on this fix until post-release so we have a full release cycle to test it. 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
