plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Comprehensive testing: Cygwin

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

Hi Alan,



Here are the results for MinGW32/MSYS - this fails with the well-known problem of the example not finding the PLplot library. Actually: the progress of the testing script simply halts (as witnessed by there no additional messages being written to the output files) and the executable x00c.exe being in the list of processes without any activity.



Regards,



Arjen



From: Arjen Markus [mailto:Arj...@de...]
Sent: Saturday, April 18, 2015 3:09 PM
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] Comprehensive testing: Cygwin


Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Does this new robust logic for Windows detection now work for you?  (To make this
> test of PATH manipulation much faster for our three main configurations [shared,
> nondynamic, and static], I suggest you temporarily edit script.txt to drop all tests
> other than the test_noninteractive one in both the build tree and installed examples
> tree, using
>
> --do_ctest no
> --do_test_interactive no
> --do_test_traditional_install_tree no
>
> Please send back a full report (preferably with automatically generated tarball, see
> above) whether this test succeeds or not.
>
I used the new logic and it seems to have worked up to some point. See the attached tarball. The shared configuration worked fine, but the tests failed on the nondynamic one. (Not automated yet, but that is going to be my next step)

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.
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] Comprehensive testing: Cygwin

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Does this new robust logic for Windows detection now work for you?  (To make this
> test of PATH manipulation much faster for our three main configurations [shared,
> nondynamic, and static], I suggest you temporarily edit script.txt to drop all tests
> other than the test_noninteractive one in both the build tree and installed examples
> tree, using
>
> --do_ctest no
> --do_test_interactive no
> --do_test_traditional_install_tree no
>
> Please send back a full report (preferably with automatically generated tarball, see
> above) whether this test succeeds or not.
>
I used the new logic and it seems to have worked up to some point. See the attached tarball. The shared configuration worked fine, but the tests failed on the nondynamic one. (Not automated yet, but that is going to be my next step)

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] Wrestling library linkage experiments.

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

Hi Greg,



I am not sure I understand exactly what you are trying to achieve (and I have only briefly looked at your explanation of the background), but have a look at the Fortran bindings. Here we explicitly use a .def file to export the various routines. The thing is that such a .def file allows the specification of the name of the DLL _independently_ of the name of the produced import library. (I made a mistake not too long with that LIBRARY statement, hence I know that it works this way).



Of course this only works on platforms where a .def file is required, MinGW and Win32.



Regards,



Arjen



> -----Original Message-----
> From: Greg Jung [mailto:gv...@gm...]
> Sent: Friday, April 17, 2015 4:48 PM
> To: plp...@li...
> Subject: [Plplot-devel] Wrestling library linkage experiments.
>
> Hi guys,
>   I have one specific plplot question then I will give a lot of background info that I'm
> fairly certain would come up in the ensuing Q/A for the issue.  The foreground is, I'm
> building GDL on mingw32, GDL wants to (optionally) bring in  a number of  libraries
> to accomplish added functionalities.
>
> The Question:
>    How do I get a specially-named libplplot version to function?  I wish to have
> libplplot-v2.dll be the shared that libplplot.dll.a is an import for - built and held in a
> directory  separately specified.  A copy of libplplot-v2.dll is then kept in the runtime
> path alongside the standard versions libplplot.dll, libplplotcxx.dll, wingcc.dll, etc.
> v2 version is actually "nodyn" - all of the same source except dynamic drivers are not
> enabled.
>
> What I've been trying:
>   I'm using a semi-updated plplot distribution from git Oct 7, 2014.
> My first attempt was to use dlltool
> to create an import library libplplot.dll.a which hooked into libplplot-nodyn.dll, itself
> created by simply renaming.  The link attempt failed so I went to the build directory
> and basically changed all references libplplot.dll to libplplot-nodyn.dll
>
> cat build.make | sed 's/libplplot.dll/libplplot-nodyn.dll/g' | sed 's/libplplot-
> nodyn.dll.a/libplplot.dll.a/g'
>
> (except that I did this in a text editor)
>
> This result worked to be successfully linked (and loaded, verified via
> depends_x86.exe).
>   But it doesn't work.
> To see that the dysfunction is not in the code, I did the same procedure for the plplot
> version that was working, going to the original build directory, making a shareable;
> libplplot-sidyn.dll described by import library libplplot.dll.a - this didn't work, either.
>
> -----------------------
>
> background:
>
>   I'm running on windows 7 (64 bit).  32-bit compiles are done using gcc 4.9.2 built by
> msys2; its all posix, dwarf2.
>   In order to centralize the support libraries I keep those needed to run programs in
> c:/mingw/dll32-psxdw2 which is entered (via an NTFS junction) as c:/usr/lib32 below:
> PATH:
> C:\cmd:C:\cmd/bin:C:\usr/bin:C:\usr/bin32:C:\usr/bin32/mingw:C:\usr/lib32:C:\Windo
> ws/system32:C:\Windows:C:\Windows/System32/Wbem
>
> greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2 $ ls -la plplot11/bin total 1232
> drwxr-xr-x 1 greg None      0 Apr 17 06:04 .
> drwxr-xr-x 1 greg None      0 Apr 17 06:04 ..
> -rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll -rwxr-xr-x 1 greg None
> 188815 Apr 17 06:02 libplplotcxx.dll -rwxr-xr-x 1 greg None 512591 Apr 17 06:02
> libplplot-sidyn.dll -rwxr-xr-x 1 greg None 195307 Apr 17 06:02 libplplotwxwidgets.dll -
> rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll -rwxr-xr-x 1 greg None
> 107360 Apr 17 06:02 pltek.exe
>
>  /d/bld/mingw32-psxdw2$ ls -la plplot11-SAVE/bin total 1236
> drwxr-xr-x 1 greg None      0 Jan 28 16:53 .
> drwxr-xr-x 1 greg None      0 Apr 17 05:33 ..
> -rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll -rwxr-xr-x 1 greg None
> 512079 Jan 28 14:54 libplplot.dll -rwxr-xr-x 1 greg None 188803 Jan 28 14:54
> libplplotcxx.dll -rwxr-xr-x 1 greg None 195295 Jan 28 14:54 libplplotwxwidgets.dll -
> rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll -rwxr-xr-x 1 greg None
> 106848 Jan 28 14:55 pltek.exe
>
> and also, higher up the path, c:/usr/bin32, which keeps a hodge-podge of libraries I
> might be linking against for special reasons.
>
> $ ls -la /c/usr/bin32
> total 14580
> drwxr-xr-x 1 greg None        0 Apr 16 21:12 .
> drwxr-xr-x 1 greg None        0 Mar 30 14:57 ..
> -rwxr-xr-x 1 greg None 12328473 Mar 30 14:29 gdl.exe
> -rwxr-xr-x 1 greg None   203638 Apr  5 22:28 libcsironn.dll
> -rwxr-xr-x 1 greg None   186311 Apr  5 22:28 libplplotcxxd.dll
> -rwxr-xr-x 1 greg None   572150 Apr  5 22:28 libplplotd.dll
> -rwxr-xr-x 1 greg None  1107048 Apr 16 17:42 libplplot-nodyn.dll
> -rwxr-xr-x 1 greg None   512591 Apr 17 06:02 libplplot-sidyn.dll
> lrwxrwxrwx 1 greg None       12 Mar  7 19:51 mingw -> /mingw32/bin
>
>
> greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2 $ ls -la plplot11/bin total 1232
> drwxr-xr-x 1 greg None      0 Apr 17 06:04 .
> drwxr-xr-x 1 greg None      0 Apr 17 06:04 ..
> -rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll -rwxr-xr-x 1 greg None
> 188815 Apr 17 06:02 libplplotcxx.dll -rwxr-xr-x 1 greg None 512591 Apr 17 06:02
> libplplot-sidyn.dll -rwxr-xr-x 1 greg None 195307 Apr 17 06:02 libplplotwxwidgets.dll -
> rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll -rwxr-xr-x 1 greg None
> 107360 Apr 17 06:02 pltek.exe
>
> greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2 $ ls -la plplot11-SAVE/bin total
> 1236
> drwxr-xr-x 1 greg None      0 Jan 28 16:53 .
> drwxr-xr-x 1 greg None      0 Apr 17 05:33 ..
> -rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll -rwxr-xr-x 1 greg None
> 512079 Jan 28 14:54 libplplot.dll -rwxr-xr-x 1 greg None 188803 Jan 28 14:54
> libplplotcxx.dll -rwxr-xr-x 1 greg None 195295 Jan 28 14:54 libplplotwxwidgets.dll -
> rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll -rwxr-xr-x 1 greg None
> 106848 Jan 28 14:55 pltek.exe
>
> greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2 $ ls -la /c/mingw/dll32-psxdw2 |
> grep Jan\ 28
> -rwxr-xr-x 1 greg None   143271 Jan 28 14:54 cairo.dll
> -rwxr-xr-x 1 greg None   118558 Jan 28 14:54 libcsirocsa.dll
> -rwxr-xr-x 1 greg None   512079 Jan 28 14:54 libplplot.dll
> -rwxr-xr-x 1 greg None   188803 Jan 28 14:54 libplplotcxx.dll
> -rwxr-xr-x 1 greg None   195295 Jan 28 14:54 libplplotwxwidgets.dll
> -rwxr-xr-x 1 greg None   120392 Jan 28 14:54 libqsastime.dll
> -rwxr-xr-x 1 greg None    90308 Jan 28 14:54 mem.dll
> -rwxr-xr-x 1 greg None    82507 Jan 28 14:54 null.dll
> -rwxr-xr-x 1 greg None   120304 Jan 28 14:54 ps.dll
> -rwxr-xr-x 1 greg None   108182 Jan 28 14:54 svg.dll
> -rwxr-xr-x 1 greg None   114481 Jan 28 14:54 wingcc.dll
> -rwxr-xr-x 1 greg None   499063 Jan 28 14:55 wxwidgets.dll
> -rwxr-xr-x 1 greg None   100481 Jan 28 14:55 xfig.dll
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your
> own process in accordance with the BPMN 2 standard Learn Process modeling best
> practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=V
> A_SF
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

