plplot-devel — Technical discussion about PLplot development

[Plplot-devel] The forthcoming release of 5.11.1

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

Some major development topics that have been raised either recently
or within the last few months are

1. Jim's substantial planned update to plmeta/plrender and
possibly plbuf.

2. Jim's potential substantial update of the wingcc device driver.

3. Arjen's substantial update to the Fortran bindings.

I strongly encourage both of you to continue to develop those topics
on dedicated topic branches, regardless of the various release
deadlines and rules that I have forwarded below. (In other words, do
not let the release process interrupt your important development
work.)

However, for major topics of development like these there is at least
one release deadline you should be aware of which is once these topics
have matured, you should wait until the first month of a release cycle
to merge these topics with master.  So note especially that deadline
has already come and gone for the current release cycle which means
the forthcoming release will be strictly a bug-fix release which I
will designate as 5.11.1.  Thus, ideally you should plan to land your
major topic work on master right after that release.  That is, please
do not miss the equivalent deadline for the next release cycle.

Although this current release cycle already has had a substantial
number of bug fixes applied to the master branch, there is still
_lots_ of bugfixing work to do for that branch.  For example, I am
sure that Phil would like to commit some fixes for the known bugs for
his new wxwidgets code.  And as a result of extremely useful reports
from Orion (Fedora) and Arjen (Cygwin and MinGW/MSYS), there are still
at least ~10 build system bugs I am aware of that I plan to fix in
this release cycle.  And once I have dealt with all of those, I plan
to call for at least one more round of comprehensive testing in this
release cycle to test those fixes but also to see whether additional
build system issues are turned up not only on Debian wheezy, Fedora,
Cygwin, and MinGW/MSYS but other platforms as well.

In sum, the exact deadline for this forthcoming release obviously
cannot be estimated at this time because all these planned bug fixes
take an indefinite time to complete, but I will do my best to make
this a short release cycle.  That means I plan to get through the bugs
I am working on as quickly as possible, and I assume others here who
have bug fixes they want to get into this forthcoming release will do
the same.

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
__________________________

---------- Forwarded message ----------
Date: Sun, 12 Apr 2015 17:49:17 -0700 (PDT)
From: Alan W. Irwin <ir...@be...>
To: PLplot development list <Plp...@li...>
Subject: [Plplot-devel] Making PLplot releases easier in future

I was confident in early February that the planned release date of
February 28th for PLplot-5.11.0 would be straightforward to achieve,
but obviously the release was delayed 6 weeks beyond that date by a
number of factors. I would prefer to avoid such factors if at all
possible in the future since a sliding release date is extremely
difficult for volunteer developers to adjust to.  All of us have lots
of other things going on in our lives, but with a fixed release date
that everybody knows in advance it is fairly likely most of us can
make an effort for the last week of the release to help get it out the
door.  But all that potential cooperation is out the window when that
single critical week stretches (ouch!) into 7 weeks.

As release manager I have to take responsibility to provide the
guidance to avoid such an issue in the future so below I discuss some
general lessons I have learned from this bad experience, and the
remedies I plan to adopt so this experience is not repeated for
future releases.

Here are the lessons:

1. Keep release cycles short.

Adopting that lesson reduces the chances of regressions creeping in
and creating surprises (as occurred for this release) that
tend to indefinitely delay the release.

2. Create definitive benchmark comprehensive tests for all platforms
accessible to us.

Adopting that lesson will make it much easier for us to detect
regressions in the future.

3. Master branch should be primarily used for bug fixing in
preparation for the next release.

So all major PLplot changes should be implemented on local topic
branches which are shared with those interested in helping with the
initial testing using the "git format-patch"/"git am" approach
mentioned in README.developers.  Only when a topic has completely
matured (i.e., all bugs discovered by initial testing have been fixed)
should it be pushed to master branch for testing and debugging by a
larger group.

4. Pushes of major topics to the master branch should be done
only relatively early in release cycles.

That gives important time for the "testing and debugging by
a larger group" referred to above to take place.

Here are the specific remedies I propose:

1'. Consistent with lesson 1, I propose to get the next release out in
4 months (by mid-August) _at the latest_.  However, an earlier bug-fix
release (say called 5.11.1) that contains only bug fixes and not major
changes is certainly possible if a lot of bug fixing gets done soon.

@Everybody:

Through release testing we uncovered a number of bugs discussed on
this mailing list that we had to put off fixing until post-release.
The time to deal with those known bugs is now.

2'. Consistent with lesson 2, I have already (in a different post)
strongly encouraged everybody here to run
scripts/comprehensive_test.sh on the platforms you have access to and
report those benchmark results to me and/or
<http://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>.
When that testing clearly reveals comprehensive_testing.sh issues
(such as Arjen having to brute-force Cygwin to get that script to run)
or build-system issues, I certainly plan to either provide the fix or
provide strong support for finding the fix.

3'. I am going to encourage everybody to use the lesson 3 approach for
further major developments.  This immediately applies to both Arjen
(currently working on a fortran binding rewrite) and Jim (currently
working on major changes to plmeta/plrender and possibly plbuf).

@Arjen and Jim: does this lesson 3 approach work for you?

4'. Consistent with lesson 4, I think pushes of important topics
to the master branch should only be done in the first month
of a release cycle.

@Arjen and Jim:

To be specific I plan to adopt May 9th as the deadline for pushing of
major mature topics to master.  So if you make that deadline, your
work will get into the next release, but if your other time
commitments make it impossible for you to make that deadline, then
please continue to mature your topics as time permits and aim to push
your major topics to master in the first month of the subsequent
release cycle.

@Everybody:

I hope these lessons I have learned and my specific plans to conform
to these lessons makes sense to everybody here.  But if not, I would
welcome further discussion of your own ideas for making the release
process a lot easier for both you and me.

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
__________________________

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Using Window's raw API for shapes and text

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

