plplot-devel

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

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

>
> On 05/11/2015 06:05 PM, Alan W. Irwin wrote:
>>
>> Hi Hazen:
>>
>> I am glad to hear you have created a topic branch that catches
>> floating point exceptions.  However, I am not keen on pulling a PLplot
>> topic branch from github for the reasons discussed in
>> README.developers.  So could you either share your topic branch using
>> "git format-patch" or else just push it to our official repo yourself?
>> The former is preferred if the work is incomplete (i.e., does not
>> include a cmake option to control when the PLPLOT_ENABLE_FLOAT_EXCEPT
>> macro is #defined). Furthermore, if the work is incomplete, I can
>> finish the cmake aspects of it as promised above and amend your commit
>> accordingly.
>>
>> Once we have implemented an option to check for floating-point
>> exceptions, then that means any of us should be able to confirm the
>> ones you have found and find others in the future due to the continued
>> evolution of our examples.  And, of course, this option should allow
>> us to fix those floating-point exceptions as time permits.
>
> Hi Alan,
>
> Sorry, that branch was not meant for incorporation into PLplot which is
> why I did not follow accepted protocols. I thought it might make it
> easier for others to see the floating point exception problem for these
> 3 examples.
>
> I think we can enable floating point exception trapping more easily
> using the -ffpe-trap option provided by gfortran. This won't require us
> to mark up all of our C examples, though we might instead need to check
> that the fortran compiler is gfortran?
>
> https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html
>
> -ffpe-trap=invalid,zero,overflow,underflow
>
> Compiling PLplot with this fortran flag (CMAKE_Fortran_FLAGS) "worked"
> for me in that it core dumps on the fortran equivalents of the C
> examples I mentioned above. I've attached my CMakeCache.txt file.
>
> -Hazen

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?

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

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

Hi Alan, Hazen,



-----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, May 14, 2015 2:19 AM
>
> 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).

Actually, this should have been caught by the compiler.

>
> @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.
>
Indeed, on the other hand, see my remark above. I will have a look at this.

> @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.
>
Any chance they are caused by something similar?

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

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

Hi Alan, Hazen,


> From: Arjen Markus [mailto:Arj...@de...]
> Sent: Friday, May 15, 2015 12:15 PM
> To: Alan W. Irwin; Hazen Babcock
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] floating point exception in example 29
>
> Hi Alan, Hazen,
>
> Actually, this should have been caught by the compiler.

Ah, that is clear: there is no interface definition for plctime. So the compiler was using the traditional F77 rules and could not check the correctness of the argument types. I will fix 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] floating point exception in example 29

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

On 2015-05-15 10:19-0000 Arjen Markus wrote:

> Hi Alan, Hazen,
>
>
>> From: Arjen Markus [mailto:Arj...@de...]
>> Sent: Friday, May 15, 2015 12:15 PM
>> To: Alan W. Irwin; Hazen Babcock
>> Cc: PLplot development list
>> Subject: Re: [Plplot-devel] floating point exception in example 29
>>
>> Hi Alan, Hazen,
>>
>> Actually, this should have been caught by the compiler.
>

> Ah, that is clear: there is no interface definition for plctime. So
the compiler was using the traditional F77 rules and could not check
the correctness of the argument types. I will fix this.

Hi Arjen:

Are you proposing to do this fix for current Fortran binding? If so, I
honestly don't think it is worth your time since (a) nobody has
complained about some of these f77 characteristics of the current
binding and (b) I assume that binding is soon going to be replaced
with your new Fortran binding.  I assume the fundamental design of
your new Fortran binding will automatically check type correctness of
all arguments so there is no chance of such an error occurring with
it.

Which reminds me, what is the status of your topic branch for your new
Fortran binding? The reason I ask is the next opportunity (just after
the forthcoming 5.11.1 will be released) to merge large topics to
master is fast approaching, and my understanding is there is still
some more work you have to do to mature that topic sufficiently
so that it is suitable for merging with master.

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

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

Hi Alan,



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


> > Ah, that is clear: there is no interface definition for plctime. So
> the compiler was using the traditional F77 rules and could not check the correctness
> of the types. I will fix this.
>
> Hi Arjen:
>
> Are you proposing to do this fix for current Fortran binding? If so, I honestly don't
> think it is worth your time since (a) nobody has complained about some of these f77
> characteristics of the current binding and (b) I assume that binding is soon going to
> be replaced with your new Fortran binding.  I assume the fundamental design of your
> new Fortran binding will automatically check type correctness of all arguments so
> there is no chance of such an error occurring with it.

