plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Fortran callback progress

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, March 14, 2016 9:23 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Fortran callback progress
>
>
> I also just asked you in another e-mail for similar report tarballs for the pure Cygwin
> and pure MinGW-w64/MSYS2 platforms.  You may have already run the desired
> simple comprehensive Fortran test on those platforms, but I need to see the report
> tarball in each case as well.
>
I attach the tarball for Cygwin 64 bits - the test was unsuccessful, as pltcl crashed running example x00. The strange thing is: I can run it manually without any problem.

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] Your recent commit 8c4fb79 = "Add allocate statements to prevent problems if allocate-on-assign not supported by default"

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

On 2016-03-14 01:13-0700 Alan W. Irwin wrote:

> As you know, after I have finally finished the current documentation
update [....]

P.S.  As you have probably noticed from the git feed I have been
making some progress with that documentation upgrade. For example, all
C callback types are now properly documented for the first time in a
table in the C chapter.  So my next documentation upgrade steps are to
refer to that table of C types wherever relevant in the documentation,
e.g., in the starting paragraphs of the api chapter and also wherever
in that chapter PLplot C callback types are being used as arguments.
I also need to add a table in the Fortran chapter concerning the
Fortran callback types, and I need to completely update the special
chapter on the special Fortran API. (Or maybe remove it altogether
if it is, as I suspect, completely dated/nonrelevant.)

Anyhow, there is still obviously quite a bit I still plan to do on the
documentation front, but hopefully in the next few days I can get that
all done to clear the way for the planned appeal to users to test our
new Fortran binding.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Fortran callback progress

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, March 14, 2016 9:23 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Fortran callback progress
>
> On 2016-03-14 07:35-0000 Arjen Markus wrote:
>
> > If you want I can send you the tar file with all details of the
> process [comprehensive test of MSVC/ifort/nmake], but I am particularly puzzled by
> the message from the linker that it knows no option "s" and what is more the Intel
> Fortran compiler is invoked with an option "-o name-of-executable", which is not the
> proper option to set the name of the executable (it should be -exe:name-of-
> executable).
>
> Yes please on sending the report tarball for your MSVC/ifort/nmake comprehensive
> test to this list as a mail attachment.  If I cannot figure out anything from that report
> tarball someone else here might be able to do so.
>

See the attachment.

> I also just asked you in another e-mail for similar report tarballs for the pure Cygwin
> and pure MinGW-w64/MSYS2 platforms.  You may have already run the desired
> simple comprehensive Fortran test on those platforms, but I need to see the report
> tarball in each case as well.
>

Will do.

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

Re: [Plplot-devel] Fortran callback progress

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

On 2016-03-14 07:35-0000 Arjen Markus wrote:

> If you want I can send you the tar file with all details of the
process [comprehensive test of MSVC/ifort/nmake], but I am particularly puzzled by the message from the linker
that it knows no option "s" and what is more the Intel Fortran
compiler is invoked with an option "-o name-of-executable", which is
not the proper option to set the name of the executable (it should be
-exe:name-of-executable).

Yes please on sending the report tarball for your MSVC/ifort/nmake
comprehensive test to this list as a mail attachment.  If I cannot
figure out anything from that report tarball someone else here might
be able to do so.

I also just asked you in another e-mail for similar report tarballs
for the pure Cygwin and pure MinGW-w64/MSYS2 platforms.  You may have
already run the desired simple comprehensive Fortran test on those
platforms, but I need to see the report tarball in each case as well.

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] Your recent commit 8c4fb79 = "Add allocate statements to prevent problems if allocate-on-assign not supported by default"

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

Hi Arjen:

Your recent Fortran fix referred to in the subject line looks good here.  I tested it with

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

here on Debian jessie, and the result was perfect PostScript
difference results for Fortran versus C for the 12 noninteractive
tests that are run by that script.

I have summarized that good result in the new table at
<http://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Reports>
which is designed to keep track of simple limited Fortran test results (like above) of
the new Fortran binding.

As you know, after I have finally finished the current documentation update and
uploaded that result to our website I
plan to appeal to our users to test our new Fortran binding.  As part
of that appeal I will refer to the comprehensive test results we have
accumulated in the above table so if you could run similar limited
Fortran tests with the above options on your Cygwin and
MinGW-w64/MSYS2 platforms, and send the report tarballs to me so I
could add your results to mine in the above table, that would be a big
immediate help.

And if after reporting those two tests to me you also could figure out
how to put Cygwin bash on your PATH and run the same comprehensive
test script (with the same limiting options) on MSVC/ifort with the
"NMAKE Makefiles" generator that would be a really worthwhile result
as well.

However, nobody has tried this theoretical possibility for
comprehensive testing of PLplot on the MSVC/ifort platform after your
unsuccessful attempt several years ago where you ran into problems
with setting the PATH for bash.  But I think you may know a lot more
about how to set the PATH now so I think this possibility is probably
worth a quick look again.

