plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Bug fix to plbuf.c

[Phil R. <p.d...@gm...>]

So how should we go about applying all this? Will we break some
drivers when it is applied? If so do we need to have all drivers
prepared so that we can apply all the fixes together?

Phil

On 16 June 2015 at 02:55, Jim Dishaw <ji...@di...> wrote:
> And here is the wingcc patch series.  I tested with cygwin and msvc and did
> not have the problem with multiple keypresses.  The wingcc driver does seem
> to have a problem when the window is made small.  It cuts off part of the
> plot.
>
>
>
>
> On Jun 15, 2015, at 12:24 PM, Jim Dishaw <ji...@di...> wrote:
>
>
> On Jun 14, 2015, at 1:40 PM, Jim Dishaw <ji...@di...> wrote:
>
>
> On Jun 14, 2015, at 5:19 AM, Alan W. Irwin <ir...@be...>
> wrote:
>
> On 2015-06-13 22:29-0400 Jim Dishaw wrote:
>
>
> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
>
>
> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm...
> <mailto:p.d...@gm...>> wrote:
>
> Hmmm
> Then hmmmm some more
> Followed by an ummm or two.
>
> As you say Jim, clearly things are more complicated than I realised. I'm not
> sure what the requirements really are here now. Now you have brought this up
> I can imagine the issues associated with entering the message loop after an
> eop.
>
> In terms of dealing with it, I'm not at my computer right now, but I think
> probably a bop_forced function which forces a bop irrespective of where we
> are in the page cycle would work. But I'm not sure if that might have some
> potential subtle effects elsewhere so it is a bit of a hack really. Perhaps
> instead it would be better to assess what is being done in a bop and ensure
> those actions end up in the buffer so a bop event is not required.
>
>
> I think that is a good approach for reasons beyond this issue, but a BOP and
> EOP of some type is still required to support the drivers adequately (e.g
> double buffering, printing from the windows API).
>
> The solution I'm going to test is one where the driver does not enter into a
> wait for input state on a redraw event from the callback.
>
>
> I came up with two solutions, one of which I tested.
>
> Solution 1 (Tested)
>
> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
> now an EOP is written to the buffer.  This will cause an EOP to be generated
> when the plot buffer is replayed.  I like the symmetry of having an EOP in
> the buffer to match the BOP.
>
> Drivers will be responsible for determining if a “wait for user input”
> should be performed during an EOP.  For the wingdi driver I track the state
> of a “page_state” that changes outside of the BOP/EOP calls.
>
> This solution feels a bit kludgy, but it works.
>
> Solution 2
>
> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
> now an EOP is written to the buffer.  This will cause an EOP to be generated
> when the plot buffer is replayed.
>
> Add a new driver function to the dispatch table (e.g. pl_wait) that calls
> the "wait for user input between pages" function.
>
> Remove from all drivers the “wait for input” from the EOP handler.
>
> The PLplot core library will call the wait for input between pages function
> (if not null).
>
> This solution strikes me as a more elegant solution because the logic for
> deciding about the wait for input is one spot.
>
>
> Regardless of the solution, some changes to the drivers will be
>
> required.  Solution 2 will touch all the drivers (at a minimum to add
> a NULL to the dispatch table).  Solution 1 adds code to the drivers
> while solution 2 removes some code from the drivers.
>
> Hi Jim:
>
> Thanks for your effort working through possible solutions to the
> problem.
>
> @Phil and Andrew:
>
> Assuming you guys agree with Jim's analysis, do you prefer solution 1
> or 2?  Elegant and "removes some code from the drivers" (i.e.,
> solution 2) seems like the better choice to me from an overview
> perspective, but I would be happy to go along with whatever you all
> decide since I do not have the driver expertise you guys have.
>
> Assuming whatever solution is decided upon here can be implemented
> in a reasonably timely way, then I think we should be able to fit
> it into the forthcoming bug-fix release since this is obviously a
> bug fix, albeit a rather intrusive one.
>
> With regard to timing for that release there is still quite a bit I
> plan to do to work through the bugs in the build system revealed by
> previous tests on Linux and Arjen's current tests on the Cygwin
> platform. And the new tarball report that is automatically collected
> by scripts/comprehensive_test.sh should make reporting of tests and
> figuring out build-system issues from those reports _much_ easier.
> Which likely means this release will be tested on a lot more platforms
> than the last one and a significant amount of time will be required to
> deal with any build system bugs that are turned up by such tests. So
> my current guestimate is the forthcoming release is likely more than a
> month away (although hopefully not longer than two months away).
>
>
> Attached is a patch series that implements the second solution.  I tested
> the changes to xwin driver; however, I was not able to test tkwin, qt, or
> cairo.  I will provide an update to wingcc separately.  I didn’t touch the
> wxwidgets driver.
>
> I didn’t have to touch the drivers that do not need the wait function
> pointer (e.g. postscript).  The way the driver dispatch table is
> initialized, I was able to set all the function pointers to NULL in the
> plcore.c file.  The drivers set each member individually, thus the wait
> function pointer is left NULL.
>
> The xwin driver occasionally misses some resizes, but I think that is some
> quirky behavior that existed prior to 5.10.
>
> If someone could test the tkwin, qt, and cairo (specifically xcairo) that
> would be greatly appreciated.
>
>
> <0001-Fix-to-the-multiple-keypress-bug-on-page-advance.patch>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Phil R. <p.d...@gm...>]

Hi Alan, Maurice and Arjen

Arjen - yes you are correct FLT_MIN was the incorrect number to use. I
should have used  PLFLT_EPSILON*MAX(xA2A1 * yB2B1, yA2A1 * xB2B1 ) for
my test. Here PLFLT_EPSILON is about 1e-16 for a double so we have
something that is much more sensible as a test.

Alan - yes you were correct I missed the second part of your email. If
only you top posted ;-).

So I think I understand the maths now. If each parameter has an
uncertainty of +/- 2 pixels then when factor should be zero, its
maximum value can be
( xA2A1 + 2 ) * ( yB2B1 +2 ) - ( yA2A1 + 2 )* ( xB2B1 + 2 )
which when expanded out gives
xA2A1 * yB2B1 - yA2A1 * xB2B1 + 2( xA2A1 + yB2B1 + yA2A1 + xB2B1 ).
= factor + factor_NBCC

So the uncertainty in factor is factor_NBCC so if abs(factor) is less
than factor_NBCC then it is within the uncertainty of zero. This
explains the dimension inconsistency - actually PL_NBCC has units of
length so that makes it work.

Is this all correct?

So in this case with the numbers I give above the line does indeed
fall within the uncertainty of zero.

However I am going to state that for this problem the initial
definition of uncertainty is incorrect. We are doing a point in
polygon test so we actually don't care at all about the rounding
precision of real numbers to integers. The actual points are exact -
even to within epsilon because all the numbers are integers and a
float can hold all integers exactly. Therefore it would actually be
safe to just test against zero. Despite this it would be worth having
an epsilon test.

In case that isn't clear let me state it like this. The points are not
scientifically exact in that when we go from the data we are plotting
onto out contour plot, we have some rounding uncertainty due to our
grid size. However, at the point of checking whether the corner of a
plot is within one of our fill regions we are no longer interested in
the original data. By this time we begin our fill function we have
divided our plot into a perfectly tessellating pattern of polygons.
And these really are perfectly tessellating. It is these polygons that
we are interested in for our fill algorithm, not the original data.
Therefore as far as the fill algorithm is concerned they are perfect
with zero uncertainty.

Therefore at the most for the fill function we might need an epsilon
test but to assume 2 pixel uncertainty is actually wrong.

Does that make sense?

Phil