No, you misunderstood me. I should have been clearer: the PLPLOT module did not include the subroutine plctime, plbtime and plconfigtime. This means that the compiler has no clue as to what arguments are required and simply accepts whatever you pass (which is the way FORTRAN 77 worked and what the compiler is obliged to do). I added interfaces to the module, so that now it does check the types. It would be nice if in fact the compiler would warn about such unknown routines.

My new bindings would not have prevented this, as it was an omission, not an incorrect implementation.

>
> Which reminds me, what is the status of your topic branch for your new Fortran
> binding? The reason I ask is the next opportunity (just after the forthcoming 5.11.1
> will be released) to merge large topics to master is fast approaching, and my
> understanding is there is still some more work you have to do to mature that topic
> sufficiently so that it is suitable for merging with master.
>
Alas, no progress here, as I have been rather busy with many things.

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.

[Plplot-devel] A possible design of our new Fortran binding

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

On 2015-05-17 07:38-0000 Arjen Markus wrote:

> My new bindings would not have prevented this [argument kind error], as it was an omission, not an incorrect implementation.

Hi Arjen:

This is an important point that I think needs more discussion because
the new Fortran binding for ephcom very much prevents such issues from
happening.

There I completely dropped all C code and C headers that helped define
the old fortran binding (the ephcom equivalent to PLplot's plstubs.h,
sc3d.c, sccont.c, and scstubs.c).  Instead, I used the features of the
iso_c_binding module to write the interface virtually entirely in
Fortran (except for the few cases where iso_c_binding did not have
some argument processing feature that I had to write from scratch in
C).  So if I had omitted something from the Fortran interface.f90
file, there was no leftover C infrastructure that would silently
generate a f77 fallback.  Instead, the omission would be immediately
detected when I attempted to use the missing function.

I am pretty sure it should be possible (since argument transformations
from single to double or double to single is the only extra
requirement) to do the same thing for our new Fortran interface.  To
make that specific, I think our first goal should be to write an
interface.f90 file that contains complete information to handle single
or double precision versions of x00f.f90 with no C code required at
all to define the interface.

If you agree, then once that first goal is achieved (again with
plstubs.h, sc3d.c, sccont.c, and scstubs.c removed), we should be able
to expand the interface (using a C layer where necessary for
processing special kinds of arguments) to handle standard examples
that include use of more complicated PLplot arguments.

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] A possible design of our new Fortran binding

[James T. <jt...@gm...>]

If I understand correctly, then this is pretty much what we do in
gtk-fortran where a script is able to parse the gtk+ (along with gdk, glib,
cairo and the other dependencies) headers to make a set of Fortran
interface definitions.

There are only a couple of significant issues that need to be considered
(and one I think does not apply to plplot).
1) The compile times can be long, unless a suitable "only" clause is used.
2) Variadic interfaces are not handled (I don't think there is a way to
call a C variadic function from Fortran at all).

James


On 17 May 2015 at 17:59, Alan W. Irwin <ir...@be...> wrote:

> On 2015-05-17 07:38-0000 Arjen Markus wrote:
>
> > My new bindings would not have prevented this [argument kind error], as
> it was an omission, not an incorrect implementation.
>
> Hi Arjen:
>
> This is an important point that I think needs more discussion because
> the new Fortran binding for ephcom very much prevents such issues from
> happening.
>
> There I completely dropped all C code and C headers that helped define
> the old fortran binding (the ephcom equivalent to PLplot's plstubs.h,
> sc3d.c, sccont.c, and scstubs.c).  Instead, I used the features of the
> iso_c_binding module to write the interface virtually entirely in
> Fortran (except for the few cases where iso_c_binding did not have
> some argument processing feature that I had to write from scratch in
> C).  So if I had omitted something from the Fortran interface.f90
> file, there was no leftover C infrastructure that would silently
> generate a f77 fallback.  Instead, the omission would be immediately
> detected when I attempted to use the missing function.
>
> I am pretty sure it should be possible (since argument transformations
> from single to double or double to single is the only extra
> requirement) to do the same thing for our new Fortran interface.  To
> make that specific, I think our first goal should be to write an
> interface.f90 file that contains complete information to handle single
> or double precision versions of x00f.f90 with no C code required at
> all to define the interface.
>
> If you agree, then once that first goal is achieved (again with
> plstubs.h, sc3d.c, sccont.c, and scstubs.c removed), we should be able
> to expand the interface (using a C layer where necessary for
> processing special kinds of arguments) to handle standard examples
> that include use of more complicated PLplot arguments.
>
> 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] A possible design of our new Fortran binding

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

Hi Alan, James,