> On May 13, 2015, at 8:43 PM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-05-13 18:27-0400 Jim Dishaw wrote:
>> 
>> 
>>> On May 13, 2015, at 6:17 PM, Aaron Hexamer <he...@co...> wrote:
>>> 
>>> Alan,
>>> 
>>> I'm a little confused by the statement about copying code from Jim's driver
>>> to wingcc.  I just assumed that wingcc was named as such because maybe
>>> PLplot was first ported to windows with support only for the gcc compiler?
>>> I.e. is there really anything specific to gcc about wingcc anymore.  I
>>> recall using it with MSVC when I first got started with PLplot. If Jim's
>>> driver did everything that wingcc does, but without plfreetype, would there
>>> be a need for both?
>>> 
>>> Aaron.
> 
>> I think the smart thing to do is to have one Windows driver. I can't
> recall any differences that could not be handled without an #ifdef
> block.
> 
> Hi Jim:
> 
> Any way you decide to implement your driver (i.e., separately or as
> part of wingcc) is fine with me.
> 
> @Aaron:
> 
> Your question about the wingcc name got me curious so I looked at git
> log results for drivers/wingcc.c, and indeed the initial commit (back
> in 2004 by Andrew Roach was the originator of the plfreetype approach
> but who has since retired from PLplot development) was for "users of
> GCC windows compilers such as mingw".  But clearly the wingcc name is
> now a misnomer.  Of course, you don't want to break backwards
> compatibility on this name now unless there is a really good reason,
> but one possible good reason is if someone could think up a really
> compelling name for this device driver that we all immediately like.
> 
> Alan
> 

How about mswin. 
> __________________________
> 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] Using Window's raw API for shapes and text

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

On 2015-05-13 18:27-0400 Jim Dishaw wrote:

>
>> On May 13, 2015, at 6:17 PM, Aaron Hexamer <he...@co...> wrote:
>>
>> Alan,
>>
>> I'm a little confused by the statement about copying code from Jim's driver
>> to wingcc.  I just assumed that wingcc was named as such because maybe
>> PLplot was first ported to windows with support only for the gcc compiler?
>> I.e. is there really anything specific to gcc about wingcc anymore.  I
>> recall using it with MSVC when I first got started with PLplot. If Jim's
>> driver did everything that wingcc does, but without plfreetype, would there
>> be a need for both?
>>
>> Aaron.
>>
>

> I think the smart thing to do is to have one Windows driver. I can't
recall any differences that could not be handled without an #ifdef
block.

Hi Jim:

Any way you decide to implement your driver (i.e., separately or as
part of wingcc) is fine with me.

@Aaron:

Your question about the wingcc name got me curious so I looked at git
log results for drivers/wingcc.c, and indeed the initial commit (back
in 2004 by Andrew Roach was the originator of the plfreetype approach
but who has since retired from PLplot development) was for "users of
GCC windows compilers such as mingw".  But clearly the wingcc name is
now a misnomer.  Of course, you don't want to break backwards
compatibility on this name now unless there is a really good reason,
but one possible good reason is if someone could think up a really
compelling name for this device driver that we all immediately like.

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] floating point exception in example 29

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

On 2015-05-13 15:18-0700 Alan W. Irwin wrote:

> On 2015-05-13 17:01-0400 Hazen Babcock wrote:
>
>> On 05/13/2015 03:58 PM, Alan W. Irwin wrote:
>>> In my case the only fortran compiler available is gfortran so I don't
>>> need to choose that.  So instead of the above I set
>>>
>>> export FFLAGS='-g -ffpe-trap=invalid,zero,overflow,underflow'
>>>
>>> before calling cmake and building the x29f95 and ps targets.
>>>
>>> After that, I got the following result
>>>
>>> software@raven> examples/f95/x29f -dev psc -o test.psc
>>>
>>> Program received signal SIGFPE: Floating-point exception - erroneous
>>> arithmetic operation.
>>> [...]
>>>
>>> So I confirm there is a floating-point issue for that example, and
>>> this should be easy for anyone else here to confirm that has access to
>>> gfortran.  However, I am completely tied up with other PLplot issues
>>> so I would appreciate it if you pursued and fixed all floating-point
>>> issues revealed by this method.  But if you are too busy to do that
>>> yourself, please let this list know so others with more time will be
>>> motivated to take a crack at it.
>>
>> The problem seems to come from line 267 in this example. It looks like the
>> "sec" argument is not getting passed to the C library correctly? 0.0 becomes
>> something like 4.2439915819305446e-314, which I think causes the later
>> problems. Perhaps there is something wrong with the fortran bindings for
>> plctime? I would appreciate it if a fortran expert could take a look.
>
> I will take a look at that immediately.  And to keep the record
> straight even with my notcrossed change, I do currently see fpe
> problems for example 29 even though before I mentioned only 21 and 33
> as the remaining issues.

Hi Hazen:

It turned out to be a fortran argument issue in Fortran example 29, where 0. had to be
replaced by 0._plflt (see commit id=a0e51cd).

@Arjen:
This issue illustrates how tricky it is to use our current fortran
bindings and should be a big motivation for you to finish up your
rewrite of those bindings so our Fortran user's don't have to worry about
using the _plflt suffix on all floating-point arguments.

@Hazen: Solving this plctime argument issue solved the floating point
exception (as you suggested it would) for fortran example 29 so I
think the only floating-point issues currently left are for examples
21 and 33.

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] Using Window's raw API for shapes and text

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

> On May 13, 2015, at 6:06 PM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-05-13 14:03-0400 Jim Dishaw wrote:
>> 
>> I still have the revised windows driver that I can blow the dust off and offer as a possible replacement.
> 
> Hi Jim:
> 
> As I recall, you had a lot of interesting ideas for your Windows
> device driver so I hope you do integrate that into PLplot in the near
> future regardless of whether or not it uses the deprecated plfreetype
> approach to render text. Of course, it would be great if it uses a
> native Windows unicode API to render text using whatever Windows
> system fonts happen to be installed since that approach could
> be straightforwardly copied over to wingcc to get rid of the
> last use of plfreetype.
> 
> Alan

I agree. I think another thing to look at for version 6 is to have a consistent menubar and keybindings for the GUI drivers. 

> 
> __________________________
> 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] Using Window's raw API for shapes and text

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

> On May 13, 2015, at 6:17 PM, Aaron Hexamer <he...@co...> wrote:
> 
> Alan,
> 
> I'm a little confused by the statement about copying code from Jim's driver
> to wingcc.  I just assumed that wingcc was named as such because maybe
> PLplot was first ported to windows with support only for the gcc compiler?
> I.e. is there really anything specific to gcc about wingcc anymore.  I
> recall using it with MSVC when I first got started with PLplot. If Jim's
> driver did everything that wingcc does, but without plfreetype, would there
> be a need for both?
> 
> Aaron.
> 