Re: [Plplot-devel] Comprehensive testing: Cygwin

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

Hi Arjen:

On 2015-04-17 13:24-0000 Arjen Markus wrote:

> Hi Alan,
>
>
> I hope this tarball is complete.

Yes it was and thanks!

However, I still advise you to modify scripts.txt to do everything you
did by hand to prepare the tarball to make it much easier for you to
report the problem the next time something goes wrong. Also, I would
appreciate complete reports when everything goes right as well.
Multiple benchmarks for good comprehensive test results from you are
useful for me to check regressions, and a subset of those will also be
useful for the purpose of Wiki test reports.

With regard to the current issue note the two critical lines in
comprehensive.out

This variable specifies whether any windows platform has been detected
ANY_WINDOWS_PLATFORM=false

That "false" result should be "true" on Cygwin meaning the script OS detection
logic failed on that platform.  That means no PATH manipulations
are done by the script ==> the errors you found subsequently.

I should have thoroughly tested that script logic for Windows
detection on MinGW/MSYS before committing it.  It turned out it worked
or not depending on exactly how the script was invoked, i.e., it was
extraordinarily fragile logic.  My apologies!

I have now discovered that the bash variable OSTYPE is what should be
used to determine OS robustly under bash (see discussion in
<http://stackoverflow.com/questions/394230/detect-the-os-from-a-bash-script>.
I have changed comprehensive_scripts.sh accordingly (commit id
02be839). And a test script with this same logic works on both Linux
and MinGW/MSYS regardless of how the test script is invoked.

Does this new robust logic for Windows detection now work for you?  (To make this test of PATH
manipulation much faster for our three main configurations [shared,
nondynamic, and static], I suggest you temporarily edit script.txt to
drop all tests other than the test_noninteractive one in both the
build tree and installed examples tree, using

--do_ctest no
--do_test_interactive no
--do_test_traditional_install_tree no

Please send back a full report (preferably with automatically generated
tarball, see above) whether this test succeeds or not.

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] [PATCH] OS X pkg-config.cmake error: string REGEX REPLACE needs 6 arguments

[J. L. M. <jl...@im...>]

Hello!

When configuring PLplot 5.11.0 from pkgsrc using my own pkgsrc plplot
package definition on OS X Yosemite using CMake 3.0.2, I get the
following error:

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

I think the problem is that the ${link_flags} argument is not quoted,
and if it's empty, then Cmake doesn't see it as an argument.  If I quote
it, then the configure succeeds.  Below is a patch against the 5.11.0
release.

Thank you!

Lewis

--- cmake/modules/pkg-config.cmake.orig	2015-04-12 10:08:04.000000000 +0000
+++ cmake/modules/pkg-config.cmake	2015-04-17 14:47:38.000000000 +0000
@@ -204,7 +204,7 @@
     "/System/Library/Frameworks/([^ ]*)\\.framework"
     "-framework \\1"
     link_flags
-    ${link_flags}
+    "${link_flags}"
     )
     #message("(frameworks) link_flags = ${link_flags}")
   endif(CMAKE_SYSTEM_NAME STREQUAL "Darwin")

[Plplot-devel] Wrestling library linkage experiments.

[Greg J. <gv...@gm...>]

Hi guys,
  I have one specific plplot question then I will give a lot of
background info that I'm fairly certain would come up in the ensuing
Q/A for the issue.  The foreground is, I'm building GDL on mingw32,
GDL wants to (optionally) bring in  a number of  libraries to
accomplish added functionalities.

The Question:
   How do I get a specially-named libplplot version to function?  I
wish to have libplplot-v2.dll be the shared that libplplot.dll.a is an
import for - built and held in a directory  separately specified.  A
copy of libplplot-v2.dll is then kept in the runtime path alongside
the standard versions libplplot.dll, libplplotcxx.dll, wingcc.dll,
etc.
v2 version is actually "nodyn" - all of the same source except dynamic
drivers are not enabled.

What I've been trying:
  I'm using a semi-updated plplot distribution from git Oct 7, 2014.
My first attempt was to use dlltool
to create an import library libplplot.dll.a which hooked into
libplplot-nodyn.dll, itself created by simply renaming.  The link
attempt failed so I went to the build directory and basically changed
all references libplplot.dll to libplplot-nodyn.dll

cat build.make | sed 's/libplplot.dll/libplplot-nodyn.dll/g' | sed
's/libplplot-nodyn.dll.a/libplplot.dll.a/g'

(except that I did this in a text editor)

This result worked to be successfully linked (and loaded, verified via
depends_x86.exe).
  But it doesn't work.
To see that the dysfunction is not in the code, I did the same
procedure for the plplot version that
was working, going to the original build directory, making a
shareable; libplplot-sidyn.dll described by import library
libplplot.dll.a - this didn't work, either.

-----------------------

background:

  I'm running on windows 7 (64 bit).  32-bit compiles are done using
gcc 4.9.2 built by msys2;
its all posix, dwarf2.
  In order to centralize the support libraries I keep those needed to
run programs in c:/mingw/dll32-psxdw2
which is entered (via an NTFS junction) as c:/usr/lib32 below:
PATH:
C:\cmd:C:\cmd/bin:C:\usr/bin:C:\usr/bin32:C:\usr/bin32/mingw:C:\usr/lib32:C:\Windows/system32:C:\Windows:C:\Windows/System32/Wbem

greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2 $ ls -la plplot11/bin
total 1232
drwxr-xr-x 1 greg None      0 Apr 17 06:04 .
drwxr-xr-x 1 greg None      0 Apr 17 06:04 ..
-rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll
-rwxr-xr-x 1 greg None 188815 Apr 17 06:02 libplplotcxx.dll
-rwxr-xr-x 1 greg None 512591 Apr 17 06:02 libplplot-sidyn.dll
-rwxr-xr-x 1 greg None 195307 Apr 17 06:02 libplplotwxwidgets.dll
-rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll
-rwxr-xr-x 1 greg None 107360 Apr 17 06:02 pltek.exe

 /d/bld/mingw32-psxdw2$ ls -la plplot11-SAVE/bin
total 1236
drwxr-xr-x 1 greg None      0 Jan 28 16:53 .
drwxr-xr-x 1 greg None      0 Apr 17 05:33 ..
-rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll
-rwxr-xr-x 1 greg None 512079 Jan 28 14:54 libplplot.dll
-rwxr-xr-x 1 greg None 188803 Jan 28 14:54 libplplotcxx.dll
-rwxr-xr-x 1 greg None 195295 Jan 28 14:54 libplplotwxwidgets.dll
-rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll
-rwxr-xr-x 1 greg None 106848 Jan 28 14:55 pltek.exe