I am not entirely sure that it is possible to eliminate all intermediate C code, for instance because of storing pointers to callback functions and NULL arguments, but using the iso_c_binding features it will at the very least be possible to let the linker detect missing interfaces: the problem with plbtime and others was that there was a C wrapper, callable from Fortran but no Fortran interface definition. In the new set-up none of the C wrapper code that may still be required will have the name mangling done on the C side - which means the linker will detect any mismatch.



As for James's observations:

Ad 1) I have not noticed anything like that up to now

Ad 2) As far as I know variadic interfaces are indeed impossible (there may be something about that in the so-called technical reports for the Fortran 2015-or-so standard), but luckily PLplot has none.



I should be able to demonstrate the interface set-up I have in mind in a few days, using x00f as an example.



Regards,



Arjen





From: James Tappin [mailto:jt...@gm...]
Sent: Sunday, May 17, 2015 8:42 PM
To: Alan W. Irwin
Cc: Arjen Markus; PLplot development list
Subject: Re: [Plplot-devel] A possible design of our new Fortran binding

If I understand correctly, then this is pretty much what we do in gtk-fortran where a script is able to parse the gtk+ (along with gdk, glib, cairo and the other dependencies) headers to make a set of Fortran interface definitions.
There are only a couple of significant issues that need to be considered (and one I think does not apply to plplot).
1) The compile times can be long, unless a suitable "only" clause is used.
2) Variadic interfaces are not handled (I don't think there is a way to call a C variadic function from Fortran at all).
James

On 17 May 2015 at 17:59, Alan W. Irwin <ir...@be...<mailto:ir...@be...>> wrote:
On 2015-05-17 07:38-0000 Arjen Markus wrote:

> My new bindings would not have prevented this [argument kind error], as it was an omission, not an incorrect implementation.

Hi Arjen:

This is an important point that I think needs more discussion because
the new Fortran binding for ephcom very much prevents such issues from
happening.

There I completely dropped all C code and C headers that helped define
the old fortran binding (the ephcom equivalent to PLplot's plstubs.h,
sc3d.c, sccont.c, and scstubs.c).  Instead, I used the features of the
iso_c_binding module to write the interface virtually entirely in
Fortran (except for the few cases where iso_c_binding did not have
some argument processing feature that I had to write from scratch in
C).  So if I had omitted something from the Fortran interface.f90
file, there was no leftover C infrastructure that would silently
generate a f77 fallback.  Instead, the omission would be immediately
detected when I attempted to use the missing function.

I am pretty sure it should be possible (since argument transformations
from single to double or double to single is the only extra
requirement) to do the same thing for our new Fortran interface.  To
make that specific, I think our first goal should be to write an
interface.f90 file that contains complete information to handle single
or double precision versions of x00f.f90 with no C code required at
all to define the interface.

If you agree, then once that first goal is achieved (again with
plstubs.h, sc3d.c, sccont.c, and scstubs.c removed), we should be able
to expand the interface (using a C layer where necessary for
processing special kinds of arguments) to handle standard examples
that include use of more complicated PLplot arguments.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca<http://astrowww.phys.uvic.ca>).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net<http://freeeos.sf.net>); the Time
Ephemerides project (timeephem.sf.net<http://timeephem.sf.net>); PLplot scientific plotting
software package (plplot.sf.net<http://plplot.sf.net>); the libLASi project
(unifont.org/lasi<http://unifont.org/lasi>); the Loads of Linux Links project (loll.sf.net<http://loll.sf.net>);
and the Linux Brochure Project (lbproject.sf.net<http://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...<mailto:Plp...@li...>
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

Re: [Plplot-devel] A possible design of our new Fortran binding

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

Hi Alan, James,



In the attachment you will find a demonstration of the sort of Fortran bindings I have in mind. The essence is:

-        Use iso_c_binding to call the C functions directly (no intervening C wrapper if that can be avoided)

-        Use the renaming feature of the use statement to switch between single and double precision without code duplication. The result is that the bindings provide two versions, one for single-precision arguments and one for double-precision arguments, which are selected automatically by the compiler. (Mixtures of precisions within a single call are not supported - that would lead to a very akward combinatorics and I doubt this at all a practical use case.)

-        Hide those things like parameters that are not intended for the public interface. I will probably go and use "private" as the default and make the individual items public instead of what I have now (default "public" and hide the things that are not needed)

The source code currently is tuned to example x00f, slightly modified wrt the trunk. You can change the worknig precision parameter "wp" to select the other precision.

Notes:

-        newbinding.f90 is the topmost source file. All other files are included into it.

-        To link the example you need the PLplot C library. See the shell script "mk", which was set up for Cygwin

-        With slight modifications this should work on Linux too (there you can use the libplplot.so shared object directly).

-        I have not tested this with command-line arguments yet - that is the trickier part of the code.

Regards,

Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, May 17, 2015 7:00 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: A possible design of our new Fortran binding
>
> On 2015-05-17 07:38-0000 Arjen Markus wrote:
>
> > My new bindings would not have prevented this [argument kind error], as it was an
> omission, not an incorrect implementation.
>
> Hi Arjen:
>
> This is an important point that I think needs more discussion because the new
> Fortran binding for ephcom very much prevents such issues from happening.
>
> There I completely dropped all C code and C headers that helped define the old
> fortran binding (the ephcom equivalent to PLplot's plstubs.h, sc3d.c, sccont.c, and
> scstubs.c).  Instead, I used the features of the iso_c_binding module to write the
> interface virtually entirely in Fortran (except for the few cases where iso_c_binding
> did not have some argument processing feature that I had to write from scratch in C).
> So if I had omitted something from the Fortran interface.f90 file, there was no leftover
> C infrastructure that would silently generate a f77 fallback.  Instead, the omission
> would be immediately detected when I attempted to use the missing function.
>
> I am pretty sure it should be possible (since argument transformations from single to
> double or double to single is the only extra
> requirement) to do the same thing for our new Fortran interface.  To make that
> specific, I think our first goal should be to write an
> interface.f90 file that contains complete information to handle single or double
> precision versions of x00f.f90 with no C code required at all to define the interface.
>
> If you agree, then once that first goal is achieved (again with plstubs.h, sc3d.c,
> sccont.c, and scstubs.c removed), we should be able to expand the interface (using
> a C layer where necessary for processing special kinds of arguments) to handle
> standard examples that include use of more complicated PLplot arguments.
>
> 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] A possible design of our new Fortran binding

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

On 2015-05-21 07:53-0000 Arjen Markus wrote:

> Hi Alan, James,
>
>
>
> In the attachment you will find a demonstration of the sort of Fortran bindings I have in mind. The essence is:
>
> -        Use iso_c_binding to call the C functions directly (no intervening C wrapper if that can be avoided)
>
> -        Use the renaming feature of the use statement to switch between single and double precision without code duplication. The result is that the bindings provide two versions, one for single-precision arguments and one for double-precision arguments, which are selected automatically by the compiler. (Mixtures of precisions within a single call are not supported - that would lead to a very akward combinatorics and I doubt this at all a practical use case.)
>
> -        Hide those things like parameters that are not intended for the public interface. I will probably go and use "private" as the default and make the individual items public instead of what I have now (default "public" and hide the things that are not needed)
>
> The source code currently is tuned to example x00f, slightly modified wrt the trunk. You can change the worknig precision parameter "wp" to select the other precision.
>
> Notes:
>
> -        newbinding.f90 is the topmost source file. All other files are included into it.
>
> -        To link the example you need the PLplot C library. See the shell script "mk", which was set up for Cygwin
>
> -        With slight modifications this should work on Linux too (there you can use the libplplot.so shared object directly).
>

Hi Arjen:

A Linux adaptation of those build instructions got that build to work
for me (with some spurious warnings because of my old gfortran 4.7.2
version as we have discussed before.)

The end result was

irwin@raven> ./x00f

worked and prompted me for device and device file name, and the
resulting PostScript plot looked good.

So that is an excellent start, and I especially like the absence of
any extra C layer at this stage (although we will ultimately need an
extremely limited C layer for some of the more complex API argument
processing); the freedom to choose any real type in the examples (so
long as that real type is chosen consistently for a single call to a
PLplot function); and the form of how you have implemented the
interface which avoids duplicate code to handle the two different
PLFLT cases.

However, there are three things we should fix before expanding
this further.

1. Fix plsparseopts 
> -        I have not tested this with command-line arguments yet - that is the trickier part of the code.

In fact, it turns out command-line options do not work correctly, e.g.,

irwin@raven> ./x00f -dev psttfc -o test.psc

Bad command line option "test.psc"
[....]

2. Fix naming scheme for kind values so the examples (and more
importantly user's programmes which are depending on plflt) can remain unchanged
for backwards compatibility.  I have developed some detailed ideas in
the way I want to do this, but instead of describing those in English
I would like to present a commit instead that you could evaluate in
detail for yourself.

3. Integrate these changes into our current build and test scheme.
Again, I would be happy to take responsibility for this.

In sum, I suggest we continue from this good start on the new Fortran
binding topic with you taking responsibility for topic 1 and me taking
responsibility for topics 2 and 3 above.

Of course, if I am going to contribute to this development I do need
git access to your private topic branch work using the usual "git
format-patch" and "git am" method that is described in
README.developers. So for now I suggest your first priority would be
to present exactly what you have given us here as a tarball in "git
format-patch" form instead with no further changes (except possibly
not including the x00f.f90 change since I would just revert that, see
above).  And that solid git start with just your present work and no
further except possibly excluding the x00f.f90 change would allow us
to develop this private topic from there. Of course, I am aware you
have had some problems with using "git format-patch" in the past, but
if those continue let me know here or off list, and I think I should
be able to give you an exact cookbook of what to do to get started.

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] A possible design of our new Fortran binding

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Arjen:
>
> A Linux adaptation of those build instructions got that build to work for me (with
> some spurious warnings because of my old gfortran 4.7.2 version as we have
> discussed before.)
>
> The end result was
>
> irwin@raven> ./x00f
>
> worked and prompted me for device and device file name, and the resulting
> PostScript plot looked good.
>
Great!

> So that is an excellent start, and I especially like the absence of any extra C layer at
> this stage (although we will ultimately need an extremely limited C layer for some of
> the more complex API argument processing); the freedom to choose any real type in
> the examples (so long as that real type is chosen consistently for a single call to a
> PLplot function); and the form of how you have implemented the interface which
> avoids duplicate code to handle the two different PLFLT cases.
>
> However, there are three things we should fix before expanding this further.
>
> 1. Fix plsparseopts
> > -        I have not tested this with command-line arguments yet - that is the trickier
> part of the code.
>
> In fact, it turns out command-line options do not work correctly, e.g.,
>
> irwin@raven> ./x00f -dev psttfc -o test.psc
>
> Bad command line option "test.psc"
> [....]

I noticed it too, when I tried it after sending the message. It always complains about the last option. I will check this.

>
> 2. Fix naming scheme for kind values so the examples (and more importantly user's
> programmes which are depending on plflt) can remain unchanged for backwards
> compatibility.  I have developed some detailed ideas in the way I want to do this, but
> instead of describing those in English I would like to present a commit instead that
> you could evaluate in detail for yourself.
>
Yes, it was pretty much ad hoc what I did to x00f.f90, I wanted to make sure it did not arcanely rely on the current style of binding.

> 3. Integrate these changes into our current build and test scheme.
> Again, I would be happy to take responsibility for this.
>

Again, the main reason for doing it that way was to make sure that no traces of the current style were left. I built the program in a separate directory with a copy of just the C library.

> In sum, I suggest we continue from this good start on the new Fortran binding topic
> with you taking responsibility for topic 1 and me taking responsibility for topics 2 and
> 3 above.
>
> Of course, if I am going to contribute to this development I do need git access to your
> private topic branch work using the usual "git format-patch" and "git am" method that
> is described in README.developers. So for now I suggest your first priority would
> be to present exactly what you have given us here as a tarball in "git format-patch"
> form instead with no further changes (except possibly not including the x00f.f90
> change since I would just revert that, see above).  And that solid git start with just
> your present work and no further except possibly excluding the x00f.f90 change
> would allow us to develop this private topic from there. Of course, I am aware you
> have had some problems with using "git format-patch" in the past, but if those
> continue let me know here or off list, and I think I should be able to give you an exact
> cookbook of what to do to get started.
>
Whenever I need to update the source tree or commit my changes, I follow the cookbook to the letter - that way it works for me. So, maybe indeed an update of the cookbook is required, but we will see.

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] A possible design of our new Fortran binding

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> However, there are three things we should fix before expanding this further.
>
> 1. Fix plsparseopts
> > -        I have not tested this with command-line arguments yet - that is the trickier
> part of the code.
>
> In fact, it turns out command-line options do not work correctly, e.g.,
>
> irwin@raven> ./x00f -dev psttfc -o test.psc
>
> Bad command line option "test.psc"
> [....]
>
A dumb little error on my part:

The line

        ptr_arg = c_loc( arg(iargs) )

should have been:

        ptr_arg(iargs) = c_loc( arg(iargs) )

With the original (erroneous) line all the elements of the array ptr_arg are set to the address of the last option.

I have fixed that now and am working to incorporate all this in a separate branch. On to the patch after that.

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] A possible design of our new Fortran binding

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Of course, if I am going to contribute to this development I do need git access to your
> private topic branch work using the usual "git format-patch" and "git am" method that
> is described in README.developers. So for now I suggest your first priority would
> be to present exactly what you have given us here as a tarball in "git format-patch"
> form instead with no further changes (except possibly not including the x00f.f90
> change since I would just revert that, see above).  And that solid git start with just
> your present work and no further except possibly excluding the x00f.f90 change
> would allow us to develop this private topic from there. Of course, I am aware you
> have had some problems with using "git format-patch" in the past, but if those
> continue let me know here or off list, and I think I should be able to give you an exact
> cookbook of what to do to get started.
>
I must be overlooking something, because whatever I do with "git format-patch" it invariably produces no patch at all.

I have made my changes on a separate branch, tried to produce a patch file (nothing happened) committed them to the local repository and tried to produce a patch file (nothing continued to happen).

What am I doing wrong? Using options like "HEAD" does not work either.

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] A possible design of our new Fortran binding

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