On 16 June 2015 at 07:43, Arjen Markus <Arj...@de...> wrote:
> Hi Phil, Alan, Maurice,
>
>
>
> I have had a look at the code (both Phil’s patch and the original). I am a
> bit uncomfortable here:
>
> -        The original, using factor_NBCC cannot be correct, if only for
> dimensional reasons. “factor” is clearly a signed surface area, so that its
> dimension is L^2, whereas “factor_NBCC” has the dimension length (L).
>
> -        Phil’s patch uses FLT_MIN or DBL_MIN as a threshold for indicating
> nearly parallel lines, but FTL_MIN is 1e-38 and DBL_MIN is even smaller.
> Given that the incoming arguments are integer, these thresholds will simply
> never be triggered.
>
>
>
> My understanding is that the code tries to determine whether the angle
> between the two lines is very small by calculating the area spanned by the
> vectors defining the direction of the lines (this is “factor”) and comparing
> it to a small value. But that value should be related to the length of both
> these vectors. I would say something like this ought to work:
>
> factor = … ; /* This is sin(angle) * length vector 1 * length vector 2 –
> plane geometry */
>
> limit = 0.01 * length vector 1 * length vector 2; /* This means an angle of
> 0.01 radians or 1 degree */
>
>
>
> if ( fabs(factor) < limit ) {
>
>    status = status | NEAR_PARALLEL;
>
> }
>
>
>
> Alas, no time right now to elaborate further.
>
>
>
> Regards,
>
>
>
> Arjen
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Monday, June 15, 2015 11:59 PM
>> To: Phil Rosenberg
>> Cc: Arjen Markus; plp...@li...
>
>> Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c
>>
>> On 2015-06-15 21:07+0100 Phil Rosenberg wrote:
>>
>> > I will have to try out git blame then. I imagined that something so
>> well embedded would predate our git usage, but I guess our svn history was
>> brought
>> in too.
>>
>> Yes, Hazen and I were careful to preserve our history back to the start in
>> ~1992 which in retrospect was really a smart idea because of facilities
>> like "git
>> blame".
>>
>> > I guess you have as little idea as me then about how it is intended to
>> > work?
>>
>> Hi Phil:
>>
>> Actually, if "it" refers to the notcrossed function, I do think I
>> understand exactly what
>> it is supposed to do, and I tried to explain it on my previous post which
>> you quoted
>> and which I quote again below.
>>
>> I suspect you may have just read my first comment below and then quit.
>> :-)
>>
>> Alan
>>
>> >
>> > -----Original Message-----
>> > From: "Alan W. Irwin" <ir...@be...>
>> > Sent: ‎15/‎06/‎2015 19:18
>> > To: "Phil Rosenberg" <p.d...@gm...>
>> > Cc: "Arjen Markus" <Arj...@de...>;
>> > "plp...@li..."
>> > <plp...@li...>
>> > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c
>> >
>> > Hi Phil:
>> >
>> > "git blame" is your friend for figuring out who authored what, and it
>> > turns out I am virtually (except for a change by Hez) the sole author
>> > of notcrossed, but IIRC, that built on top of what Arjen had done
>> > before with (embedded logic rather than a function) which built on top
>> > of what Maurice had done before....
>> >
>> >
>> > On 2015-06-15 11:10+0100 Phil Rosenberg wrote:
>> >
>> >> Hi Arjen
>> >>
>> >> I've just copied the code below as I don't just have time at the
>> >> moment to sort a git patch (The plot I was making is for a
>> >> presentation this afternoon!).  The old code has been commented out
>> >> with /* */ and my new code is directly above that from the #ifdef
>> >> onwards.
>> >>
>> >> Basically I get that the variable factor will be zero for parallel
>> >> lines and I get that there is a precision limit on that due to
>> >> floating point rounding. However I don't understand how factor_NBCC
>> >> works as a test.
>> >>
>> >> For the bug in question the inputs were xA1=20994, yA1=12219,
>> >> xA2=4915, yA2=12561 xB1=20979, yB1=12219, xB2=20979, yB2=12221.
>> >> Although perhaps the As and Bs were reversed, but the flagging should
>> >> be identical.
>> >
>> > I (and presumably the rest here) were having a hard time figuring out
>> > whether those two lines mathematically intersected or not. So I have
>> > prepared a plot (see attached) that demonstrates that the two lines
>> > _do_ mathematically intersect (where the red line is a clipped portion
>> > of the A line segment and the yellow line is the B line segment in
>> > totality.)
>> >
>> > Note however, that all the xA1, etc. values have a precision of +/- 2
>> > because of rounding issues so the purpose of the PL_NBCC = 2 fuzz
>> > factor is to make sure that the result are not subject to such
>> > rounding issues, i.e., notcrossed only returns 0 status if the
>> > crossing would occur regardless of shifts of +/- 2 in each of the xA,
>> > yA, xB, and yB coordinates.  And of course, in this case when the
>> > second line segment only has a length of 2, the crossing result is
>> > never going to be definite so you will always get a non-zero return
>> > code from notcrossed.
>> >
>> > If that explanation makes sense to you, but you still feel noncrossed
>> > needs a fix, please send that in git format-patch form so I can
>> > conveniently evaluate your proposed logic change.  But I suspect the
>> > noncrossed logic is fine, and the fix for the issue you found needs to
>> > be made in another part of our code to deal correctly with non-zero
>> > return values from notcrossed.
>> >
>> > By the way, I hope your presentation went well despite the distraction
>> > introduced by this PLplot bug you discovered at the last minute.
>> >
>> > 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
>> > __________________________
>>
>> __________________________
>> 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
>> __________________________
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Arjen M. <Arj...@de...>]

Hi Phil, Alan, Maurice,



I have had a look at the code (both Phil’s patch and the original). I am a bit uncomfortable here:

-        The original, using factor_NBCC cannot be correct, if only for dimensional reasons. “factor” is clearly a signed surface area, so that its dimension is L^2, whereas “factor_NBCC” has the dimension length (L).

-        Phil’s patch uses FLT_MIN or DBL_MIN as a threshold for indicating nearly parallel lines, but FTL_MIN is 1e-38 and DBL_MIN is even smaller. Given that the incoming arguments are integer, these thresholds will simply never be triggered.



My understanding is that the code tries to determine whether the angle between the two lines is very small by calculating the area spanned by the vectors defining the direction of the lines (this is “factor”) and comparing it to a small value. But that value should be related to the length of both these vectors. I would say something like this ought to work:

factor = … ; /* This is sin(angle) * length vector 1 * length vector 2 – plane geometry */

limit = 0.01 * length vector 1 * length vector 2; /* This means an angle of 0.01 radians or 1 degree */



if ( fabs(factor) < limit ) {

   status = status | NEAR_PARALLEL;

}



Alas, no time right now to elaborate further.



Regards,



Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, June 15, 2015 11:59 PM
> To: Phil Rosenberg
> Cc: Arjen Markus; plp...@li...
> Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c
>
> On 2015-06-15 21:07+0100 Phil Rosenberg wrote:
>
> > I will have to try out git blame then. I imagined that something so
> well embedded would predate our git usage, but I guess our svn history was brought
> in too.
>
> Yes, Hazen and I were careful to preserve our history back to the start in
> ~1992 which in retrospect was really a smart idea because of facilities like "git
> blame".
>
> > I guess you have as little idea as me then about how it is intended to work?
>
> Hi Phil:
>
> Actually, if "it" refers to the notcrossed function, I do think I understand exactly what
> it is supposed to do, and I tried to explain it on my previous post which you quoted
> and which I quote again below.
>
> I suspect you may have just read my first comment below and then quit.  :-)
>
> Alan
>
> >
> > -----Original Message-----
> > From: "Alan W. Irwin" <ir...@be...>
> > Sent: ‎15/‎06/‎2015 19:18
> > To: "Phil Rosenberg" <p.d...@gm...>
> > Cc: "Arjen Markus" <Arj...@de...>;
> > "plp...@li..."
> > <plp...@li...>
> > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c
> >
> > Hi Phil:
> >
> > "git blame" is your friend for figuring out who authored what, and it
> > turns out I am virtually (except for a change by Hez) the sole author
> > of notcrossed, but IIRC, that built on top of what Arjen had done
> > before with (embedded logic rather than a function) which built on top
> > of what Maurice had done before....
> >
> >
> > On 2015-06-15 11:10+0100 Phil Rosenberg wrote:
> >
> >> Hi Arjen
> >>
> >> I've just copied the code below as I don't just have time at the
> >> moment to sort a git patch (The plot I was making is for a
> >> presentation this afternoon!).  The old code has been commented out
> >> with /* */ and my new code is directly above that from the #ifdef
> >> onwards.
> >>
> >> Basically I get that the variable factor will be zero for parallel
> >> lines and I get that there is a precision limit on that due to
> >> floating point rounding. However I don't understand how factor_NBCC
> >> works as a test.
> >>
> >> For the bug in question the inputs were xA1=20994, yA1=12219,
> >> xA2=4915, yA2=12561 xB1=20979, yB1=12219, xB2=20979, yB2=12221.
> >> Although perhaps the As and Bs were reversed, but the flagging should
> >> be identical.
> >
> > I (and presumably the rest here) were having a hard time figuring out
> > whether those two lines mathematically intersected or not. So I have
> > prepared a plot (see attached) that demonstrates that the two lines
> > _do_ mathematically intersect (where the red line is a clipped portion
> > of the A line segment and the yellow line is the B line segment in
> > totality.)
> >
> > Note however, that all the xA1, etc. values have a precision of +/- 2
> > because of rounding issues so the purpose of the PL_NBCC = 2 fuzz
> > factor is to make sure that the result are not subject to such
> > rounding issues, i.e., notcrossed only returns 0 status if the
> > crossing would occur regardless of shifts of +/- 2 in each of the xA,
> > yA, xB, and yB coordinates.  And of course, in this case when the
> > second line segment only has a length of 2, the crossing result is
> > never going to be definite so you will always get a non-zero return
> > code from notcrossed.
> >
> > If that explanation makes sense to you, but you still feel noncrossed
> > needs a fix, please send that in git format-patch form so I can
> > conveniently evaluate your proposed logic change.  But I suspect the
> > noncrossed logic is fine, and the fix for the issue you found needs to
> > be made in another part of our code to deal correctly with non-zero
> > return values from notcrossed.
> >
> > By the way, I hope your presentation went well despite the distraction
> > introduced by this PLplot bug you discovered at the last minute.
> >
> > 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
> > __________________________
>
> __________________________
> 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
> __________________________

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Maurice L. <mj...@br...>]

On Monday, June 15, 2015 at 11:18:33 (-0700) Alan W. Irwin writes:
 > Hi Phil:
 > 
 > "git blame" is your friend for figuring out who authored what, and it
 > turns out I am virtually (except for a change by Hez) the sole author
 > of notcrossed, but IIRC, that built on top of what Arjen had done before
 > with (embedded logic rather than a function)
 > which built on top of what Maurice had done before....