and also, higher up the path, c:/usr/bin32, which keeps a hodge-podge
of libraries I might be linking against for special reasons.

$ ls -la /c/usr/bin32
total 14580
drwxr-xr-x 1 greg None        0 Apr 16 21:12 .
drwxr-xr-x 1 greg None        0 Mar 30 14:57 ..
-rwxr-xr-x 1 greg None 12328473 Mar 30 14:29 gdl.exe
-rwxr-xr-x 1 greg None   203638 Apr  5 22:28 libcsironn.dll
-rwxr-xr-x 1 greg None   186311 Apr  5 22:28 libplplotcxxd.dll
-rwxr-xr-x 1 greg None   572150 Apr  5 22:28 libplplotd.dll
-rwxr-xr-x 1 greg None  1107048 Apr 16 17:42 libplplot-nodyn.dll
-rwxr-xr-x 1 greg None   512591 Apr 17 06:02 libplplot-sidyn.dll
lrwxrwxrwx 1 greg None       12 Mar  7 19:51 mingw -> /mingw32/bin


greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2
$ ls -la plplot11/bin
total 1232
drwxr-xr-x 1 greg None      0 Apr 17 06:04 .
drwxr-xr-x 1 greg None      0 Apr 17 06:04 ..
-rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll
-rwxr-xr-x 1 greg None 188815 Apr 17 06:02 libplplotcxx.dll
-rwxr-xr-x 1 greg None 512591 Apr 17 06:02 libplplot-sidyn.dll
-rwxr-xr-x 1 greg None 195307 Apr 17 06:02 libplplotwxwidgets.dll
-rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll
-rwxr-xr-x 1 greg None 107360 Apr 17 06:02 pltek.exe

greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2
$ ls -la plplot11-SAVE/bin
total 1236
drwxr-xr-x 1 greg None      0 Jan 28 16:53 .
drwxr-xr-x 1 greg None      0 Apr 17 05:33 ..
-rwxr-xr-x 1 greg None 118558 Jan 28 14:54 libcsirocsa.dll
-rwxr-xr-x 1 greg None 512079 Jan 28 14:54 libplplot.dll
-rwxr-xr-x 1 greg None 188803 Jan 28 14:54 libplplotcxx.dll
-rwxr-xr-x 1 greg None 195295 Jan 28 14:54 libplplotwxwidgets.dll
-rwxr-xr-x 1 greg None 120392 Jan 28 14:54 libqsastime.dll
-rwxr-xr-x 1 greg None 106848 Jan 28 14:55 pltek.exe

greg@Homerw7 MINGW32 /d/bld/mingw32-psxdw2
$ ls -la /c/mingw/dll32-psxdw2 | grep Jan\ 28
-rwxr-xr-x 1 greg None   143271 Jan 28 14:54 cairo.dll
-rwxr-xr-x 1 greg None   118558 Jan 28 14:54 libcsirocsa.dll
-rwxr-xr-x 1 greg None   512079 Jan 28 14:54 libplplot.dll
-rwxr-xr-x 1 greg None   188803 Jan 28 14:54 libplplotcxx.dll
-rwxr-xr-x 1 greg None   195295 Jan 28 14:54 libplplotwxwidgets.dll
-rwxr-xr-x 1 greg None   120392 Jan 28 14:54 libqsastime.dll
-rwxr-xr-x 1 greg None    90308 Jan 28 14:54 mem.dll
-rwxr-xr-x 1 greg None    82507 Jan 28 14:54 null.dll
-rwxr-xr-x 1 greg None   120304 Jan 28 14:54 ps.dll
-rwxr-xr-x 1 greg None   108182 Jan 28 14:54 svg.dll
-rwxr-xr-x 1 greg None   114481 Jan 28 14:54 wingcc.dll
-rwxr-xr-x 1 greg None   499063 Jan 28 14:55 wxwidgets.dll
-rwxr-xr-x 1 greg None   100481 Jan 28 14:55 xfig.dll

Re: [Plplot-devel] Comprehensive testing: Cygwin

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

Hi Alan,


I hope this tarball is complete.

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> 1. Output from the printenv command (which gives a list of all environment variables);
>
The file env.out

> 2. the script you used to invoke scripts/comprehensive_test.sh
>

The file script.txt

> 3. complete scripts/comprehensive_test.sh output;
>
The file comprehensive.out

> 4. and all the files in the relevant output_tree subdirectories.
>
Subdirectory output_tree - ctest.out, cmake.out and make.out

>
> 5. However, those build_dir results did give me an idea which is it would be useful to
> have a detailed listing of all files that were generated by the test.  Of course, that
> listing is fairly large (mine here contains 30 thousand files in the listing!)
>
The file build_tree_listing.out

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] Comprehensive testing: Cygwin

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

Hi Alan,



Oh, I should have checked all this more carefully. Hm, right now there is an update running for Cygwin and this is taking a remarkably long time. I will prepare the new test run by cleaning up the directory. As I thought the script had done that, I copied the subdirectories that were touched into the tarball. Hopefully I will get a chance to rerun the test before I have to leave for home ;).



Regards,



Arjen


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, April 17, 2015 2:44 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: Comprehensive testing: Cygwin
>
> On 2015-04-17 10:05-0000 Arjen Markus wrote:
>
> >> -----Original Message-----
> >> From: Alan W. Irwin [mailto:ir...@be...]
> >>
> >> Hi Arjen:
> >>
> [....]
>
> > Please have a look at the tarball - I have included all the information you asked for.
>
> I cannot find everything I requested in the tarball.  So I repeat what I asked for before
> in numbered form.
>
> 1. Output from the printenv command (which gives a list of all environment variables);
>
> 2. the script you used to invoke scripts/comprehensive_test.sh
>
> 3. complete scripts/comprehensive_test.sh output;
>
> 4. and all the files in the relevant output_tree subdirectories.
>
> I believe you sent me 1. as env.out in the tarball, but I can find no sign of 2. or 3. in
> the tarball.
>
> You did send me 4, but I believe there are stale files left in there from previous runs
> of the script (although I am not sure because I don't have 3).
>
> You also sent me the unrequested build_dir in the tarball. I didn't request that part of
> the generated results because those large files are fairly useless to me. So please
> drop that the next time to save bandwidth, i.e., only include results from the relevant
> output_tree subdirectories for 4.
>
> 5. However, those build_dir results did give me an idea which is it would be useful to
> have a detailed listing of all files that were generated by the test.  Of course, that
> listing is fairly large (mine here contains 30 thousand files in the listing!)
>
> To generate such a list do the following:
>
> cd $prefix #where $prefix is the prefix containing all the results
>
> find . -type f |xargs ls -l >& listing.out
>
> and include that listing.out in the tarball.
>
> What I suggest you do to make the requested data collection completely repeatable
> and automatic is make those commands part of your bash script that invokes
> scripts/comprehensive_test.sh.
>
> So what that overall script should do is the following.
>
> A. Remove all the stale results from previous runs of the script.
>
> B. Capture printenv output
>
> C. Run scripts/comprehensive_test.sh with output captured using the tee command
> as discussed previously here when discussing the same subject with Greg, i.e.,
>
> scripts/comprehensive_test.sh |& tee comprehensive_test.sh.out
>
> D. Add further commands to collect all the requested additional information and pack
> it in a tarball.
>
> B and C take care of requests 1 and 3 above so D must handle request 2, 4, and 5.
>
> If you need bash scripting help with any of A through D, let me know.
>
> Thanks in advance for this additional effort to automate the data collection for 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
> __________________________

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] Comprehensive testing: Cygwin

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

On 2015-04-17 10:05-0000 Arjen Markus wrote:

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

> Please have a look at the tarball - I have included all the information you asked for.

I cannot find everything I requested in the tarball.  So I repeat what I asked for before in numbered form.

1. Output from the printenv command (which gives a list of all
environment variables);

2. the script you used to invoke scripts/comprehensive_test.sh

3. complete scripts/comprehensive_test.sh output;

4. and all the files in the relevant output_tree subdirectories.

I believe you sent me 1. as env.out in the tarball, but I can find no
sign of 2. or 3. in the tarball.