Note, one of my ToDo list items is to fix all "space in pathname" issues
for source tree, build tree, and install tree, but I haven't done that
yet so for now only use unspaced pathnames for those three trees in your
comprehensive tests.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Fortran callback progress

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, March 05, 2016 1:11 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Fortran callback progress
>
> On 2016-03-04 14:33-0800 Alan W. Irwin wrote:
>
> > For convenient complete testing of Fortran while avoiding additional
> > testing of other components of PLplot I would recommend running
> >
> > scripts/comprehensive_test.sh --cmake_added_options
> > "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -
> DDEFAULT_NO_BINDINGS=ON
> > -DENABLE_f95=ON -DPL_DOUBLE=OFF" --do_test_interactive no
>
> Oops!  That option should read -DPL_DOUBLE=ON or else don't specify -
> DPL_DOUBLE at all (since ON is the default).
>
Alas, I tried that this weekend: somehow CMake gets confused. I have stared at the error messages, but I can make heads nor tails of the cause.

Here is what I did:

1.     I added the directory containing MinGW-w64's sh.exe to the path, so that the shell script would be run properly

2.     I invoked the script like this:

../plplot-git/scripts/comprehensive_test.sh --generator_string "NMake Makefiles" --do_clean_as_you_go yes --do_test_interactive no --do_test_traditional_install_tree yes --cmake_added_options "-DTCL_INCLUDE_PATH=/usr/include" --cmake_added_options "-DENABLE_ada=OFF -DENABLE_octave=OFF" --do_ctest no --build_command "nmake" --cmake_added_options "-DCMAKE_Fortran_COMPILER=ifort"

to make sure the Intel Fortran compiler is selected ("NMake Makefiles" was not enough). It took some experimenting ;).

The error report shows the confusion:

-- The Fortran compiler identification is unknown

-- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe

-- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe  -- broken

CMake Error at D:/cmake3.4.3/share/cmake-3.4/Modules/CMakeTestFortranCompiler.cmake:54 (message):

  The Fortran compiler "C:/Program Files (x86)/Intel/Composer XE

  2015/bin/intel64/ifort.exe" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: D:/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/CMakeFiles/CMakeTmp

  Run Build Command:"nmake" "/NOLOGO" "cmTC_a824d\fast"

            "C:\Program Files (x86)\Microsoft Visual Studio

  12.0\VC\BIN\amd64\nmake.exe" -f CMakeFiles\cmTC_a824d.dir\build.make

  /nologo -L CMakeFiles\cmTC_a824d.dir\build

  Building Fortran object

  CMakeFiles/cmTC_a824d.dir/testFortranCompiler.f.obj

            C:\PROGRA~2\Intel\COMPOS~4\bin\intel64\ifort.exe -c

  D:\plplot-svn\comprehensive_test_disposeable\shared\noninteractive\build_tree\CMakeFiles\CMakeTmp\testFortranCompiler.f

  -o CMakeFiles\cmTC_a824d.dir\testFortranCompiler.f.obj

  Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on

  Intel(R) 64, Version 15.0.1.148 Build 20141023

  Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

  Linking Fortran executable cmTC_a824d.exe

            C:\PROGRA~2\Intel\COMPOS~4\bin\intel64\ifort.exe

  "CMakeFiles\cmTC_a824d.dir\testFortranCompiler.f.obj" -o cmTC_a824d.exe

  Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on

  Intel(R) 64, Version 15.0.1.148 Build 20141023

  Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

  link: unknown option -- s

  Try 'link --help' for more information.

  NMAKE : fatal error U1077:

  'C:\PROGRA~2\Intel\COMPOS~4\bin\intel64\ifort.exe' : return code '0x1'

  Stop.

  NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio

  12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'

  Stop.

  CMake will not be able to correctly generate this project.

Call Stack (most recent call first):

  cmake/modules/fortran.cmake:44 (enable_language)

  cmake/modules/plplot.cmake:481 (include)

  CMakeLists.txt:136 (include)

(several empty lines eluded)

If you want I can send you the tar file with all details of the process, but I am particularly puzzled by the message from the linker that it knows no option "s" and what is more the Intel Fortran compiler is invoked with an option "-o name-of-executable", which is not the proper option to set the name of the executable (it should be -exe:name-of-executable).