..and I can't take credit for that either, as the core contourer had already
been written when I got hold of it.  IIRC I fixed a bug or two and added the
function evaluator interface so I could use it from Fortran and later our C++
matrix class.  This is what I started with, summer of 1990:

http://amiga-fish.erkan.se/amiga-fish-disk-340-content-Plplot/

-- 
Maurice LeBrun

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

And here is the wingcc patch series.  I tested with cygwin and msvc and did not have the problem with multiple keypresses.  The wingcc driver does seem to have a problem when the window is made small.  It cuts off part of the plot.



> On Jun 15, 2015, at 12:24 PM, Jim Dishaw <ji...@di...> wrote:
> 
>> 
>> On Jun 14, 2015, at 1:40 PM, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>>> On Jun 14, 2015, at 5:19 AM, Alan W. Irwin <ir...@be...> wrote:
>>> 
>>> On 2015-06-13 22:29-0400 Jim Dishaw wrote:
>>> 
>>>> 
>>>>> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
>>>>> 
>>>>> 
>>>>> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>> wrote:
>>>>> 
>>>>>> Hmmm
>>>>>> Then hmmmm some more
>>>>>> Followed by an ummm or two.
>>>>>> 
>>>>>> As you say Jim, clearly things are more complicated than I realised. I'm not sure what the requirements really are here now. Now you have brought this up I can imagine the issues associated with entering the message loop after an eop.
>>>>>> 
>>>>>> In terms of dealing with it, I'm not at my computer right now, but I think probably a bop_forced function which forces a bop irrespective of where we are in the page cycle would work. But I'm not sure if that might have some potential subtle effects elsewhere so it is a bit of a hack really. Perhaps instead it would be better to assess what is being done in a bop and ensure those actions end up in the buffer so a bop event is not required.
>>>>>> 
>>>>> 
>>>>> I think that is a good approach for reasons beyond this issue, but a BOP and EOP of some type is still required to support the drivers adequately (e.g double buffering, printing from the windows API).
>>>>> 
>>>>> The solution I'm going to test is one where the driver does not enter into a wait for input state on a redraw event from the callback.
>>>> 
>>>> I came up with two solutions, one of which I tested.
>>>> 
>>>> Solution 1 (Tested)
>>>> 
>>>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed.  I like the symmetry of having an EOP in the buffer to match the BOP.
>>>> 
>>>> Drivers will be responsible for determining if a “wait for user input” should be performed during an EOP.  For the wingdi driver I track the state of a “page_state” that changes outside of the BOP/EOP calls.
>>>> 
>>>> This solution feels a bit kludgy, but it works.
>>>> 
>>>> Solution 2
>>>> 
>>>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed.
>>>> 
>>>> Add a new driver function to the dispatch table (e.g. pl_wait) that calls the "wait for user input between pages" function.
>>>> 
>>>> Remove from all drivers the “wait for input” from the EOP handler.
>>>> 
>>>> The PLplot core library will call the wait for input between pages function (if not null).
>>>> 
>>>> This solution strikes me as a more elegant solution because the logic for deciding about the wait for input is one spot.
>>>> 
>>> 
>>>> Regardless of the solution, some changes to the drivers will be
>>> required.  Solution 2 will touch all the drivers (at a minimum to add
>>> a NULL to the dispatch table).  Solution 1 adds code to the drivers
>>> while solution 2 removes some code from the drivers.
>>> 
>>> Hi Jim:
>>> 
>>> Thanks for your effort working through possible solutions to the
>>> problem.
>>> 
>>> @Phil and Andrew:
>>> 
>>> Assuming you guys agree with Jim's analysis, do you prefer solution 1
>>> or 2?  Elegant and "removes some code from the drivers" (i.e.,
>>> solution 2) seems like the better choice to me from an overview
>>> perspective, but I would be happy to go along with whatever you all
>>> decide since I do not have the driver expertise you guys have.
>>> 
>>> Assuming whatever solution is decided upon here can be implemented
>>> in a reasonably timely way, then I think we should be able to fit
>>> it into the forthcoming bug-fix release since this is obviously a
>>> bug fix, albeit a rather intrusive one.
>>> 
>>> With regard to timing for that release there is still quite a bit I
>>> plan to do to work through the bugs in the build system revealed by
>>> previous tests on Linux and Arjen's current tests on the Cygwin
>>> platform. And the new tarball report that is automatically collected
>>> by scripts/comprehensive_test.sh should make reporting of tests and
>>> figuring out build-system issues from those reports _much_ easier.
>>> Which likely means this release will be tested on a lot more platforms
>>> than the last one and a significant amount of time will be required to
>>> deal with any build system bugs that are turned up by such tests. So
>>> my current guestimate is the forthcoming release is likely more than a
>>> month away (although hopefully not longer than two months away).
>>> 
> 
> Attached is a patch series that implements the second solution.  I tested the changes to xwin driver; however, I was not able to test tkwin, qt, or cairo.  I will provide an update to wingcc separately.  I didn’t touch the wxwidgets driver.
> 
> I didn’t have to touch the drivers that do not need the wait function pointer (e.g. postscript).  The way the driver dispatch table is initialized, I was able to set all the function pointers to NULL in the plcore.c file.  The drivers set each member individually, thus the wait function pointer is left NULL.
> 
> The xwin driver occasionally misses some resizes, but I think that is some quirky behavior that existed prior to 5.10.  
> 
> If someone could test the tkwin, qt, and cairo (specifically xcairo) that would be greatly appreciated.
> 
> 
> <0001-Fix-to-the-multiple-keypress-bug-on-page-advance.patch>
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li... <mailto:Plp...@li...>
> https://lists.sourceforge.net/lists/listinfo/plplot-devel <https://lists.sourceforge.net/lists/listinfo/plplot-devel>

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Alan W. I. <ir...@be...>]

On 2015-06-15 21:07+0100 Phil Rosenberg wrote:

> I will have to try out git blame then. I imagined that something so
well embedded would predate our git usage, but I guess our svn history
was brought in too.

Yes, Hazen and I were careful to preserve our history back to the start in
~1992 which in retrospect was really a smart idea because of facilities
like "git blame".

> I guess you have as little idea as me then about how it is intended to work?

Hi Phil:

Actually, if "it" refers to the notcrossed function, I do think I
understand exactly what it is supposed to do, and I tried to explain
it on my previous post which you quoted and which I quote again below.

I suspect you may have just read my first comment below and then quit.  :-)

Alan

>
> -----Original Message-----
> From: "Alan W. Irwin" <ir...@be...>
> Sent: ‎15/‎06/‎2015 19:18
> To: "Phil Rosenberg" <p.d...@gm...>
> Cc: "Arjen Markus" <Arj...@de...>; "plp...@li..." <plp...@li...>
> Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c
>
> Hi Phil:
>
> "git blame" is your friend for figuring out who authored what, and it
> turns out I am virtually (except for a change by Hez) the sole author
> of notcrossed, but IIRC, that built on top of what Arjen had done before
> with (embedded logic rather than a function)
> which built on top of what Maurice had done before....
>
>
> On 2015-06-15 11:10+0100 Phil Rosenberg wrote:
>
>> Hi Arjen
>>
>> I've just copied the code below as I don't just have time at the
>> moment to sort a git patch (The plot I was making is for a
>> presentation this afternoon!).  The old code has been commented out
>> with /* */ and my new code is directly above that from the #ifdef
>> onwards.
>>
>> Basically I get that the variable factor will be zero for parallel
>> lines and I get that there is a precision limit on that due to
>> floating point rounding. However I don't understand how factor_NBCC
>> works as a test.
>>
>> For the bug in question the inputs were xA1=20994, yA1=12219,
>> xA2=4915, yA2=12561 xB1=20979, yB1=12219, xB2=20979, yB2=12221.
>> Although perhaps the As and Bs were reversed, but the flagging should
>> be identical.
>
> I (and presumably the rest here) were having a hard time figuring out
> whether those two lines mathematically intersected or not. So I have
> prepared a plot (see attached) that demonstrates that the two lines _do_
> mathematically intersect (where the red line is a clipped portion of the A line
> segment and the yellow line is the B line segment in totality.)
>
> Note however, that all the xA1, etc. values have a precision of +/- 2
> because of rounding issues so the purpose of the PL_NBCC = 2 fuzz
> factor is to make sure that the result are not subject to such
> rounding issues, i.e., notcrossed only returns 0 status if the
> crossing would occur regardless of shifts of +/- 2 in each of the xA,
> yA, xB, and yB coordinates.  And of course, in this case when the
> second line segment only has a length of 2, the crossing result is
> never going to be definite so you will always get a non-zero return
> code from notcrossed.
>
> If that explanation makes sense to you, but you still feel noncrossed
> needs a fix, please send that in git format-patch form so I can
> conveniently evaluate your proposed logic change.  But I suspect the
> noncrossed logic is fine, and the fix for the issue you found needs to
> be made in another part of our code to deal correctly with non-zero
> return values from notcrossed.
>
> By the way, I hope your presentation went well despite the
> distraction introduced by this PLplot bug you discovered at
> the last minute.
>
> 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
> __________________________

__________________________
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
__________________________

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Phil R. <p.d...@gm...>]