You did send me 4, but I believe there are stale files left in there
from previous runs of the script (although I am not sure because I
don't have 3).

You also sent me the unrequested build_dir in the tarball. I didn't
request that part of the generated results because those large files
are fairly useless to me. So please drop that the next time to save
bandwidth, i.e., only include results from the relevant output_tree
subdirectories for 4.

5. However, those build_dir results did give me an idea which is it would
be useful to have a detailed listing of all files that were generated
by the test.  Of course, that listing is fairly large (mine here
contains 30 thousand files in the listing!)

To generate such a list do the following:

cd $prefix #where $prefix is the prefix containing all the results

find . -type f |xargs ls -l >& listing.out

and include that listing.out in the tarball.

What I suggest you do to make the requested data collection completely
repeatable and automatic is make those commands part of your bash
script that invokes scripts/comprehensive_test.sh.

So what that overall script should do is the following.

A. Remove all the stale results from previous runs of the script.

B. Capture printenv output

C. Run scripts/comprehensive_test.sh with output captured using the tee command as
discussed previously here when discussing the same subject with Greg,
i.e.,

scripts/comprehensive_test.sh |& tee comprehensive_test.sh.out

D. Add further commands to collect all the requested additional
information and pack it in a tarball.

B and C take care of requests 1 and 3 above so D must handle request 2, 4, and
5.

If you need bash scripting help with any of A through D, let me
know.

Thanks in advance for this additional effort to automate the data
collection for 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] Comprehensive testing: Cygwin

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Arjen:
>
> I changed the subject line to be more appropriate to the subject.
>
> When things don't work you have a tendency to elide information which I guess you
> like to do to save bandwidth.  But that approach actually wastes bandwidth, wastes
> my time and yours, and delays resolution of bugs because I then have to follow up
> with a request for complete information which because of time zone differences
> usually delays everything by a day.  So please resist that tendency to elide
> information and instead _always_ give complete reports when things go wrong as
> they have in this case.

Indeed, this is a bad habit. I was in a bit of a hurry.

>
> In this case that requested complete information should include output from the
> printenv command (which gives a list of all enviromnent variables); the script you
> used to invoke scripts/comprehensive_test.sh (or the exact script arguments if you
> invoked scripts/comprehensive_test.sh by hand); complete
> scripts/comprehensive_test.sh output; and all the files in the relevant output_tree
> subdirectories. (This requested kind of information is the same as you supplied
> before for your successful recent runs of scripts/comprehensive_test.sh so it should
> not be a lot of trouble for you to also collect this information when things go
> wrong.)
>
> Because you didn't provide complete information this time, I have no access to your
> script output which would tell me whether you are using the latest version of
> scripts/comprehensive_test.sh (which added some useful output to that script as well
> as cleaning up the logic for the required PATH manipulations) and whether the
> detection of the windows platform and implemented PATH manipulations is working
> well there or not. But, in any case, all the other information requested above could be
> useful to me as well so please collect it in a compressed tarball and attach it.
>
Please have a look at the tarball - I have included all the information you asked for.

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] Comprehensive testing: Cygwin

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

On 2015-04-17 07:45-0000 Arjen Markus wrote:

> So I conclude [from all ctests failing] that your fix for computing
the PATH is not quite up to its taks yet. This was under Cygwin, using
2.8.11.2 for that platform.

Hi Arjen:

I changed the subject line to be more appropriate to the subject.

When things don't work you have a tendency to elide information which
I guess you like to do to save bandwidth.  But that approach actually
wastes bandwidth, wastes my time and yours, and delays resolution of
bugs because I then have to follow up with a request for complete
information which because of time zone differences usually delays
everything by a day.  So please resist that tendency to elide
information and instead _always_ give complete reports when things go
wrong as they have in this case.

In this case that requested complete information should include output
from the printenv command (which gives a list of all enviromnent
variables); the script you used to invoke
scripts/comprehensive_test.sh (or the exact script arguments if you
invoked scripts/comprehensive_test.sh by hand); complete
scripts/comprehensive_test.sh output; and all the files in the 
relevant output_tree subdirectories. (This requested kind of
information is the same as you supplied before for your successful
recent runs of scripts/comprehensive_test.sh so it should not be a lot
of trouble for you to also collect this information when things go
wrong.)

Because you didn't provide complete information this time, I have no
access to your script output which would tell me whether you are using
the latest version of scripts/comprehensive_test.sh (which added some
useful output to that script as well as cleaning up the logic for the
required PATH manipulations) and whether the detection of the windows
platform and implemented PATH manipulations is working well there or
not. But, in any case, all the other information requested above could
be useful to me as well so please collect it in a compressed tarball
and attach it.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] Welcome to Jim Dishaw as the latest member of the core development group

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

On behalf of the PLplot core team, I am happy to welcome Jim Dishaw as
the latest developer to join that team.  That status gives Jim
official recognition as a PLplot developer (at
<https://sourceforge.net/p/plplot/_members/>) and also gives him
access to a lot more PLplot project capabilities at SourceForge such
as pushing commits to our SF git server, adding to or modifying our
wiki pages, etc.

Anybody lurking on this list is probably already aware that Jim has
been adding a lot to plbuf capability recently and has some big future
plans for that component of PLplot as well as other PLplot components
such as plmeta and plrender.

So we are all looking forward to seeing what Jim can do for PLplot
for the forseeable future.

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] Comprehensive testing: OpenSuse-13.2: finding stuff

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Hi Arjen:
>
> I think I have found a good bash shell method of automatically detecting any
> windows platform (using the "exe" suffix that occurs for the bash fullpathname on all
> Windows platforms).  So there is no need for the user to specify whether Windows
> PATH manipulation is needed or not and therefore no need to implement the above -
> -manipulate_PATH option for the script.
>
> As of commit id 13a3baa, I have changed the script to implement the automatic
> Windows platform detection described above.  That means path manipulations will
> automatically occur on all Windows platforms within the script and there is no longer
> any need to use brute-force PATH changes before running the script on Cygwin (or
> any other Windows platform).
>
> Could you let me know if the fix works (i.e., by running the script with no special
> brute-force PATH manipulations beforehand). This might also be a good opportunity
> for you to permanently remove some of the constraints on your prior successful
> Cygwin test.  For example, note
> (E) on your current test report at
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> implies if you install swig on your Cygwin platform, the Java, Python, Octave, and
> Lua components of PLplot will be included in your comprehensive testing (assuming
> you have the development versions of those software packages already installed).
>
I just tried running the comprehensive tests with no special provisions for the PATH and that failed in ctest. Here is a fragment of the report (the "shared" tests):

4: Test command: /usr/bin/bash.exe "-c" "EXAMPLES_DIR=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/examples SRC_EXAMPLES_DIR=/cygdrive/d/plplot-svn/plplot-git/examples OUTPUT_DIR=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/ctest_examples_output_dir VC_CTEST_DIRECTORY= ./plplot-test.sh --verbose --device=psc --front-end=tcl"

4: Test timeout computed to be: 1500

4: Testing front-end tcl

4: /cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/bindings/tcl/pltcl demo of plot

1: Testing front-end c

1: x00c

3: Testing front-end f95

3: x16af

3: /cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/examples/f95/x16af.exe: error while loading shared libraries: cygplplotf95c-12.dll: cannot open shared object file: No such file or directory

2: Testing front-end cxx

2: x00

1/17 Test  #1: examples_c .......................***Failed    0.15 sec

2/17 Test  #3: examples_f95 .....................***Failed    0.12 sec

3/17 Test  #2: examples_cxx .....................***Failed    0.14 sec

test 5

      Start  5: examples_svg

So I conclude that your fix for computing the PATH is not quite up to its taks yet. This was under Cygwin, using 2.8.11.2 for that platform.

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] wxwidgets error when building plplot 5.11.0 on FreeBSD

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

On 2015-04-16 22:48-0000 Ben Woods wrote:

> Hey everyone,
>
> I'm trying to build plplot 5.11.0 on FreeBSD with wxwidgets support. I
> have wx28-gtk2-2.8.12 and agg-2.5_11 installed, and am compiling with
> the following options:
> -DPLD_wxpng:BOOL=ON
> -DwxWidgets_CONFIG_EXECUTABLE:FILEPATH="/usr/local/bin/wxgtk2-2.8-config"