Anyway, I concluded that that was not a viable route.

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] Recently introduced Tcl regressions for examples 15 and 18

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, March 14, 2016 7:46 AM
> To: Arjen Markus; PLplot development list
> Subject: Re: Recently introduced Tcl regressions for examples 15 and 18
>
> On 2016-03-08 10:52-0800 Alan W. Irwin wrote:
>
> > However, for master tip there are still two remaining issues from your
> > commit which are the following PostScript difference regressions from
> > the perfect Tcl PostScript differences I obtained in January:
> >
> > tcl
> >  Missing examples            :
> >  Differing graphical output  :  15 18
> >  Missing stdout              :
> >  Differing stdout            :
>
> Hi Arjen:
>
> A run of
>
> scripts/comprehensive_test.sh --cmake_added_options "-
> DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -
> DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON -DENABLE_tcl=ON" --
> do_test_interactive no
>
> confirms your recent git commit (1183a10 = "Solve issues with the redacted form of
> the Tcl API") got rid of those regressions, i.e., we now have perfect PostScript
> comparisons between Tcl and C results again for all 12 sets of comparisons (ctest
> + 3 separate "test_noninteractive" target builds for each of our three principal
> configurations) that are done as part of the comprehensive tests.
>
> Thanks!
>
Wonderful to see this confirmation! That leaves one issue to be handled: I have not dared looking at that yet, as it is one of the obscure things regarding data in a DLL. That issue pops up with Tcl on bare Windows only. I will try and solve it this week (the easiest way is probably to use a special case for bare Windows, but a "universal" solution has my preference).

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] Recently introduced Tcl regressions for examples 15 and 18

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

On 2016-03-08 10:52-0800 Alan W. Irwin wrote:

> However, for master tip there are still two remaining issues from your
> commit which are the following PostScript difference regressions from
> the perfect Tcl PostScript differences I obtained in January:
>
> tcl
>  Missing examples            :
>  Differing graphical output  :  15 18
>  Missing stdout              :
>  Differing stdout            :

Hi Arjen:

A run of

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

confirms your recent git commit (1183a10 = "Solve issues with the
redacted form of the Tcl API") got rid of those regressions, i.e.,
we now have perfect PostScript comparisons between Tcl and C results
again for all 12 sets of comparisons (ctest + 3 separate
"test_noninteractive" target builds for each of our three principal
configurations) that are done as part of the comprehensive tests.

Thanks!

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

Sounds good. I will take a look at it

> On Mar 9, 2016, at 6:07 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> I have summarized the wingcc-relevant parts of this important thread at
> https://sourceforge.net/p/plplot/feature-requests/20/.
> 
> @Jim:
> 
> I have made you the owner of this feature request on the assumption
> (based on your historical interest in updating the wingcc device) that
> it will be you that implements it.  N.B. my writeup of this feature
> request was based on wikipedia-level information rather than
> experience so feel free to edit this feature request if you find any
> glaring errors in the current writeup.
> 
> 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...>]

I have summarized the wingcc-relevant parts of this important thread at
https://sourceforge.net/p/plplot/feature-requests/20/.

@Jim:

I have made you the owner of this feature request on the assumption
(based on your historical interest in updating the wingcc device) that
it will be you that implements it.  N.B. my writeup of this feature
request was based on wikipedia-level information rather than
experience so feel free to edit this feature request if you find any
glaring errors in the current writeup.

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] Recently introduced Tcl regressions for examples 15 and 18

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, March 08, 2016 7:52 PM
> To: Arjen Markus; PLplot development list
> Subject: Recently introduced Tcl regressions for examples 15 and 18
>
> Hi Arjen:
>
> Just before your recent holiday you committed a Tcl change to support redacted
> argument lists for all parts of the Tcl binding API that involved matrix arguments,
> but I reported back to you at the time that certain Tcl examples errored out at run
> time due to those changes.
>
> It turns out that report from me was a false alarm which I attribute to inconsistent
> build results cached by CMake.  Currently when I start with an empty build tree,
> configure PLplot with cmake, and then build the test_diff_psc target, the entire set
> of Tcl examples completes without any showstopper errors.  So that is a big relief
> and sorry for the noise about run-time errors for the Tcl examples!
>
> However, for master tip there are still two remaining issues from your commit which
> are the following PostScript difference regressions from the perfect Tcl PostScript
> differences I obtained in January:
>
> tcl
>    Missing examples            :
>    Differing graphical output  :  15 18
>    Missing stdout              :
>    Differing stdout            :
>
> I would appreciate it if you solved these regressions as a high priority the next time
> you have a chance to work on PLplot.
>
Okay, I have put that on my TODO list. There is also the matter of the linkage problem under bare Windows that requires looking into.

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] Development topics for the remainder of this release cycle + proposed release schedule for 5.12.0

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

I have been making steady progress of my list of things I want to get
done before PLplot-5.12.0 is released.  Currently I am working on a
big update to the DocBook documentation, and after that is completed
and uploaded to the website, I plan to call for widespread testing of
the new Fortran binding based on that updated documentation. However,
there is still quite a few more topics on my list other than those two
items so I plan to hold off declaring the freeze on merges of major
topics to master until one month from now.

So this continues to be a good opportunity for the rest of you to
merge in your own matured development topics to master. Here is a list
of such topics that I am aware of where I believe there is still a
chance for you to mature them during this release cycle rather than
waiting until after the release of 5.12.0.

Arjen: Tcl and Fortran fixes.