On 2015-05-25 12:38-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> Of course, if I am going to contribute to this development I do need git access to your
>> private topic branch work using the usual "git format-patch" and "git am" method that
>> is described in README.developers. So for now I suggest your first priority would
>> be to present exactly what you have given us here as a tarball in "git format-patch"
>> form instead with no further changes (except possibly not including the x00f.f90
>> change since I would just revert that, see above).  And that solid git start with just
>> your present work and no further except possibly excluding the x00f.f90 change
>> would allow us to develop this private topic from there. Of course, I am aware you
>> have had some problems with using "git format-patch" in the past, but if those
>> continue let me know here or off list, and I think I should be able to give you an exact
>> cookbook of what to do to get started.
>>
> I must be overlooking something, because whatever I do with "git format-patch" it invariably produces no patch at all.
>

> I have made my changes on a separate branch, tried to produce a patch file (nothing happened) committed them to the local repository
> and tried to produce a patch file (nothing continued to happen).

Hi Arjen:

I assume from what you said above that your current situation is a
master branch (presumably the same as the one at SF, but if you are
behind in updating that with the SF variant it doesn't matter) and
private branch (let's call it f95update) that is identical to the
master branch except that the f95update branch has some extra commits.
To verify that situation use the "git log --oneline" command, e.g.,

git log --oneline -4 master
git log --oneline -7 f95update

which respectively show the last 4 commits in master and
last 7 commits in f95update where you specified 7 because
you were pretty sure there were 3 extra commits in the f95update branch.

So let's assume those commands show you that your situation is

master: ... A-B-C
                  \ 
f95update:        D-E-F

where D-E-F are the extra commits you want to package with
format-patch.

Then from "git help format-patch" I would try

git checkout f95update
git format-patch master

where "master" refers to the commit ID C at the tip of the master
branch where you branched f95update from master.

For a more complicated example, suppose you have kept up with
ordinary development from the rest of us and updated the master
branch after you created f95update.

Then the situation has changed to

master: ... A-B-C-R-S-T-U-V-W-X-Y-Z
                  \ 
f95update:        D-E-F

In this case to collect D-E-F in a format patch you simply run

git checkout f95update
git format-patch D^

where D^ is notation for the ancestor of D which is the same as C.  Or
you also have the option of rebasing so you end up effectively with

master: ... A-B-C-R-S-T-U-V-W-X-Y-Z
                                    \ 
f95update:                          G-H-I

where I have used different letters for the 3 extra commits to show
that the rebase has changed those commits (since each commit refers to
a complete file system snapshot) from what they were before.  But in
this case

git checkout f95update
git format-patch G^

would give you the same patch file (except for the commit identity
associated with each of the 3 commits) that you produced before.

I hope these examples help to clarify what goes on with git
format-patch, but the principal message I want you to take away from
this is always to use "git help <commandname>" first whenever you are
having trouble figuring out the syntax of some git command.

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] A possible design of our new Fortran binding

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

On 2015-05-25 09:33-0700 Alan W. Irwin wrote:

> Or
> you also have the option of rebasing so you end up effectively with
>
> master: ... A-B-C-R-S-T-U-V-W-X-Y-Z
>                                    \
> f95update:                          G-H-I
>
> where I have used different letters for the 3 extra commits to show
> that the rebase has changed those commits (since each commit refers to
> a complete file system snapshot) from what they were before.  But in
> this case
>
> git checkout f95update
> git format-patch G^
>
> would give you the same patch file (except for the commit identity
> associated with each of the 3 commits) that you produced before.

Oops.  I should have added the same patch file would be produced
assuming the rebase process is a clean one (i.e., there are no conflicts
to resolve between your changes and the additional changes done by
rebasing on master).

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] A possible design of our new Fortran binding

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