> -- WARNING: You have enabled the PLD_wxpng device which is disabled by
> default either because it is deprecated or because there are know
> issues with it. Please check the documentation / release notes for
> details.

Hi Ben:

I have reviewed our old mailing list archive and
PLD_wxpng has been disabled by default since its implementation many
years ago because it had all sorts of run-time problems (segfaults, etc.),
and nobody has fixed it since.

Just out of curiosity I tried to use

-DPLD_wxpng:BOOL=ON

as you did above,

and I got the following build error (which apparently is not the same as your
build error):

/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp: In function ‘void plD_init_wxpng(PLStream*)’:
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:231:5: error: ‘wxPLDevBase’ was not declared in this scope
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:231:18: error: ‘dev’ was not declared in this scope
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:232:28: error: ‘common_init’ was not declared in this scope
make[3]: *** [drivers/CMakeFiles/wxwidgets.dir/wxwidgets.cpp.o] Error 1
make[2]: *** [drivers/CMakeFiles/wxwidgets.dir/all] Error 2
make[1]: *** [drivers/CMakeFiles/wxwidgets.dir/rule] Error 2
make: *** [wxwidgets] Error 2

So it appears wxpng has fallen into even a greater state of
disrepair (it now doesn't even build) for the new wxwidgets implementation
used for 5.11.0.  It might build (but would probably still have the
same run-time errors as previously) if you used the -DOLD_WXWIDGETS=ON
option we have implemented for 5.11.0 to give access to the old
wxwidgets implementation.

But I think what you really should do is pay attention to the above
warning message and do not use the -DPLD_wxpng:BOOL=ON option for
5.11.0 at all.

@Phil:

I think Werner's historical idea with wxpng was as a proof-of-concept
that wxwidgets could be the basis of a whole bunch of additional file
device drivers.  He obviously never got that idea to work properly,
but it might be a lot easier now with modern wxwidgets and your
simplification/rationalization of our own wxwidgets-related code.

Anyhow, my advice is to consider this possibility.  If you think wxpng
(and other possible file devices) are a good idea and straightforward
to implement properly with you new wxwidgets approach, then please put
getting wxpng to build and actually execute properly without segfaults
on your wxwidgets ToDo list.  Otherwise, though, you should remove the
wxpng code from your new wxwidgets source files so nobody runs into
the type of build errors I did above for new wxwidgets.

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] wxwidgets error when building plplot 5.11.0 on FreeBSD

[Ben W. <woo...@gm...>]

Hey everyone,

I'm trying to build plplot 5.11.0 on FreeBSD with wxwidgets support. I
have wx28-gtk2-2.8.12 and agg-2.5_11 installed, and am compiling with
the following options:
-DPLD_wxpng:BOOL=ON
-DwxWidgets_CONFIG_EXECUTABLE:FILEPATH="/usr/local/bin/wxgtk2-2.8-config"


Compiler output is below including the error (only key parts extracted
to keep the size down). Any help with this would be appreciated. Note
that plplot 5.11.0 builds fine with wxwidgets support disabled.

...

-- WARNING: You have enabled the PLD_png device which is disabled by
default either because it is deprecated or because there are know
issues with it. Please check the documentation / release notes for
details.
-- WARNING: You have enabled the PLD_wxpng device which is disabled by
default either because it is deprecated or because there are know
issues with it. Please check the documentation / release notes for
details.

...

Summary of CMake build system results for PLplot

Install location variables which can be set by the user:
CMAKE_INSTALL_PREFIX:      /usr/local
CMAKE_INSTALL_EXEC_PREFIX  /usr/local
CMAKE_INSTALL_BINDIR   /usr/local/bin
CMAKE_INSTALL_DATADIR   /usr/local/share
CMAKE_INSTALL_LIBDIR   /usr/local/lib
CMAKE_INSTALL_INCLUDEDIR   /usr/local/include
CMAKE_INSTALL_INFODIR   /usr/local/info
CMAKE_INSTALL_MANDIR   /usr/local/man

Derived install location variables:
DATA_DIR /usr/local/share/plplot
LIB_DIR /usr/local/lib
INCLUDE_DIR /usr/local/include/plplot
BIN_DIR /usr/local/bin
TCL_DIR /usr/local/share/plplot/tcl
ADA_INCLUDE_DIR /usr/local/share/ada/adainclude/plplotada
ADA_LIB_DIR /usr/local/lib/ada/adalib/plplotada
PYTHON_INSTDIR
DRV_DIR /usr/local/lib/plplot/drivers
DOC_DIR /usr/local/share/doc/plplot
MAN_DIR /usr/local/man
INFO_DIR /usr/local/info

Other important CMake variables:

CMAKE_SYSTEM_NAME: FreeBSD
UNIX: 1
WIN32:
APPLE:
MSVC: (MSVC_VERSION: )
MINGW:
MSYS:
CYGWIN:
BORLAND:
WATCOM:

SWIG_FOUND: 1
PERL_FOUND: TRUE
X11_FOUND: 1

CMAKE_BUILD_TYPE: Release
CMAKE_C_COMPILER CMAKE_C_FLAGS: /usr/bin/cc -O2 -pipe
-D_IS_BUILDING_PLPLOT_PORT_ -fstack-protector -fno-strict-aliasing
CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS: /usr/bin/c++ -O2 -pipe
-D_IS_BUILDING_PLPLOT_PORT_ -fstack-protector -fno-strict-aliasing
CMAKE_Fortran_COMPILER CMAKE_Fortran_FLAGS: /usr/local/bin/gfortran48
-O -Wl,-rpath=/usr/local/lib/gcc48
Target Fortran:

ENABLE_DYNDRIVERS: ON
DRIVERS_LIST: cairo;qt;gd;mem;null;ps;psttf;svg;wxwidgets;xfig;xwin
DEVICES_LIST: memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcair
o;xcairo;epsqt;pdfqt;qtwidget;bmpqt;jpgqt;pngqt;ppmqt;
tiffqt;extqt;memqt;svgqt;png;mem;null;ps;psttf;svg;wxwidgets;wxpng;xfig;xwin

Library options:
BUILD_SHARED_LIBS: ON PL_DOUBLE: ON

Optional libraries:
PL_HAVE_QHULL: ON WITH_CSA: ON
PL_HAVE_FREETYPE: ON PL_HAVE_PTHREAD: ON
HAVE_AGG: HAVE_SHAPELIB: OFF

Language Bindings:
ENABLE_ada: OFF
ENABLE_cxx: ON
ENABLE_d: OFF
ENABLE_f95: ON
ENABLE_java: OFF
ENABLE_lua: ON
ENABLE_ocaml: OFF
ENABLE_octave: OFF
ENABLE_pdl: OFF
ENABLE_python: OFF
ENABLE_qt: ON
ENABLE_pyqt4: OFF
ENABLE_tcl: ON
ENABLE_itcl: ON
ENABLE_tk: OFF
ENABLE_itk: OFF
ENABLE_wxwidgets: ON

-- Configuring done

...


Building CXX object drivers/CMakeFiles/wxwidgets.dir/wxwidgets_dev.cpp.o
cd /wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/drivers &&
/usr/bin/c++   -DPLPLOT_HAVE_CONFIG_H -Dwxwidgets_EXPORTS -O2 -pipe
-D_IS_BUILDING_PLPLOT_PORT_ -fstack-protector -fno-strict-aliasing -O2
-pipe -D_IS_BUILDING_PLPLOT_PORT_ -fstack-protector
-fno-strict-aliasing -fPIC
-I/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/include
-I/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/lib/qsastime
-I/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/lib/nistcd
-I/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0
-I/usr/local/lib/wx/include/gtk2-ansi-release-2.8
-I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-D__WXGTK__ -D_THREAD_SAFE  -DUSINGDLL -o
CMakeFiles/wxwidgets.dir/wxwidgets_dev.cpp.o -c
/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/drivers/wxwidgets_dev.cpp
/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/drivers/
wxwidgets.cpp:231:5:
error: unknown type name 'wxPLDevBase'; did you mean 'wxPLDevice'?
    wxPLDevBase* dev;
    ^~~~~~~~~~~
    wxPLDevice
/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/drivers/wxwidgets.h:40:7:
note: 'wxPLDevice' declared here
class wxPLDevice
      ^
/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/drivers/
wxwidgets.cpp:232:11:
error: use of undeclared identifier 'common_init'
    dev = common_init( pls );
          ^