Phil: wxwidgets bug fixes (especially concerning the severe
inefficiency issue on Linux that I documented). Implementation of
uniform reporting of memory allocation errors using exit (as a
preliminary to the planned post-release implemention of a proper error
report system).  Once Phil has designed plmalloc, plcalloc, and
plrealloc, I would be willing to help with the editing work of
replacing all our current raw calls to malloc, calloc, and realloc
with those PLplot equivalents which treat errors in a uniform way
(currently with exit, but that should be convenient to update later
once the proper error report system has been implemented).

Jim: plmeta, plbuf, and wingcc fixes and implementation of his enhanced
wingcc device.

Jerry: fix Ada issues (the current PostScript differences for examples
8 and 19).

Both Jim and Jerry have told me off-list that merging a git topic
branch to master is still somewhat intimidating for them. To bypass
that issue for now I suggest you both proceed by simply sending
patches to this list.  Patches formatted by "git format-patch" would
be ideal (since that approach gives you automatic git credit for your
work in a standard way), but ordinary patches are still acceptable as
well if you are having trouble getting good results with the "git
format-patch" command.

Here is my proposed schedule for PLplot development leading up to the
5.12.0 release:

* In the next few days: Call for widespread testing of the new Fortran binding.

* In the next month: Lots of merges of matured work from all of us to the
master branch.

* 2016-04-09: Freeze for all but simple bug fixes and documentation
updates.

* In the month after the freeze date: Comprehensive testing on as many platforms as are accessible to us.

* 2016-05-07: Release of PLplot-5.12.0.

Please let me know if anyone has issues with this proposed schedule of
events leading up to the release of PLplot-5.12.0.

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] Recently introduced Tcl regressions for examples 15 and 18

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

Hi Arjen:

Just before your recent holiday you committed a Tcl change to support
redacted argument lists for all parts of the Tcl binding API that
involved matrix arguments, but I reported back to you at the time that
certain Tcl examples errored out at run time due to those changes.

It turns out that report from me was a false alarm which I attribute
to inconsistent build results cached by CMake.  Currently when I start
with an empty build tree, configure PLplot with cmake, and then build
the test_diff_psc target, the entire set of Tcl examples completes
without any showstopper errors.  So that is a big relief and sorry
for the noise about run-time errors for the Tcl examples!

However, for master tip there are still two remaining issues from your
commit which are the following PostScript difference regressions from
the perfect Tcl PostScript differences I obtained in January:

tcl
   Missing examples            :
   Differing graphical output  :  15 18
   Missing stdout              :
   Differing stdout            :

I would appreciate it if you solved these regressions as a high priority
the next time you have a chance to work on PLplot.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Fortran callback progress

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, March 05, 2016 1:11 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Fortran callback progress
>
> On 2016-03-04 14:33-0800 Alan W. Irwin wrote:
>
> > For convenient complete testing of Fortran while avoiding additional
> > testing of other components of PLplot I would recommend running
> >
> > scripts/comprehensive_test.sh --cmake_added_options
> > "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -
> DDEFAULT_NO_BINDINGS=ON
> > -DENABLE_f95=ON -DPL_DOUBLE=OFF" --do_test_interactive no
>
I tried whether adjusting the path could help with running the shell script. It seems to do the trick indeed, but I had no time to actually run the tests.

What I have done is a systematic testing and comparing of the various suboptions in examples x09f, x15f, x16f, x19f, x20f and x22f. Apart from two cases where the identity mapping is used and which give deliberately different scales, all the PostScript files were identical between these suboptions. So that is a confirmation that the interface variants are working fine. Mostly tested for Windows + Intel Fortran, as this is the critical platform (see my earlier remarks on implicit allocation). For example x19f I also used MinGW-w64/MSYS2, as that is currently the platform which includes Shapelib.

I did find one more case where implicit allocation was used, it popped up when I used one of the alternatives. Easy to correct. So this means I can commit these minor changes to the Fortran examples. Just trying to find a convenient moment :).

Regards,

Arjen



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

Re: [Plplot-devel] Fortran callback progress

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

On 2016-03-04 14:33-0800 Alan W. Irwin wrote:

> For convenient complete testing of Fortran while avoiding additional testing
> of other components of PLplot I would recommend running
>
> scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON -DPL_DOUBLE=OFF" --do_test_interactive no

Oops!  That option should read -DPL_DOUBLE=ON or else don't specify
-DPL_DOUBLE at all (since ON is the default).

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Fortran callback progress

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