Hi Alan,



Right, that worked, that is: I updated the repository first, changed to the new branch and then applied my changes. So "git format-patch master" did the trick. I must have overlooked that possibility in the man page - it describes the options in extenso, but I did not see this one. Anyway, the patches are attached.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, May 25, 2015 6:33 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: A possible design of our new Fortran binding
>
> On 2015-05-25 12:38-0000 Arjen Markus wrote:
>
> > Hi Alan,
> >
> >
> >
> >> -----Original Message-----
> >> From: Alan W. Irwin [mailto:ir...@be...]
> >>
> >> Of course, if I am going to contribute to this development I do need
> >> git access to your private topic branch work using the usual "git
> >> format-patch" and "git am" method that is described in
> >> README.developers. So for now I suggest your first priority would be to present
> exactly what you have given us here as a tarball in "git format-patch"
> >> form instead with no further changes (except possibly not including
> >> the x00f.f90 change since I would just revert that, see above).  And
> >> that solid git start with just your present work and no further
> >> except possibly excluding the x00f.f90 change would allow us to
> >> develop this private topic from there. Of course, I am aware you have
> >> had some problems with using "git format-patch" in the past, but if
> >> those continue let me know here or off list, and I think I should be able to give you
> an exact cookbook of what to do to get started.
> >>
> > I must be overlooking something, because whatever I do with "git format-patch" it
> invariably produces no patch at all.
> >
>
> > I have made my changes on a separate branch, tried to produce a patch
> > file (nothing happened) committed them to the local repository and tried to produce
> a patch file (nothing continued to happen).
>
> Hi Arjen:
>
> I assume from what you said above that your current situation is a master branch
> (presumably the same as the one at SF, but if you are behind in updating that with
> the SF variant it doesn't matter) and private branch (let's call it f95update) that is
> identical to the master branch except that the f95update branch has some extra
> commits.
> To verify that situation use the "git log --oneline" command, e.g.,
>
> git log --oneline -4 master
> git log --oneline -7 f95update
>
> which respectively show the last 4 commits in master and last 7 commits in
> f95update where you specified 7 because you were pretty sure there were 3 extra
> commits in the f95update branch.
>
> So let's assume those commands show you that your situation is
>
> master: ... A-B-C
>                   \
> f95update:        D-E-F
>
> where D-E-F are the extra commits you want to package with format-patch.
>
> Then from "git help format-patch" I would try
>
> git checkout f95update
> git format-patch master
>
> where "master" refers to the commit ID C at the tip of the master branch where you
> branched f95update from master.
>
> For a more complicated example, suppose you have kept up with ordinary
> development from the rest of us and updated the master branch after you created
> f95update.
>
> Then the situation has changed to
>
> master: ... A-B-C-R-S-T-U-V-W-X-Y-Z
>                   \
> f95update:        D-E-F
>
> In this case to collect D-E-F in a format patch you simply run
>
> git checkout f95update
> git format-patch D^
>
> where D^ is notation for the ancestor of D which is the same as C.  Or you also have
> the option of rebasing so you end up effectively with
>
> master: ... A-B-C-R-S-T-U-V-W-X-Y-Z
>                                     \
> f95update:                          G-H-I
>
> where I have used different letters for the 3 extra commits to show that the rebase
> has changed those commits (since each commit refers to a complete file system
> snapshot) from what they were before.  But in this case
>
> git checkout f95update
> git format-patch G^
>
> would give you the same patch file (except for the commit identity associated with
> each of the 3 commits) that you produced before.
>
> I hope these examples help to clarify what goes on with git format-patch, but the
> principal message I want you to take away from this is always to use "git help
> <commandname>" first whenever you are having trouble figuring out the syntax of
> some git command.
>
> 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] A possible design of our new Fortran binding

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