I think the smart thing to do is to have one Windows driver. I can't recall any differences that could not be handled without an #ifdef block. 

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...] 
> Sent: Wednesday, May 13, 2015 5:06 PM
> To: Jim Dishaw
> Cc: Aaron Hexamer; PLplot development list
> Subject: Re: [Plplot-devel] Using Window's raw API for shapes and text
> 
>> On 2015-05-13 14:03-0400 Jim Dishaw wrote:
>> 
>> I still have the revised windows driver that I can blow the dust off and
> offer as a possible replacement.
> 
> Hi Jim:
> 
> As I recall, you had a lot of interesting ideas for your Windows device
> driver so I hope you do integrate that into PLplot in the near future
> regardless of whether or not it uses the deprecated plfreetype approach to
> render text. Of course, it would be great if it uses a native Windows
> unicode API to render text using whatever Windows system fonts happen to be
> installed since that approach could be straightforwardly copied over to
> wingcc to get rid of the last use of plfreetype.
> 
> 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] floating point exception in example 29

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

On 2015-05-13 17:01-0400 Hazen Babcock wrote:

> On 05/13/2015 03:58 PM, Alan W. Irwin wrote:
>> In my case the only fortran compiler available is gfortran so I don't
>> need to choose that.  So instead of the above I set
>> 
>> export FFLAGS='-g -ffpe-trap=invalid,zero,overflow,underflow'
>> 
>> before calling cmake and building the x29f95 and ps targets.
>> 
>> After that, I got the following result
>> 
>> software@raven> examples/f95/x29f -dev psc -o test.psc
>> 
>> Program received signal SIGFPE: Floating-point exception - erroneous
>> arithmetic operation.
>> [...]
>> 
>> So I confirm there is a floating-point issue for that example, and
>> this should be easy for anyone else here to confirm that has access to
>> gfortran.  However, I am completely tied up with other PLplot issues
>> so I would appreciate it if you pursued and fixed all floating-point
>> issues revealed by this method.  But if you are too busy to do that
>> yourself, please let this list know so others with more time will be
>> motivated to take a crack at it.
>
> The problem seems to come from line 267 in this example. It looks like the 
> "sec" argument is not getting passed to the C library correctly? 0.0 becomes 
> something like 4.2439915819305446e-314, which I think causes the later 
> problems. Perhaps there is something wrong with the fortran bindings for 
> plctime? I would appreciate it if a fortran expert could take a look.

I will take a look at that immediately.  And to keep the record
straight even with my notcrossed change, I do currently see fpe
problems for example 29 even though before I mentioned only 21 and 33
as the remaining issues.

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] Using Window's raw API for shapes and text

[Aaron H. <he...@co...>]

Alan,

I'm a little confused by the statement about copying code from Jim's driver
to wingcc.  I just assumed that wingcc was named as such because maybe
PLplot was first ported to windows with support only for the gcc compiler?
I.e. is there really anything specific to gcc about wingcc anymore.  I
recall using it with MSVC when I first got started with PLplot. If Jim's
driver did everything that wingcc does, but without plfreetype, would there
be a need for both?

Aaron.

-----Original Message-----
From: Alan W. Irwin [mailto:ir...@be...] 
Sent: Wednesday, May 13, 2015 5:06 PM
To: Jim Dishaw
Cc: Aaron Hexamer; PLplot development list
Subject: Re: [Plplot-devel] Using Window's raw API for shapes and text

On 2015-05-13 14:03-0400 Jim Dishaw wrote:

> I still have the revised windows driver that I can blow the dust off and
offer as a possible replacement.

Hi Jim:

As I recall, you had a lot of interesting ideas for your Windows device
driver so I hope you do integrate that into PLplot in the near future
regardless of whether or not it uses the deprecated plfreetype approach to
render text. Of course, it would be great if it uses a native Windows
unicode API to render text using whatever Windows system fonts happen to be
installed since that approach could be straightforwardly copied over to
wingcc to get rid of the last use of plfreetype.

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] Using Window's raw API for shapes and text

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

On 2015-05-13 14:03-0400 Jim Dishaw wrote:

> I still have the revised windows driver that I can blow the dust off and offer as a possible replacement.

Hi Jim:

As I recall, you had a lot of interesting ideas for your Windows
device driver so I hope you do integrate that into PLplot in the near
future regardless of whether or not it uses the deprecated plfreetype
approach to render text. Of course, it would be great if it uses a
native Windows unicode API to render text using whatever Windows
system fonts happen to be installed since that approach could
be straightforwardly copied over to wingcc to get rid of the
last use of plfreetype.

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] FPE in plfill.c

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

Hi Hazen:

On 2015-05-13 11:46-0400 Hazen Babcock wrote:

>
> Hello Alan, Arjen,
>
> As I mentioned before, the FPE's in x25c, x30c and x33c are all coming from 
> the notcrossed() function in plfill.c. Hopefully you can provide some insight 
> as the authors. Basically the problem arises in a situation where the two 
> lines do not cross, but are not parallel.
> In this situation this function 
> still calculates the x,y intersection. However, depending on the position and 
> orientation of the two lines this intersection can be way outside the range 
> of values that can be represented using (4 byte) integers. Do you recall if 
> functions that call this function expect to receive a valid intersection 
> point in this case? Or is it ok to just return zero?

Hi Hazen:

I have reviewed plfill.c, and the returned intersection from
notcrossed is only used when status is zero.  So I have (commit ID =
b916d4b) considerably simplified noncrossed to do the PLINT
transformation of the intersection and return those values _only_ when
status = 0.

This change solved all fpe problem for examples 25 and 30, but there
are remaining fpe issues for fortran examples 21 and 33.  The logic in
noncrossed is pretty bullet-proof now so my prediction is those
remaining fpe issues are completely independent of notcrossed or else
there is a non-initialized variable somewhere in fortran examples 21
and 33. But I look forward to your definitive conclusion concerning
those remaining fpe issues.

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] floating point exception in example 29

[Tom K. <tom...@ve...>]

On Wed, May 13, 2015 at 5:01 PM, Hazen Babcock <hba...@ma...> wrote:

> On 05/13/2015 03:58 PM, Alan W. Irwin wrote:
> > In my case the only fortran compiler available is gfortran so I don't
> > need to choose that.  So instead of the above I set
> >
> > export FFLAGS='-g -ffpe-trap=invalid,zero,overflow,underflow'
> >
> > before calling cmake and building the x29f95 and ps targets.
> >
> > After that, I got the following result
> >
> > software@raven> examples/f95/x29f -dev psc -o test.psc
> >
> > Program received signal SIGFPE: Floating-point exception - erroneous
> > arithmetic operation.
> > [...]
> >
> > So I confirm there is a floating-point issue for that example, and
> > this should be easy for anyone else here to confirm that has access to
> > gfortran.  However, I am completely tied up with other PLplot issues
> > so I would appreciate it if you pursued and fixed all floating-point
> > issues revealed by this method.  But if you are too busy to do that
> > yourself, please let this list know so others with more time will be
> > motivated to take a crack at it.
>
> The problem seems to come from line 267 in this example. It looks like
> the "sec" argument is not getting passed to the C library correctly? 0.0
> becomes something like 4.2439915819305446e-314, which I think causes the
> later problems. Perhaps there is something wrong with the fortran
> bindings for plctime? I would appreciate it if a fortran expert could
> take a look.
>
> -Hazen
>
>
I would look into setting the DAZ and FTZ bits for the floating point unit.
Intel fortran has an -ftz option (can't remember how to do DAZ).  For an
example of how to do ftz in code, see:

http://geoweb3.princeton.edu/~luet/specfem3d_globe/src/shared/force_ftz.c

Tom

Re: [Plplot-devel] Version 6?

[Andrew R. <and...@us...>]

On Tue, May 12, 2015 at 02:51:12PM -0400, Hazen Babcock wrote:
> 
> This e-mail is to provide a summary of what we had discussed, please let 
> me know if I left anything out. I think we had a consensus that the 
> following change would be made as part of a possible version 6:
> 
> 1. All API functions return error codes.
> 
> 
> I think we also agreed on these items, which might not actually require 
> a major version bump as the actual change to the API is potentially 
> small / nil:
> 
> 2. Thread safety.
> 
> 3. Improved text handling between core and the drivers.
> 
> 
> And there was some discussion about whether this was a good idea:
> 
> 4. Core handles some text rendering.
> 
> 
> Now I think the question is if the effort and disruption involved in (1) 
> justifies making the change. I would say that I'm neutral about this. I 
> feel that it is the way a modern library should behave. However I'm not 
> sure that the fact that PLplot does not currently work this way is 
> actually causing a lot of problems for people.

Hazen, 

There are some cases where 1) does cause problems - notably for
interactive drivers like octave where you do not want errors to result in
the program being killed off. The library should report the error and let
the program deal with it.

It also causes lintian warnings on Debian as it is a Bad Thing (TM) for
libraries to do. (For those who don't know, lintian is a package checking
program which looks for a whole range of errors / breaches of policy / bad
practice when packaging software for Debian).

Andrew

Re: [Plplot-devel] floating point exception in example 29

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

On 05/13/2015 03:58 PM, Alan W. Irwin wrote:
> In my case the only fortran compiler available is gfortran so I don't
> need to choose that.  So instead of the above I set
>
> export FFLAGS='-g -ffpe-trap=invalid,zero,overflow,underflow'
>
> before calling cmake and building the x29f95 and ps targets.
>
> After that, I got the following result
>
> software@raven> examples/f95/x29f -dev psc -o test.psc
>
> Program received signal SIGFPE: Floating-point exception - erroneous
> arithmetic operation.
> [...]
>
> So I confirm there is a floating-point issue for that example, and
> this should be easy for anyone else here to confirm that has access to
> gfortran.  However, I am completely tied up with other PLplot issues
> so I would appreciate it if you pursued and fixed all floating-point
> issues revealed by this method.  But if you are too busy to do that
> yourself, please let this list know so others with more time will be
> motivated to take a crack at it.

The problem seems to come from line 267 in this example. It looks like 
the "sec" argument is not getting passed to the C library correctly? 0.0 
becomes something like 4.2439915819305446e-314, which I think causes the 
later problems. Perhaps there is something wrong with the fortran 
bindings for plctime? I would appreciate it if a fortran expert could 
take a look.

-Hazen

Re: [Plplot-devel] Using Window's raw API for shapes and text

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

I never sent it up. I'm away foe my machine, so I will send it in a few days. 



> On May 13, 2015, at 2:21 PM, he...@co... wrote:
> 
> Jim,
> 
> That sounds like a good place to start.
> 
> Would you mind posting it? Or maybe it's in an early branch of the code?
> 
> Thanks,
> 
> Aaron.
> 
> 
> Sent from XFINITY Connect Mobile App
> -----Original Message-----
> 
> From: ji...@di...
> To: ir...@be...
> Cc: Plp...@li...,he...@co...
> Sent: 2015-05-13 13:03:32 GMT
> Subject: Re: [Plplot-devel] Using Window's raw API for shapes and text
> 
> I still have the revised windows driver that I can blow the dust off and offer as a possible replacement. 
> 
> 
> 
> > On May 13, 2015, at 1:59 PM, Alan W. Irwin wrote:
> > 
> > Hi Aaron:
> > 
> > I am putting this further discussion on the plplot-devel mailing list
> > since some developers there have more device expertise than I do (and
> > also a lot more Windows expertise) and therefore will likely want to
> > contribute to the discussion.
> > 
> >> On 2015-05-13 07:37-0500 Aaron Hexamer wrote:
> >> 
> >> [....] I've been wondering is if it
> >> would be feasible to make a driver that uses more of Window's raw API for
> >> shapes and text, thus avoiding the need for libs like Qt, Cairo-Pango, etc.
> >> - one would still get portability through other drivers on other platforms.
> >> It looks like wingcc is somewhat like that, but preferred to use Freetype.
> >> I gather from looking at the history that text rendering is challenging,
> >> especially around vertical alignment topics.
> > 
> > For your information, the plfreetype approach is strongly deprecated. 
> > The primary reason for this is the user can only control the selection
> > of the needed font files at cmake time or else at run-time via
> > environment variables which is a very clumsy approach. A secondary
> > reason is the plfreetype approach only works for simple text layout
> > (left-to-right) languages. Instead, our preferred approach is to rely
> > on external libraries such as pango/cairo/fontconfig, Qt, or wxwidgets
> > to automatically select the best system font (of the sans, serif,
> > normal weight, bold, etc., generic classes of fonts that PLplot
> > supports) to render each unicode glyph encountered (which
> > automatically allows multi-language plots such as example 24) and to
> > do the required (complex) text layout.
> > 
> > Thus, I agree that the plfreetype approach used by wingcc (the last
> > device driver that still uses that approach) should be completely
> > replaced by calling the appropriate native Windows API for selecting
> > the best system font to render each unicode glyph that is encountered
> > and to do the text layout.
> > 
> > I think in the past that Arjen Markus has commented this approach
> > should be possible, but he has not had time to pursue it further.
> > Also, my understanding is that Jim Dishaw has worked on implementing a
> > Windows device driver. I am not sure what the status of that project
> > is, but he might have some comments also about the feasibility of
> > modifying wingcc this way.
> > 
> > Anyhow, if you feel such modification of wingcc is possible, I would
> > encourage you to give it a try following, say, the broad outline of
> > the alt_unicode text handling that is done in drivers/cairo.c.
> > 
> > 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
> > __________________________
> > 
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud 
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] floating point exception in example 29

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