On 2016-03-04 07:59-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> I have tested the latest version of the Fortran examples on three Windows platforms (all 64-bits but not yet in all details, that is not for all examples I have tried all API variants). For Cygwin and MinGW-w64 I found no problems, but I did for bare Windows with Intel Fortran. I first feared for some obscure bug in the way we deal with callbacks and such, but it turned out to be a feature (or quirk, if you like) of Intel Fortran.
>
>
>
> The Fortran 2003 standard says that allocatable arrays that appear on the left-hand side of an assignment are automatically (re)allocated if necessary. For Intel Fortran this behaviour requires an explicit compiler option (-assume:lhs_realloc). Since this is not included in our build scripts, the examples that use this fail. In my private repository I have added the explicit allocation statements and that gives correct results (at least as far as the my eyes are concerned - I need to formally verify it by comparing output files).
>
>
>
> Anyway, the message at this moment is: the Fortran binding is doing fine on the mentioned platforms and I need to make a few small changes to the examples (the allocate statements and a comment about why they are used).
>
>
>
> Some more extensive tests are required, but things are looking quite good.

Hi Arjen:

I am glad your preliminary Fortran tests are going well on all three
platforms.

For convenient complete testing of Fortran while avoiding additional testing
of other components of PLplot I would recommend running

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

on the Cygwin and MinGW-w64/MSYS2 platforms.

In theory, if you take care with your PATH setup (e.g., so that
bash.exe from Cygwin or MinGW-w64/MSYS2 was on your PATH), then that
same script (with the additional options --generator_string "NMake
Makefiles" --build_command nmake) _should_ also work for the MSVC
case. But if you cannot get that script to work on MSVC, then you
should at minimum run all 33 Fortran examples by hand for the MSVC
case to help find all cases where automatic allocation needs to
be replaced by explicit allocation.

Thanks for your heads-up that the Intel compiler does not support
automatic allocation by default.  Probably most/all of those automatic
allocations were introduced by my changes since once I discovered
gfortran supported that Fortran 2003 feature by default, I incorrectly
assumed the other Fortran compilers would as well.  Anyhow, your
solution of using explicit allocations is obviously what should be
done here to work around this Intel compiler deficiency, and I look
forward to your commit to that effect once you find all the instances
of automatic allocations in our Fortran examples.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Fortran callback progress

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

Hi Alan,



I have tested the latest version of the Fortran examples on three Windows platforms (all 64-bits but not yet in all details, that is not for all examples I have tried all API variants). For Cygwin and MinGW-w64 I found no problems, but I did for bare Windows with Intel Fortran. I first feared for some obscure bug in the way we deal with callbacks and such, but it turned out to be a feature (or quirk, if you like) of Intel Fortran.



The Fortran 2003 standard says that allocatable arrays that appear on the left-hand side of an assignment are automatically (re)allocated if necessary. For Intel Fortran this behaviour requires an explicit compiler option (-assume:lhs_realloc). Since this is not included in our build scripts, the examples that use this fail. In my private repository I have added the explicit allocation statements and that gives correct results (at least as far as the my eyes are concerned - I need to formally verify it by comparing output files).



Anyway, the message at this moment is: the Fortran binding is doing fine on the mentioned platforms and I need to make a few small changes to the examples (the allocate statements and a comment about why they are used).



Some more extensive tests are required, but things are looking quite good.



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] Deprecation of the MinGW/MSYS platform

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, March 02, 2016 9:26 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Deprecation of the MinGW/MSYS platform
>
> Hi Arjen:
>
> Sorry, I did not state what I meant very clearly. There is no doubt that distributions
> of free software such as Cygwin and MinGW-w64/MSYS2 provide free libraries that
> are soft dependencies of PLplot such as the pthread, shapelib, and qhull libraries;
> the Qt4 suite of libraries, the Pango/Cairo subset of the GTK+ suite of libraries,
> wxWidgets, etc.


Oh, I was not even thinking about these - I just saw the dependency and found it curious - it reminded me of Cygwin's DLLs. But the security issue is definitely an issue and more important than avoiding a single dependency somewhere.

>
> Therefore, I feel the proper way to deal with the inherent security issues for binary
> distribution is to let official distributions of free software handle that headache.  So I
> am pleased that Orion is packaging PLplot for Fedora, Andrew is doing the same
> thing on Debian (and indirectly on Debian derivatives such as Ubuntu).  Similarly,
> there are PLplot packaging efforts on most other Linux distributions, the principal
> Mac OS X distributions Fink, MacPorts, and Homebrew, and also the principal
> *BSD variants, FreeBSD, OpenBSD, and NetBSD.
>
> In contrast to that situation, my understanding is that both the Cygwin and MinGW-
> w64/MSYS2 platforms do not currently distribute PLplot.  To fix those important
> issues we need someone with access to those two platforms to become a packager
> for each of them.  Would you be willing to take on those two additional important
> roles?  I think that would be a time-consuming effort to start for you, but after that
> required initial burst of activity, I don't think it would take a major effort to maintain
> the Cygwin and MinGW-w64/MSYS2 packages for PLplot going forward.
>
> If it turns out you are interested in becoming the PLplot packager for either/both
> those distributions, I think the next steps would be to query the Cygwin and MSYS2
> mailing lists to find out exact details of how to become a packager of PLplot for
> those two distributions.
>


