> On Mar 13, 2015, at 2:34 PM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
>
> Hi Jim Alan
> Firstly I'm not in front of a pc right now so I'm doing function names from
> memory. Apologies if they are wrong.
>
> Are you talking about the call to plP_eop() that is in the plreplot()
> function?
>
> If so, I put that there. The reason is that when creating the first page from
> a buffer, we need to do the bop actions, however due to the plinit call the
> status is already set to bop, so the call to plP_bop does nothing. The state
> #define values are not exposed to plbuf.c so the appropriate action appeared
> to be to end the existing page.
> It might be that changes to device initialization mean this is no longer
> necessary, but I don't know without testing. I'm not sure why it would cause
> the behaviour you describe though. Which device were they in?
>
The plP_eop() call, for some reason, results in extra keypresses needed to
advance to the next page. I thought I knew the reason, but after examining the
code, my initial hypothesis doesn't look correct. I will step through the code
to see what is causing the issue.
> Phil
> From: Alan W. Irwin
> Sent: 13/03/2015 17:59
> To: Phil Rosenberg; Jim Dishaw
> Cc: PLplot development list
> Subject: Release status: fix for plbuf resizing issue
>
> 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.
>
> 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