I will have to try out git blame then. I imagined that something so well embedded would predate our git usage, but I guess our svn history was brought in too.

I guess you have as little idea as me then about how it is intended to work?

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎15/‎06/‎2015 19:18
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "Arjen Markus" <Arj...@de...>; "plp...@li..." <plp...@li...>
Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

Hi Phil:

"git blame" is your friend for figuring out who authored what, and it
turns out I am virtually (except for a change by Hez) the sole author
of notcrossed, but IIRC, that built on top of what Arjen had done before
with (embedded logic rather than a function)
which built on top of what Maurice had done before....


On 2015-06-15 11:10+0100 Phil Rosenberg wrote:

> Hi Arjen
>
> I've just copied the code below as I don't just have time at the
> moment to sort a git patch (The plot I was making is for a
> presentation this afternoon!).  The old code has been commented out
> with /* */ and my new code is directly above that from the #ifdef
> onwards.
>
> Basically I get that the variable factor will be zero for parallel
> lines and I get that there is a precision limit on that due to
> floating point rounding. However I don't understand how factor_NBCC
> works as a test.
>
> For the bug in question the inputs were xA1=20994, yA1=12219,
> xA2=4915, yA2=12561 xB1=20979, yB1=12219, xB2=20979, yB2=12221.
> Although perhaps the As and Bs were reversed, but the flagging should
> be identical.

I (and presumably the rest here) were having a hard time figuring out
whether those two lines mathematically intersected or not. So I have
prepared a plot (see attached) that demonstrates that the two lines _do_
mathematically intersect (where the red line is a clipped portion of the A line
segment and the yellow line is the B line segment in totality.)

Note however, that all the xA1, etc. values have a precision of +/- 2
because of rounding issues so the purpose of the PL_NBCC = 2 fuzz
factor is to make sure that the result are not subject to such
rounding issues, i.e., notcrossed only returns 0 status if the
crossing would occur regardless of shifts of +/- 2 in each of the xA,
yA, xB, and yB coordinates.  And of course, in this case when the
second line segment only has a length of 2, the crossing result is
never going to be definite so you will always get a non-zero return
code from notcrossed.

If that explanation makes sense to you, but you still feel noncrossed
needs a fix, please send that in git format-patch form so I can
conveniently evaluate your proposed logic change.  But I suspect the
noncrossed logic is fine, and the fix for the issue you found needs to
be made in another part of our code to deal correctly with non-zero
return values from notcrossed.

By the way, I hope your presentation went well despite the
distraction introduced by this PLplot bug you discovered at
the last minute.

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
__________________________

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Alan W. I. <ir...@be...>]

Hi Phil:

"git blame" is your friend for figuring out who authored what, and it
turns out I am virtually (except for a change by Hez) the sole author
of notcrossed, but IIRC, that built on top of what Arjen had done before
with (embedded logic rather than a function)
which built on top of what Maurice had done before....


On 2015-06-15 11:10+0100 Phil Rosenberg wrote:

> Hi Arjen
>
> I've just copied the code below as I don't just have time at the
> moment to sort a git patch (The plot I was making is for a
> presentation this afternoon!).  The old code has been commented out
> with /* */ and my new code is directly above that from the #ifdef
> onwards.
>
> Basically I get that the variable factor will be zero for parallel
> lines and I get that there is a precision limit on that due to
> floating point rounding. However I don't understand how factor_NBCC
> works as a test.
>
> For the bug in question the inputs were xA1=20994, yA1=12219,
> xA2=4915, yA2=12561 xB1=20979, yB1=12219, xB2=20979, yB2=12221.
> Although perhaps the As and Bs were reversed, but the flagging should
> be identical.

I (and presumably the rest here) were having a hard time figuring out
whether those two lines mathematically intersected or not. So I have
prepared a plot (see attached) that demonstrates that the two lines _do_
mathematically intersect (where the red line is a clipped portion of the A line
segment and the yellow line is the B line segment in totality.)

Note however, that all the xA1, etc. values have a precision of +/- 2
because of rounding issues so the purpose of the PL_NBCC = 2 fuzz
factor is to make sure that the result are not subject to such
rounding issues, i.e., notcrossed only returns 0 status if the
crossing would occur regardless of shifts of +/- 2 in each of the xA,
yA, xB, and yB coordinates.  And of course, in this case when the
second line segment only has a length of 2, the crossing result is
never going to be definite so you will always get a non-zero return
code from notcrossed.

If that explanation makes sense to you, but you still feel noncrossed
needs a fix, please send that in git format-patch form so I can
conveniently evaluate your proposed logic change.  But I suspect the
noncrossed logic is fine, and the fix for the issue you found needs to
be made in another part of our code to deal correctly with non-zero
return values from notcrossed.

By the way, I hope your presentation went well despite the
distraction introduced by this PLplot bug you discovered at
the last minute.

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
__________________________

Re: [Plplot-devel] Tcl build error

[Alan W. I. <ir...@be...>]

On 2015-06-15 15:34+0100 Phil Rosenberg wrote:

> So I can see where the lines appear to be written from the
> CMakeLists.txt, but I don't know how to split that block to output the
> individual ${index} list items. I might have to rely on you to have a
> look.

Hi Phil:

I have taken a look at this, and I believe commit id 32c5cf8 will fix
the "spaced" build-tree pathname issue you discovered, but I have only
superficially tested this fix so please let me know if it solves the
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
__________________________

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 14, 2015, at 1:40 PM, Jim Dishaw <ji...@di...> wrote:
> 
> 
>> On Jun 14, 2015, at 5:19 AM, Alan W. Irwin <ir...@be...> wrote:
>> 
>> On 2015-06-13 22:29-0400 Jim Dishaw wrote:
>> 
>>> 
>>>> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
>>>> 
>>>> 
>>>> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>> wrote:
>>>> 
>>>>> Hmmm
>>>>> Then hmmmm some more
>>>>> Followed by an ummm or two.
>>>>> 
>>>>> As you say Jim, clearly things are more complicated than I realised. I'm not sure what the requirements really are here now. Now you have brought this up I can imagine the issues associated with entering the message loop after an eop.
>>>>> 
>>>>> In terms of dealing with it, I'm not at my computer right now, but I think probably a bop_forced function which forces a bop irrespective of where we are in the page cycle would work. But I'm not sure if that might have some potential subtle effects elsewhere so it is a bit of a hack really. Perhaps instead it would be better to assess what is being done in a bop and ensure those actions end up in the buffer so a bop event is not required.
>>>>> 
>>>> 
>>>> I think that is a good approach for reasons beyond this issue, but a BOP and EOP of some type is still required to support the drivers adequately (e.g double buffering, printing from the windows API).
>>>> 
>>>> The solution I'm going to test is one where the driver does not enter into a wait for input state on a redraw event from the callback.
>>> 
>>> I came up with two solutions, one of which I tested.
>>> 
>>> Solution 1 (Tested)
>>> 
>>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed.  I like the symmetry of having an EOP in the buffer to match the BOP.
>>> 
>>> Drivers will be responsible for determining if a “wait for user input” should be performed during an EOP.  For the wingdi driver I track the state of a “page_state” that changes outside of the BOP/EOP calls.
>>> 
>>> This solution feels a bit kludgy, but it works.
>>> 
>>> Solution 2
>>> 
>>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed.
>>> 
>>> Add a new driver function to the dispatch table (e.g. pl_wait) that calls the "wait for user input between pages" function.
>>> 
>>> Remove from all drivers the “wait for input” from the EOP handler.
>>> 
>>> The PLplot core library will call the wait for input between pages function (if not null).
>>> 
>>> This solution strikes me as a more elegant solution because the logic for deciding about the wait for input is one spot.
>>> 
>> 
>>> Regardless of the solution, some changes to the drivers will be
>> required.  Solution 2 will touch all the drivers (at a minimum to add
>> a NULL to the dispatch table).  Solution 1 adds code to the drivers
>> while solution 2 removes some code from the drivers.
>> 
>> Hi Jim:
>> 
>> Thanks for your effort working through possible solutions to the
>> problem.
>> 
>> @Phil and Andrew:
>> 
>> Assuming you guys agree with Jim's analysis, do you prefer solution 1
>> or 2?  Elegant and "removes some code from the drivers" (i.e.,
>> solution 2) seems like the better choice to me from an overview
>> perspective, but I would be happy to go along with whatever you all
>> decide since I do not have the driver expertise you guys have.
>> 
>> Assuming whatever solution is decided upon here can be implemented
>> in a reasonably timely way, then I think we should be able to fit
>> it into the forthcoming bug-fix release since this is obviously a
>> bug fix, albeit a rather intrusive one.
>> 
>> With regard to timing for that release there is still quite a bit I
>> plan to do to work through the bugs in the build system revealed by
>> previous tests on Linux and Arjen's current tests on the Cygwin
>> platform. And the new tarball report that is automatically collected
>> by scripts/comprehensive_test.sh should make reporting of tests and
>> figuring out build-system issues from those reports _much_ easier.
>> Which likely means this release will be tested on a lot more platforms
>> than the last one and a significant amount of time will be required to
>> deal with any build system bugs that are turned up by such tests. So
>> my current guestimate is the forthcoming release is likely more than a
>> month away (although hopefully not longer than two months away).
>> 