Getting PLplot into the collections of packages managed by Cygwin and MSYS2 definitely seems worthwhile and would solve a problem that we have discussed every so often over the years. I have no idea though what amount of time is to be invested and what kind of work it involves. I can find out though - I happen to know a contributor ;).

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] Deprecation of the MinGW/MSYS platform

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

On 2016-03-02 07:53-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Wednesday, March 02, 2016 1:20 AM
>> To: PLplot development list
>> Subject: [Plplot-devel] Deprecation of the MinGW/MSYS platform
>>
>> For a variety of reasons discussed below I think it is time (unless someone strongly
>> objects) for us to deprecate the MinGW/MSYS in favour of MinGW-w64/MSYS2
>> and other Windows alternatives.
>>
>> One advantage MinGW/MSYS can still claim is libraries such as PLplot built on that
>> platform are native Windows libraries and do not depend on any special dll such as
>> the Cygwin dll that is a required dependency for all software built on Cygwin.  But
>> that advantage is no longer unique to MinGW/MSYS because MinGW-w64/MSYS2
>> (a completely independent project with different developers than the ones who are
>> still supporting MinGW/MSYS) shares that same advantage.
>>

> I am not completely sure that programs built with MinGW-w64/MSYS2
are indeed independent of an installation of this platform. At least
they are not for a default build. I checked this with one of the C
examples: it requires LIBWINPTHREAD-1.DLL and LIBSHP-1.DLL (it seems
to be from the Shapelib library, so not a system DLL) to be present in
the path (of course you can include these in the PLplot distribution).

Hi Arjen:

Sorry, I did not state what I meant very clearly. There is no doubt
that distributions of free software such as Cygwin and MinGW-w64/MSYS2
provide free libraries that are soft dependencies of PLplot such as
the pthread, shapelib, and qhull libraries; the Qt4 suite of libraries, the
Pango/Cairo subset of the GTK+ suite of libraries, wxWidgets, etc.
The availability of those free libraries _with a uniform ABI_ (i.e., all
compiled with exactly the same compiler) is what
makes PLplot so powerful on those platforms.  But the distinction I
was trying to make between Cygwin and MinGW-w64/MSYS2 is the former
also requires an additional (fairly large) dll called cygwin.dll as a
PLplot library dependency while the latter has no such "special" dll
dependency requirement.

> It might be a good idea to find out if the reference to
LIBWINPTHREAD-1.DLL can be eliminated via a static version of that
library. Then I think the program will be entirely independent of the
MinGW-w64 installation. A first glance at the available static
libraries indicates that this is not impossible. It will be a matter
of finding the right compile/link switches.

If you link PLplot libraries with the static versions of all the
different MinGW-w64/MSYS2 libraries that are required for a powerful
PLplot, then you _could_ indeed distribute that powerful result
independent of MinGW-w64/MSYS2.  But I would advise you not to do that
because of all the security concerns implied by binary distribution.
For example, PLplot's reputation is not going to be enhanced if we by
accident (because of an undetected security intrusion on the machine
where we are building the binary version of PLplot) end up
distributing an attack vector to all users' machines.  And this is
true of all platforms and not just Windows.

Therefore, I feel the proper way to deal with the inherent security
issues for binary distribution is to let official distributions of
free software handle that headache.  So I am pleased that Orion is
packaging PLplot for Fedora, Andrew is doing the same thing on Debian
(and indirectly on Debian derivatives such as Ubuntu).  Similarly,
there are PLplot packaging efforts on most other Linux distributions,
the principal Mac OS X distributions Fink, MacPorts, and Homebrew, and
also the principal *BSD variants, FreeBSD, OpenBSD, and NetBSD.

In contrast to that situation, my understanding is that both the
Cygwin and MinGW-w64/MSYS2 platforms do not currently distribute
PLplot.  To fix those important issues we need someone with access to
those two platforms to become a packager for each of them.  Would you
be willing to take on those two additional important roles?  I think
that would be a time-consuming effort to start for you, but after that
required initial burst of activity, I don't think it would take a
major effort to maintain the Cygwin and MinGW-w64/MSYS2 packages for
PLplot going forward.

If it turns out you are interested in becoming the PLplot packager for
either/both those distributions, I think the next steps would be to
query the Cygwin and MSYS2 mailing lists to find out exact details of
how to become a packager of PLplot for those two distributions.

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] Deprecation of the MinGW/MSYS platform

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, March 02, 2016 1:20 AM
> To: PLplot development list
> Subject: [Plplot-devel] Deprecation of the MinGW/MSYS platform
>
> For a variety of reasons discussed below I think it is time (unless someone strongly
> objects) for us to deprecate the MinGW/MSYS in favour of MinGW-w64/MSYS2
> and other Windows alternatives.
>
> One advantage MinGW/MSYS can still claim is libraries such as PLplot built on that
> platform are native Windows libraries and do not depend on any special dll such as
> the Cygwin dll that is a required dependency for all software built on Cygwin.  But
> that advantage is no longer unique to MinGW/MSYS because MinGW-w64/MSYS2
> (a completely independent project with different developers than the ones who are
> still supporting MinGW/MSYS) shares that same advantage.
>
I am not completely sure that programs built with MinGW-w64/MSYS2 are indeed independent of an installation of this platform. At least they are not for a default build. I checked this with one of the C examples: it requires LIBWINPTHREAD-1.DLL and LIBSHP-1.DLL (it seems to be from the Shapelib library, so not a system DLL) to be present in the path (of course you can include these in the PLplot distribution).