On 2015-05-25 17:08-0000 Arjen Markus wrote:

> Hi Alan,

> Right, that worked, that is: I updated the repository first, changed
to the new branch and then applied my changes. So "git format-patch
master" did the trick. I must have overlooked that possibility in the
man page - it describes the options in extenso, but I did not see this
one. Anyway, the patches are attached.

Hi Arjen:

I request two changes in the results:

1. Please use the --stdout option to git format-patch.  That allows
you to store the result in one file rather than a series of them.

2. Base your topic branch on work that is available to me from the SF
repository.  The reason I mention this is the files you deleted were not clean.  They had some local changes
you had made before deleting them so that applying the patches
here failed.  Here is an example, where I edited your deleted file
patch to remove all the starting "-" characters so that it should
have been identical with the file to be deleted.  Instead, I
got this diff between the two results:

--- /tmp/test_software	2015-05-25 12:34:54.203951576 -0700
+++ bindings/f95/plstubs.h	2015-03-19 15:39:24.030125232 -0700
@@ -194,7 +194,7 @@
  #define    PLCTIME                   FNAME( PLCTIME, plctime )
  #define    PLEND                     FNAME( PLEND, plend )
  #define    PLEND1                    FNAME( PLEND1, plend1 )
-#define    PLENV                     FNAME( PLENVF95, plenvf95 )
+#define    PLENV                     FNAME( PLENV, plenv )
  #define    PLENV0                    FNAME( PLENV0, plenv0 )
  #define    PLEOP                     FNAME( PLEOP, pleop )
  #define    PLERRX                    FNAME( PLERRXF95, plerrxf95 )