/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/drivers/
wxwidgets.cpp:246:10:
error: no member named 'showGUI' in 'wxPLDevice'
    dev->showGUI    = false;
    ~~~  ^
/wrkdirs/usr/ports/math/plplot/work/plplot-5.11.0/drivers/
wxwidgets.cpp:247:10:
error: no member named 'bitmapType' in 'wxPLDevice'
    dev->bitmapType = wxBITMAP_TYPE_PNG;
    ~~~  ^
4 errors generated.
drivers/CMakeFiles/wxwidgets.dir/build.make:57: recipe for target
'drivers/CMakeFiles/wxwidgets.dir/wxwidgets.cpp.o' failed

Re: [Plplot-devel] Minimum allowed cmake version is now bumped to 3.0.2

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

On 2015-04-16 14:54-0700 Alan W. Irwin wrote:

> I don't think the requirement of CMake-3.0.2 or later is going to
> cause issues for distributions of modern versions of free software.
[...]
> If anyone else here has problems moving from CMake-2 to CMake-3.0.2 or
> later please let me know.

I just checked Ubuntu and it turns out they have been very slow to
move to CMake-3 for some reason so neither 14.04 LTS (a.k.a Trusty
Tahr) nor 14.10 (a.k.a Utopic Unicorn) includes CMake-3. The
pre-release 15.04 (a.k.a. Vivid Vervet which is scheduled for final
release a week from today) does include CMake-3.0.2 so the Ubuntu
users here will have to either be careful to use Vivid or else build
or epa_build cmake-3.0.2 or later themselves.

In any case in a few months time when we release again from master
tip, we should be able to claim that both the latest stable version of
Debian and Ubuntu do include cmake-3.0.2.  Furthermore most Debian and
Ubuntu users will have updated to those versions by that time.  So I
don't think this cmake version requirement will be a burden for most
of the Debian and Ubuntu users of our next release.

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] Minimum allowed cmake version is now bumped to 3.0.2

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

In order to solve some issues with our build system (see the commit
message for commit id = 8972f92 for the details) CMake 3 features will
be required.

Accordingly as a preliminary step before solving those issues I have
bumped (as of commit id 8972f92) the minimum cmake version used in our
build system from various 2.x.y versions to 3.0.2.

I don't think the requirement of CMake-3.0.2 or later is going to
cause issues for distributions of modern versions of free software.

For example, the Windows and Mac OS X distros Cygwin, fink, homebrew,
and macports provide packages for version 3.1.2 (Cygwin), 3.2.1
(Fink), 3.2.2 (Homebrew), and 3.2.1 (MacPorts) of cmake, and I think
the same is generally true of Linux distributions of software. The
well-known exception for the Linux case would be so-called
"enterprise-class" distribution (e.g., RedHat and CentOS) which tend
to stick with old versions of everything.  But the solution for users
of such distros is to stick to old PLplot versions or else
download, build, or epa_build CMake-3.0.2 or
later similarly to how they have to update to modern versions of most
Linux libraries to get modern PLplot to work.

One other exception I am aware of is Debian wheezy (the current Debian
stable) which only packages cmake-2.8.9.  However, most Debian desktop
users are already using Debian jessie which gives access to 3.0.2, and
in any case Debian jessie is scheduled to become the new Debian stable
only 9 days from now.  So I don't think this is a big concern.

@Arjen: your current testing on Cygwin used an older cmake-2.8 version
so you will have to update your Cygwin distro to use
cmake-3.1.2 to continue such testing.

If anyone else here has problems moving from CMake-2 to CMake-3.0.2 or
later please let me know.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] bug 159

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

Alan,

I'll try and take a look. Just to confirm, I also see the issue with
example 27. I also tried different drivers, and they all segfault with
non-zero orientation. Exactly where the segfault occurs does depend on the
driver though so this will require a bit more digging.

Andrew

On Thu, Apr 16, 2015 at 10:35:53AM -0700, Alan Irwin wrote:
> Hi Andrew:
> 
> James Tappin reported a bug with using orientation and plfill with a
> large number of points in bug 159 for every device driver he looked
> at.  I didn't bother with his fortran example, but I did remember our standard
> example 27 uses a large number of points with plfill so tried the
> following valgrind experiments first without and then with a non-zero
> orientation.
> 
> ==3260== Memcheck, a memory error detector
> ==3260== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==3260== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==3260== Command: examples/c/x27c -dev svg -ori 0. -fam -o test.svg
> ==3260== 
> ==3260== 
> ==3260== HEAP SUMMARY:
> ==3260==     in use at exit: 0 bytes in 0 blocks
> ==3260==   total heap usage: 1,121 allocs, 1,121 frees, 593,146 bytes allocated
> ==3260== 
> ==3260== All heap blocks were freed -- no leaks are possible
> ==3260== 
> ==3260== For counts of detected and suppressed errors, rerun with: -v
> ==3260== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
> 
> So far so good.  But with non-zero -ori parameter we get a severe
> memory management error (invalid read) and segfault.
> 
> ==3263== Memcheck, a memory error detector
> ==3263== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==3263== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==3263== Command: examples/c/x27c -dev svg -ori 0.1 -fam -o test.svg
> ==3263== 
> plOpenFile: Opened test.svg.12
> ==3263== Invalid read of size 1
> ==3263==    at 0x6E1E87C: svg_fill_background_color (svg.c:1122)
> ==3263==    by 0x6E1C837: plD_bop_svg (svg.c:277)
> ==3263==    by 0x4E5204C: plP_bop (plcore.c:211)
> ==3263==    by 0x4E808E9: c_pladv (plpage.c:49)
> ==3263==    by 0x400FBD: main (x27c.c:108)
> ==3263==  Address 0x128900001295 is not stack'd, malloc'd or (recently) free'd
> ==3263== 
> ==3263== 
> ==3263== Process terminating with default action of signal 11 (SIGSEGV)
> ==3263==  Access not within mapped region at address 0x128900001295
> ==3263==    at 0x6E1E87C: svg_fill_background_color (svg.c:1122)
> ==3263==    by 0x6E1C837: plD_bop_svg (svg.c:277)
> ==3263==    by 0x4E5204C: plP_bop (plcore.c:211)
> ==3263==    by 0x4E808E9: c_pladv (plpage.c:49)
> ==3263==    by 0x400FBD: main (x27c.c:108)
> ==3263==  If you believe this happened as a result of a stack
> ==3263==  overflow in your program's main thread (unlikely but
> ==3263==  possible), you can try to increase the size of the
> ==3263==  main thread stack using the --main-stacksize= flag.
> ==3263==  The main thread stack size used in this run was 8388608.
> ==3263== 
> ==3263== HEAP SUMMARY:
> ==3263==     in use at exit: 74,003 bytes in 286 blocks
> ==3263==   total heap usage: 1,135 allocs, 849 frees, 458,756 bytes allocated
> ==3263== 
> ==3263== LEAK SUMMARY:
> ==3263==    definitely lost: 3,456 bytes in 2 blocks
> ==3263==    indirectly lost: 0 bytes in 0 blocks
> ==3263==      possibly lost: 0 bytes in 0 blocks
> ==3263==    still reachable: 70,547 bytes in 284 blocks
> ==3263==         suppressed: 0 bytes in 0 blocks
> ==3263== Rerun with --leak-check=full to see details of leaked memory
> ==3263== 
> ==3263== For counts of detected and suppressed errors, rerun with: -v
> ==3263== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
> Segmentation fault
> 
> If I try the same experiments with example 25 (which also uses plfill
> but with just a small number of points) I get a valgrind clean result
> for both orientations.  A significant difference between the two
> examples is 27 uses a much larger number of points for the vertices of
> the filled area.  If you look at the plfill routine in src/plfill.c if
> the number of vertices are greater than PL_MAXPOLY - 1 (= 255) it
> allocates (and later frees) some memory to hold the vertices rather
> than using a static array for that purpose.  But I cannot figure out
> why a non-zero orientation parameter affects this logic at all.
> 
> James summary of the issue was that the fill was corrupted.  I am
> pretty sure that rendering issue was because of the severe memory
> management error, but by chance he did not get the segfault while I did.
> 
> In any case, it is clear from the above results that we have a severe
> memory management issue for the stated corner case (non-zero
> orientation, large number of points, and fill) for 5.11.0 (my test was
> for current master tip) and many prior versions (probably back to when
> we found example 27 was overflowing the static array and put in the
> logic to use a dynamic array to store the vertices for the case when
> the number of vertices was greater than 255.
> 
> Could you please take a look?
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________
> 
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] bug 159

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