On 2015-05-13 11:29-0400 Hazen Babcock wrote:

> On 05/12/2015 01:22 PM, Alan W. Irwin wrote:
>> [...]Of course, the fortran examples go through a lot of additional code
>> before finally calling our core C library so this method should detect
>> floating-point exceptions in the fortran example implementation, the
>> fortran wrapper library code, AND, our core C library.  So we do want
>> to solve all of those.  Furthermore, once we have done so then I
>> believe the only C floating-point exception left that would go
>> undetected would be in the actual C example implementation, i.e., if
>> we divided by 0. right in one of the examples.  But we guard against
>> such issues in other ways (with the comparisons of PostScript and SVG
>> results) so I don't think we need to be concerned about such an issue.
>> 
>> If you agree with my above reasoning that gfortran with
>> -ffpe-trap=invalid,zero,overflow,underflow is what we want to do going
>> forward to detect floating point exceptions, then I hope you have the
>> time to fix all the causes of those exceptions in this release cycle.
>
> I'd add it to the debug build flags for fortran. Perhaps a check is also 
> needed that the fortran compiler is gfortran?

Hi Hazen:

Actually, we don't have to (and should not) change anything in our
code base.  Instead, the tester should simply set an environment
variable to choose the compiler and its options.

For example, you should be able to use

export FC='/usr/bin/gfortran -g -ffpe-trap=invalid,zero,overflow,underflow'

before running cmake (where the -g option sets up using gdb
on the results).

In my case the only fortran compiler available is gfortran so I don't
need to choose that.  So instead of the above I set

export FFLAGS='-g -ffpe-trap=invalid,zero,overflow,underflow'

before calling cmake and building the x29f95 and ps targets.

After that, I got the following result

software@raven> examples/f95/x29f -dev psc -o test.psc

Program received signal SIGFPE: Floating-point exception - erroneous
arithmetic operation.
[...]

So I confirm there is a floating-point issue for that example, and
this should be easy for anyone else here to confirm that has access to
gfortran.  However, I am completely tied up with other PLplot issues
so I would appreciate it if you pursued and fixed all floating-point
issues revealed by this method.  But if you are too busy to do that
yourself, please let this list know so others with more time will be
motivated to take a crack at it.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Spurious warnings on Cygwin should now be gone

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

On 2015-05-13 07:41-0000 Arjen Markus wrote:

> Well, that was easy and it brought up the warning immediately:
>
>
>
> -- Explicitly setting policy CMP0051 to OLD
>
> -- Explicitly setting policy CMP0052 to OLD
>
> -- Explicitly setting policy CMP0053 to OLD
>
> -- Explicitly setting policy CMP0054 to OLD
>
> CMake Warning at /usr/share/cmake-3.1.2/Modules/Platform/CYGWIN.cmake:15 (message):
>
>  CMake no longer defines WIN32 on Cygwin!
>
>
>
>  (1) If you are just trying to build this project, ignore this warning or
>
>  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
>
>  the CMake cache.  If later configuration or build errors occur then this
>
>  project may have been written under the assumption that Cygwin is WIN32.
>
>  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.
>
>
>
>  (2) If you are developing this project, add the line
>
>
>
>    set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required
>
>
>
>  at the top of your top-level CMakeLists.txt file or set the minimum
>
>  required version of CMake to 2.8.4 or higher.  Then teach your project to
>
>  build on Cygwin without WIN32.
>
> Call Stack (most recent call first):
>
>  /usr/share/cmake-3.1.2/Modules/CMakeSystemSpecificInformation.cmake:36 (include)
>
>  CMakeLists.txt:39 (project)

That is tremendous progress to get it down to a fairly simple example
without having to do an entire PLplot build to see the issue.
But please
keep debugging the reason why the first simple project did
not emit the spurious warning and the second simple project did.  For example, from the
above the message occurred in the project command so you can remove
the next few lines, i.e.,

if(NOT (CYGWIN OR CMAKE_SYSTEM_NAME STREQUAL "Linux") )
   # Latest CMake version as of 2015-05 for all platforms
   # other than Cygwin or Linux.
   plplot_cmake_minimum_required(VERSION 3.2.2 FATAL_ERROR)
endif(NOT (CYGWIN OR CMAKE_SYSTEM_NAME STREQUAL "Linux") )

to make the second project more similar to the first (presumably without
affecting the spurious warning).

Also, you can dispense completely with the function and
replace

plplot_cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)

with

cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
if(POLICY CMP0051)
      message(STATUS "Explicitly setting policy CMP0051 to OLD")
      cmake_policy(SET CMP0051 OLD)
endif(POLICY CMP0051)

to mimic what goes on in the function.

Note, those two changes should make the third simple example identical
with the first except for the if(POLICY CMP0051) stanza
above.

So if that third version emits the spurious error message, then that
narrows down the cause to the if, message, or cmake_policy commands,
but if the 3rd simple example does not emit the message, then
please simplify the second version as follows to see whether that
generates the message

function(plplot_cmake_minimum_required)
cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
if(POLICY CMP0051)
      message(STATUS "Explicitly setting policy CMP0051 to OLD")
      cmake_policy(SET CMP0051 OLD)
endif(POLICY CMP0051)
endfunction(plplot_cmake_minimum_required)

plplot_cmake_minimum_required()
project(plplot NONE)
enable_language(C)

message(STATUS "CMake version = ${CMAKE_VERSION}")
message(STATUS "CMAKE_SYSTEM_NAME = ${CMAKE_SYSTEM_NAME}")