Attached is a patch series that implements the second solution.  I tested the changes to xwin driver; however, I was not able to test tkwin, qt, or cairo.  I will provide an update to wingcc separately.  I didn’t touch the wxwidgets driver.

I didn’t have to touch the drivers that do not need the wait function pointer (e.g. postscript).  The way the driver dispatch table is initialized, I was able to set all the function pointers to NULL in the plcore.c file.  The drivers set each member individually, thus the wait function pointer is left NULL.

The xwin driver occasionally misses some resizes, but I think that is some quirky behavior that existed prior to 5.10.  

If someone could test the tkwin, qt, and cairo (specifically xcairo) that would be greatly appreciated.

Re: [Plplot-devel] Tcl build error

[Phil R. <p.d...@gm...>]

Hi Alan
The I've had a look and it seems that there are two problems. I'm not
sure if these are CMake version issues as much as anything else.

Basically in the foreach on line 4 of concatenate_pkgIndex.tcl.cmake
the filenames need quoting. However, even when this is done, my
version of CMake complains that the variables are split with a
semicolon rather than a space, so the semicolon separator needs
replacing with a space too. Knowing that in the foreach a space should
be used rather than a semicolon makes the cause of the problem clear.

So I can see where the lines appear to be written from the
CMakeLists.txt, but I don't know how to split that block to output the
individual ${index} list items. I might have to rely on you to have a
look.

Phil

On 14 June 2015 at 17:36, Alan W. Irwin <ir...@be...> wrote:
> On 2015-06-14 11:12+0100 Phil Rosenberg wrote:
>
>> I've recently started getting a build error for TCL
>>
>> The error I get is
>>
>> 8>------ Build started: Project: concatenate_pkgIndex.tcl,
>> Configuration: Release x64 ------
>> 8> Building Custom Rule
>> D:/usr/local/src/plplot-plplot/bindings/CMakeLists.txt
>> 8> CMake does not need to re-run because
>> D:\usr\local\src\plplot-plplot\build\Visual Studio 11
>> 64s\bindings\CMakeFiles\generate.stamp is up-to-date.
>> 8> Generating pkgIndex.tcl
>> 8> CMake Error at concatenate_pkgIndex.tcl.cmake:4 (file):
>> 8> file failed to open for reading (No such file or directory):
>> 8>
>> 8> D:/usr/local/src/plplot-plplot/build/Visual Studio 11
>> 64s/bindings/Studio
>> 8>
>> 8>
>>
>> Looking at the path it is trying to find I would guess that the issue
>> is related to me having spaces in my build path.
>>
>> Unfortunately this error means that my INSTALL project (the equivalent
>> to make install) doesn't run to completion and I am currently having
>> to manually copy the built results to the install directory.
>
>
> Hi Phil:
>
> You can use
>
> git blame bindings/CMakeLists.txt |less
>
> to discover the last change in this concatanation logic was done by me
> on 2015-04-21.  And you can then use
>
> git blame a8873275^ bindings/CMakeLists.txt |less
>
> to show the previous change to the concatanation part of the code was back
> in 2009-11-01 so likely not
> relevant to the issue you just discovered.
>
> I have also used
>
> git diff a8873275^..a8873275 bindings/CMakeLists.txt |less
>
> to look carefully at the change in logic there which simply changes
> the contatanation from cmake time to build time.  I frankly don't see
> how that change affects "spaced" path issues so perhaps using
> the cmake -P command to exercise this logic at build time somehow
> treats blanks in pathnames differently than the original logic?
>
> Anyhow, to investigate further, will you please take a look at the
> file bindings/concatenate_pkgIndex.tcl.cmake in the build tree which
> is generated at CMake time by the CMake concatanation logic in
> bindings/CMakeLists.txt and executed at run time by building the
> concatenate_pkgIndex.tcl target which in turn simply runs
>
> cmake -P bindings/concatenate_pkgIndex.tcl.cmake
>
> You can also run that command by hand to see exactly what the issue is.
>
> If there is some obvious part of that generated file that needs quotes
> around the pathname, please insert the corresponding escaped quotes
> into the concatanation logic in bindings/CMakeLists.txt, test that
> change, and if it works for you please push 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
> __________________________

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Phil R. <p.d...@gm...>]

Yeah, that seems like a good argument to me

On 15 June 2015 at 03:30, Jim Dishaw <ji...@di...> wrote:
>
> On Jun 14, 2015, at 5:28 AM, Phil Rosenberg <p.d...@gm...> wrote:
>
> On 11 June 2015 at 17:57, Jim Dishaw <ji...@di...> wrote:
>
>
> On Jun 11, 2015, at 4:06 AM, Phil Rosenberg <p.d...@gm...> wrote:
>
> Hi Jim
> The documentation states that the provided text height will be in mm.
> The user can set dpi with plspage so you should use the PLStream->xdpi
> and PLStream->ydpi to size your text in pixels. In case the user
> hasn't set this you should use a sensible default. Of course the
> actual value will depend on the monitor, but rather than try to grab
> this it seems that there are two standards and for consistency you
> should use one of these. One is to use 72 pixels per inch so that 1
> pixel = 1 pt. The other is 90 pixels per inch which seems to be the
> default for most svg renderers. For wxWidgets I chose 90 pixels per
> inch. I also noticed tect seems a little smaller than the example
> online (from the cairo driver?) but it does as described in the
> documentation so I am happy with that.
>
>
>
>
>
> The recommendation in the Windows API is to use GetDeviceCaps () with the
>>LOGPIXELSX/LOGPIXELSY values to get the dpi setting.  Right now I’m
>>ignoring the DPI setting provided by the user.  On native text rendering
> devices >the xdpi/ydpi settings are essentially being used to scale the size
> of fonts, >which (IMHO) abuses the meaning of “DPI”.
>
> Yes as you say the windows API provides this mechanism - in fact there
> is something about if you wish to have your app in the windows store
> you must do this so your app can work on phones/tablets/pcs or
> something. Not sure of the details.
> For The windows interactive device it is perhaps not a big deal - for
> wxWidgets the user can pass in a paint dc or a memory dc so in the
> latter case it is down to the user to specify a DPI. Because all DCs
> are treated equal it is up to the user in all instances. Re DPI
> basically being a text scaling parameter - well you are correct - but
> does any other function receive arguments in mm/inches or is text the
> only one?
>
>
> At least when it comes to DPI, text is the only that uses that field.  I
> think all the drawing commands are in the plot coordinate system, thus
> physical dimensions are subsumed into the coordinate system.  There is
> plsvpa() that allows the user to specify the viewport in terms of physical
> measurements.
>
> My rationale for keeping the dpi tied to the device is to ensure that
> physical measurements are invariant (the principle of least surprise).  If
> the API says “mm” or “inches” the driver should render something that
> measures correctly.
>
> Which size are you referring to?  When the window is resized, the driver
> gets >the new dimensions of the client area (via GetClientRect() for
> displays and >GetDeviceCaps() for printers).  It uses the new size to
> calculate the new >scaling between device virtual coordinates
> (PIXELS_X/PIXELS_Y in PLplot) >and the new output device coordinates, The
> dpi remains consistent with what >Windows reports.
>
> So for wxWidgets if I resize the window to double the size, the text
> stays the same size. I.e. I maintain the same dpi and text height in
> mm when the window is resized.
>
>
> Same with wingdi.  When resized the text stays the same.
>

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Phil R. <p.d...@gm...>]

Hi Arjen

I've just copied the code below as I don't just have time at the
moment to sort a git patch (The plot I was making is for a
presentation this afternoon!).  The old code has been commented out
with /* */ and my new code is directly above that from the #ifdef
onwards.

Basically I get that the variable factor will be zero for parallel
lines and I get that there is a precision limit on that due to
floating point rounding. However I don't understand how factor_NBCC
works as a test.

For the bug in question the inputs were xA1=20994, yA1=12219,
xA2=4915, yA2=12561 xB1=20979, yB1=12219, xB2=20979, yB2=12221.
Although perhaps the As and Bs were reversed, but the flagging should
be identical.

Phil


Code Below:

int

notcrossed( PLINT * xintersect, PLINT * yintersect,

PLINT xA1, PLINT yA1, PLINT xA2, PLINT yA2,

PLINT xB1, PLINT yB1, PLINT xB2, PLINT yB2 )