Hi Andrew:

James Tappin reported a bug with using orientation and plfill with a
large number of points in bug 159 for every device driver he looked
at.  I didn't bother with his fortran example, but I did remember our standard
example 27 uses a large number of points with plfill so tried the
following valgrind experiments first without and then with a non-zero
orientation.

==3260== Memcheck, a memory error detector
==3260== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==3260== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==3260== Command: examples/c/x27c -dev svg -ori 0. -fam -o test.svg
==3260== 
==3260== 
==3260== HEAP SUMMARY:
==3260==     in use at exit: 0 bytes in 0 blocks
==3260==   total heap usage: 1,121 allocs, 1,121 frees, 593,146 bytes allocated
==3260== 
==3260== All heap blocks were freed -- no leaks are possible
==3260== 
==3260== For counts of detected and suppressed errors, rerun with: -v
==3260== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

So far so good.  But with non-zero -ori parameter we get a severe
memory management error (invalid read) and segfault.

==3263== Memcheck, a memory error detector
==3263== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==3263== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==3263== Command: examples/c/x27c -dev svg -ori 0.1 -fam -o test.svg
==3263== 
plOpenFile: Opened test.svg.12
==3263== Invalid read of size 1
==3263==    at 0x6E1E87C: svg_fill_background_color (svg.c:1122)
==3263==    by 0x6E1C837: plD_bop_svg (svg.c:277)
==3263==    by 0x4E5204C: plP_bop (plcore.c:211)
==3263==    by 0x4E808E9: c_pladv (plpage.c:49)
==3263==    by 0x400FBD: main (x27c.c:108)
==3263==  Address 0x128900001295 is not stack'd, malloc'd or (recently) free'd
==3263== 
==3263== 
==3263== Process terminating with default action of signal 11 (SIGSEGV)
==3263==  Access not within mapped region at address 0x128900001295
==3263==    at 0x6E1E87C: svg_fill_background_color (svg.c:1122)
==3263==    by 0x6E1C837: plD_bop_svg (svg.c:277)
==3263==    by 0x4E5204C: plP_bop (plcore.c:211)
==3263==    by 0x4E808E9: c_pladv (plpage.c:49)
==3263==    by 0x400FBD: main (x27c.c:108)
==3263==  If you believe this happened as a result of a stack
==3263==  overflow in your program's main thread (unlikely but
==3263==  possible), you can try to increase the size of the
==3263==  main thread stack using the --main-stacksize= flag.
==3263==  The main thread stack size used in this run was 8388608.
==3263== 
==3263== HEAP SUMMARY:
==3263==     in use at exit: 74,003 bytes in 286 blocks
==3263==   total heap usage: 1,135 allocs, 849 frees, 458,756 bytes allocated
==3263== 
==3263== LEAK SUMMARY:
==3263==    definitely lost: 3,456 bytes in 2 blocks
==3263==    indirectly lost: 0 bytes in 0 blocks
==3263==      possibly lost: 0 bytes in 0 blocks
==3263==    still reachable: 70,547 bytes in 284 blocks
==3263==         suppressed: 0 bytes in 0 blocks
==3263== Rerun with --leak-check=full to see details of leaked memory
==3263== 
==3263== For counts of detected and suppressed errors, rerun with: -v
==3263== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault

If I try the same experiments with example 25 (which also uses plfill
but with just a small number of points) I get a valgrind clean result
for both orientations.  A significant difference between the two
examples is 27 uses a much larger number of points for the vertices of
the filled area.  If you look at the plfill routine in src/plfill.c if
the number of vertices are greater than PL_MAXPOLY - 1 (= 255) it
allocates (and later frees) some memory to hold the vertices rather
than using a static array for that purpose.  But I cannot figure out
why a non-zero orientation parameter affects this logic at all.

James summary of the issue was that the fill was corrupted.  I am
pretty sure that rendering issue was because of the severe memory
management error, but by chance he did not get the segfault while I did.

In any case, it is clear from the above results that we have a severe
memory management issue for the stated corner case (non-zero
orientation, large number of points, and fill) for 5.11.0 (my test was
for current master tip) and many prior versions (probably back to when
we found example 27 was overflowing the static array and put in the
logic to use a dynamic array to store the vertices for the case when
the number of vertices was greater than 255.

Could you please take a look?

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] Making PLplot releases easier in future

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> > Well, I feel comfortable with Cygwin, and from the point of using
> it, also with MinGW (and to a lesser extent MSYS). Installing new stuff on MinGW is
> a bit of a pain, as there is not a single point of entry like with Cygwin. I have,
> however, hardly any experience with MinGW-w64/MSYS2, and the last time I looked
> at it, it was even worse vis-à-vis available software than MinGW. But that may have
> changed.
>
> Apparently it has.
>

Ah, good to know that.

>
> > [MinGW-w64/MSYS2] is largely terra incognita for me.
> And for the rest of us too.
>
> So even with all your existing PLplot-Cygwin knowledge, and the similarities
> between Cygwin and MinGW-w64/MSYS2, there are important differences between
> Cygwin and MinGW-w64/MSYS2, and those might make it initially difficult for you to
> get a PLplot build to work on MinGW-w64/MSYS2.  For that reason I think Cygwin
> should be your first priority, but I would recommend MinGW-w64/MSYS2 as your
> second priority because of all the benefits of getting that platform to work for PLplot.
>
These differences are by design: programs built for Cygwin require a Cygwin environment to work, whereas programs built using MinGW can be used outside MinGW and behave as native Windows programs (or at least that is the intent :)).

I am fine with that list of priorities.

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] Making PLplot releases easier in future

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

Hi Arjen:

On 2015-04-15 12:16-0000 Arjen Markus wrote:

> Well, I feel comfortable with Cygwin, and from the point of using
it, also with MinGW (and to a lesser extent MSYS). Installing new
stuff on MinGW is a bit of a pain, as there is not a single point of
entry like with Cygwin. I have, however, hardly any experience with
MinGW-w64/MSYS2, and the last time I looked at it, it was even worse
vis-à-vis available software than MinGW. But that may have changed.

Apparently it has.

There are currently 5638 + 3563 free software packages for
MinGW-w64/MSYS2 located at
<https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/> and
<https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/x86_64/>.
Installation of those packages is controlled by the pacman automatic
installer that has been ported by the project to Windows.

If you install that automatic installer (see "Installing and
upgrading" at <https://sourceforge.net/p/msys2/wiki/Home/>), you
should be able to find out the complete story quickly, but I just did
a very quick survey of the above two locations, and found, for
example, cmake, pango, cairo, qt, wxwidgets, python, lua, Tcl/Tk,
pkg-config, swig, etc. Therefore, it appears that the MinGW-w64/MSYS2
is a fully loaded free software distribution giving access to the same
packages as Cygwin.  However, MinGW-w64/MSYS2 packages apparently
don't have the same baggage as the equivalent Cygwin packages, i.e,
they depend on native windows tools and libraries rather than
cygwin.dll.

> [MinGW-w64/MSYS2] is largely terra incognita for me.
And for the rest of us too.

So even with all your existing PLplot-Cygwin knowledge, and the
similarities between Cygwin and MinGW-w64/MSYS2, there are important
differences between Cygwin and MinGW-w64/MSYS2, and those might make
it initially difficult for you to get a PLplot build to work on
MinGW-w64/MSYS2.  For that reason I think Cygwin should be your first
priority, but I would recommend MinGW-w64/MSYS2 as your second
priority because of all the benefits of getting that platform to
work for 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] Making PLplot releases easier in future

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

Hi Alan,



Well, I feel comfortable with Cygwin, and from the point of using it, also with MinGW (and to a lesser extent MSYS). Installing new stuff on MinGW is a bit of a pain, as there is not a single point of entry like with Cygwin. I have, however, hardly any experience with MinGW-w64/MSYS2, and the last time I looked at it, it was even worse vis-à-vis available software than MinGW. But that may have changed.