which should be identical to the 3rd version other than
using the plplot_cmake_minimum_required function wrapper.

Remember, the goal here is to come up with the simplest possible
example that emits the spurious message that I can take to the cmake
developers.  So I have come up with several variations between the
current first simple example and current second simple example, but
please use your imagination as well to add as little as possible to
the first simple example to get it to emit the spurious message.

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] Using Window's raw API for shapes and text

[<he...@co...>]

Jim,<br><br>That sounds like a good place to start.<br><br>Would you mind posting it?  Or maybe it's in an early branch of the code?<br><br>Thanks,<br><br>Aaron.<br><br><br>Sent from XFINITY Connect Mobile App<br>-----Original Message-----<br><br>From: ji...@di...<br>To: ir...@be...<br>Cc: Plp...@li...,he...@co...<br>Sent: 2015-05-13 13:03:32 GMT<br>Subject: Re: [Plplot-devel] Using Window's raw API for shapes and text<br><br>I still have the revised windows driver that I can blow the dust off and offer as a possible replacement. <br><br><br><br>> On May 13, 2015, at 1:59 PM, Alan W. Irwin <ir...@be...> wrote:<br>> <br>> Hi Aaron:<br>> <br>> I am putting this further discussion on the plplot-devel mailing list<br>> since some developers there have more device expertise than I do (and<br>> also a lot more Windows expertise) and therefore will likely want to<br>> contribute to the discussion.<br>> <br>>> On 2015-05-13 07:37-0500 Aaron Hexamer wrote:<br>>> <br>>> [....] I've been wondering is if it<br>>> would be feasible to make a driver that uses more of Window's raw API for<br>>> shapes and text, thus avoiding the need for libs like Qt, Cairo-Pango, etc.<br>>> - one would still get portability through other drivers on other platforms.<br>>> It looks like wingcc is somewhat like that, but preferred to use Freetype.<br>>> I gather from looking at the history that text rendering is challenging,<br>>> especially around vertical alignment topics.<br>> <br>> For your information, the plfreetype approach is strongly deprecated. <br>> The primary reason for this is the user can only control the selection<br>> of the needed font files at cmake time or else at run-time via<br>> environment variables which is a very clumsy approach.  A secondary<br>> reason is the plfreetype approach only works for simple text layout<br>> (left-to-right) languages.  Instead, our preferred approach is to rely<br>> on external libraries such as pango/cairo/fontconfig, Qt, or wxwidgets<br>> to automatically select the best system font (of the sans, serif,<br>> normal weight, bold, etc., generic classes of fonts that PLplot<br>> supports) to render each unicode glyph encountered (which<br>> automatically allows multi-language plots such as example 24) and to<br>> do the required (complex) text layout.<br>> <br>> Thus, I agree that the plfreetype approach used by wingcc (the last<br>> device driver that still uses that approach) should be completely<br>> replaced by calling the appropriate native Windows API for selecting<br>> the best system font to render each unicode glyph that is encountered<br>> and to do the text layout.<br>> <br>> I think in the past that Arjen Markus has commented this approach<br>> should be possible, but he has not had time to pursue it further.<br>> Also, my understanding is that Jim Dishaw has worked on implementing a<br>> Windows device driver.  I am not sure what the status of that project<br>> is, but he might have some comments also about the feasibility of<br>> modifying wingcc this way.<br>> <br>> Anyhow, if you feel such modification of wingcc is possible, I would<br>> encourage you to give it a try following, say, the broad outline of<br>> the alt_unicode text handling that is done in drivers/cairo.c.<br>> <br>> Alan<br>> __________________________<br>> Alan W. Irwin<br>> <br>> Astronomical research affiliation with Department of Physics and Astronomy,<br>> University of Victoria (astrowww.phys.uvic.ca).<br>> <br>> Programming affiliations with the FreeEOS equation-of-state<br>> implementation for stellar interiors (freeeos.sf.net); the Time<br>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting<br>> software package (plplot.sf.net); the libLASi project<br>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);<br>> and the Linux Brochure Project (lbproject.sf.net).<br>> __________________________<br>> <br>> Linux-powered Science<br>> __________________________<br>> <br>> ------------------------------------------------------------------------------<br>> One dashboard for servers and applications across Physical-Virtual-Cloud <br>> Widest out-of-the-box monitoring support with 50+ applications<br>> Performance metrics, stats and reports that give you Actionable Insights<br>> Deep dive visibility with transaction tracing using APM Insight.<br>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y<br>> _______________________________________________<br>> Plplot-devel mailing list<br>> Plp...@li...<br>> https://lists.sourceforge.net/lists/listinfo/plplot-devel<br>

Re: [Plplot-devel] Using Window's raw API for shapes and text

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

I still have the revised windows driver that I can blow the dust off and offer as a possible replacement. 



> On May 13, 2015, at 1:59 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> Hi Aaron:
> 
> I am putting this further discussion on the plplot-devel mailing list
> since some developers there have more device expertise than I do (and
> also a lot more Windows expertise) and therefore will likely want to
> contribute to the discussion.
> 
>> On 2015-05-13 07:37-0500 Aaron Hexamer wrote:
>> 
>> [....] I've been wondering is if it
>> would be feasible to make a driver that uses more of Window's raw API for
>> shapes and text, thus avoiding the need for libs like Qt, Cairo-Pango, etc.
>> - one would still get portability through other drivers on other platforms.
>> It looks like wingcc is somewhat like that, but preferred to use Freetype.
>> I gather from looking at the history that text rendering is challenging,
>> especially around vertical alignment topics.
> 
> For your information, the plfreetype approach is strongly deprecated. 
> The primary reason for this is the user can only control the selection
> of the needed font files at cmake time or else at run-time via
> environment variables which is a very clumsy approach.  A secondary
> reason is the plfreetype approach only works for simple text layout
> (left-to-right) languages.  Instead, our preferred approach is to rely
> on external libraries such as pango/cairo/fontconfig, Qt, or wxwidgets
> to automatically select the best system font (of the sans, serif,
> normal weight, bold, etc., generic classes of fonts that PLplot
> supports) to render each unicode glyph encountered (which
> automatically allows multi-language plots such as example 24) and to
> do the required (complex) text layout.
> 
> Thus, I agree that the plfreetype approach used by wingcc (the last
> device driver that still uses that approach) should be completely
> replaced by calling the appropriate native Windows API for selecting
> the best system font to render each unicode glyph that is encountered
> and to do the text layout.
> 
> I think in the past that Arjen Markus has commented this approach
> should be possible, but he has not had time to pursue it further.
> Also, my understanding is that Jim Dishaw has worked on implementing a
> Windows device driver.  I am not sure what the status of that project
> is, but he might have some comments also about the feasibility of
> modifying wingcc this way.
> 
> Anyhow, if you feel such modification of wingcc is possible, I would
> encourage you to give it a try following, say, the broad outline of
> the alt_unicode text handling that is done in drivers/cairo.c.
> 
> 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
> __________________________
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Using Window's raw API for shapes and text

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