It might be a good idea to find out if the reference to LIBWINPTHREAD-1.DLL can be eliminated via a static version of that library. Then I think the program will be entirely independent of the MinGW-w64 installation. A first glance at the available static libraries indicates that this is not impossible. It will be a matter of finding the right compile/link switches.

Apart from this: I agree that the MinGW/MSYS platform is not to be recommended, if only because of the severe lack of package management.

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] Deprecation of the MinGW/MSYS platform

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

For a variety of reasons discussed below I think it is time (unless
someone strongly objects) for us to deprecate the MinGW/MSYS in favour
of MinGW-w64/MSYS2 and other Windows alternatives.

One advantage MinGW/MSYS can still claim is libraries such as PLplot
built on that platform are native Windows libraries and do not depend
on any special dll such as the Cygwin dll that is a required
dependency for all software built on Cygwin.  But that advantage is no
longer unique to MinGW/MSYS because MinGW-w64/MSYS2 (a completely
independent project with different developers than the ones who are
still supporting MinGW/MSYS) shares that same advantage.

I have always had something of a negative view of the MinGW/MSYS
platform because it provided few of the PLplot soft prerequisite
libraries.  This substantial constraint has historically made PLplot
extremely limited on MinGW/MSYS with none of our best device drivers
available as a result. That is a big contrast with both the Cygwin and
MinGW-w64/MSYS2 platforms which supply essentially all PLplot soft
prerequisites making PLplot extremely powerful on those platforms.

Furthermore, I just plain don't like the MinGW/MSYS lack of quality
control on the packages they build.  The recent egregious example of
this (which was the motivation of this e-mail) is the gcc-4.9.3
release for MinGW/MSYS.  According to the release announcement by
Keith Marshall (who no longer uses Windows (!), but instead has
created this version using cross-compilation) this is an experimental
version that does not support either Posix threads or Ada due to other
long-standing issues with MinGW/MSYS.  However, despite these
"experimental" caveats this is the version MinGW/MSYS users
automatically download if they update their system, and as a result
complaints are beginning to trickle in about gcc no longer working on
this platform!

According to
<https://sourceforge.net/p/msys2/wiki/MSYS2%20introduction> "MSYS2 is
an independent rewrite of MSYS, based on modern Cygwin (POSIX
compatibility layer) and MinGW-w64 with the aim of better
interoperability with native Windows software."

>From Greg's good comprehensive test results on the MinGW-w64/MSYS2
platform, I think the MSYS2 developers have fulfilled this promise,
and meanwhile there continue to be the packaging issues like the one I
mentioned above for gcc on MinGW/MSYS.  Thus, it appears that
MinGW-w64/MSYS2 does a _much_ better job of implementing the original
idea behind MinGW/MSYS than MinGW/MSYS currently does, and it is
therefore time to deprecate the latter platform.  As a result I plan
to ignore MinGW/MSYS and emphasize only MinGW-w64/MSYS2, Cygwin, and
MSVC when calling for comprehensive testing of Windows platforms from
now on.  And from time to time I will likely put some "deprecated"
qualifiers into our wiki for pages that discuss PLplot on the
MinGW/MSYS platform.

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] Error report system plus thread safety

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

>
> @Phil: I assume with a lot of trouble (such as implementing more
> centralized control of our memory allocations) you could deal with
> resource leaks using the setjmp/longjmp approach, but for the above
> reason I don't think you should bother.

actually not that much trouble. We just have plmalloc keep a list of
all memory allocations in a variable in the PLStream and plfree can
remove items from that list. Then we have a free all function which
gets called before the API returns, which frees anything left on the
list. This not only deals with memory leaks after a longjmp, but if we
miss a free anywhere it will also clean up any other memory leaks. I
have already implemented it in the plmalloc/plfree functions I've
written. I'm just adding the calls and I will forward it round.

Phil

Re: [Plplot-devel] Error report system plus thread safety

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

On 2016-02-28 16:42-0000 Phil Rosenberg wrote:

> Do we do any other resource allocation other than memory? I guess we
> deal with files too, so that answer makes a good point that they need
> considering too.
> It's not quite just a goto. The registers are all reset too, so the
> stack pointer function pointer etc are all put back, but you are
> correct that the stack is left as it was so any allocated resources
> get left. They therefore need managing in a way that they can be freed
> when the plplot returns.
>
> What I really don't want to do here is obfuscate the code to the point
> where others are not happy to tinker with things. I'm starting to feel
> that there is a real risk of that. What I will do is set up a single
> API function to use setjmp and longjmp and I will send that around as
> a patch. If and only if there is consensus that people are happy with
> how this works then I will continue.