>
> I fully agree making the PLplot experience much smoother for all the many different
> Windows platforms is a really important topic.  But from my perspective, I think the
> priority of the platforms should 1.
> Cygwin, 2. MinGW-w64/MSYS2, 3. the MSVC family of platforms, and 4., finally
> MinGW/MSYS.

I have noted the priorities you propose. Well, it should be interesting - for 3 out of 4 of these, things work when you ask them nicely and pet them on their heads once in a while (though sometimes they do bite). No. 2 is largely terra incognita for me.

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] Making PLplot releases easier in future

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

Hi Arjen:

On 2015-04-15 07:00-0000 Arjen Markus wrote:

> [...] That [quick release cycles, pushes of major changes only in
the first part of the release cycle] seems a wise approach. I can not
predict whether I will be able to get the Fortran bindings reorganised
as we planned before that time, but given that we are working to short
release cycles, that should be less of a problem. The thing is I
realised that my current approach leads to much more code than is
required, and especially duplication thereof. I want to explore an
alternative I have in mind.

Sounds intriguing.  I will certainly be willing to test whatever you
decide to implement.

> The past period has also revealed a number of things regarding
Windows (especially MinGW/MSYS) that should be made smoother and that
is something I would like to explore as well.

I fully agree making the PLplot experience much smoother for all the
many different Windows platforms is a really important topic.  But
from my perspective, I think the priority of the platforms should 1.
Cygwin, 2. MinGW-w64/MSYS2, 3. the MSVC family of platforms, and 4.,
finally MinGW/MSYS.  Perhaps that is all I should say since you have a
lot more Windows experience than I do, and you will be doing a lot
more of such testing than I can do with Wine because of its lack of
speed. However, here are my reasons why I would suggest this order of
priorities for you or anyone else wanting to help out with
our comprehensive testing of PLplot components on Windows platforms.

1. With Cygwin you have already demonstrated complete (except for the
interactive part) comprehensive test success for a small number of
PLplot components.  So that gives you an excellent starting point, and
because the major open-source packages that are PLplot soft
dependencies are already available for the Cygwin distribution, and
the minor PLplot soft dependencies are easy to build (e.g., qhull,
shapelib, libLASi) there is good hope you can expand relatively
rapidly from that initial success to comprehensive test success on
Cygwin for most/all PLplot components.

2. Once you have achieved that complete success on Cygwin for all
components of PLplot, I suggest the second priority should be
MinGW-w64/MSYS2 because of its many similarities with Cygwin including
a distribution of free libraries that is similar in size and extent to
the Cygwin distribution of free libraries (since apparently an
automatically generated reconfiguration of software package builds for
Cygwin can be used to derive MinGW-w64-MSYS2 package builds). However,
MinGW-w64/MSYS2 also apparently has the big advantage of classical
MinGW/MSYS over Cygwin which is it relies on native Windows tools
rather than the Cygwin dll.  For these reasons it is rapidly becoming
an extremely popular Windows platform as can be seen from the
following monthly download statistics (taken from
<https://sourceforge.net/projects/msys2/files/>):

2014-04 16,524
2014-05 12,047
2014-06 12,778
2014-07 14,157
2014-08 18,684
2014-09 21,588
2014-10 26,008
2014-11 29,550
2014-12 139,340
2015-01 343,260
2015-02 339,326
2015-03 493,047

This is obviously phenomenal growth over the last year with no end in sight so this is a platform we really do
not want to ignore.

3. I have no way of measuring the popularity of the MSVC family of
platforms, but I assume that family is quite popular because the CMake
developers devote a large effort to it (consisting now of 8 different
visual studio generators and counting), and you and Phil do
hand-crafted tests of a limited set of PLplot components on that
platform from time to time. Thus, I feel strongly it is a worthwhile
goal (after complete success for Cygwin and MinGW-w64/MSYS2) to expand
that current MSVC testing to running scripts/comprehensive_test.sh
(e.g., run the full set of 21 different test configuration
combinations available with that script) for at least a limited subset
of the PLplot components.  However, running that script for all
components of PLplot is very likely only a distant goal on this
platform since in contrast to Cygwin and MinGW-w64-MSYS2 most of the
PLplot soft dependencies are not available in a MSVC distribution.
Thus, the only alternative for MSVC is to build these soft
dependencies yourself.  One can use the
epa_build approach to help keep track of exactly what build methods
work, but finding out that essential information for each package
in a dependency tree starting with the soft dependencies of PLplot is
non-trivial.

4. MinGW/MSYS is still a very popular project from the user
perspective, but I rank this platform as our last priority because of
two real issues with it and a possible speculative issue with it.

i. The number of free software libraries that are installable with
MSYS is quite limited which makes an epa_build-like approach necessary
to test more than a tiny subset of the PLplot components.

ii. The inability of that platform's developers to fix a parallel
build regression on that platform that was introduced several years
ago now (and which apparently has never affected either Cygwin or
MinGW-w64/MSYS2). This regression can be worked around by limiting
yourself to no parallel builds of any kind on MinGW/MSYS, but that
completely wastes the resources of multi-processor machines. I
actually used parallel builds for my own recent 30-hour
MinGW/MSYS/Wine tests but one of those tests failed the first time because
of parallel build issues and (only by chance I assume) worked the
second time.  Thus, that is likely the last time I will try parallel
builds on that platform, but I am not looking forward to 60-90 hour
tests if I ever attempt to test that platform again on Wine.

iii. To speculate further, my opinion is that an unfixed egregious
regression like this is likely a symptom of not enough personnel to
deal with the issue (likely caused by potential or even current
MinGW/MSYS developers choosing to join the rapidly growing
MinGW-w64/MSYS2 project instead of maintaining MinGW/MSYS any
further). If this speculation proves to be correct, then MinGW/MSYS
is, of course, in big trouble in the long run, but in the short run we
should continue to test on this platform in a non-parallel way (as our
lowest priority among Windows 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] Making PLplot releases easier in future

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> 3'. I am going to encourage everybody to use the lesson 3 approach for further major
> developments.  This immediately applies to both Arjen (currently working on a fortran
> binding rewrite) and Jim (currently working on major changes to plmeta/plrender and
> possibly plbuf).
>
> @Arjen and Jim: does this lesson 3 approach work for you?
>
> 4'. Consistent with lesson 4, I think pushes of important topics to the master branch
> should only be done in the first month of a release cycle.
>
> @Arjen and Jim:
>
> To be specific I plan to adopt May 9th as the deadline for pushing of major mature
> topics to master.  So if you make that deadline, your work will get into the next
> release, but if your other time commitments make it impossible for you to make that
> deadline, then please continue to mature your topics as time permits and aim to
> push your major topics to master in the first month of the subsequent release cycle.
>
That seems a wise approach. I can not predict whether I will be able to get the Fortran bindings reorganised as we planned before that time, but given that we are working to short release cycles, that should be less of a problem. The thing is I realised that my current approach leads to much more code than is required, and especially duplication thereof. I want to explore an alternative I have in mind.

The past period has also revealed a number of things regarding Windows (especially MinGW/MSYS) that should be made smoother and that is something I would like to explore as well.

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] Comprehensive testing: OpenSuse-13.2: finding stuff

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

Hi Alan,




> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> I think I have found a good bash shell method of automatically detecting any
> windows platform (using the "exe" suffix that occurs for the bash fullpathname on all
> Windows platforms).  So there is no need for the user to specify whether Windows
> PATH manipulation is needed or not and therefore no need to implement the above -
> -manipulate_PATH option for the script.
>
> As of commit id 13a3baa, I have changed the script to implement the automatic
> Windows platform detection described above.  That means path manipulations will
> automatically occur on all Windows platforms within the script and there is no longer
> any need to use brute-force PATH changes before running the script on Cygwin (or
> any other Windows platform).
>
> Could you let me know if the fix works (i.e., by running the script with no special
> brute-force PATH manipulations beforehand). This might also be a good opportunity
> for you to permanently remove some of the constraints on your prior successful
> Cygwin test.  For example, note
> (E) on your current test report at
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> implies if you install swig on your Cygwin platform, the Java, Python, Octave, and
> Lua components of PLplot will be included in your comprehensive testing (assuming
> you have the development versions of those software packages already installed).
>


I saw your commit. If this indeed works, that would be great. While I just keep around all manner of scripts and batchfiles to take care of these PATH manipulations, it is a nuisance and makes testing a more tedious job than it should be.

I will try it asap and let you know the results.

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.