Hi Aaron:

I am putting this further discussion on the plplot-devel mailing list
since some developers there have more device expertise than I do (and
also a lot more Windows expertise) and therefore will likely want to
contribute to the discussion.

On 2015-05-13 07:37-0500 Aaron Hexamer wrote:

> [....] I've been wondering is if it
> would be feasible to make a driver that uses more of Window's raw API for
> shapes and text, thus avoiding the need for libs like Qt, Cairo-Pango, etc.
> - one would still get portability through other drivers on other platforms.
> It looks like wingcc is somewhat like that, but preferred to use Freetype.
> I gather from looking at the history that text rendering is challenging,
> especially around vertical alignment topics.

For your information, the plfreetype approach is strongly deprecated. 
The primary reason for this is the user can only control the selection
of the needed font files at cmake time or else at run-time via
environment variables which is a very clumsy approach.  A secondary
reason is the plfreetype approach only works for simple text layout
(left-to-right) languages.  Instead, our preferred approach is to rely
on external libraries such as pango/cairo/fontconfig, Qt, or wxwidgets
to automatically select the best system font (of the sans, serif,
normal weight, bold, etc., generic classes of fonts that PLplot
supports) to render each unicode glyph encountered (which
automatically allows multi-language plots such as example 24) and to
do the required (complex) text layout.

Thus, I agree that the plfreetype approach used by wingcc (the last
device driver that still uses that approach) should be completely
replaced by calling the appropriate native Windows API for selecting
the best system font to render each unicode glyph that is encountered
and to do the text layout.

I think in the past that Arjen Markus has commented this approach
should be possible, but he has not had time to pursue it further.
Also, my understanding is that Jim Dishaw has worked on implementing a
Windows device driver.  I am not sure what the status of that project
is, but he might have some comments also about the feasibility of
modifying wingcc this way.

Anyhow, if you feel such modification of wingcc is possible, I would
encourage you to give it a try following, say, the broad outline of
the alt_unicode text handling that is done in drivers/cairo.c.

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] FPE in plfill.c

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

Hello Alan, Arjen,

As I mentioned before, the FPE's in x25c, x30c and x33c are all coming 
from the notcrossed() function in plfill.c. Hopefully you can provide 
some insight as the authors. Basically the problem arises in a situation 
where the two lines do not cross, but are not parallel. In this 
situation this function still calculates the x,y intersection. However, 
depending on the position and orientation of the two lines this 
intersection can be way outside the range of values that can be 
represented using (4 byte) integers. Do you recall if functions that 
call this function expect to receive a valid intersection point in this 
case? Or is it ok to just return zero?

-Hazen

Re: [Plplot-devel] floating point exception in example 29

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

On 05/12/2015 01:22 PM, Alan W. Irwin wrote:
> On 2015-05-12 09:41-0400 Hazen Babcock wrote:
>>
>> Hm.. example 21 also generates an FPE, but at least in this case it
>> looks like it is coming from the qhull library. And example 29 also
>> generates an FPE, but only the Fortran version not the C version. So,
>> maybe it would be better in the end to add this check to all of the C
>> examples as well?
>
> I sympathize with your desire not to mark up all the examples.  Which
> lead to the thought that if gfortran has an option to report the above
> exceptions without additional code markup, then gcc might have such
> options as well.
>
> A google search on the terms <gcc floating point exception traps>
> found somehow else had asked that exact question at
> <http://stackoverflow.com/questions/18644168/catch-floating-point-exceptions-using-a-compiler-option-with-c>
>
> I don't understand the answers myself, but perhaps they might be useful
> to you.

I found this as well, which is what led me to the gfortran flag. They 
are saying that such a flag does not currently exist for C.

> If it turns out the answer is currently "no" (i.e., you must mark up
> the examples in order to detect floating-point exceptions with gcc),
> then I think we could probably just stick with gfortran and
> -ffpe-trap=invalid,zero,overflow,underflow.
>
> Of course, the fortran examples go through a lot of additional code
> before finally calling our core C library so this method should detect
> floating-point exceptions in the fortran example implementation, the
> fortran wrapper library code, AND, our core C library.  So we do want
> to solve all of those.  Furthermore, once we have done so then I
> believe the only C floating-point exception left that would go
> undetected would be in the actual C example implementation, i.e., if
> we divided by 0. right in one of the examples.  But we guard against
> such issues in other ways (with the comparisons of PostScript and SVG
> results) so I don't think we need to be concerned about such an issue.
>
> If you agree with my above reasoning that gfortran with
> -ffpe-trap=invalid,zero,overflow,underflow is what we want to do going
> forward to detect floating point exceptions, then I hope you have the
> time to fix all the causes of those exceptions in this release cycle.

I'd add it to the debug build flags for fortran. Perhaps a check is also 
needed that the fortran compiler is gfortran?

-Hazen

Re: [Plplot-devel] Spurious warnings on Cygwin should now be gone

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

Hi Alan,



Well, that was easy and it brought up the warning immediately:



-- Explicitly setting policy CMP0051 to OLD

-- Explicitly setting policy CMP0052 to OLD

-- Explicitly setting policy CMP0053 to OLD

-- Explicitly setting policy CMP0054 to OLD

CMake Warning at /usr/share/cmake-3.1.2/Modules/Platform/CYGWIN.cmake:15 (message):

  CMake no longer defines WIN32 on Cygwin!



  (1) If you are just trying to build this project, ignore this warning or

  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in

  the CMake cache.  If later configuration or build errors occur then this

  project may have been written under the assumption that Cygwin is WIN32.

  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.



  (2) If you are developing this project, add the line



    set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required



  at the top of your top-level CMakeLists.txt file or set the minimum

  required version of CMake to 2.8.4 or higher.  Then teach your project to

  build on Cygwin without WIN32.