@@ -241,7 +241,7 @@
  #define    PLIMAGEFR17               FNAME( PLIMAGEFR17, plimagefr17 )
  #define    PLIMAGEFR27               FNAME( PLIMAGEFR27, plimagefr27 )
  #define    PLIMAGEFR7                FNAME( PLIMAGEFR7, plimagefr7 )
-//#define    PLINIT                    FNAME( PLINIT, plinit )
+#define    PLINIT                    FNAME( PLINIT, plinit )
  #define    PLJOIN                    FNAME( PLJOIN, pljoin )
  #define    PLLAB7                    FNAME( PLLAB7, pllab7 )
  #define    PLLEGEND_CNV_TEXT         FNAME( PLLEGEND07_CNV_TEXT, pllegend07_cnv_text )

That is you had made a local change to the PLENV definition and
commented out the PLINT definition before deleting plstubs.h.  I am
pretty sure the "git rm" command would have complained about your
local uncommitted changes to plstubs.h.  The only explanation I can
think of is you are basing your current work on top of your previous
f95-update work and then using git format-patch to extract just the
latest few commits from the long range of commits from that older
private work.  Instead, you should start fresh and base your private
f95_update tree on the current SF version of the master branch and
then add your commits to that fresh f95_update tree before sending
them to me in git format-patch form.

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] A possible design of our new Fortran binding

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Hi Arjen:
>
> I request two changes in the results:
>
> 1. Please use the --stdout option to git format-patch.  That allows you to store the
> result in one file rather than a series of them.
>
Clear, I was a bit surprised seeing these two files myself.