@Phil:

I think this cautious approach is a good initial plan but also note my
further comments below about the advantages below of simply ignoring
resource leaks.

> On 28 February 2016 at 03:47, Hazen Babcock <hba...@ma...> wrote:
>> Before you begin I would encourage you to read this:
>>
>> http://stackoverflow.com/questions/14685406/practical-usage-of-setjmp-and-longjmp-in-c
>>
>> Particularly the 2nd and 3rd answers. As they point out, this is *not* C++
>> exception handling in C, this is just a goto statement.

@Hazen:

The following quote from your reference

"So allocations, locks, half-initialized data structures, etc, are
still allocated, locked and half-initialized when you get back to
where setjmp was called."

is definitely a good point to remember. However, we are dealing in
each case (where plexit is currently called) with a showstopper PLplot
error where we want to call plend (as plexit currently does) to kill
the PLplot library, and then return control to the user's environment
rather than doing a raw exit.

Under these circumstances I think it is OK to be sloppy with regard to
left over memory allocations that are not already killed off by plend.
I suppose such memory and other resource leaks could be a problem if
the PLplot library was being initialized zillions of times by a user
with all error conditions ignored, but otherwise I don't think such
resource leaks from PLplot showstopper errors are that important an
issue.

For this reason I had no plans whatsoever to be careful to free memory
in routines that were propagating an error condition down the caller
map because that would make an already difficult editing task
substantially more difficult for not much (in my view) benefit.  So my
return code implementation would have been functionally equivalent to
longjmp.

@Phil: I assume with a lot of trouble (such as implementing more
centralized control of our memory allocations) you could deal with
resource leaks using the setjmp/longjmp approach, but for the above
reason I don't think you should bother.

@Phil and Hazen:

In sum, I think this is one of those cases where a search for
perfection is a substantial hindrance to progress.

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] Error report system plus thread safety

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

Do we do any other resource allocation other than memory? I guess we
deal with files too, so that answer makes a good point that they need
considering too.
It's not quite just a goto. The registers are all reset too, so the
stack pointer function pointer etc are all put back, but you are
correct that the stack is left as it was so any allocated resources
get left. They therefore need managing in a way that they can be freed
when the plplot returns.

What I really don't want to do here is obfuscate the code to the point
where others are not happy to tinker with things. I'm starting to feel
that there is a real risk of that. What I will do is set up a single
API function to use setjmp and longjmp and I will send that around as
a patch. If and only if there is consensus that people are happy with
how this works then I will continue.

Phil

On 28 February 2016 at 03:47, Hazen Babcock <hba...@ma...> wrote:
>
>
> On 02/27/2016 10:10 PM, Alan W. Irwin wrote:
>>
>> On 2016-02-27 23:22-0000 Phil Rosenberg wrote:
>>
>>> Perhaps it would be good for Hazen and Alan to start looking
>>
>> in more detail at implementing the error code propagation? If there
>> are tools to help with that, then maybe it will be easier than I
>> suspect.
>>
>> I am now confident of the return code method because of the
>> 'warn_unused_result' gcc attribute capability, but let's not even
>> start the substantial work required for this alternative unless it is
>> made necessary because you run into some showstopper issue with the C
>> exception-based alternative.
>
>
> Before you begin I would encourage you to read this:
>
> http://stackoverflow.com/questions/14685406/practical-usage-of-setjmp-and-longjmp-in-c
>
> Particularly the 2nd and 3rd answers. As they point out, this is *not* C++
> exception handling in C, this is just a goto statement. To me that would be
> a showstopper issue. However, who does the work decides, so if this approach
> is still your preference then I won't persist in trying to dissuade you.
>
> -Hazen

Re: [Plplot-devel] Error report system plus thread safety

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

On 02/27/2016 10:10 PM, Alan W. Irwin wrote:
> On 2016-02-27 23:22-0000 Phil Rosenberg wrote:
>
>> Perhaps it would be good for Hazen and Alan to start looking
> in more detail at implementing the error code propagation? If there
> are tools to help with that, then maybe it will be easier than I
> suspect.
>
> I am now confident of the return code method because of the
> 'warn_unused_result' gcc attribute capability, but let's not even
> start the substantial work required for this alternative unless it is
> made necessary because you run into some showstopper issue with the C
> exception-based alternative.

Before you begin I would encourage you to read this:

http://stackoverflow.com/questions/14685406/practical-usage-of-setjmp-and-longjmp-in-c

Particularly the 2nd and 3rd answers. As they point out, this is *not* 
C++ exception handling in C, this is just a goto statement. To me that 
would be a showstopper issue. However, who does the work decides, so if 
this approach is still your preference then I won't persist in trying to 
dissuade you.

-Hazen