plplot-devel — Technical discussion about PLplot development

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

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

Hi Phil,



> -----Original Message-----
> From: Phil Rosenberg [mailto:p.d...@gm...]
>
> ...

> I assume this has something to do with aspect ratios of the page on the different
> devices or something. But anyway, these inconsistent sizes means it isn't possible
> to generate a case that exposes the bug on all devices. I think all those involved
> have access to wxWidgets - please state if not - so I think this should be fine for us
> to work on.
>
wxWidgets is not available on bare Windows. It is on Cygwin, though I have never done much with it.

Regards,

Arjen



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

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

On 13 September 2016 at 02:13, Alan W. Irwin <ir...@be...> wrote:
> On 2016-09-12 21:21+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>> I just built on Ubuntu (disabling F95 due to the issue I reported a
>> short while ago). I get the same full fill issue with wxWidgets, but
>> not with other drivers. I guess each driver may use slightly different
>> geometry so it ruins the example. Please could you try with wxWidgets
>> driver or let me know if you have tried that and it still fails.
>
>
> I confirm the full fill issue with -dev wxwidgets.  So it appears we
> finally have a reproducible example of a problem, but you should
> follow up by figuring out exactly why wxwidgets shows the issue and
> our other devices currently do not and ideally you will be able to
> follow up even further by adjusting the example slightly so all our
> devices show the issue.

Hi Alan
I have just checked by trying the case I sent round with the svg
device on Windows. The viewport has different dimensions for this
device compared to wxWidgets and hence the geometry does not work and
the bug is not exposed. For example the bottom left corner for the svg
device is [4587,2867], whereas for wxWidgets it is [4468,3965].

I assume this has something to do with aspect ratios of the page on
the different devices or something. But anyway, these inconsistent
sizes means it isn't possible to generate a case that exposes the bug
on all devices. I think all those involved have access to wxWidgets -
please state if not - so I think this should be fine for us to work
on.

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

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

Hi Phil, Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> @Arjen: I am interested whether gcc on Cygwin for this current example triggers
> the bug or not.
>
I will test it but it may be a one or two days before I get around to it.

Regards,

Arjen

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] Fortran build error on Ubuntu

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

Hi Phil, Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Phil:
>
> ...

>
> Could the problem be that you are using an older version of gfortran that does not
> completely support the Fortran 2003 standards that we depend on for our new
> Fortran binding and examples?
>
An old version might indeed be the cause of this. Given that the code produces no warnings like that with several other compilers (including the gfortran compiler in one version or other) is a strong indication for this.

Regards,

Arjen



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

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

On 2016-09-12 21:39+0100 Phil Rosenberg wrote:

>>>> I'm still of the opinion that the notcrossed function should not use
>>>> the 2 pixel fuzziness. At this point in the drawing we are dealing in
>>>> integer pixels and we need only an epsilon test I think. I think the
>>>> best fix is to change this. There are some sticking plaster solutions
>>>> that would hide the problem but not really fix it in my opinion. I
>>>> would really like to change the notcrossed function unless anyone has
>>>> some really strong objections?
>>>
>>>
>>> My opinion is this is an extraordinarily tricky topic where all the
>>> currently active fill code (i.e., the part of the code not currently
>>> removed by the C preprocessor) needs to be completely reviewed and
>>> potentially rewritten. Also, I think the fuzziness logic (with all
>>> bugs fixed in that code) should stay just in the interests of
>>> providing some tolerance for numerical rounding errors.  For example,
>>> even the article <https://en.wikipedia.org/wiki/Point_in_polygon>
>>> talks of providing some numerical tolerance.  Note also, such
>>> tolerance is certainly required for the integer case since minute
>>> rounding errors in the floating point calculations that decide, for
>>> example, whether a point is inside or outside a polygon can shift
>>> integer results around by +/- 1.
>>>
>>> I have a topic branch where I have already taken some substantial
>>> steps along the above ideas (including at least one bug fix in our
>>> current fuzzy logic in notcrossed). I temporarily halted work on that
>>> topic some time ago, but assuming you can provide a test example that
>>> triggers fill bugs regardless of compiler or optimization level, I
>>> plan to take up that topic again where the first order of business
>>> will be to compare (using imagemagick image differences) updated fill
>>> algorithm results versus 5.11.1 results for all our standard examples
>>> that use fill in some way.  (That test should turn up any unusual fill
>>> artifacts in our examples that are generated by bugs in the original
>>> or revised fill algorithm, and once that test is implemented it should
>>> be done for any fill change from now on.) In addition, of course, I
>>> will look carefully at your example to make sure the revised fill
>>> algorithm produces the correct result for it.
>>>
>>> Assuming you are able to provide the requested example which triggers
>>> the fill bug regardless of rounding issues, and the above
>>> plan meets with your approval, I would plan to start working on this
>>> topic again just after the current release is out the door.
>>>
>>> Note also there are still a number of relatively small issues I would
>>> like to address for this release, but because of the break I mentioned
>>> above, I made little progress on those this summer so that release
>>> deadline is still indefinite and at least a month or two away.
>>>
> I agree that this is tricky, but feel this is something we can deal
> with without being too troublesome. Algorithms and code already exist
> to do this consistently - we're not the first to have to deal with it.
> In fact here is a 7 line C implementation that deals with the ray
> hitting a vertex correctly, but doesn't give any warning about if the
> point is close to or on a segment.
>
> I still don't understand why we need two whole plplot units of
> fuzziness. I understand that we round and that can give us up to two
> pixels of error. But surely we just accept that and work with the
> rounded polygons as if they were exact - in fact they are exact
> because they use integers.
>
> for example we wish to plot two rectangles which end up with internal
> coordinates of the opposite corners of (200,400.2),(600,600.4) and
> (200,600.4),(600,800.1). We round these to give (200,400),(600,600)
> and (200,600),(600,800). Now there is absolutely no count that the
> point (350,600.2) is in the second rectangle. Of course if we were
> using the original coordinates this point would have been in the first
> rectangle. But we are not plotting the original coordinates, we are
> plotting the rounded coordinates and that is what matters - the
> coordinates we are plotting.

We shouldn't care about 1-pixel rounding shifts in results.  But we do
need to care about logic screwups caused by such shifts.  Of course,
you are also demonstrating the current fuzzy logic sucks, i.e., the
cure is currently worse than the disease.  But let's fix that fuzzy
logic rather than throwing it out completely.

>
> I would clearly like to get this fixed properly, but in the meantime
> would anyone object if I apply a sticking plaster fix for this as it
> is something I have hit about half a dozen times over the last six
> months - I presume this is because I've been plotting some really high
> resolution data. So I do really need to avoid the issue for now.

There is a substantial testing requirement for fill changes. The
reason for that is we have had years of mostly good user experience
with the present fill algorithm so I feel it is important that anybody
that changes the fill algorithm in any further way needs to
demonstrate with substantial testing that their change does not
introduce fill regressions.

I have alluded previously to automated fill regression testing (for
all our standard examples that directly or indirectly use fill and all
our file devices).  The core of the idea is to compare old and updated
plot file results using imagemagick image differences.  Do you agree
this general approach (supplemented by actually looking at the "fill"
subset of our examples for each of our interactive devices) is the way
forward to insure that our further fill changes do not introduce more
issues than they fix?

Assuming you like this idea, please implement it if you are in a hurry
or else wait for me to implement it post-release.  Then once our fill
regression testing scheme is in place, you should test any proposed
fill change with that scheme before you merge that fill change to the
master branch.

Of course, while waiting for one of us to implement such a fill
testing scheme, there is still the problem about what to do for the
fill problems that have recently been bugging you?  I suggest you
should simply solve those issues locally in any convenient way that
you find that works for your particular needs, and circulate that
patch on this list to be referred to when we finally start working on
the definitive fix.

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...>]

On 2016-09-12 21:21+0100 Phil Rosenberg wrote:

> Hi Alan
> I just built on Ubuntu (disabling F95 due to the issue I reported a
> short while ago). I get the same full fill issue with wxWidgets, but
> not with other drivers. I guess each driver may use slightly different
> geometry so it ruins the example. Please could you try with wxWidgets
> driver or let me know if you have tried that and it still fails.

I confirm the full fill issue with -dev wxwidgets.  So it appears we
finally have a reproducible example of a problem, but you should
follow up by figuring out exactly why wxwidgets shows the issue and
our other devices currently do not and ideally you will be able to
follow up even further by adjusting the example slightly so all our
devices show 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] Fortran build error on Ubuntu

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

On 2016-09-12 21:07+0100 Phil Rosenberg wrote:

> Hi Alan
> I just tried to build on Ubuntu to check your results and got a build
> error that seems fortran related. I thought I'd start a new thread to
> keep the subjects separate. I'm just doing
>
> cmake ..
> make all
>
> My build directory is a subdirectory of the source directory. The
> compile error is
>
>
> make: *** [all] Error 2make[1]: ***
> [bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2make[2]: ***
> [bindings/f95/CMakeFiles/plplotf95.dir/plplot_double.f90.o.provides]
> Error 2make[3]: ***
> [bindings/f95/CMakeFiles/plplotf95.dir/plplot_double.f90.o] Error
> 1Error: Assumed-shape array 'plotentries' at (1) cannot be an argument
> to the procedure 'c_loc' because it is not C interoperable
>            1                   c_loc(plotentries), size(plotentries,

[...]

> Is there anything I need to do differently? This is a totally clean
> build directory with the latest source.

Hi Phil:

Everything you are doing to test the Fortran build seems fine, but
Arjen does not get such compile errors (or any warnings at all!) with
the NAG compiler (notorious for being sensitive to any violation of
Fortran standards in the source code for our Fortran binding and
examples), and I don't get such compile errors when I build our
fortran bindind and examples on Debian using gfortran version 4.9.2.

Could the problem be that you are using an older version of gfortran
that does not completely support the Fortran 2003 standards that we
depend on for our new Fortran binding and examples?

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

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

sorry meant "no doubt that the point" not "no count that the point"

On 12 September 2016 at 21:39, Phil Rosenberg <p.d...@gm...> wrote:
>>>> I'm still of the opinion that the notcrossed function should not use
>>>> the 2 pixel fuzziness. At this point in the drawing we are dealing in
>>>> integer pixels and we need only an epsilon test I think. I think the
>>>> best fix is to change this. There are some sticking plaster solutions
>>>> that would hide the problem but not really fix it in my opinion. I
>>>> would really like to change the notcrossed function unless anyone has
>>>> some really strong objections?
>>>
>>>
>>> My opinion is this is an extraordinarily tricky topic where all the
>>> currently active fill code (i.e., the part of the code not currently
>>> removed by the C preprocessor) needs to be completely reviewed and
>>> potentially rewritten. Also, I think the fuzziness logic (with all
>>> bugs fixed in that code) should stay just in the interests of
>>> providing some tolerance for numerical rounding errors.  For example,
>>> even the article <https://en.wikipedia.org/wiki/Point_in_polygon>
>>> talks of providing some numerical tolerance.  Note also, such
>>> tolerance is certainly required for the integer case since minute
>>> rounding errors in the floating point calculations that decide, for
>>> example, whether a point is inside or outside a polygon can shift
>>> integer results around by +/- 1.
>>>
>>> I have a topic branch where I have already taken some substantial
>>> steps along the above ideas (including at least one bug fix in our
>>> current fuzzy logic in notcrossed). I temporarily halted work on that
>>> topic some time ago, but assuming you can provide a test example that
>>> triggers fill bugs regardless of compiler or optimization level, I
>>> plan to take up that topic again where the first order of business
>>> will be to compare (using imagemagick image differences) updated fill
>>> algorithm results versus 5.11.1 results for all our standard examples
>>> that use fill in some way.  (That test should turn up any unusual fill
>>> artifacts in our examples that are generated by bugs in the original
>>> or revised fill algorithm, and once that test is implemented it should
>>> be done for any fill change from now on.) In addition, of course, I
>>> will look carefully at your example to make sure the revised fill
>>> algorithm produces the correct result for it.
>>>
>>> Assuming you are able to provide the requested example which triggers
>>> the fill bug regardless of rounding issues, and the above
>>> plan meets with your approval, I would plan to start working on this
>>> topic again just after the current release is out the door.
>>>
>>> Note also there are still a number of relatively small issues I would
>>> like to address for this release, but because of the break I mentioned
>>> above, I made little progress on those this summer so that release
>>> deadline is still indefinite and at least a month or two away.
>>>
> I agree that this is tricky, but feel this is something we can deal
> with without being too troublesome. Algorithms and code already exist
> to do this consistently - we're not the first to have to deal with it.
> In fact here is a 7 line C implementation that deals with the ray
> hitting a vertex correctly, but doesn't give any warning about if the
> point is close to or on a segment.
>
> I still don't understand why we need two whole plplot units of
> fuzziness. I understand that we round and that can give us up to two
> pixels of error. But surely we just accept that and work with the
> rounded polygons as if they were exact - in fact they are exact
> because they use integers.
>
> for example we wish to plot two rectangles which end up with internal
> coordinates of the opposite corners of (200,400.2),(600,600.4) and
> (200,600.4),(600,800.1). We round these to give (200,400),(600,600)
> and (200,600),(600,800). Now there is absolutely no count that the
> point (350,600.2) is in the second rectangle. Of course if we were
> using the original coordinates this point would have been in the first
> rectangle. But we are not plotting the original coordinates, we are
> plotting the rounded coordinates and that is what matters - the
> coordinates we are plotting.
>
> I would clearly like to get this fixed properly, but in the meantime
> would anyone object if I apply a sticking plaster fix for this as it
> is something I have hit about half a dozen times over the last six
> months - I presume this is because I've been plotting some really high
> resolution data. So I do really need to avoid the issue for now.
>
> Phil

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

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

>>> I'm still of the opinion that the notcrossed function should not use
>>> the 2 pixel fuzziness. At this point in the drawing we are dealing in
>>> integer pixels and we need only an epsilon test I think. I think the
>>> best fix is to change this. There are some sticking plaster solutions
>>> that would hide the problem but not really fix it in my opinion. I
>>> would really like to change the notcrossed function unless anyone has
>>> some really strong objections?
>>
>>
>> My opinion is this is an extraordinarily tricky topic where all the
>> currently active fill code (i.e., the part of the code not currently
>> removed by the C preprocessor) needs to be completely reviewed and
>> potentially rewritten. Also, I think the fuzziness logic (with all
>> bugs fixed in that code) should stay just in the interests of
>> providing some tolerance for numerical rounding errors.  For example,
>> even the article <https://en.wikipedia.org/wiki/Point_in_polygon>
>> talks of providing some numerical tolerance.  Note also, such
>> tolerance is certainly required for the integer case since minute
>> rounding errors in the floating point calculations that decide, for
>> example, whether a point is inside or outside a polygon can shift
>> integer results around by +/- 1.
>>
>> I have a topic branch where I have already taken some substantial
>> steps along the above ideas (including at least one bug fix in our
>> current fuzzy logic in notcrossed). I temporarily halted work on that
>> topic some time ago, but assuming you can provide a test example that
>> triggers fill bugs regardless of compiler or optimization level, I
>> plan to take up that topic again where the first order of business
>> will be to compare (using imagemagick image differences) updated fill
>> algorithm results versus 5.11.1 results for all our standard examples
>> that use fill in some way.  (That test should turn up any unusual fill
>> artifacts in our examples that are generated by bugs in the original
>> or revised fill algorithm, and once that test is implemented it should
>> be done for any fill change from now on.) In addition, of course, I
>> will look carefully at your example to make sure the revised fill
>> algorithm produces the correct result for it.
>>
>> Assuming you are able to provide the requested example which triggers
>> the fill bug regardless of rounding issues, and the above
>> plan meets with your approval, I would plan to start working on this
>> topic again just after the current release is out the door.
>>
>> Note also there are still a number of relatively small issues I would
>> like to address for this release, but because of the break I mentioned
>> above, I made little progress on those this summer so that release
>> deadline is still indefinite and at least a month or two away.
>>
I agree that this is tricky, but feel this is something we can deal
with without being too troublesome. Algorithms and code already exist
to do this consistently - we're not the first to have to deal with it.
In fact here is a 7 line C implementation that deals with the ray
hitting a vertex correctly, but doesn't give any warning about if the
point is close to or on a segment.

I still don't understand why we need two whole plplot units of
fuzziness. I understand that we round and that can give us up to two
pixels of error. But surely we just accept that and work with the
rounded polygons as if they were exact - in fact they are exact
because they use integers.

for example we wish to plot two rectangles which end up with internal
coordinates of the opposite corners of (200,400.2),(600,600.4) and
(200,600.4),(600,800.1). We round these to give (200,400),(600,600)
and (200,600),(600,800). Now there is absolutely no count that the
point (350,600.2) is in the second rectangle. Of course if we were
using the original coordinates this point would have been in the first
rectangle. But we are not plotting the original coordinates, we are
plotting the rounded coordinates and that is what matters - the
coordinates we are plotting.

I would clearly like to get this fixed properly, but in the meantime
would anyone object if I apply a sticking plaster fix for this as it
is something I have hit about half a dozen times over the last six
months - I presume this is because I've been plotting some really high
resolution data. So I do really need to avoid the issue for now.

Phil

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

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

Hi Alan
I just built on Ubuntu (disabling F95 due to the issue I reported a
short while ago). I get the same full fill issue with wxWidgets, but
not with other drivers. I guess each driver may use slightly different
geometry so it ruins the example. Please could you try with wxWidgets
driver or let me know if you have tried that and it still fails.

Phil

On 12 September 2016 at 20:11, Alan W. Irwin <ir...@be...> wrote:
> Hi Phil:
>
> It was good to hear from you again.
>
> On 2016-09-12 03:06+0100 Phil Rosenberg wrote:
>
>> Hi All
>> It's been a while. Sorry for my lack of activity over the summer.
>
>
> I took quite a long break from PLplot this summer as well.  So no
> worries about that.
>
>
>>
>> I've just picked up some Plplot items again on my to do list, starting
>> with the fill problem that I reported a rather long time ago.
>>
>> I have sorted a minimal example to reproduce the bug - see attached.
>> it turns out that a number of things need to come together to cause
>> this problem. The example is based on example 12 and draws a very
>> small trapezium just off the bottom left corner of the plot. however
>> what happens instead is that the whole plot is filled. The way this
>> works is that a test point is selected to the right of the fill shape
>> and Plplot examines if a line between this point and the bottom left
>> corner intersects the polygon segments to test if the bottom left
>> corner is in the polygon. When the test is performed segments that are
>> close to parallel (based on a ~2 pixel fuzziness) are flagged and in
>> the end treat as a non-intersection. Also if the intersection is close
>> to the end of a line (again 2 pixels is the limit) then the
>> intersection is flagged as too close.
>>
>> In this special case the three short sides are all approximately 2
>> Plplot internal units long which fools the intersection test into
>> thinking they are close to parallel to the test line. See
>> notpointinpolygon() and notcrossed() functions. These three lines are
>> therefore treated as non-intersectionctions even though the test line
>> does intersect one of them. Finally the fourth section is just long
>> enough and the location is just correct that the test line intersects
>> it more than 2 pixels from each end. The result is that the point in
>> polygon test sees 1 intersection instead of two and incorrectly
>> concludes that the bottom left corner is inside the polygon.
>>
>> The final item that causes the bug to manifest is that the polygon is
>> entirely outside of the plot area so no segments are drawable. The
>> test that Plplot performs to see if the whole plot needs filling is
>> that the bottom left corner is inside the fill polygon and all
>> segments are outside the plot area. Hence the incorrect full fill.
>
>
> Thanks very much for providing this example and a thorough explanation
> of what is going wrong on your particular platform, but I cannot
> reproduce the problem here on Linux (gcc version 4.9.2 with
> CFLAGS="-O3" which I presume makes some rounding go just the wrong way
> so this fill bug is not exposed).  Instead of the coloured fill of the
> whole plot you describe, all I get is a labelled blank plot (which is
> I believe the result you desired). Assuming you confirm that good
> result with gcc and CFLAGS="-O3", can you modify your example so it
> triggers the fill bug(s) for all compiler and optimization level
> cases?
>
> @Arjen: I am interested whether gcc on Cygwin for this current example
> triggers the bug or not.
>
>>
>> I'm still of the opinion that the notcrossed function should not use
>> the 2 pixel fuzziness. At this point in the drawing we are dealing in
>> integer pixels and we need only an epsilon test I think. I think the
>> best fix is to change this. There are some sticking plaster solutions
>> that would hide the problem but not really fix it in my opinion. I
>> would really like to change the notcrossed function unless anyone has
>> some really strong objections?
>
>
> My opinion is this is an extraordinarily tricky topic where all the
> currently active fill code (i.e., the part of the code not currently
> removed by the C preprocessor) needs to be completely reviewed and
> potentially rewritten. Also, I think the fuzziness logic (with all
> bugs fixed in that code) should stay just in the interests of
> providing some tolerance for numerical rounding errors.  For example,
> even the article <https://en.wikipedia.org/wiki/Point_in_polygon>
> talks of providing some numerical tolerance.  Note also, such
> tolerance is certainly required for the integer case since minute
> rounding errors in the floating point calculations that decide, for
> example, whether a point is inside or outside a polygon can shift
> integer results around by +/- 1.
>
> I have a topic branch where I have already taken some substantial
> steps along the above ideas (including at least one bug fix in our
> current fuzzy logic in notcrossed). I temporarily halted work on that
> topic some time ago, but assuming you can provide a test example that
> triggers fill bugs regardless of compiler or optimization level, I
> plan to take up that topic again where the first order of business
> will be to compare (using imagemagick image differences) updated fill
> algorithm results versus 5.11.1 results for all our standard examples
> that use fill in some way.  (That test should turn up any unusual fill
> artifacts in our examples that are generated by bugs in the original
> or revised fill algorithm, and once that test is implemented it should
> be done for any fill change from now on.) In addition, of course, I
> will look carefully at your example to make sure the revised fill
> algorithm produces the correct result for it.
>
> Assuming you are able to provide the requested example which triggers
> the fill bug regardless of rounding issues, and the above
> plan meets with your approval, I would plan to start working on this
> topic again just after the current release is out the door.
>
> Note also there are still a number of relatively small issues I would
> like to address for this release, but because of the break I mentioned
> above, I made little progress on those this summer so that release
> deadline is still indefinite and at least a month or two 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
> __________________________

[Plplot-devel] Fortran build error on Ubuntu

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

Hi Alan
I just tried to build on Ubuntu to check your results and got a build
error that seems fortran related. I thought I'd start a new thread to
keep the subjects separate. I'm just doing

cmake ..
make all

My build directory is a subdirectory of the source directory. The
compile error is


make: *** [all] Error 2make[1]: ***
[bindings/f95/CMakeFiles/plplotf95.dir/all] Error 2make[2]: ***
[bindings/f95/CMakeFiles/plplotf95.dir/plplot_double.f90.o.provides]
Error 2make[3]: ***
[bindings/f95/CMakeFiles/plplotf95.dir/plplot_double.f90.o] Error
1Error: Assumed-shape array 'plotentries' at (1) cannot be an argument
to the procedure 'c_loc' because it is not C interoperable
            1                   c_loc(plotentries), size(plotentries,
kind=private_plint) )    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:2502.25:Error:
Assumed-shape array 'plotentries' at (1) cannot be an argument to the
procedure 'c_loc' because it is not C interoperable
     1                   c_loc(plotentries), size(plotentries,
kind=private_plint) )    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:2520.25:Error:
Assumed-shape array 'plotentries' at (1) cannot be an argument to the
procedure 'c_loc' because it is not C interoperable
     1                   c_loc(plotentries), size(plotentries,
kind=private_plint) )    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:2541.25:Error:
Assumed-shape array 'plotentries' at (1) cannot be an argument to the
procedure 'c_loc' because it is not C interoperable
     1                   c_loc(plotentries), size(plotentries,
kind=private_plint) )    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:2559.25:Error:
Assumed-shape array 'plotentries' at (1) cannot be an argument to the
procedure 'c_loc' because it is not C interoperable
     1                   c_loc(plotentries), size(plotentries,
kind=private_plint) )    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:2581.25:Error:
Assumed-shape array 'plotentries' at (1) cannot be an argument to the
procedure 'c_loc' because it is not C interoperable
     1                   c_loc(plotentries), size(plotentries,
kind=private_plint) )    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:2601.25:Warning:
Symbol 'pltransformf2c_data' at (1) is marked PRIVATE but has been
given the binding label 'plplot_double_private_pltransformf2c_data'
                              1    subroutine pltransformf2c_data( x,
y, tx, ty, data ) bind(c, name =
'plplot/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:256.34:Warning:
Symbol 'pltransformf2c' at (1) is marked PRIVATE but has been given
the binding label 'plplot_double_private_pltransformf2c'
              1    subroutine pltransformf2c( x, y, tx, ty, data )
bind(c, name = 'plplot_doub/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:239.29:Warning:
Symbol 'plmapformf2c' at (1) is marked PRIVATE but has been given the
binding label 'plplot_double_private_plmapformf2c'
      1    subroutine plmapformf2c( n, x, y ) bind(c, name =
'plplot_double_private_pl/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:186.27:Warning:
Symbol 'pllabelerf2c_data' at (1) is marked PRIVATE but has been given
the binding label 'plplot_double_private_pllabelerf2c_data'
                    1    subroutine pllabelerf2c_data( axis, value,
label, length, data ) bind(c,
na/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:223.32:Warning:
Symbol 'pllabelerf2c' at (1) is marked PRIVATE but has been given the
binding label 'plplot_double_private_pllabelerf2c'
      1    subroutine pllabelerf2c( axis, value, label, length, data )
bind(c, name =/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:202.27:Warning:
Symbol 'interface_plvect' at (1) is marked PRIVATE but has been given
the binding label 'c_plvect'                                   1
 subroutine interface_plvect( u, v, nx, ny, scale, transform, data )
bin    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:497.35:Warning:
Symbol 'interface_pltr2f' at (1) is marked PRIVATE but has been given
the binding label 'pltr2f'                                   1
subroutine interface_pltr2f( x, y, tx, ty, data ) bind(c, name =
'pltr2    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:485.35:Warning:
Symbol 'interface_pltr1' at (1) is marked PRIVATE but has been given
the binding label 'pltr1'                                  1
subroutine interface_pltr1( x, y, tx, ty, data ) bind(c, name =
'pltr1'    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:474.34:Warning:
Symbol 'interface_pltr0' at (1) is marked PRIVATE but has been given
the binding label 'pltr0'                                  1
subroutine interface_pltr0( x, y, tx, ty, data ) bind(c, name =
'pltr0'    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:463.34:Warning:
Symbol 'interface_plstransform' at (1) is marked PRIVATE but has been
given the binding label 'c_plstransform'
          1        subroutine interface_plstransform( proc, data )
bind(c, name = 'c_plstr/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:69.41:Warning:
Symbol 'interface_plslabelfunc' at (1) is marked PRIVATE but has been
given the binding label 'c_plslabelfunc'
          1        subroutine interface_plslabelfunc( proc, data )
bind(c, name = 'c_plsla/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:60.41:Warning:
Symbol 'interface_plshades_null' at (1) is marked PRIVATE but has been
given the binding label 'plshades_null'
          1        subroutine interface_plshades_null( a, nx, ny,
defined, xmin, xmax, ymi    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:438.42:Warning:
Symbol 'interface_plshades' at (1) is marked PRIVATE but has been
given the binding label 'c_plshades'
  1        subroutine interface_plshades( a, nx, ny, defined, xmin,
xmax, ymin, ym    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:402.37:Warning:
Symbol 'interface_plshade_null' at (1) is marked PRIVATE but has been
given the binding label 'plshade_null'
        1        subroutine interface_plshade_null( a, nx, ny,
defined, xmin, xmax, ymin    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:376.41:Warning:
Symbol 'interface_plshade' at (1) is marked PRIVATE but has been given
the binding label 'c_plshade'                                    1
   subroutine interface_plshade( a, nx, ny, defined, xmin, xmax, ymin,
yma    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:339.36:Warning:
Symbol 'interface_plmeridians' at (1) is marked PRIVATE but has been
given the binding label 'c_plmeridians'
        1        subroutine interface_plmeridians( proc, dlong, dlat,
minlong, maxlong,    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:328.40:Warning:
Symbol 'interface_plmaptex' at (1) is marked PRIVATE but has been
given the binding label 'c_plmaptex'
  1        subroutine interface_plmaptex( proc, name, dx, dy, just,
text, minx, ma    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:315.37:Warning:
Symbol 'interface_plmapstring' at (1) is marked PRIVATE but has been
given the binding label 'c_plmapstring'
        1        subroutine interface_plmapstring( proc, name, string,
minx, maxx, miny,    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:301.40:Warning:
Symbol 'interface_plmapline' at (1) is marked PRIVATE but has been
given the binding label 'c_plmapline'
    1        subroutine interface_plmapline( proc, name, minx, maxx,
miny, maxy, plo    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:287.38:Warning:
Symbol 'interface_plmapfill' at (1) is marked PRIVATE but has been
given the binding label 'c_plmapfill'
    1        subroutine interface_plmapfill( proc, name, minx, maxx,
miny, maxy, plo    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:273.38:Warning:
Symbol 'interface_plmap' at (1) is marked PRIVATE but has been given
the binding label 'c_plmap'                                  1
subroutine interface_plmap( proc, name, minx, maxx, miny, maxy ) &
Included at /home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:261.34:Warning:
Symbol 'interface_plimagefr_null' at (1) is marked PRIVATE but has
been given the binding label 'plimagefr_null'
                 1        subroutine interface_plimagefr_null( idata,
nx, ny, &    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:247.43:Warning:
Symbol 'interface_plimagefr' at (1) is marked PRIVATE but has been
given the binding label 'c_plimagefr'
    1        subroutine interface_plimagefr( idata, nx, ny, &
Included at /home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:222.38:Warning:
Symbol 'interface_plfvect' at (1) is marked PRIVATE but has been given
the binding label 'plfvect'                                    1
 subroutine interface_plfvect( lookup, fgrid1, fgrid2, nx, ny, scale,
tr    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:189.36:Warning:
Symbol 'interface_plfill' at (1) is marked PRIVATE but has been given
the binding label 'c_plfill'                                   1
 subroutine interface_plfill( n, x, y ) bind( c, name='c_plfill')
Included at /home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:179.35:Warning:
Symbol 'interface_plfcont' at (1) is marked PRIVATE but has been given
the binding label 'plfcont'                                    1
 subroutine interface_plfcont( lookup, grid, nx, ny, kx, lx, ky, ly,
cle    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:145.36:Warning:
Symbol 'interface_plf2evalr' at (1) is marked PRIVATE but has been
given the binding label 'plf2evalr'        1        function
interface_plf2evalr( ix, iy, data ) bind(c, name = 'plf2evalr'
Included at /home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:133.8:Warning:
Symbol 'interface_plcont' at (1) is marked PRIVATE but has been given
the binding label 'c_plcont'                                   1
 subroutine interface_plcont( z, nx, ny, kx, lx, ky, ly, clevel,
nlevel,    Included at
/home/tv/src/plplot-plplot/bindings/f95/plplot_double.f90:117:included_plplot_real_interfaces.f90:109.35:



Is there anything I need to do differently? This is a totally clean
build directory with the latest source.

Phil

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

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

Hi Phil:

It was good to hear from you again.

On 2016-09-12 03:06+0100 Phil Rosenberg wrote:

> Hi All
> It's been a while. Sorry for my lack of activity over the summer.

I took quite a long break from PLplot this summer as well.  So no
worries about that.

>
> I've just picked up some Plplot items again on my to do list, starting
> with the fill problem that I reported a rather long time ago.
>
> I have sorted a minimal example to reproduce the bug - see attached.
> it turns out that a number of things need to come together to cause
> this problem. The example is based on example 12 and draws a very
> small trapezium just off the bottom left corner of the plot. however
> what happens instead is that the whole plot is filled. The way this
> works is that a test point is selected to the right of the fill shape
> and Plplot examines if a line between this point and the bottom left
> corner intersects the polygon segments to test if the bottom left
> corner is in the polygon. When the test is performed segments that are
> close to parallel (based on a ~2 pixel fuzziness) are flagged and in
> the end treat as a non-intersection. Also if the intersection is close
> to the end of a line (again 2 pixels is the limit) then the
> intersection is flagged as too close.
>
> In this special case the three short sides are all approximately 2
> Plplot internal units long which fools the intersection test into
> thinking they are close to parallel to the test line. See
> notpointinpolygon() and notcrossed() functions. These three lines are
> therefore treated as non-intersectionctions even though the test line
> does intersect one of them. Finally the fourth section is just long
> enough and the location is just correct that the test line intersects
> it more than 2 pixels from each end. The result is that the point in
> polygon test sees 1 intersection instead of two and incorrectly
> concludes that the bottom left corner is inside the polygon.
>
> The final item that causes the bug to manifest is that the polygon is
> entirely outside of the plot area so no segments are drawable. The
> test that Plplot performs to see if the whole plot needs filling is
> that the bottom left corner is inside the fill polygon and all
> segments are outside the plot area. Hence the incorrect full fill.

Thanks very much for providing this example and a thorough explanation
of what is going wrong on your particular platform, but I cannot
reproduce the problem here on Linux (gcc version 4.9.2 with
CFLAGS="-O3" which I presume makes some rounding go just the wrong way
so this fill bug is not exposed).  Instead of the coloured fill of the
whole plot you describe, all I get is a labelled blank plot (which is
I believe the result you desired). Assuming you confirm that good
result with gcc and CFLAGS="-O3", can you modify your example so it
triggers the fill bug(s) for all compiler and optimization level
cases?

@Arjen: I am interested whether gcc on Cygwin for this current example
triggers the bug or not.

>
> I'm still of the opinion that the notcrossed function should not use
> the 2 pixel fuzziness. At this point in the drawing we are dealing in
> integer pixels and we need only an epsilon test I think. I think the
> best fix is to change this. There are some sticking plaster solutions
> that would hide the problem but not really fix it in my opinion. I
> would really like to change the notcrossed function unless anyone has
> some really strong objections?

My opinion is this is an extraordinarily tricky topic where all the
currently active fill code (i.e., the part of the code not currently
removed by the C preprocessor) needs to be completely reviewed and
potentially rewritten. Also, I think the fuzziness logic (with all
bugs fixed in that code) should stay just in the interests of
providing some tolerance for numerical rounding errors.  For example,
even the article <https://en.wikipedia.org/wiki/Point_in_polygon>
talks of providing some numerical tolerance.  Note also, such
tolerance is certainly required for the integer case since minute
rounding errors in the floating point calculations that decide, for
example, whether a point is inside or outside a polygon can shift
integer results around by +/- 1.

I have a topic branch where I have already taken some substantial
steps along the above ideas (including at least one bug fix in our
current fuzzy logic in notcrossed). I temporarily halted work on that
topic some time ago, but assuming you can provide a test example that
triggers fill bugs regardless of compiler or optimization level, I
plan to take up that topic again where the first order of business
will be to compare (using imagemagick image differences) updated fill
algorithm results versus 5.11.1 results for all our standard examples
that use fill in some way.  (That test should turn up any unusual fill
artifacts in our examples that are generated by bugs in the original
or revised fill algorithm, and once that test is implemented it should
be done for any fill change from now on.) In addition, of course, I
will look carefully at your example to make sure the revised fill
algorithm produces the correct result for it.

Assuming you are able to provide the requested example which triggers
the fill bug regardless of rounding issues, and the above
plan meets with your approval, I would plan to start working on this
topic again just after the current release is out the door.

Note also there are still a number of relatively small issues I would
like to address for this release, but because of the break I mentioned
above, I made little progress on those this summer so that release
deadline is still indefinite and at least a month or two 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
__________________________

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

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

Hi Phil,



> -----Original Message-----
> From: Phil Rosenberg [mailto:p.d...@gm...]

>
> In this special case the three short sides are all approximately 2 Plplot internal units
> long which fools the intersection test into thinking they are close to parallel to the
> test line. See
> notpointinpolygon() and notcrossed() functions. These three lines are therefore
> treated as non-intersectionctions even though the test line does intersect one of
> them. Finally the fourth section is just long enough and the location is just correct
> that the test line intersects it more than 2 pixels from each end. The result is that
> the point in polygon test sees 1 intersection instead of two and incorrectly
> concludes that the bottom left corner is inside the polygon.
>
> The final item that causes the bug to manifest is that the polygon is entirely outside
> of the plot area so no segments are drawable. The test that Plplot performs to see
> if the whole plot needs filling is that the bottom left corner is inside the fill polygon
> and all segments are outside the plot area. Hence the incorrect full fill.
>
> I'm still of the opinion that the notcrossed function should not use the 2 pixel
> fuzziness. At this point in the drawing we are dealing in integer pixels and we need
> only an epsilon test I think. I think the best fix is to change this. There are some
> sticking plaster solutions that would hide the problem but not really fix it in my
> opinion. I would really like to change the notcrossed function unless anyone has
> some really strong objections?
>
Thanks for constructing that example. This is the sort of things that makes "numerical geometry" an interesting topic ;). I have not studied the example in detail yet, but I am not entirely sure your proposed solution would work in all cases either. I will have a closer look.

Regards,

Arjen



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

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

Hi All
It's been a while. Sorry for my lack of activity over the summer.

I've just picked up some Plplot items again on my to do list, starting
with the fill problem that I reported a rather long time ago.

I have sorted a minimal example to reproduce the bug - see attached.
it turns out that a number of things need to come together to cause
this problem. The example is based on example 12 and draws a very
small trapezium just off the bottom left corner of the plot. however
what happens instead is that the whole plot is filled. The way this
works is that a test point is selected to the right of the fill shape
and Plplot examines if a line between this point and the bottom left
corner intersects the polygon segments to test if the bottom left
corner is in the polygon. When the test is performed segments that are
close to parallel (based on a ~2 pixel fuzziness) are flagged and in
the end treat as a non-intersection. Also if the intersection is close
to the end of a line (again 2 pixels is the limit) then the
intersection is flagged as too close.

In this special case the three short sides are all approximately 2
Plplot internal units long which fools the intersection test into
thinking they are close to parallel to the test line. See
notpointinpolygon() and notcrossed() functions. These three lines are
therefore treated as non-intersectionctions even though the test line
does intersect one of them. Finally the fourth section is just long
enough and the location is just correct that the test line intersects
it more than 2 pixels from each end. The result is that the point in
polygon test sees 1 intersection instead of two and incorrectly
concludes that the bottom left corner is inside the polygon.

The final item that causes the bug to manifest is that the polygon is
entirely outside of the plot area so no segments are drawable. The
test that Plplot performs to see if the whole plot needs filling is
that the bottom left corner is inside the fill polygon and all
segments are outside the plot area. Hence the incorrect full fill.

I'm still of the opinion that the notcrossed function should not use
the 2 pixel fuzziness. At this point in the drawing we are dealing in
integer pixels and we need only an epsilon test I think. I think the
best fix is to change this. There are some sticking plaster solutions
that would hide the problem but not really fix it in my opinion. I
would really like to change the notcrossed function unless anyone has
some really strong objections?

Phil



On 18 January 2016 at 20:08, Alan W. Irwin <ir...@be...> wrote:
> On 2016-01-18 16:57-0000 Phil Rosenberg wrote:
>
>> Hi
>> Can we reopen this again please. I have just hit another case where
>> when plotting a contour plot something goes wrong and the whole plot
>> gets filled.
>>
>> Alan, you said you were going to see if you could work out why the
>> fuzzy logic was needed and I said I would try to generate a test case.
>> I know I haven't held up my side of the bargain, but I will try to
>> sort one asap.
>
>
> Hi Phil:
>
> The status here is I guessed at the cause of the issue you originally
> reported and got pretty far with a fix for that on a private topic
> branch but did not finish that off because some higher priorities
> intervened such as the new Fortran binding.  But if you have found a
> complicated case demonstrating an issue with the fill logic on master
> branch, that would be like gold because such cases are quite rare.
>
> So your absolutely first priority should be to preserve the exact
> complicated conditions where you found the bug.  Then please send me
> _that exact case_ to make sure I can replicate it here.  After that,
> we can attempt to simplify the issue down to a much more managable
> simple test case, fix that simple case, then go back to the
> complicated case to make sure that fix works for it as well. Or other
> possibilities exist such as fixing some fuzzy issues with the present
> logic (for example, how nearly parallel intersections are treated by
> the logic) to see if those fixes make any difference to your complex
> case.  But essential to all of this bug-fixing process is a case (no
> matter how complicated) that can be replicated elsewhere.
>
>
> 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] Potential Mac OS X rpath change needs testing on that platformu

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

On 2016-08-25 15:32-0400 Jim Dishaw wrote:

>
>
>> On Aug 25, 2016, at 3:19 PM, Alan W. Irwin <ir...@be...> wrote:
>>
>> @Jim: You stated recently that you had some trouble with getting the
>> Fortran parts of PLplot to work on Mac OS X.  If that is still the
>> case, the report tarball generated by the above script invocatin will
>> likely give me everything I need to fix that issue.
>>
>
> The issue is that MacPorts had installed gfortran as gfortran-mp-49 and gfortran-mp-5. There was no gfortran executable.
>
> I don't know if that is normal or an artifact of having two different versions installed. The fix was simple--I set FC=/opt/local/bin/gfortran-mp-5
>
> We could fix the cmake configuration to try different names or just document it in the wiki.

My feeling is CMake itself and the PLplot build system should not be expected to
support idiosyncratic platform names for the Fortran (or any other)
compiler in a seamless manner.  So I suggest you just document the use
of the FC environment variable.

By the way, Linux distributions typically handle multiple versions of
any tool by an extremely convenient update-alternatives script (which,
for example, would symbolically link gfortran to the version preferred
by the user). Back in 2008, this possibility was discussed for
MacPorts (see
<https://lists.macosforge.org/pipermail/macports-dev/2008-May/005172.html>),
but if anyone followed through with implementing such a script for
MacPorts, I could not find that with a quick google search.  If you
confirm there is currently no update-alternatives script or equivalent
on MacPorts, perhaps a good bug report from you about that situation
might motivate the MacPorts developers to simply adapt (if adaptation
is necessary at all) an existing update-alternatives script from one of
the Linux distros.

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] Potential Mac OS X rpath change needs testing on that platformu

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

> On Aug 25, 2016, at 3:19 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> @Jim: You stated recently that you had some trouble with getting the
> Fortran parts of PLplot to work on Mac OS X.  If that is still the
> case, the report tarball generated by the above script invocatin will
> likely give me everything I need to fix that issue.
> 

The issue is that MacPorts had installed gfortran as gfortran-mp-49 and gfortran-mp-5. There was no gfortran executable. 

I don't know if that is normal or an artifact of having two different versions installed. The fix was simple--I set FC=/opt/local/bin/gfortran-mp-5

We could fix the cmake configuration to try different names or just document it in the wiki. 

> 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] Potential Mac OS X rpath change needs testing on that platformu

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

On 2016-08-23 22:55-0700 Alan W. Irwin wrote:

[....]
> It appears [...] that the INSTALL_NAME_DIR method does
> work for Mac OS X, but I would prefer to use the rpath approach to
> keep as parallel as possible with what goes on in the Linux case. I
> think the attached patch (which should be applied on top of the
> original unpatched source tree) should do that, i.e., it only drops
> rpath and uses INSTALL_NAME_DIR instead if the user has specified
> -DUSE_RPATH=OFF. So could you (and Jerry) try this patch instead and
> send me the test_fortran report tarball?  Additional otool -l results
> to figure out rpath for the library and executable for both build tree
> and install tree would also be much appreciated.

Jerry kindly came through with that requested test of the new patch,
and indeed, his report tarball indicated the rpath method was used for
the installed examples linking as expected for that particular patch.
Furthermore, his report showed the test of that method of linking
worked perfectly for test_fortran.  Encouraged by that limited
success, I have changed the entire PLplot project to use the rpath
linking method for installed examples by default on Mac OS X just like
what occurs in the Linux case.  See commit 5314c65 which supersedes
the limited test_fortran (and test_ada) patches I have been asking
Jerry and Jim to test.

@Jerry and Jim: Please test commit 5314c65 (without any additional
patching) on your Mac OS X platforms using (N.B. from the top-level
directory in the PLplot source tree so this is a test of the plplot
project and not either of the test_ada or test_fortran projects)

scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no

This comprehensive test of the plplot project restricts the components
of PLplot that are tested to just the ps and psc devices, just the
Fortran binding, and just noninteractive tests.  Those restrictions
considerably speeds up this test (which only took 6 minutes on my
7-yr-old PC with these restrictions).

N.B. this test of the PLplot Fortran binding and examples is obviously
much more substantial than the equivalent test of the extremely simple
test_fortran project.  In particular, the above script invocation
tests the traditional (make + pkg-config) build of the installed
Fortran examples without DYLD_LIBRARY_PATH manipulations. My guess is
the new rpath linking method for the installed examples will allow
that to work, but I do need one or both of you to confirm that.

@Jim: You stated recently that you had some trouble with getting the
Fortran parts of PLplot to work on Mac OS X.  If that is still the
case, the report tarball generated by the above script invocatin will
likely give me everything I need to fix that 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] Potential Mac OS X rpath change needs testing on that platformu

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

On 2016-08-23 21:29-0400 Jim Dishaw wrote:

>
>> On Aug 22, 2016, at 1:19 PM, Alan W. Irwin <ir...@be...> wrote:
>>
>> Hi Jim:
>>
>> You said:
>>
>>> I ran the comprehensive test suite [presumably for test_fortran] and got the following error
>>
>>> ERROR: cmake in the build tree failed
>>
>>> I reran the test and specified the fortran compiler and got the test
>> to run (see attached tarball)
>>
>> Thanks very much for that.  Your comprehensive test of the
>> test_fortran project indeed seems to work, but I have further
>> questions about what goes on with the Mac OS X rpath manipulations,
>> and if you don't have the Mac OS X linking experience to answer those,
>> I hope someone else from this list does.
>>
>> Here is what is bothering me about the Mac OS X rpath manipulations.
>>
>> Specifically (see
>> shared/noninteractive/output_tree/make_noninteractive.out) in the
>> build tree, the library build is done using
>>
>> /opt/local/bin/gfortran-mp-5   -dynamiclib -Wl,-headerpad_max_install_names  -o libhello.0.0.dylib -install_name @rpath/libhello.0.dylib CMakeFiles/hello_1.dir/hello_1.f90.o
>
> Per the Apple documentation (https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html) the @rpath is used to create a run-path dependent library.
>
>>
>> and the executable build is done using
>>
>> /opt/local/bin/gfortran-mp-5     CMakeFiles/hello.dir/hello.f90.o  -o hello  ../src_lib/libhello.0.0.dylib -Wl,-rpath,/Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree/src_lib
>>
>
> In this case gfortran is invoking ld, which will resolve the run-path.  Because the rpath is specified with an absolute path name, the executable will be have absolute paths to the dynamic libraries.  One can have a path search if “@loader_path” is used.
>
>>
>>
>> In the install tree (see
>> shared/noninteractive/output_tree/make_noninteractive.out) the Mac OS X and Linux equivalent
>> commands for building the installed executable are
>>
>> /opt/local/bin/gfortran-mp-5  CMakeFiles/hello.dir/hello.f90.o  -o hello  /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.0.dylib
>>
>
> Looking at the output from otool, the paths to libhello is the absolute.  Looking at the Apple documentation, it appears that ld will use use the absolute path name if @rpath is not specified.
>
> Relevant output from otool
>
> Load command 12
>          cmd LC_LOAD_DYLIB
>      cmdsize 152
>         name /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.dylib (offset 24)
>   time stamp 2 Wed Dec 31 19:00:02 1969
>      current version 0.0.0
> compatibility version 0.0.0
> Load command 13
>          cmd LC_LOAD_DYLIB
>      cmdsize 72
>         name /opt/local/lib/libgcc/libgfortran.3.dylib (offset 24)
>   time stamp 2 Wed Dec 31 19:00:02 1969
>      current version 4.0.0
> compatibility version 4.0.0
> Load command 14
>          cmd LC_LOAD_DYLIB
>      cmdsize 56
>         name /usr/lib/libSystem.B.dylib (offset 24)
>   time stamp 2 Wed Dec 31 19:00:02 1969
>      current version 1226.10.1
> compatibility version 1.0.0
> Load command 15
>          cmd LC_LOAD_DYLIB
>      cmdsize 64
>         name /opt/local/lib/libgcc/libgcc_s.1.dylib (offset 24)
>   time stamp 2 Wed Dec 31 19:00:02 1969
>      current version 1.0.0
> compatibility version 1.0.0
> Load command 16
>          cmd LC_LOAD_DYLIB
>      cmdsize 72
>         name /opt/local/lib/libgcc/libquadmath.0.dylib (offset 24)
>   time stamp 2 Wed Dec 31 19:00:02 1969
>      current version 1.0.0
> compatibility version 1.0.0
>
>> Here we have used (with the patched version of test_fortran and
>> test_ada) the same installed rpath manipulations for both Mac OS X and
>> Linux which (following what works for PLplot and Linux) are simply to
>> set the INSTALL_RPATH property of the library to the install location
>> of that library but say nothing at all about the rpath of the
>> executable (see cmake/test_fortran/src_lib/CMakeLists.txt and
>> cmake/test_fortran/src_executable/CMakeLists.txt).  As
>> you can see above, the result is rpath is set properly for the build
>> of the executable in the install tree for the Linux case, but there is
>> _no_ rpath manipulation at all for that executable in the Mac OS X case.
>>
>> Nevertheless, the result for both Mac OS X and Linux is the run-time loader finds
>> the library and executes the hello executable in the install tree
>> without issues, but for the Mac OS X case, I don't see how that is
>> possible since rpath has obviously not been set.
>>
>
> The lack rpath manipulation is not needed, though it results in an executable that will not run if the
> library is moved.  If I remove or move libhello, the executable fails to load:
>
> dyld: Library not loaded: /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.dylib
>  Referenced from: /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/./install_build_tree/fortran/hello
>  Reason: image not found
> Trace/BPT trap: 5
>
>> Can you (or someone else here with Mac OS X linking expertise) help me
>> figure out what is going on here?  The first step in that investigation (after the
>> comprehensive test is completed) is you should be able to go
>> to the installed location of the hello executable (in your case that would be
>> /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_build_tree/fortran)
>> and execute ./hello there without setting DYLD_LIBRARY_PATH.  If that
>> works (and I assume it will from your comprehensive test results done
>> without setting DYLD_LIBRARY_PATH), then how does the run-time loader
>> know the location of the installed library which in your case is
>> /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.0.dylib?
>> From past interactions with Mac OS X users, my understanding is you
>> can find the answer to the above questions with tool.
>
> It works fine and I do not have DYLD_LIBRARY_PATH set.
>

> For PLplot, there are several options on how to proceed for Mac OS
X.  From what I can tell, it is possible to mimic the Linux behavior.
There is a discussion on the CMake site
(https://cmake.org/Wiki/CMake_RPATH_handling) that might help with the
configuration.

Thanks, Jim, for the above.  It is going to take some time to
completely absorb this information and other Mac OS X resources I
found today, but my initial take is your results showed no use of
rpath in the install tree because we set the INSTALL_NAME_DIR property
(a property that is specific to Mac OS X that apparently supersedes
rpath on that platform) for the library (see the current patched
cmake/test_fortran/src_lib/CMakeLists.txt).

It appears from your results that the INSTALL_NAME_DIR method does
work for Mac OS X, but I would prefer to use the rpath approach to
keep as parallel as possible with what goes on in the Linux case. I
think the attached patch (which should be applied on top of the
original unpatched source tree) should do that, i.e., it only drops
rpath and uses INSTALL_NAME_DIR instead if the user has specified
-DUSE_RPATH=OFF. So could you (and Jerry) try this patch instead and
send me the test_fortran report tarball?  Additional otool -l results
to figure out rpath for the library and executable for both build tree
and install tree would also be much appreciated.

Thanks in advance.

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] Potential Mac OS X rpath change needs testing on that platform

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

> On Aug 22, 2016, at 1:19 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> Hi Jim:
> 
> You said:
> 
>> I ran the comprehensive test suite [presumably for test_fortran] and got the following error
> 
>> ERROR: cmake in the build tree failed
> 
>> I reran the test and specified the fortran compiler and got the test
> to run (see attached tarball)
> 
> Thanks very much for that.  Your comprehensive test of the
> test_fortran project indeed seems to work, but I have further
> questions about what goes on with the Mac OS X rpath manipulations,
> and if you don't have the Mac OS X linking experience to answer those,
> I hope someone else from this list does.
> 
> Here is what is bothering me about the Mac OS X rpath manipulations.
> 
> Specifically (see
> shared/noninteractive/output_tree/make_noninteractive.out) in the
> build tree, the library build is done using
> 
> /opt/local/bin/gfortran-mp-5   -dynamiclib -Wl,-headerpad_max_install_names  -o libhello.0.0.dylib -install_name @rpath/libhello.0.dylib CMakeFiles/hello_1.dir/hello_1.f90.o

Per the Apple documentation (https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html) the @rpath is used to create a run-path dependent library.

> 
> and the executable build is done using
> 
> /opt/local/bin/gfortran-mp-5     CMakeFiles/hello.dir/hello.f90.o  -o hello  ../src_lib/libhello.0.0.dylib -Wl,-rpath,/Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree/src_lib
> 

In this case gfortran is invoking ld, which will resolve the run-path.  Because the rpath is specified with an absolute path name, the executable will be have absolute paths to the dynamic libraries.  One can have a path search if “@loader_path” is used.

> 
> 
> In the install tree (see
> shared/noninteractive/output_tree/make_noninteractive.out) the Mac OS X and Linux equivalent
> commands for building the installed executable are
> 
> /opt/local/bin/gfortran-mp-5  CMakeFiles/hello.dir/hello.f90.o  -o hello  /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.0.dylib
> 

Looking at the output from otool, the paths to libhello is the absolute.  Looking at the Apple documentation, it appears that ld will use use the absolute path name if @rpath is not specified.

Relevant output from otool 

Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 152
         name /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 0.0.0
compatibility version 0.0.0
Load command 13
          cmd LC_LOAD_DYLIB
      cmdsize 72
         name /opt/local/lib/libgcc/libgfortran.3.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 4.0.0
compatibility version 4.0.0
Load command 14
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /usr/lib/libSystem.B.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1226.10.1
compatibility version 1.0.0
Load command 15
          cmd LC_LOAD_DYLIB
      cmdsize 64
         name /opt/local/lib/libgcc/libgcc_s.1.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1.0.0
compatibility version 1.0.0
Load command 16
          cmd LC_LOAD_DYLIB
      cmdsize 72
         name /opt/local/lib/libgcc/libquadmath.0.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1.0.0
compatibility version 1.0.0

> Here we have used (with the patched version of test_fortran and
> test_ada) the same installed rpath manipulations for both Mac OS X and
> Linux which (following what works for PLplot and Linux) are simply to
> set the INSTALL_RPATH property of the library to the install location
> of that library but say nothing at all about the rpath of the
> executable (see cmake/test_fortran/src_lib/CMakeLists.txt and
> cmake/test_fortran/src_executable/CMakeLists.txt).  As
> you can see above, the result is rpath is set properly for the build
> of the executable in the install tree for the Linux case, but there is
> _no_ rpath manipulation at all for that executable in the Mac OS X case.
> 
> Nevertheless, the result for both Mac OS X and Linux is the run-time loader finds
> the library and executes the hello executable in the install tree
> without issues, but for the Mac OS X case, I don't see how that is
> possible since rpath has obviously not been set.
> 

The lack rpath manipulation is not needed, though it results in an executable that will not run if the
library is moved.  If I remove or move libhello, the executable fails to load: 

dyld: Library not loaded: /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.dylib
  Referenced from: /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/./install_build_tree/fortran/hello
  Reason: image not found
Trace/BPT trap: 5

> Can you (or someone else here with Mac OS X linking expertise) help me
> figure out what is going on here?  The first step in that investigation (after the
> comprehensive test is completed) is you should be able to go
> to the installed location of the hello executable (in your case that would be
> /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_build_tree/fortran)
> and execute ./hello there without setting DYLD_LIBRARY_PATH.  If that
> works (and I assume it will from your comprehensive test results done
> without setting DYLD_LIBRARY_PATH), then how does the run-time loader
> know the location of the installed library which in your case is
> /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.0.dylib?
> From past interactions with Mac OS X users, my understanding is you
> can find the answer to the above questions with tool.

It works fine and I do not have DYLD_LIBRARY_PATH set.  

For PLplot, there are several options on how to proceed for Mac OS X.  From what I can tell, it is possible to mimic the Linux behavior.  There is a discussion on the CMake site (https://cmake.org/Wiki/CMake_RPATH_handling) that might help with the configuration. 

Re: [Plplot-devel] Potential Mac OS X rpath change needs testing on that platform

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

PPS.

According to
<http://stackoverflow.com/questions/12521802/print-rpath-of-executable-on-osx>
you can also obtain the rpath for any executable or library using
otool.  So it looks like you don't need gobjdump for this purpose.

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] Potential Mac OS X rpath change needs testing on that platform

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

P.S.  According to discussion in
<http://stackoverflow.com/questions/3286675/readelf-like-tool-for-mac-os-x>
there is a gobjdump executable that is available from homebrew and
macports which does the same thing as the Linux objdump.

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] Potential Mac OS X rpath change needs testing on that platform

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

Hi Jim:

You said:

> I ran the comprehensive test suite [presumably for test_fortran] and got the following error

> ERROR: cmake in the build tree failed

> I reran the test and specified the fortran compiler and got the test
to run (see attached tarball)

Thanks very much for that.  Your comprehensive test of the
test_fortran project indeed seems to work, but I have further
questions about what goes on with the Mac OS X rpath manipulations,
and if you don't have the Mac OS X linking experience to answer those,
I hope someone else from this list does.

Here is what is bothering me about the Mac OS X rpath manipulations.

Specifically (see
shared/noninteractive/output_tree/make_noninteractive.out) in the
build tree, the library build is done using

/opt/local/bin/gfortran-mp-5   -dynamiclib -Wl,-headerpad_max_install_names  -o libhello.0.0.dylib -install_name @rpath/libhello.0.dylib CMakeFiles/hello_1.dir/hello_1.f90.o

and the executable build is done using

/opt/local/bin/gfortran-mp-5     CMakeFiles/hello.dir/hello.f90.o  -o hello  ../src_lib/libhello.0.0.dylib -Wl,-rpath,/Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree/src_lib

On Linux (from my own comprehensive test of
test_fortran where I happened to set the environment variable

FFLAGS=-O3 -Wuninitialized -Wunused

) the equivalents of these two commands are

/usr/bin/f95 -fPIC -O3 -Wuninitialized -Wunused   -shared -Wl,-soname,libhello.so.0 -o libhello.so.0.0 CMakeFiles/hello_1.dir/hello_1.f90.o  -Wl,-rpath,::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

and

/usr/bin/f95 -O3 -Wuninitialized -Wunused CMakeFiles/hello.dir/hello.f90.o  -o hello  ../src_lib/libhello.so.0.0 -Wl,-rpath,/home/software/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree/src_lib

The test_fortran project (and test_ada and plplot projects) do not do anything
special for rpath in the build tree so the above is what CMake does by
default for the build tree.

In the install tree (see
shared/noninteractive/output_tree/make_noninteractive.out) the Mac OS X and Linux equivalent
commands for building the installed executable are

/opt/local/bin/gfortran-mp-5  CMakeFiles/hello.dir/hello.f90.o  -o hello  /Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.0.dylib

and

/usr/bin/f95 -O3 -Wuninitialized -Wunused CMakeFiles/hello.dir/hello.f90.o  -o hello /home/software/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.so.0.0 -Wl,-rpath,/home/software/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib

Here we have used (with the patched version of test_fortran and
test_ada) the same installed rpath manipulations for both Mac OS X and
Linux which (following what works for PLplot and Linux) are simply to
set the INSTALL_RPATH property of the library to the install location
of that library but say nothing at all about the rpath of the
executable (see cmake/test_fortran/src_lib/CMakeLists.txt and
cmake/test_fortran/src_executable/CMakeLists.txt).  As
you can see above, the result is rpath is set properly for the build
of the executable in the install tree for the Linux case, but there is
_no_ rpath manipulation at all for that executable in the Mac OS X case.

Nevertheless, the result for both Mac OS X and Linux is the run-time loader finds
the library and executes the hello executable in the install tree
without issues, but for the Mac OS X case, I don't see how that is
possible since rpath has obviously not been set.

Can you (or someone else here with Mac OS X linking expertise) help me
figure out what is going on here?  The first step in that investigation (after the
comprehensive test is completed) is you should be able to go
to the installed location of the hello executable (in your case that would be
/Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_build_tree/fortran)
and execute ./hello there without setting DYLD_LIBRARY_PATH.  If that
works (and I assume it will from your comprehensive test results done
without setting DYLD_LIBRARY_PATH), then how does the run-time loader
know the location of the installed library which in your case is
/Users/jim/Development/plplot2/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/libhello.0.0.dylib?
>From past interactions with Mac OS X users, my understanding is you
can find the answer to the above questions with otool.

Furthermore, on Linux, to
look deeper to find exactly what rpath is set for a library or
executable you would use (see
<http://stackoverflow.com/questions/2836330/is-there-a-way-to-inspect-the-current-rpath-on-linux>)

objdump -x binary-or-library |grep -E 'RPATH|RUNPATH'

or

readelf -d binary-or-library |head -20

For my test_fortran result here, the installed hello executable is
located at
~/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/install_build_tree/fortran
so if I cd to that directory and use either one of the above methods, I
get the result that the installed library location,

/home/software/plplot/HEAD/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib

is the rpath location (as expected).  Is either objdump or readelf
available to you on Mac OS X so you can do a similar test there?

Once I am satisfied concerning the otool and either objdump or readelf
results that rpath is working properly for (the patched) test_fortran
project on Mac OS X platforms, then I intend to modify the plplot
project to use that working rpath method for Mac OS X platforms.  So
further investigation by you or someone else along the lines I have
suggested above is important.

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] Potential Mac OS X rpath change needs testing on that platform

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

> On Aug 21, 2016, at 5:55 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> Hi Jim (and any others here with access to Mac OS X):
> 
> I need some fairly urgent help with a test of a potential rpath change
> for Mac OS X.  If you have time to help out this way, please apply
> the attached patch to the latest update of the master
> branch, then follow the directions in cmake/test_fortran/README to
> comprehensively test that tiny Fortran project (which the attached
> patch updates to use the rpath option on Mac OS X) using the trace
> option.  (Those directions should boil down to
> 
> cd cmake/test_fortran
> scripts/comprehensive_test.sh --do_trace yes
> 
> .) When the test has completed (which normally should take only a
> second or so) please send me the resulting report tarball (which
> should be stored at ../../../comprehensive_test_fortran_disposeable/comprehensive_test.tar.gz).

The build environment: Mac OS X 10.11.6, Apple LLVM version 7.3.0 (clang-703.0.31), GNU Fortran (MacPorts gcc5 5.4.0_0) 5.4.0

I created a new clone of the repository from source forge.

I applied the patch and git status lists the following modified files

	modified:   cmake/test_ada/CMakeLists.txt
	modified:   cmake/test_ada/scripts/comprehensive_test.sh
	modified:   cmake/test_fortran/CMakeLists.txt
	modified:   cmake/test_fortran/scripts/comprehensive_test.sh

I followed the configuration and build instructions as outlined in the manual.  I had to specify the fortran compiler (I have two different versions on my system and neither is linked to gfortran—by default MacPorts installs as gfortran-mp-version_number, e.g gfortran-mp-5).

There were several errors in the cmake output, most appeared to be related to Ada and D (neither are installed on my system).  There was one Fortran related error:

CMake Error at cmake/modules/pkg-config.cmake:228 (string):
  string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
  command.
Call Stack (most recent call first):
  cmake/modules/pkg-config.cmake:399 (pkg_config_link_flags)
  bindings/f95/CMakeLists.txt:202 (pkg_config_file)

There was also errors in CMakeFiles/CMakeError.log (see attached).

[Plplot-devel] Potential Mac OS X rpath change needs testing on that platform

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

Hi Jim (and any others here with access to Mac OS X):

I need some fairly urgent help with a test of a potential rpath change
for Mac OS X.  If you have time to help out this way, please apply
the attached patch to the latest update of the master
branch, then follow the directions in cmake/test_fortran/README to
comprehensively test that tiny Fortran project (which the attached
patch updates to use the rpath option on Mac OS X) using the trace
option.  (Those directions should boil down to

cd cmake/test_fortran
scripts/comprehensive_test.sh --do_trace yes

.) When the test has completed (which normally should take only a
second or so) please send me the resulting report tarball (which
should be stored at 
../../../comprehensive_test_fortran_disposeable/comprehensive_test.tar.gz).

To give you some background on why I need this test result, on Linux
our build system uses the default rpath method that is normally
employed by CMake for the build tree, and by default uses that same
method for the installed examples. However, when we were putting all
this logic together a decade ago the Mac OS X version was 10.4 =
"Tiger" which did not honor rpath. Accordingly at that time, CMake did
not use rpath in the build tree and we disabled rpath in the install
tree just for the Mac OS X case. Of course, that caused find problems
for the run-time loader if the install location was nonstandard so to
workaround that issue we asked users to fiddle with the
DYLD_LIBRARY_PATH brute-force technique when installing by hand (or
else our comprehensive test script did that when testing installed
versions).

Fast forward to today.  Mac OS X 10.5 = "Leopard" (which was released
in 2007) and all later versions honor rpath according to comments at
<https://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac>.
In any case, CMake has long since converted to using rpath by default
for the build tree for Mac OS X (and our build system automatically
followed along with that change).  That works well, but we never
followed up by converting to using rpath in the installed examples
tree for the Mac OS X case.  The attached patch tests whether that
possibility works (not only for test_fortran but also test_ada,
although you should ignore that latter project for now because it has
known issues on Mac OS X).

If your report shows a good result for the test_fortran project, then
I plan to make an equivalent change for the plplot project itself.  In
addition, I plan to use any good test_fortran results you produce to
help narrow down what might be wrong for the Mac OS X test_ada case.

I have described this requested test as "fairly urgent" because I am
anxious to get this whole rpath issue settled for Mac OS X. 
Therefore, your timely response would be much appreciated.

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] ocaml cairo

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

On 2016-07-21 14:25-0600 Orion Poplawski wrote:

> Re:
>
> commit 893625ca34ed22f4d8941f9902aa71bf30eaf8fb
> Author: Alan W. Irwin <ai...@us...>
> Date:   Sat Oct 24 13:30:10 2015 -0700
>
>    Build system: Disable OCAML_HAS_CAIRO
>
>    I have taken this step because substantial maintenance will be
>    required before this component of PLplot will configure, build, or run
>    again because of backwards incompatibilities that have been introduced
>    in ocaml support of cairo. For example, the package name "cairo2" no
>    longer exists any more and should probably be replaced by the package
>    name cairo, but that is just the start of the backwards
>    incompatibilities.
>
> diff --git a/cmake/modules/ocaml.cmake b/cmake/modules/ocaml.cmake
> index 0403abd..a106ed2 100644
> --- a/cmake/modules/ocaml.cmake
> +++ b/cmake/modules/ocaml.cmake
> @@ -2,7 +2,7 @@
> #
> # Copyright (C) 2008 Andrew Ross
> # Copyright (C) 2009 Hezekiah M. Carty
> -# Copyright (C) 2009-2014 Alan W. Irwin
> +# Copyright (C) 2009-2015 Alan W. Irwin
> #
> # This file is part of PLplot.
> #
> @@ -196,6 +196,9 @@ if(ENABLE_ocaml)
>   if(OCAMLFIND)
>     if(PLD_extcairo)
>       option(OCAML_HAS_CAIRO "OCaml has the cairo package" ON)
> +      # Disable since substantial maintenance is required before this component
> +      # of PLplot will configure, build, and/or run.
> +      set(OCAML_HAS_CAIRO OFF CACHE BOOL "OCaml has the cairo package" FORCE)
>       if(OCAML_HAS_CAIRO)
>        set(text_cairo "module C = Cairo")
>        file(WRITE ${CMAKE_BINARY_DIR}/test_cairo.ml ${text_cairo})
>
>
> It would be nice if the message was changed to something like "plplot ocaml
> cairo support currently disabled", so avoid having people like me spend time
> figuring out why it's not finding the cairo package.  Thanks.

Hi Orion:

I don't want to clutter up the usual stdout from cmake with warning
messages concerning development issues that ordinary users can do nothing
about. So this is a perfect case where the CMake message option AUTHOR_WARNING
should be used.  The result is the messages go to stderr and can be
turned off by ordinary users if they use the CMake -Wno-dev option.

So I have used message(AUTHOR_WARNING ....) for this case (commit
56f415a) and plan to do that from now on when other components of
PLplot need to be permanently disabled.  I hope this method will
completely satisfy your future packaging needs.

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
__________________________