Call Stack (most recent call first):

  /usr/share/cmake-3.1.2/Modules/CMakeSystemSpecificInformation.cmake:36 (include)

  CMakeLists.txt:39 (project)





-- The C compiler identification is GNU 4.9.2

-- Check for working C compiler: /usr/bin/cc

-- Check for working C compiler: /usr/bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- CMake version = 3.1.2

-- CMAKE_SYSTEM_NAME = CYGWIN

-- Configuring done

-- Generating done

-- Build files have been written to: /cygdrive/d/tmp/cmake




Regards,

Arjen


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Thanks for these no-spurious-message results which are quite puzzling/unexpected.
>
> To proceed further please change that test to be identical to
>
> line 33 through line 87 of our top-level CMakeLists.txt file, i.e., the range of lines:
>
> function(plplot_cmake_minimum_required)
> [...]
> message(STATUS "CMAKE_SYSTEM_NAME = ${CMAKE_SYSTEM_NAME}")
>
> ?


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] Spurious warnings on Cygwin should now be gone

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

On 2015-05-13 06:37-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> The outcome of that test was:
>
>
>
> -- The C compiler identification is GNU 4.9.2
>
> -- Check for working C compiler: /usr/bin/cc
>
> -- Check for working C compiler: /usr/bin/cc -- works
>
> -- Detecting C compiler ABI info
>
> -- Detecting C compiler ABI info - done
>
> -- Detecting C compile features
>
> -- Detecting C compile features - done
>
> -- CMake version = 3.1.2
>
> -- CMAKE_SYSTEM_NAME = CYGWIN
>
> -- Configuring done
>
> -- Generating done
>
> -- Build files have been written to: /cygdrive/d/tmp/cmake

Thanks for these no-spurious-message results which are quite puzzling/unexpected.

To proceed further please change that test to be identical to

line 33 through line 87 of our top-level CMakeLists.txt file, i.e.,
the range of lines:

function(plplot_cmake_minimum_required)
[...]
message(STATUS "CMAKE_SYSTEM_NAME = ${CMAKE_SYSTEM_NAME}")

?

If that second simple example (which is really not that different than
the first simple example) generates the spurious message, please debug
further by using the --debug-output and/or -trace cmake options and/or
inserting message statements into this special simple example to do an
approximate binary search to find the line that is generating the
spurious message.

If that second simple example does not generate the spurious message,
please do similar debugging of our real top-level CMakeLists.txt file
for PLplot until you find the line that is generating the spurious
message.

The spurious message does indicate something is not quite right either
with CMake or our build system on the Cygwin platform so I really
would appreciate you doing this further detective work to figure out
the line that is causing 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] Request for comprehensive test of traditional install tree on Cygwin

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

Hi Alan,



Please find the result of the comprehensive test in the attachment. From a quick inspection of the report I see that there are various issues:

-        The Fortran examples are not properly built because of the name of the libraries:

x00

/usr/bin/cc x01c.c -o x01c.exe -Wl,-rpath -Wl,"/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/lib:/usr/local/lib" -I/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/include/plplot -L/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/lib -L/usr/local/lib -lplplot -lltdl.dll -ldl -lshp -lfreetype.dll -lcsirocsa -lqsastime

/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lplplotf95-12.0.0

/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lplplotf95c-12.0.0





-        There is an issue with gtk when compiling the C++ examples

-        At some point the compiler cannot find the header file plplot.h

As test runs pretty fast, I only excluded the interactive parts.

Regards,

Arjen


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, May 12, 2015 9:50 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Request for comprehensive test of traditional install tree on Cygwin
>
> On 2015-05-12 10:51-0000 Arjen Markus wrote:
>
> > [...] As the comprehensive tests fail [on Cygwin] with the traditional install tree, I
> have turned that off.
>
> My impression was you originally turned that off because you did not have pkg-
> config installed on your Cygwin platform.  But your current cmake.out files shows
> pkg-config is now installed so at least you should be able to try a comprehensive test
> (with options
>
> --do_test_interactive no
> --do_ctest no
> --do_test_build_tree no
> --do_test_install_tree no
> --do_test_traditional_install_tree yes
>
> ) of the traditional install tree on Cygwin.  (Those "no" options are simply there to
> speed up the test by dropping the interactive part and by not duplicating what you did
> before.)
>
> Your report from this run should help me to diagnose what (if
> anything) is wrong with the traditional install tree on Cygwin.
>
> 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
> __________________________

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] Spurious warnings on Cygwin should now be gone

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

Hi Alan,



The outcome of that test was:



-- The C compiler identification is GNU 4.9.2

-- Check for working C compiler: /usr/bin/cc

-- Check for working C compiler: /usr/bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- CMake version = 3.1.2

-- CMAKE_SYSTEM_NAME = CYGWIN

-- Configuring done

-- Generating done

-- Build files have been written to: /cygdrive/d/tmp/cmake


So no spurious message whatsoever. I have attached the complete set of files for your convenience, though that probably is superfluous.
Regards,
Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, May 12, 2015 9:36 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: Spurious warnings on Cygwin should now be gone
>
> On 2015-05-12 10:51-0000 Arjen Markus wrote:
>
> > I used commit c67fd667347b09bf5d3be6c0bc73de3762e59ab1 and still see
> that warning. I have attached the compressed tar-ball for your convenience.
>
> I very much appreciate that report since it is a largely successful test of all the recent
> build-system changes I have been doing.
>
> That report shows we have a substantial improvement from your previous report
> since the warnings are now reduced from 5 or so per cmake run to just one instance
> that occurs immediately at the start of our top-level CMake logic.
>
> To pursue this further, could you please try the following mini-project?
>
> cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
> project(test_cygwin_warnings NONE)
> enable_language(C)
> message(STATUS "CMake version = ${CMAKE_VERSION}") message(STATUS
> "CMAKE_SYSTEM_NAME = ${CMAKE_SYSTEM_NAME}")
>
> The point of this mini-project is to try and find a simple test case that generates the
> spurious warning that I can pass on to the CMake developers to help them fix that
> bug on Cygwin.
>
> If the above mini-project does not generate the spurious warning, then there is a
> slightly less simple test project we can try that mimics the PLplot initial code much
> more closely.  However, the differences between that more complex project and the
> one above should not make any difference with regard to the spurious warning so
> my bet is the above project will demonstrate that bug.
>
> 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
> __________________________

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.