> 2. Base your topic branch on work that is available to me from the SF repository.
> The reason I mention this is the files you deleted were not clean.  They had some
> local changes you had made before deleting them so that applying the patches here
> failed.  Here is an example, where I edited your deleted file patch to remove all the
> starting "-" characters so that it should have been identical with the file to be deleted.
> Instead, I got this diff between the two results:
>
While these changes are irrelevant, that is indeed annoying. I will have to take more care with 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] floating point exception in example 29

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

On 2015-05-12 09:41-0400 Hazen Babcock wrote:

>>
>> On 05/11/2015 06:05 PM, Alan W. Irwin wrote:
>>>
>>> Hi Hazen:
>>>
>>> I am glad to hear you have created a topic branch that catches
>>> floating point exceptions.  However, I am not keen on pulling a PLplot
>>> topic branch from github for the reasons discussed in
>>> README.developers.  So could you either share your topic branch using
>>> "git format-patch" or else just push it to our official repo yourself?
>>> The former is preferred if the work is incomplete (i.e., does not
>>> include a cmake option to control when the PLPLOT_ENABLE_FLOAT_EXCEPT
>>> macro is #defined). Furthermore, if the work is incomplete, I can
>>> finish the cmake aspects of it as promised above and amend your commit
>>> accordingly.
>>>
>>> Once we have implemented an option to check for floating-point
>>> exceptions, then that means any of us should be able to confirm the
>>> ones you have found and find others in the future due to the continued
>>> evolution of our examples.  And, of course, this option should allow
>>> us to fix those floating-point exceptions as time permits.
>>
>> Hi Alan,
>>
>> Sorry, that branch was not meant for incorporation into PLplot which is
>> why I did not follow accepted protocols. I thought it might make it
>> easier for others to see the floating point exception problem for these
>> 3 examples.
>>
>> I think we can enable floating point exception trapping more easily
>> using the -ffpe-trap option provided by gfortran. This won't require us
>> to mark up all of our C examples, though we might instead need to check
>> that the fortran compiler is gfortran?
>>
>> https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html
>>
>> -ffpe-trap=invalid,zero,overflow,underflow
>>
>> Compiling PLplot with this fortran flag (CMAKE_Fortran_FLAGS) "worked"
>> for me in that it core dumps on the fortran equivalents of the C
>> examples I mentioned above. I've attached my CMakeCache.txt file.
>>
>> -Hazen
>
> 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.

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.

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
__________________________