{

PLFLT factor, factor_NBCC, fxintersect, fyintersect, limit;

// These variables are PLFLT not for precision, but to

// avoid integer overflows if they were typed as PLINT.

PLFLT xA2A1, yA2A1, xB2B1, yB2B1;

PLFLT xB1A1, yB1A1, xB2A1, yB2A1;

PLINT status = 0;

//

// Two linear equations to be solved for x and y.

// y = ((x - xA1)*yA2 + (xA2 - x)*yA1)/(xA2 - xA1)

// y = ((x - xB1)*yB2 + (xB2 - x)*yB1)/(xB2 - xB1)

//

// Transform those two equations to coordinate system with origin

// at (xA1, yA1).

// y' = x'*yA2A1/xA2A1

// y' = ((x' - xB1A1)*yB2A1 + (xB2A1 - x')*yB1A1)/xB2B1

// ==>

// x' = -(

// (-xB1A1*yB2A1 + xB2A1*yB1A1)/xB2B1)/

// (yB2B1/xB2B1 - yA2A1/xA2A1)

// = (xB1A1*yB2A1 - xB2A1*yB1A1)*xA2A1/

// (xA2A1*yB2B1 - yA2A1*xB2B1)

//

//

xA2A1 = xA2 - xA1;

yA2A1 = yA2 - yA1;

xB2B1 = xB2 - xB1;

yB2B1 = yB2 - yB1;

factor = xA2A1 * yB2B1 - yA2A1 * xB2B1;

#ifdef PL_DOUBLE

limit= sqrt( FLT_MIN );

#else

limit = sqrt( DBL_MIN );

#endif

if( factor == 0 )

status = status | PL_PARALLEL;

else if( fabs( factor ) < limit )

status = status | PL_NEAR_PARALLEL;

/*factor_NBCC = PL_NBCC * ( fabs( xA2A1 ) + fabs( yB2B1 ) + fabs(
yA2A1 ) + fabs( xB2B1 ) );

if ( fabs( factor ) <= factor_NBCC )

{

if ( fabs( factor ) > 0. )

status = status | PL_NEAR_PARALLEL;

else

status = status | PL_PARALLEL;

}*/

else

{

xB1A1 = xB1 - xA1;

yB1A1 = yB1 - yA1;

xB2A1 = xB2 - xA1;

yB2A1 = yB2 - yA1;

factor = ( xB1A1 * yB2A1 - yB1A1 * xB2A1 ) / factor;

fxintersect = factor * xA2A1 + xA1;

fyintersect = factor * yA2A1 + yA1;

// The "redundant" x and y segment range checks (which include near the

// end points) are needed for the vertical and the horizontal cases.

if ( ( BETW_NBCC( fxintersect, xA1, xA2 ) && BETW_NBCC( fyintersect,
yA1, yA2 ) ) &&

( BETW_NBCC( fxintersect, xB1, xB2 ) && BETW_NBCC( fyintersect, yB1, yB2 ) ) )

{

// The intersect is close (within +/- PL_NBCC) to an end point or

// corresponds to a definite crossing of the two line segments.

// Find out which.

if ( fabs( fxintersect - xA1 ) <= PL_NBCC && fabs( fyintersect - yA1 )
<= PL_NBCC )

status = status | PL_NEAR_A1;

else if ( fabs( fxintersect - xA2 ) <= PL_NBCC && fabs( fyintersect -
yA2 ) <= PL_NBCC )

status = status | PL_NEAR_A2;

else if ( fabs( fxintersect - xB1 ) <= PL_NBCC && fabs( fyintersect -
yB1 ) <= PL_NBCC )

status = status | PL_NEAR_B1;

else if ( fabs( fxintersect - xB2 ) <= PL_NBCC && fabs( fyintersect -
yB2 ) <= PL_NBCC )

status = status | PL_NEAR_B2;

// N.B. if none of the above conditions hold then status remains at

// zero to signal we have a definite crossing.

}

else

status = status | PL_NOT_CROSSED;

}

if ( !status )

{

*xintersect = (PLINT) fxintersect;

*yintersect = (PLINT) fyintersect;

}

return status;

}

On 15 June 2015 at 10:46, Arjen Markus <Arj...@de...> wrote:
> Hi Phil,
>
>
>
> I do not remember who wrote it, I may have made some changes to it in a now
> distant past, but I could have a look at your fix.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>> -----Original Message-----
>> From: Phil Rosenberg [mailto:p.d...@gm...]
>> Sent: Monday, June 15, 2015 11:35 AM
>> To: plp...@li...
>> Subject: [Plplot-devel] Bug in notcrossed() function of plfill.c
>>
>>  Hi All
>> I have just been dealing with a bug where I was drawing a contour plot and
>> my entire
>> plot was being filled with one contour level. I have fought my way through
>> the code
>> and it turned out to be a perfect storm of a bug which begins with the
>> notcrossed
>> function returning a PL_NEAR_PARALLEL status for two lines which are
>> actually
>> near perpendicular (and cross) which then causes the top left corner of my
>> plot to be
>> incorrectly labelled as inside a fill region. However because the fill
>> region is actually
>> outside the plot plplot sees no intersections with the plot boundaries so
>> checks if the
>> top left corner of the plot is inside the fill region. In this case it
>> sees that it is flagged
>> as inside so assumes the whole plot must be inside and fills the whole
>> plot.
>>
>> I have fixed my code, but I actually don't understand the exixting logic
>> inside
>> notcrossed(). This might be because it is an error or it might be because
>> I just don't
>> get it. So before I push my change I just wanted to check if whoever
>> authored this
>> function is still around?
>>
>> Phil
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

[Arjen M. <Arj...@de...>]

Hi Phil,



I do not remember who wrote it, I may have made some changes to it in a now distant past, but I could have a look at your fix.



Regards,



Arjen



> -----Original Message-----
> From: Phil Rosenberg [mailto:p.d...@gm...]
> Sent: Monday, June 15, 2015 11:35 AM
> To: plp...@li...
> Subject: [Plplot-devel] Bug in notcrossed() function of plfill.c
>
>  Hi All
> I have just been dealing with a bug where I was drawing a contour plot and my entire
> plot was being filled with one contour level. I have fought my way through the code
> and it turned out to be a perfect storm of a bug which begins with the notcrossed
> function returning a PL_NEAR_PARALLEL status for two lines which are actually
> near perpendicular (and cross) which then causes the top left corner of my plot to be
> incorrectly labelled as inside a fill region. However because the fill region is actually
> outside the plot plplot sees no intersections with the plot boundaries so checks if the
> top left corner of the plot is inside the fill region. In this case it sees that it is flagged
> as inside so assumes the whole plot must be inside and fills the whole plot.
>
> I have fixed my code, but I actually don't understand the exixting logic inside
> notcrossed(). This might be because it is an error or it might be because I just don't
> get it. So before I push my change I just wanted to check if whoever authored this
> function is still around?
>
> Phil
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Bug in notcrossed() function of plfill.c

[Phil R. <p.d...@gm...>]

 Hi All
I have just been dealing with a bug where I was drawing a contour plot
and my entire plot was being filled with one contour level. I have
fought my way through the code and it turned out to be a perfect storm
of a bug which begins with the notcrossed function returning a
PL_NEAR_PARALLEL status for two lines which are actually near
perpendicular (and cross) which then causes the top left corner of my
plot to be incorrectly labelled as inside a fill region. However
because the fill region is actually outside the plot plplot sees no
intersections with the plot boundaries so checks if the top left
corner of the plot is inside the fill region. In this case it sees
that it is flagged as inside so assumes the whole plot must be inside
and fills the whole plot.

I have fixed my code, but I actually don't understand the exixting
logic inside notcrossed(). This might be because it is an error or it
might be because I just don't get it. So before I push my change I
just wanted to check if whoever authored this function is still
around?

Phil

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Jim D. <ji...@di...>]

> On Jun 14, 2015, at 5:28 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> On 11 June 2015 at 17:57, Jim Dishaw <ji...@di... <mailto:ji...@di...>> wrote:
>> 
>>> On Jun 11, 2015, at 4:06 AM, Phil Rosenberg <p.d...@gm...> wrote:
>>> 
>>> Hi Jim
>>> The documentation states that the provided text height will be in mm.
>>> The user can set dpi with plspage so you should use the PLStream->xdpi
>>> and PLStream->ydpi to size your text in pixels. In case the user
>>> hasn't set this you should use a sensible default. Of course the
>>> actual value will depend on the monitor, but rather than try to grab
>>> this it seems that there are two standards and for consistency you
>>> should use one of these. One is to use 72 pixels per inch so that 1
>>> pixel = 1 pt. The other is 90 pixels per inch which seems to be the
>>> default for most svg renderers. For wxWidgets I chose 90 pixels per
>>> inch. I also noticed tect seems a little smaller than the example
>>> online (from the cairo driver?) but it does as described in the
>>> documentation so I am happy with that.
>> 
> 
> 
>> 
>> The recommendation in the Windows API is to use GetDeviceCaps () with the >LOGPIXELSX/LOGPIXELSY values to get the dpi setting.  Right now I’m >ignoring the DPI setting provided by the user.  On native text rendering devices >the xdpi/ydpi settings are essentially being used to scale the size of fonts, >which (IMHO) abuses the meaning of “DPI”.
>> 
> Yes as you say the windows API provides this mechanism - in fact there
> is something about if you wish to have your app in the windows store
> you must do this so your app can work on phones/tablets/pcs or
> something. Not sure of the details.
> For The windows interactive device it is perhaps not a big deal - for
> wxWidgets the user can pass in a paint dc or a memory dc so in the
> latter case it is down to the user to specify a DPI. Because all DCs
> are treated equal it is up to the user in all instances. Re DPI
> basically being a text scaling parameter - well you are correct - but
> does any other function receive arguments in mm/inches or is text the
> only one?
> 

At least when it comes to DPI, text is the only that uses that field.  I think all the drawing commands are in the plot coordinate system, thus physical dimensions are subsumed into the coordinate system.  There is plsvpa() that allows the user to specify the viewport in terms of physical measurements.

My rationale for keeping the dpi tied to the device is to ensure that physical measurements are invariant (the principle of least surprise).  If the API says “mm” or “inches” the driver should render something that measures correctly.

>> Which size are you referring to?  When the window is resized, the driver gets >the new dimensions of the client area (via GetClientRect() for displays and >GetDeviceCaps() for printers).  It uses the new size to calculate the new >scaling between device virtual coordinates (PIXELS_X/PIXELS_Y in PLplot) >and the new output device coordinates, The dpi remains consistent with what >Windows reports.
>> 
> So for wxWidgets if I resize the window to double the size, the text
> stays the same size. I.e. I maintain the same dpi and text height in
> mm when the window is resized.
> 

Same with wingdi.  When resized the text stays the same.  

Re: [Plplot-devel] Bug fix to plbuf.c

[Hazen B. <hba...@ma...>]

On 06/14/2015 05:59 PM, Alan W. Irwin wrote:
> On 2015-06-14 13:40-0400 Jim Dishaw wrote:
>
>> [....]The aqt driver is a mystery.  It does not use the plot buffer
> nor does it look at the nopause member; however, it is an interactive
> driver. It should work with just a NULL in the wait handler because
> the EOP will be called only once.  The dg300 is another example.
>
> Hi Jim:
>
> See cmake/modules/drivers-init.cmake for the status of each device
> driver.  Some of them (e.g., dg300) have been completely retired
> because they are unmaintained and likely not compatible with modern
> PLplot any more.  We should completely remove the source code for
> every retired PLplot device such as dg300 so as not to have old
> incompatible driver code obfuscating the source code for devices that
> are being actively maintained.
>
> @Hazen:
> Have you given up on maintaining aqt, i.e., is it time to retire that
> driver and completely remove its source code?

I am not maintaining it, but I believe that it still works so I would 
not remove it.

-Hazen

Re: [Plplot-devel] Bug fix to plbuf.c

[Alan W. I. <ir...@be...>]

On 2015-06-14 19:16-0400 Jim Dishaw wrote:

> I am planning on making a native driver for macos x, though I am not
sure if I can make the cutoff for 5.11.1

Hi Jim:

Such a native Mac OS X device would be quite welcome.  However, that's
new development where the cutoff for pushing to the master branch is
roughly one month after the latest release.  The reason why I decided
to assert that policy as release manager is to provide plenty of
testing time during a release cycle for any new development.

So we are long past that cutoff for this release cycle, but I still
strongly encourage merging bug fixes (like one of your two suggestions
for fixing the eop bug) and documentation (e.g., the documentation for
developers of modern devices that was discussed) to master for quite a
while longer during this current release cycle.

With regard to new development such as the new GDI and Mac OS X
devices, ideally you should develop and mature them now on private
development branches so you will be prepared to merge them to master
just after the release of 5.11.1 (and certainly within the first month
after that date).

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
__________________________

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 14, 2015, at 5:59 PM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-06-14 13:40-0400 Jim Dishaw wrote:
>> 
>> [....]The aqt driver is a mystery.  It does not use the plot buffer
> nor does it look at the nopause member; however, it is an interactive
> driver. It should work with just a NULL in the wait handler because
> the EOP will be called only once.  The dg300 is another example.
> 
> Hi Jim:
> 
> See cmake/modules/drivers-init.cmake for the status of each device
> driver.  Some of them (e.g., dg300) have been completely retired
> because they are unmaintained and likely not compatible with modern
> PLplot any more.  We should completely remove the source code for
> every retired PLplot device such as dg300 so as not to have old
> incompatible driver code obfuscating the source code for devices that
> are being actively maintained.
> 
> @Hazen:
> Have you given up on maintaining aqt, i.e., is it time to retire that
> driver and completely remove its source code?
> 

I am planning on making a native driver for macos x, though I am not sure if I can make the cutoff for 5.11.1

Re: [Plplot-devel] Bug fix to plbuf.c

[Alan W. I. <ir...@be...>]

On 2015-06-14 13:40-0400 Jim Dishaw wrote:

> [....]The aqt driver is a mystery.  It does not use the plot buffer
nor does it look at the nopause member; however, it is an interactive
driver. It should work with just a NULL in the wait handler because
the EOP will be called only once.  The dg300 is another example.

Hi Jim:

See cmake/modules/drivers-init.cmake for the status of each device
driver.  Some of them (e.g., dg300) have been completely retired
because they are unmaintained and likely not compatible with modern
PLplot any more.  We should completely remove the source code for
every retired PLplot device such as dg300 so as not to have old
incompatible driver code obfuscating the source code for devices that
are being actively maintained.

@Hazen:
Have you given up on maintaining aqt, i.e., is it time to retire that
driver and completely remove its source code?

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
__________________________

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 14, 2015, at 5:19 AM, Alan W. Irwin <ir...@be...> wrote:
> 
> On 2015-06-13 22:29-0400 Jim Dishaw wrote:
> 
>> 
>>> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
>>> 
>>> 
>>> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>> wrote:
>>> 
>>>> Hmmm
>>>> Then hmmmm some more
>>>> Followed by an ummm or two.
>>>> 
>>>> As you say Jim, clearly things are more complicated than I realised. I'm not sure what the requirements really are here now. Now you have brought this up I can imagine the issues associated with entering the message loop after an eop.
>>>> 
>>>> In terms of dealing with it, I'm not at my computer right now, but I think probably a bop_forced function which forces a bop irrespective of where we are in the page cycle would work. But I'm not sure if that might have some potential subtle effects elsewhere so it is a bit of a hack really. Perhaps instead it would be better to assess what is being done in a bop and ensure those actions end up in the buffer so a bop event is not required.
>>>> 
>>> 
>>> I think that is a good approach for reasons beyond this issue, but a BOP and EOP of some type is still required to support the drivers adequately (e.g double buffering, printing from the windows API).
>>> 
>>> The solution I'm going to test is one where the driver does not enter into a wait for input state on a redraw event from the callback.
>> 
>> I came up with two solutions, one of which I tested.
>> 
>> Solution 1 (Tested)
>> 
>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed.  I like the symmetry of having an EOP in the buffer to match the BOP.
>> 
>> Drivers will be responsible for determining if a “wait for user input” should be performed during an EOP.  For the wingdi driver I track the state of a “page_state” that changes outside of the BOP/EOP calls.
>> 
>> This solution feels a bit kludgy, but it works.
>> 
>> Solution 2
>> 
>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed.
>> 
>> Add a new driver function to the dispatch table (e.g. pl_wait) that calls the "wait for user input between pages" function.
>> 
>> Remove from all drivers the “wait for input” from the EOP handler.
>> 
>> The PLplot core library will call the wait for input between pages function (if not null).
>> 
>> This solution strikes me as a more elegant solution because the logic for deciding about the wait for input is one spot.
>> 
> 
>> Regardless of the solution, some changes to the drivers will be
> required.  Solution 2 will touch all the drivers (at a minimum to add
> a NULL to the dispatch table).  Solution 1 adds code to the drivers
> while solution 2 removes some code from the drivers.
> 
> Hi Jim:
> 
> Thanks for your effort working through possible solutions to the
> problem.
> 
> @Phil and Andrew:
> 
> Assuming you guys agree with Jim's analysis, do you prefer solution 1
> or 2?  Elegant and "removes some code from the drivers" (i.e.,
> solution 2) seems like the better choice to me from an overview
> perspective, but I would be happy to go along with whatever you all
> decide since I do not have the driver expertise you guys have.
> 
> Assuming whatever solution is decided upon here can be implemented
> in a reasonably timely way, then I think we should be able to fit
> it into the forthcoming bug-fix release since this is obviously a
> bug fix, albeit a rather intrusive one.
> 
> With regard to timing for that release there is still quite a bit I
> plan to do to work through the bugs in the build system revealed by
> previous tests on Linux and Arjen's current tests on the Cygwin
> platform. And the new tarball report that is automatically collected
> by scripts/comprehensive_test.sh should make reporting of tests and
> figuring out build-system issues from those reports _much_ easier.
> Which likely means this release will be tested on a lot more platforms
> than the last one and a significant amount of time will be required to
> deal with any build system bugs that are turned up by such tests. So
> my current guestimate is the forthcoming release is likely more than a
> month away (although hopefully not longer than two months away).
> 

The drivers that look at the npause of the PLStream structure are:

drivers/cairo.c
drivers/deprecated_wxwidgets.cpp
drivers/linuxvga.c
drivers/mem.c
drivers/ntk.c
drivers/pbm.c
drivers/qt.cpp
drivers/tek.c
drivers/tk.c
drivers/tkwin.c
drivers/wingcc.c
drivers/xwin.c

Of those, the ones that use plRemakePlot() or the plot buffer are:

drivers/tkwin.c
drivers/wingcc.c
drivers/xwin.c
The new wxWidgets drivers

Thus, implementing the second solution is fairly trivial for the non-plot buffer drivers (just need to split the EOP handler)

Looking at the relevant files:

The easy to split: cairo, linuxvga, qt, tk, twin, wingcc, xwin

The “needs some thought”:
  ntk - driver pauses when the stream is destroyed (in the plD_tidy_ntk function rather than the EOP handler).
  tek - will need to move the CLEAR_VIEW in addition to splitting

The false positives (they don’t actually pause, they set nopause to true): men, pbm

The aqt driver is a mystery.  It does not use the plot buffer nor does it look at the nopause member; however, it is an interactive driver. It should work with just a NULL in the wait handler because the EOP will be called only once.  The dg300 is another example.

 

Re: [Plplot-devel] Tcl build error

[Alan W. I. <ir...@be...>]

On 2015-06-14 11:12+0100 Phil Rosenberg wrote:

> I've recently started getting a build error for TCL
>
> The error I get is
>
> 8>------ Build started: Project: concatenate_pkgIndex.tcl,
> Configuration: Release x64 ------
> 8> Building Custom Rule D:/usr/local/src/plplot-plplot/bindings/CMakeLists.txt
> 8> CMake does not need to re-run because
> D:\usr\local\src\plplot-plplot\build\Visual Studio 11
> 64s\bindings\CMakeFiles\generate.stamp is up-to-date.
> 8> Generating pkgIndex.tcl
> 8> CMake Error at concatenate_pkgIndex.tcl.cmake:4 (file):
> 8> file failed to open for reading (No such file or directory):
> 8>
> 8> D:/usr/local/src/plplot-plplot/build/Visual Studio 11 64s/bindings/Studio
> 8>
> 8>
>
> Looking at the path it is trying to find I would guess that the issue
> is related to me having spaces in my build path.
>
> Unfortunately this error means that my INSTALL project (the equivalent
> to make install) doesn't run to completion and I am currently having
> to manually copy the built results to the install directory.

Hi Phil:

You can use

git blame bindings/CMakeLists.txt |less

to discover the last change in this concatanation logic was done by me
on 2015-04-21.  And you can then use

git blame a8873275^ bindings/CMakeLists.txt |less

to show the previous change to the concatanation part of the code was back in 2009-11-01 so likely not
relevant to the issue you just discovered.

I have also used

git diff a8873275^..a8873275 bindings/CMakeLists.txt |less

to look carefully at the change in logic there which simply changes
the contatanation from cmake time to build time.  I frankly don't see
how that change affects "spaced" path issues so perhaps using
the cmake -P command to exercise this logic at build time somehow
treats blanks in pathnames differently than the original logic?

Anyhow, to investigate further, will you please take a look at the
file bindings/concatenate_pkgIndex.tcl.cmake in the build tree which
is generated at CMake time by the CMake concatanation logic in
bindings/CMakeLists.txt and executed at run time by building the
concatenate_pkgIndex.tcl target which in turn simply runs

cmake -P bindings/concatenate_pkgIndex.tcl.cmake

You can also run that command by hand to see exactly what the issue is.

If there is some obvious part of that generated file that needs quotes
around the pathname, please insert the corresponding escaped quotes
into the concatanation logic in bindings/CMakeLists.txt, test that
change, and if it works for you please push 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
__________________________

[Plplot-devel] Tcl build error

[Phil R. <p.d...@gm...>]

I've recently started getting a build error for TCL

The error I get is

8>------ Build started: Project: concatenate_pkgIndex.tcl,
Configuration: Release x64 ------
8> Building Custom Rule D:/usr/local/src/plplot-plplot/bindings/CMakeLists.txt
8> CMake does not need to re-run because
D:\usr\local\src\plplot-plplot\build\Visual Studio 11
64s\bindings\CMakeFiles\generate.stamp is up-to-date.
8> Generating pkgIndex.tcl
8> CMake Error at concatenate_pkgIndex.tcl.cmake:4 (file):
8> file failed to open for reading (No such file or directory):
8>
8> D:/usr/local/src/plplot-plplot/build/Visual Studio 11 64s/bindings/Studio
8>
8>

Looking at the path it is trying to find I would guess that the issue
is related to me having spaces in my build path.

Unfortunately this error means that my INSTALL project (the equivalent
to make install) doesn't run to completion and I am currently having
to manually copy the built results to the install directory.

Phil

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Phil R. <p.d...@gm...>]

On 11 June 2015 at 17:57, Jim Dishaw <ji...@di...> wrote:
>
>> On Jun 11, 2015, at 4:06 AM, Phil Rosenberg <p.d...@gm...> wrote:
>>
>> Hi Jim
>> The documentation states that the provided text height will be in mm.
>> The user can set dpi with plspage so you should use the PLStream->xdpi
>> and PLStream->ydpi to size your text in pixels. In case the user
>> hasn't set this you should use a sensible default. Of course the
>> actual value will depend on the monitor, but rather than try to grab
>> this it seems that there are two standards and for consistency you
>> should use one of these. One is to use 72 pixels per inch so that 1
>> pixel = 1 pt. The other is 90 pixels per inch which seems to be the
>> default for most svg renderers. For wxWidgets I chose 90 pixels per
>> inch. I also noticed tect seems a little smaller than the example
>> online (from the cairo driver?) but it does as described in the
>> documentation so I am happy with that.
>


>
> The recommendation in the Windows API is to use GetDeviceCaps () with the >LOGPIXELSX/LOGPIXELSY values to get the dpi setting.  Right now I’m >ignoring the DPI setting provided by the user.  On native text rendering devices >the xdpi/ydpi settings are essentially being used to scale the size of fonts, >which (IMHO) abuses the meaning of “DPI”.
>
Yes as you say the windows API provides this mechanism - in fact there
is something about if you wish to have your app in the windows store
you must do this so your app can work on phones/tablets/pcs or
something. Not sure of the details.
For The windows interactive device it is perhaps not a big deal - for
wxWidgets the user can pass in a paint dc or a memory dc so in the
latter case it is down to the user to specify a DPI. Because all DCs
are treated equal it is up to the user in all instances. Re DPI
basically being a text scaling parameter - well you are correct - but
does any other function receive arguments in mm/inches or is text the
only one?

> Which size are you referring to?  When the window is resized, the driver gets >the new dimensions of the client area (via GetClientRect() for displays and >GetDeviceCaps() for printers).  It uses the new size to calculate the new >scaling between device virtual coordinates (PIXELS_X/PIXELS_Y in PLplot) >and the new output device coordinates,  The dpi remains consistent with what >Windows reports.
>
So for wxWidgets if I resize the window to double the size, the text
stays the same size. I.e. I maintain the same dpi and text height in
mm when the window is resized.

Phil

Re: [Plplot-devel] Bug fix to plbuf.c

[Alan W. I. <ir...@be...>]

On 2015-06-13 22:29-0400 Jim Dishaw wrote:

>
>> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
>>
>>
>> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>> wrote:
>>
>>> Hmmm
>>> Then hmmmm some more
>>> Followed by an ummm or two.
>>>
>>> As you say Jim, clearly things are more complicated than I realised. I'm not sure what the requirements really are here now. Now you have brought this up I can imagine the issues associated with entering the message loop after an eop.
>>>
>>> In terms of dealing with it, I'm not at my computer right now, but I think probably a bop_forced function which forces a bop irrespective of where we are in the page cycle would work. But I'm not sure if that might have some potential subtle effects elsewhere so it is a bit of a hack really. Perhaps instead it would be better to assess what is being done in a bop and ensure those actions end up in the buffer so a bop event is not required.
>>>
>>
>> I think that is a good approach for reasons beyond this issue, but a BOP and EOP of some type is still required to support the drivers adequately (e.g double buffering, printing from the windows API).
>>
>> The solution I'm going to test is one where the driver does not enter into a wait for input state on a redraw event from the callback.
>
> I came up with two solutions, one of which I tested.
>
> Solution 1 (Tested)
>
> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed.  I like the symmetry of having an EOP in the buffer to match the BOP.
>
> Drivers will be responsible for determining if a “wait for user input” should be performed during an EOP.  For the wingdi driver I track the state of a “page_state” that changes outside of the BOP/EOP calls.
>
> This solution feels a bit kludgy, but it works.
>
> Solution 2
>
> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed.
>
> Add a new driver function to the dispatch table (e.g. pl_wait) that calls the "wait for user input between pages" function.
>
> Remove from all drivers the “wait for input” from the EOP handler.
>
> The PLplot core library will call the wait for input between pages function (if not null).
>
> This solution strikes me as a more elegant solution because the logic for deciding about the wait for input is one spot.
>

> Regardless of the solution, some changes to the drivers will be
required.  Solution 2 will touch all the drivers (at a minimum to add
a NULL to the dispatch table).  Solution 1 adds code to the drivers
while solution 2 removes some code from the drivers.

Hi Jim:

Thanks for your effort working through possible solutions to the
problem.

@Phil and Andrew:

Assuming you guys agree with Jim's analysis, do you prefer solution 1
or 2?  Elegant and "removes some code from the drivers" (i.e.,
solution 2) seems like the better choice to me from an overview
perspective, but I would be happy to go along with whatever you all
decide since I do not have the driver expertise you guys have.

Assuming whatever solution is decided upon here can be implemented
in a reasonably timely way, then I think we should be able to fit
it into the forthcoming bug-fix release since this is obviously a
bug fix, albeit a rather intrusive one.

With regard to timing for that release there is still quite a bit I
plan to do to work through the bugs in the build system revealed by
previous tests on Linux and Arjen's current tests on the Cygwin
platform. And the new tarball report that is automatically collected
by scripts/comprehensive_test.sh should make reporting of tests and
figuring out build-system issues from those reports _much_ easier.
Which likely means this release will be tested on a lot more platforms
than the last one and a significant amount of time will be required to
deal with any build system bugs that are turned up by such tests. So
my current guestimate is the forthcoming release is likely more than a
month away (although hopefully not longer than two months away).

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
__________________________