Re: [Plplot-devel] Building plplot in Windows with Intel Fortran Compiler

[Arjen Markus]

Hi Jeremy,

Thanks for this clarification. None of the options seems really special, but I 
can imagine that the pkg-config one is the culprit. At least, it is one I have 
never used myself and pkg-config files are intended to publish information 
about tools.

Regards,

Arjen

From: Jeremy Nesbitt 
Sent: Thursday, August 24, 2023 10:43 PM
To: Arjen Markus 
Cc: plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel] Building plplot in Windows with Intel Fortran 
Compiler

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl<mailto:servicedesk-...@deltares.nl>" as an 
attachment.

Hi,

Thanks for the reply.  Following your note, I did the following:

Start the Intel oneAPI Tools command line (installed when I installed their 
fortran compiler).
Go to plplot code and make a build directory.
cmake ..

When I do this, it finds ifort as the fortran compiler, which meets your 
expectations.

Then I deleted the build folder and started over with all the options I wanted

cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON 
-DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe 
-DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON

When I did this, cmake found the ifx compiler instead.  I know next to nothing 
about Cmake so my opinion bears little weight, but it seems suspicious that the 
compiler detection depends on the options I specified.  But it was 
reproducible.  When I pass no options, cmake finds ifort first.  When I pass 
the options I want, it finds ifx first.

Thanks,
Jeremy

On Thu, Aug 24, 2023 at 4:04 AM Arjen Markus 
mailto:arjen.mar...@deltares.nl>> wrote:
Hi Jeremy,

My apologies for not reacting sooner (me being one of the maintainers of 
PLplot), but at the very least you were able to solve your problem yourself. 
Could you specify the problems you met with the Intel oneAPI ifx compiler? 
Intel intends to phase out the classic one at some point in the near future and 
I was not aware of any problems it might cause. I have not seen any issues with 
other CMake-enabled builds for Fortran programs. As far as I know CMake picks 
the classic ifort compiler by default.

Regards,

Arjen

From: Jeremy Nesbitt mailto:jrnesb...@gmail.com>>
Sent: Saturday, August 19, 2023 3:30 AM
To: 
plplot-devel@lists.sourceforge.net<mailto:plplot-devel@lists.sourceforge.net>
Subject: Re: [Plplot-devel] Building plplot in Windows with Intel Fortran 
Compiler

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl<mailto:servicedesk-...@deltares.nl>" as an 
attachment.

Hi,

I had some time today and figured out the issue.  CMake found the Intel IFX 
compiler first and it seemed to cause confusion about what type of compiler was 
actually being used.  I worked around this by simply using set FC=ifort and 
re-running CMake.  Was able to get everything I wanted built and tested using 
the command line tools.

I'm guessing this is not a common use case, but if it happens to others it 
might be worth updating the CMake files to handle both the Fortran compilers 
that are installed from the Intel OneAPI tools.

Thanks,
Jeremy



On Thu, Aug 17, 2023 at 9:10 AM Jeremy Nesbitt 
mailto:jrnesb...@gmail.com>> wrote:
Hi,

I would like to get plplot built in windows with intel fortran bindings using 
the Visual Studio command line.  I can get build files generated via CMake if I 
turn off fortran bindings, but if I enable fortran I always get an error when 
running CMake.  I have tried NMake, Ninja, and Visual Studio 2022 generator 
files.

In initial troubleshooting to see if this is a more general problem, I came 
across this note on the plplot site:


Intel Fortran
If you use Intel Fortran, the solution/project files may cause errors when 
building. These affect only the Fortran libraries and examples. It is due to a 
small bug in CMake that should be fixed with the next release.

Was wondering if anyone had any more information on this, such as what bug it 
is, what version of CMake it might be fixed in, and whether there is a 
workaround?  I don't know CMake at all, but if I know there is some hope to get 
tthis working I can give it a shot.

Some details if anyone cares:
-I am using CMake 3.26-msvc

For NMake, used this command
cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON 
-DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe 
-DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON

Error I get at end
-- Configuring done (29.4s)
CMake Error at cmake

Re: [Plplot-devel] Building plplot in Windows with Intel Fortran Compiler

[Arjen Markus]

Hi Jeremy,

My apologies for not reacting sooner (me being one of the maintainers of 
PLplot), but at the very least you were able to solve your problem yourself. 
Could you specify the problems you met with the Intel oneAPI ifx compiler? 
Intel intends to phase out the classic one at some point in the near future and 
I was not aware of any problems it might cause. I have not seen any issues with 
other CMake-enabled builds for Fortran programs. As far as I know CMake picks 
the classic ifort compiler by default.

Regards,

Arjen

From: Jeremy Nesbitt 
Sent: Saturday, August 19, 2023 3:30 AM
To: plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel] Building plplot in Windows with Intel Fortran 
Compiler

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an 
attachment.

Hi,

I had some time today and figured out the issue.  CMake found the Intel IFX 
compiler first and it seemed to cause confusion about what type of compiler was 
actually being used.  I worked around this by simply using set FC=ifort and 
re-running CMake.  Was able to get everything I wanted built and tested using 
the command line tools.

I'm guessing this is not a common use case, but if it happens to others it 
might be worth updating the CMake files to handle both the Fortran compilers 
that are installed from the Intel OneAPI tools.

Thanks,
Jeremy



On Thu, Aug 17, 2023 at 9:10 AM Jeremy Nesbitt 
mailto:jrnesb...@gmail.com>> wrote:
Hi,

I would like to get plplot built in windows with intel fortran bindings using 
the Visual Studio command line.  I can get build files generated via CMake if I 
turn off fortran bindings, but if I enable fortran I always get an error when 
running CMake.  I have tried NMake, Ninja, and Visual Studio 2022 generator 
files.

In initial troubleshooting to see if this is a more general problem, I came 
across this note on the plplot site:


Intel Fortran
If you use Intel Fortran, the solution/project files may cause errors when 
building. These affect only the Fortran libraries and examples. It is due to a 
small bug in CMake that should be fixed with the next release.

Was wondering if anyone had any more information on this, such as what bug it 
is, what version of CMake it might be fixed in, and whether there is a 
workaround?  I don't know CMake at all, but if I know there is some hope to get 
tthis working I can give it a shot.

Some details if anyone cares:
-I am using CMake 3.26-msvc

For NMake, used this command
cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON 
-DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe 
-DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON

Error I get at end
-- Configuring done (29.4s)
CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library):
  Cannot find source file:

plplotfortran.def

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h
  .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc
Call Stack (most recent call first):
  bindings/fortran/CMakeLists.txt:172 (configure_library_build)


CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library):
  No SOURCES given to target: plplotfortran
Call Stack (most recent call first):
  bindings/fortran/CMakeLists.txt:172 (configure_library_build)


CMake Generate step failed.  Build files cannot be regenerated correctly.

___

What I use for Visual Studio IDE
cmake .. -G "Visual Studio 17 2022" -Ax64 -DBUILD_TEST=ON 
-DBUILD_SHARED_LIBS=ON 
-DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe 
-DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON

Error I get (Truncated as it repeats several times at the end)
-- Configuring done (201.6s)
CMake Error in bindings/fortran/CMakeLists.txt:
  Evaluation file to be written multiple times with different content.  This
  is generally caused by the content evaluating the configuration type,
  language, or location of object files:

   
C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh


CMake Error in bindings/fortran/CMakeLists.txt:
  Evaluation file to be written multiple times with different content.  This
  is generally caused by the content evaluating the configuration type,
  language, or location of object files:

   
C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh

Thanks,
Jeremy
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 

Re: [Plplot-devel] setlocale

[Arjen Markus]

Hi Hazen, Phil,

If the setting and restoring of the locale takes so much time, then would it be 
an option to use this only on the plot functions that might actually be 
affected by the locale? I have only glanced at the code and I have no idea how 
much work it would be. That would preserve the intended functionality though 
and get rid of the performance issue.

Regards,

Arjen

-Original Message-
From: Hazen Babcock via Plplot-devel 
Sent: Thursday, June 1, 2023 12:57 AM
To: plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel] setlocale

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


Github has an interesting feature which lets you browse the code and see the 
last commit that touched a particular part of the code. Using that it looks 
like saving and restoring the locale was added to the functions in src/plcore.c 
by Alan on Sep 7, 2009.

The commit message:
"""
Protect all device driver calls using the (now) reentrant plsave_set_... 
...locale

and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC locale 
and then sets the LC_NUMERIC locale to "C" for everything done by all device 
drivers.  Of course, any library called by a device driver can also change the 
locale, but we guard against such changes affecting the rest of PLplot by using 
plrestore_locale to restore the fundamental PLplot LC_NUMERIC locale saved by 
plsave_set_locale.

N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except for the 
parts like the device drivers and palette file reading that are protected by 
the combination of plsave_set_locale and plrestore_locale) to be any valid 
locale set by any application or library that calls the PLplot library.  If 
that locale specifies comma decimal separators rather than period decimal 
separators, for example, then the PLplot core will automatically use those for 
for specifying axis labels.  Those commas for axis labels are drawn by the 
PLplot core for the Hershey font device drivers or just propagate to the 
unicode device drivers as UCS4 arrays.  Thus, in both cases, we get a comma 
decimal separator for axis labels (if that is what the fundamental PLplot 
LC_NUMERIC locale calls for) independently of the logic of the present commit 
that sets the LC_NUMERIC locale to "C" for all device driver code that is 
executed.


svn path=/trunk/; revision=10383
"""

-Hazen

On 5/31/23 10:56, Phil Rosenberg wrote:
 > Sorry, I was wrong in my last email - removing the locale calls from 
 > plP_state as well (used to reset the width after a contour draw within
plshade) I ended up with a 2.5 times speed increase  >  > Phil  >  > On Mon, 29 
May 2023 at 00:38, Phil Rosenberg mailto:p.d.rosenb...@gmail.com>> wrote:
 >
 > Hi all
 > I have been making further optimisations to the wxwidgets backen, as
 > I have still been finding it painfully slow for plshade calls.
 > It turned out that almost all the time within the backend (>99%) was
 > spent selecting pens and brushes and allocating memory for every
 > fill within the plshade call. Less that 1% was actually spent within
 > the rendering call to wxWidgets. I have made some good improvements
 > here.
 >
 > However, in addition to this, about 50% of the total execution time
 > is spent in the setlocale function. This is called before and after
 > each polygon fill in the core plplot code.
 >
 > I wondered if anyone really knows the purpose of these calls?
 > Perhaps they are to ensure we have consistent numeric
 > representations across regions? If so, then I don't really
 > understand why they are needed for polygon fills.
 >
 > Any thoughts would be welcome
 > Phil
 >
 >
 >
 > ___
 > Plplot-devel mailing list
 > Plplot-devel@lists.sourceforge.net
 > https://lists.sourceforge.net/lists/listinfo/plplot-devel



On 5/31/23 10:56, Phil Rosenberg wrote:
> Sorry, I was wrong in my last email - removing the locale calls from
> plP_state as well (used to reset the width after a contour draw within
> plshade) I ended up with a 2.5 times speed increase
>
> Phil
>
> On Mon, 29 May 2023 at 00:38, Phil Rosenberg  > wrote:
>
> Hi all
> I have been making further optimisations to the wxwidgets backen, as
> I have still been finding it painfully slow for plshade calls.
> It turned out that almost all the time within the backend (>99%) was
> spent selecting pens and brushes and allocating memory for every
> fill within the plshade call. Less that 1% was actually spent within
> the rendering call to wxWidgets. I have made some good improvements
> here.
>
> However, in addition to this, about 50% of the total 

Re: [Plplot-devel] bug in notpointinpolygon

[Arjen Markus]

Hi Phil,

Thanks for analysing this. In the past I have seen awkward fills as well. The 
code is rather tricky and it seems you have uncovered yet another case where 
things may go wrong. The test suite should be able to capture if anything 
breaks with your change. So, if that is not the case, then go ahead merging it, 
I’d say.

Regards,

Arjen

From: Phil Rosenberg 
Sent: donderdag 11 mei 2023 22:42
To: PLplot development list 
Subject: Re: [Plplot-devel] bug in notpointinpolygon

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an 
attachment.

I have managed to further isolate the issue and I've attached a minimum 
example. Internal integer pixel units are a factor, so it might not show up on 
all devices. This example shows up the error on my Windows machine with the 
wxWidgets device.

The example draws a single rectangle using plfill, but the rectangle itself is 
well outside the range of the axes. Despite the position of the rectangle, the 
result is that the whole plot area is filled.

The bug occurs when drawing polygons with a very high aspect ratio (tall and 
thin), outside the plot area in certain positions. It may even only happen for 
polygons one internal plot unit wide.

As part of the plP_plfclp code, we check if each of the bottom left corner of 
the plot area is within the polygon and if no edges of the polygon intersect 
the plot area. If both these conditions are true, the polygon must cover the 
whole plot area, so we fill it all. To check if the bottom left corner is 
within the polygon, we trace a ray from that point in a particular direction. 
If the ray crosses an even number of polygon edges the point is external and if 
it crosses an odd number of edges then the point is internal. The crossings are 
checked by a function called notcrossed and they are accumulated over a whole 
polygon by a function called notpointinpolygon.

However, there is some ambiguity due to floating point arithmetic when lines 
are close to parallel and intersections are close to vertices. Hence, 
notcrossed can return 0 (crossed) 1 (notcrossed) and a series of other values 
indicating that we are uncertain if we have crossed or not. One of those return 
values is PL_NEAR_PARALLEL(32), however, notpointinpolygon does not check for 
this and counts it as true, i.e. not crossed. In almost all scenarios, the 
return of PL_NEAR_PARALLEL for one edge, results in a PL_NEAR_POINT (where 
POINT is A1, A2, B1 or B2) return for another edge. This return value is picked 
up by notpointinpolygon and is reflected in its return value, so this bug 
almost never manifests.

However, it turns out that a polygon edge with size of 1 internal unit, if 
intersected, will always generate a PL_NEAR_PARALLEL return value, even if the 
lines are close to perpendicular. this is treated as not crossed. If the 
polygon has a large aspect ratio, the ray can intersect another edge 
significantly far from its ends that it does not trigger a PL_NEAR_POINT return 
value. notpointinpolygon therefore misses one edge intersection and incorrectly 
thinks the point is in the polygon.

Where this happens for the bottom left corner, and no edges cross the plot area 
we end up filling the whole box. Although it might seem like this is very 
unlikely, if you use plshades to do a contour plot  with very fine horizontal 
resolution and much coarser vertical resolution and zoom in on the y axis to 
crop some of the data out, then it turns out to be almost inevitable that at 
least one polygon will trigger the problem. In my case I'm plotting data from a 
meteorological lidar - high temporal resolution, coarser vertical resolution.

To fix this I've written an optimised version of notcrossed, called 
notcrossedhorizontalray. This uses a horizontal ray rather than a ray to a 
point near the polygon. It uses entirely boolean logic and integer maths except 
for one division, so it should be accurate. I updated notpointinpolygon to use 
the new function and recognise the unsure case. I added some extra checks in 
plP_plfclp. I attach a patch if anyone wants to test it. Clearly I'm not the 
first person to wrestle with this code as there is another commented out 
version. In my code USE_FILL_INTERSECTION_POLYGON is not defined, so there is a 
large chunk of code unused. I don't know if this gets used in some builds, but 
maybe it could be cleaned up if not.

If nobody objects I will commit the change to the repo

Thanks
Phil

On Wed, 10 May 2023 at 10:38, Phil Rosenberg 
mailto:p.d.rosenb...@gmail.com>> wrote:
Hi again
I just found a bug in plP_plfclp.

I hit a scenario where during a plshades call, my whole window (including 
outside the x and y limits of the data) got filled with one of the colours. 
I've traced 

Re: [Plplot-devel] [PATCH] drivers/wingdi: Fix compiling in 64-bit Windows system

[Arjen Markus]

Hi,

Thanks for this patch. I will apply it. Is GCLP_HCURSOR also available under 
32-bits?

Regards,

Arjen

-Original Message-
From: Biswapriyo Nath 
Sent: 28 March 2023 08:06
To: plplot-devel@lists.sourceforge.net
Subject: [Plplot-devel] [PATCH] drivers/wingdi: Fix compiling in 64-bit Windows 
system

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


This replaces GCL_HCURSOR with GCLP_HCURSOR because the previous one is 
undefined in 64-bit Windows SDK and in mingw-w64 toolchain. Hence, fixes the 
following compiler error.

plplot/drivers/wingdi.c: In function 'CrossHairCursor':
plplot/drivers/wingdi.c:201:33: error: 'GCL_HCURSOR' undeclared (first use in 
this function); did you mean 'GCLP_HCURSOR'?
  201 | SetClassLongPtr( dev->plot, GCL_HCURSOR, (long) cursor );
  | ^~~
  | GCLP_HCURSOR

Signed-off-by: Biswapriyo Nath 
---
 drivers/wingdi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/wingdi.c b/drivers/wingdi.c index b81778a..6731ff6 100644
--- a/drivers/wingdi.c
+++ b/drivers/wingdi.c
@@ -198,7 +198,7 @@ CrossHairCursor( struct wingdi_Dev * dev )
 HCURSOR cursor;

 cursor = LoadCursor( NULL, IDC_CROSS );
-SetClassLongPtr( dev->plot, GCL_HCURSOR, (long) cursor );
+SetClassLongPtr( dev->plot, GCLP_HCURSOR, (LONG_PTR) cursor );
 return SetCursor( cursor );
 }

@@ -208,7 +208,7 @@ NormalCursor( struct wingdi_Dev * dev )
 HCURSOR cursor;

 cursor = LoadCursor( NULL, IDC_ARROW );
-SetClassLongPtr( dev->plot, GCL_HCURSOR, (LONG_PTR) cursor );
+SetClassLongPtr( dev->plot, GCLP_HCURSOR, (LONG_PTR) cursor );
 SetCursor( cursor );
 }

@@ -218,7 +218,7 @@ BusyCursor( struct wingdi_Dev * dev )
 HCURSOR cursor;

 cursor = LoadCursor( NULL, IDC_WAIT );
-SetClassLongPtr( dev->plot, GCL_HCURSOR, (LONG_PTR) cursor );
+SetClassLongPtr( dev->plot, GCLP_HCURSOR, (LONG_PTR) cursor );
 SetCursor( cursor );
 }

--
2.40.0



___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel=05%7C01%7C%7Cc3a0fe55c1354907a80d08db2f529dde%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C638155804121464716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pr0ioI2caWsjjXuw2YtowMrZ7QoX120llWaeWcOYtw4%3D=0
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Deprecated operator in the Octave binding

[Arjen Markus]

Hi Rafael,

Quick update:
I just checked: Cygwin does not seem to have updates for these two packages. I 
will have to look at some other platforms.

Regards,

Arjen

-Original Message-
From: Rafael Laboissière 
Sent: 05 January 2023 10:36
To: PLplot development list 
Subject: Re: [Plplot-devel] Deprecated operator in the Octave binding

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


* Arjen Markus  [2022-12-29 13:32]:

> I am currently trying to incorporate the patches you sent, but I am running 
> into a problem with Octave. Here is the start of a whole series of error 
> messages:
>
>  [ 16%] Swig compile plplot_octave.i for octave  [ 16%] Built target
> plplot_octave_swig_compilation  [ 17%] Building CXX object
> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.
> cxx.o
>  
> /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:31:
>  error: 'oct_mach_info' has not been declared
>  1768 |   oct_mach_info::float_format fmt) {
>   |   ^
>  
> /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:59:
>  error: expected ',' or '...' before 'fmt'
>  1768 |   oct_mach_info::float_format fmt) {
>   |   ^~~
>  
> /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
>  In member function 'octave_value_list 
> octave_swig_type::member_deref(octave_swig_type::member_value_pair*, const 
> octave_value_list&)':
>  
> /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1044:94:
>  error: invalid new-expression of abstract class type 'octave_swig_bound_func'
>  1044 | #define SWIG_OCTAVE_BOUND_FUNC(func, args) octave_value(new 
> octave_swig_bound_func(func, args))
>   |   
>^
>  /
>
> I have no idea how to solve this, so I am hoping you or somebody else 
> familiar with Octave and SWIG can give me a few pointers, or better still, a 
> patch to solve this.
>
> For your information:
>
>  - SWIG: version 4.0.2
>  - Octave: version 6.4.0
>  - I am building this under Cygwin with all the packages updated to the 
> current versions.

It works for me with these versions:

  - SWIG 4.1.0
  - Octave 7.3.0

Could you please test with them?

> By the way, under Cygwin I do not seem to have a useable Ada compiler,
> so I cannot test the changes that you and Nicolas suggested. But to
> keep them in line with the rest, I have now implemented the building
> of the static library as:
>
>  if(ENABLE_ada_static)
>set(ADA_lib_type "STATIC")
>  else(ENABLE_ada_static)
>set(ADA_lib_type "")
>  endif(ENABLE_ada_static)
>
>  # target_link_libraries used in special way below so avoid using it inside 
> configure_library_build.
>  configure_library_build(plplotada ${ADA_lib_type}
> "${plplotada_BODY_SRCS}" "" "${LIB_INSTALL_RPATH}")
>
> so that, if you add the option "-DENABLE_ada_static=ON" to the CMake command 
> line you will get the static library. So, there will be  either a static or a 
> dynamic (shared) library.
>
> I have not checked in these changes yet, but this is what I intend to do.

The ideal situation would be to allow users to enable both static and dynamic, 
if they wish so.  Is this what you are intending to do?

Best,

Rafael


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel=05%7C01%7C%7Ca00a15b047b147e6c14608daef0055b2%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C638085081986053924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=N2g8cx3xw2q%2FlhWKsiJQsk%2BHE4XiwuUHGpl52te3D5M%3D=0
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Deprecated operator in the Octave binding

[Arjen Markus]

I have more luck with MinGW-w64/MSYS2: SWIG 4.1.1 and Octave 7.3.0. I will try 
those then.

Regards,

Arjen

-Original Message-
From: Arjen Markus
Sent: 10 January 2023 15:44
To: Rafael Laboissière ; PLplot development list 

Subject: RE: [Plplot-devel] Deprecated operator in the Octave binding

Hi Rafael,

Quick update:
I just checked: Cygwin does not seem to have updates for these two packages. I 
will have to look at some other platforms.

Regards,

Arjen

-Original Message-
From: Rafael Laboissière 
Sent: 05 January 2023 10:36
To: PLplot development list 
Subject: Re: [Plplot-devel] Deprecated operator in the Octave binding

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


* Arjen Markus  [2022-12-29 13:32]:

> I am currently trying to incorporate the patches you sent, but I am running 
> into a problem with Octave. Here is the start of a whole series of error 
> messages:
>
>  [ 16%] Swig compile plplot_octave.i for octave  [ 16%] Built target
> plplot_octave_swig_compilation  [ 17%] Building CXX object
> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.
> cxx.o
>  
> /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:31:
>  error: 'oct_mach_info' has not been declared
>  1768 |   oct_mach_info::float_format fmt) {
>   |   ^
>  
> /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:59:
>  error: expected ',' or '...' before 'fmt'
>  1768 |   oct_mach_info::float_format fmt) {
>   |   ^~~
>  
> /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
>  In member function 'octave_value_list 
> octave_swig_type::member_deref(octave_swig_type::member_value_pair*, const 
> octave_value_list&)':
>  
> /cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1044:94:
>  error: invalid new-expression of abstract class type 'octave_swig_bound_func'
>  1044 | #define SWIG_OCTAVE_BOUND_FUNC(func, args) octave_value(new 
> octave_swig_bound_func(func, args))
>   |   
>^
>  /
>
> I have no idea how to solve this, so I am hoping you or somebody else 
> familiar with Octave and SWIG can give me a few pointers, or better still, a 
> patch to solve this.
>
> For your information:
>
>  - SWIG: version 4.0.2
>  - Octave: version 6.4.0
>  - I am building this under Cygwin with all the packages updated to the 
> current versions.

It works for me with these versions:

  - SWIG 4.1.0
  - Octave 7.3.0

Could you please test with them?

> By the way, under Cygwin I do not seem to have a useable Ada compiler,
> so I cannot test the changes that you and Nicolas suggested. But to
> keep them in line with the rest, I have now implemented the building
> of the static library as:
>
>  if(ENABLE_ada_static)
>set(ADA_lib_type "STATIC")
>  else(ENABLE_ada_static)
>set(ADA_lib_type "")
>  endif(ENABLE_ada_static)
>
>  # target_link_libraries used in special way below so avoid using it inside 
> configure_library_build.
>  configure_library_build(plplotada ${ADA_lib_type}
> "${plplotada_BODY_SRCS}" "" "${LIB_INSTALL_RPATH}")
>
> so that, if you add the option "-DENABLE_ada_static=ON" to the CMake command 
> line you will get the static library. So, there will be  either a static or a 
> dynamic (shared) library.
>
> I have not checked in these changes yet, but this is what I intend to do.

The ideal situation would be to allow users to enable both static and dynamic, 
if they wish so.  Is this what you are intending to do?

Best,

Rafael


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel=05%7C01%7C%7Ca00a15b047b147e6c14608daef0055b2%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C638085081986053924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=N2g8cx3xw2q%2FlhWKsiJQsk%2BHE4XiwuUHGpl52te3D5M%3D=0
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 de

Re: [Plplot-devel] Run Octave non-interactive tests with the --no-gui option

[Arjen Markus]

Hi Rafael,

Thanks for this update. I will try and test the Octave and SWIG versions you 
mentioned today or within the next few days. (I am currently limited to 
Windows-based environments - Cygwin and MinGW, as well as basic Windows - so I 
may not have access to these versions. But wewill see.)

Regards,

Arjen

-Original Message-
From: Rafael Laboissière 
Sent: 07 January 2023 21:43
To: PLplot development list 
Subject: Re: [Plplot-devel] Run Octave non-interactive tests with the --no-gui 
option

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


* Rafael Laboissière  [2023-01-05 16:22]:

> When running the non-interactive tests for the Octave binding, it is
> preferable to run them with the --no-gui option of octave. This allows
> headless systems (without access to an X server) to run the tests.
> This is the case for the autobuilders of Debian. BTW, I am currently
> applying the patch attached to this message to the Debian package for
> PLplot and you might be interested in applying it to the PLplot source
> as well.

Please, consider the improved version of the patch attached to this message. 
Besides the --no-gui option, it also passes option --no-window-system to 
Octave, what is the appropriate for running the tests on headless systems.

Best,

Rafael Laboissière
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Deprecated operator in the Octave binding

[Arjen Markus]

Hi Rafael,

I am currently trying to incorporate the patches you sent, but I am running 
into a problem with Octave. Here is the start of a whole series of error 
messages:

[ 16%] Swig compile plplot_octave.i for octave
[ 16%] Built target plplot_octave_swig_compilation
[ 17%] Building CXX object 
bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
/cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:31:
 error: ‘oct_mach_info’ has not been declared
 1768 |   oct_mach_info::float_format fmt) {
  |   ^
/cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1768:59:
 error: expected ‘,’ or ‘...’ before ‘fmt’
 1768 |   oct_mach_info::float_format fmt) {
  |   ^~~
/cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
 In member function ‘octave_value_list 
octave_swig_type::member_deref(octave_swig_type::member_value_pair*, const 
octave_value_list&)’:
/cygdrive/d/plplot-svn/build-cygwin/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1044:94:
 error: invalid new-expression of abstract class type ‘octave_swig_bound_func’
 1044 | #define SWIG_OCTAVE_BOUND_FUNC(func, args) octave_value(new 
octave_swig_bound_func(func, args))
  | 
 ^
/

I have no idea how to solve this, so I am hoping you or somebody else familiar 
with Octave and SWIG can give me a few pointers, or better still, a patch to 
solve this.

For your information:
- SWIG: version 4.0.2
- Octave: version 6.4.0
- I am building this under Cygwin with all the packages updated to the current 
versions.

By the way, under Cygwin I do not seem to have a useable Ada compiler, so I 
cannot test the changes that you and Nicolas suggested. But to keep them in 
line with the rest, I have now implemented the building of the static library 
as:


  if(ENABLE_ada_static)
set(ADA_lib_type "STATIC")
  else(ENABLE_ada_static)
set(ADA_lib_type "")
  endif(ENABLE_ada_static)

  # target_link_libraries used in special way below so avoid using it inside 
configure_library_build.
  configure_library_build(plplotada ${ADA_lib_type} "${plplotada_BODY_SRCS}" "" 
"${LIB_INSTALL_RPATH}")

so that, if you add the option "-DENABLE_ada_static=ON" to the CMake command 
line you will get the static library. So, there will be  either a static or a 
dynamic (shared) library.

I have not checked in these changes yet, but this is what I intend to do.

Regards,

Arjen


-Original Message-
From: Rafael Laboissière 
Sent: 26 December 2022 19:38
To: PLplot development list 
Subject: [Plplot-devel] Deprecated operator in the Octave binding

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


Dear PLplot developers,

SWIG support for Octave 6.0 was broken, but this has been fixed in release 4.1. 
I am therefore planning to reintroduce the plplot-octave package in Debian.

When compiling the package against Octave 7, several warnings regarding 
operators .- and .+ are issued, like this one:

 warning: the '.-' operator was deprecated in version 7 and will not be 
allowed in a future version of Octave; please use '-' instead;

Please, find attached to this message a patch that fixes the problem.

Best,

Rafael Laboissière
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Build a static version of libplplotada

[Arjen Markus]

Hi Nicolas,

Thanks for this information. The original patch had some Debian-specific 
environment variables, so I started to wonder about the relation to the Debian 
platform. I will have a closer look at this.

Regards,

Arjen

-Original Message-
From: Nicolas Boulenguez 
Sent: 19 December 2022 11:55
To: Arjen Markus 
Cc: Rafael Laboissière ; PLplot development list 

Subject: Re: [Plplot-devel] Build a static version of libplplotada

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


Hello.

These suggestions are not specific to Debian or Ada.

The most common kind of libraries is shared/relocatable (.so/dll/...), but some 
people may want a static library (.a/.o/...) or more exotic choices (static-pic 
for example).

Currently, plplotada builds a shared library.  This is good.

CMake seems able to also build a static library.  As far as I understand 
Rafael's commit, adding the following line into bindings/ada/CMakeLists.txt 
tells CMake to build *both* the shared and static library.

  configure_library_build(plplotada_static STATIC "${plplotada_BODY_SRCS}" "" 
"${LIB_INSTALL_RPATH}")

Debian is happy with this, but this is probably not a satisfying default.  I 
suggest to make the static library an opt-in option.

if(enable_ADA_STATIC)
  # Also build the static library
  configure_library_build(plplotada_static STATIC "${plplotada_BODY_SRCS}" "" 
"${LIB_INSTALL_RPATH}")
endif(enable_ADA_STATIC)

The ideal would be to allow any combination through an explicit configure 
option for each library kind.  I do not know how easy it would be, and this is 
not useful to Debian right now.

By the way, does this trivial change not fix the renaming issue?

  configure_library_build(plplotada STATIC "${plplotada_BODY_SRCS}" "" 
"${LIB_INSTALL_RPATH}")
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Build a static version of libplplotada

[Arjen Markus]

Hi Rafael,

I am looking into the patches and suggestions you sent. This is specific to 
Debian, you say, so the new code is to be run on Debian only. What would be an 
appropriate check that we are running on this platform? (I have no experience 
with building the Ada package or  with Ada at all, nor  have I access to a 
Debian platform.)

Regards,

Arjen

-Original Message-
From: Rafael Laboissière 
Sent: 08 December 2022 12:10
To: PLplot development list 
Cc: Nicolas Boulenguez 
Subject: [Plplot-devel] Build a static version of libplplotada

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


Dear PLplot developers,

We are currently applying the patch attached below when building the Debian 
package for PLplot. It allows the creation of a static version of libplplotada, 
what is recommended to meet the Ada standards in Debian.

This solution is not ideal, because the new target libplplotada_static.a is 
created and later, in debian/rules, the following is needed in target 
execute_after_dh_auto_install (see [1]):

mv debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada_static.a \
   debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada.a

My knowledge of CMake is too scarce and I could not figure out how to avoid the 
renaming above.

According to Nicolas Boulenguez, this change could be accompanied by a new 
configuration option :

 shared_library  *yes/no
 static_library  yes/*no

This schema could allow one to add a static-pic in the future.

Best,

Rafael Laboissière

  [1] 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fscience-team%2Fplplot%2F-%2Fcommit%2F82895090f80180bd1d085e03fb09056e31138e92data=05%7C01%7C%7C46d0b47393524d4aaadd08dad90e4c70%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C638060952705369812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=c2%2FlFMScn3wHgzmnAChlQSrKoN4%2FnqWuGSn2i100x6c%3Dreserved=0
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Build a static version of libplplotada

[Arjen Markus]

Hi Rafael,

Thanks for the patches. I will try and apply them in the coming few days. I 
have not seen any other replies and was away myself, so my reply is a trifle 
late.

Regards,

Arjen

-Original Message-
From: Rafael Laboissière 
Sent: 08 December 2022 12:10
To: PLplot development list 
Cc: Nicolas Boulenguez 
Subject: [Plplot-devel] Build a static version of libplplotada

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


Dear PLplot developers,

We are currently applying the patch attached below when building the Debian 
package for PLplot. It allows the creation of a static version of libplplotada, 
what is recommended to meet the Ada standards in Debian.

This solution is not ideal, because the new target libplplotada_static.a is 
created and later, in debian/rules, the following is needed in target 
execute_after_dh_auto_install (see [1]):

mv debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada_static.a \
   debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libplplotada.a

My knowledge of CMake is too scarce and I could not figure out how to avoid the 
renaming above.

According to Nicolas Boulenguez, this change could be accompanied by a new 
configuration option :

 shared_library  *yes/no
 static_library  yes/*no

This schema could allow one to add a static-pic in the future.

Best,

Rafael Laboissière

  [1] 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fscience-team%2Fplplot%2F-%2Fcommit%2F82895090f80180bd1d085e03fb09056e31138e92data=05%7C01%7C%7C46d0b47393524d4aaadd08dad90e4c70%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C638060952705369812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=c2%2FlFMScn3wHgzmnAChlQSrKoN4%2FnqWuGSn2i100x6c%3Dreserved=0
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] CMake fails to detect NaN for Fortran

[Arjen Markus]

Hi Rafael,

I overlooked the patch you attached. This is certainly a workaround, but the 
function isnan (in the guise of myisnan) is called by a single example only. 
Like I stated, most compilers support the ieee_is_nan standard function 
nowadays, so I suggest we clean this up more thoroughly.

Regards,

Arjen (slightly distracted by pressing matters, not a good time to answer 
e-mails like this)

-Original Message-
From: Rafael Laboissière 
Sent: 30 November 2022 12:40
To: PLplot development list 
Subject: [Plplot-devel] CMake fails to detect NaN for Fortran

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


Dear PLplot developers,

When building the plplot package for Debian, using the latest version of 
gfortran:

 $ gfortran --version | head -n1
 GNU Fortran (Debian 12.2.0-9) 12.2.0

The CMake configuration fails to detect the NaN capability:

 -- Check if isnan function is available in fortran
 -- Check for isnan in fortran - not found

I see the following in CMakeFiles/CMakeError.log:

 Determining if fortran has isnan function failed with the following output:
 Change Dir: [path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

 Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_58c30/fast && 
gmake[2]: Entering directory 
'[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
 /usr/bin/gmake  -f CMakeFiles/cmTC_58c30.dir/build.make 
CMakeFiles/cmTC_58c30.dir/build
 gmake[3]: Entering directory 
'[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
 Building Fortran object CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
 /usr/bin/gfortran   -g -O2 -ffile-prefix-map=[path]/plplot=. 
-fstack-protector-strong -fvisibility=hidden  -c 
[path]/plplot/cmake/modules/TestFortran
 Isnan.f -o CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
 [path]/plplot/cmake/modules/TestFortranIsnan.f:5:19:

 5 |   if (isnan(0.0/0.0)) then
   |   1
 Error: Division by zero at (1)
 [path]/plplot/cmake/modules/TestFortranIsnan.f:7:9:

 7 |   endif
   | 1
 Error: Expecting END PROGRAM statement at (1)
 gmake[3]: *** [CMakeFiles/cmTC_58c30.dir/build.make:78: 
CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o] Error 1

The patch attached to this message fixes the problem. I think that the problems 
arises because the gfortran compiler is trying to do the computation "0.0/0.0" 
at compile-time.

Best,

Rafael Laboissière
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] CMake fails to detect NaN for Fortran

[Arjen Markus]

Hi Rafael,

Hm, that means that the compiler detects the problem at compile time. As 
compilers get better all the time, shortcuts like these will fail from time to 
time. I would have to investigate what the best way is to solve this. (Most 
compilers support the standard function ieee_is_nan() now, so I suspect this 
check is superfluous or needs to be transformed altogether.)

Regards,

Arjen


-Original Message-
From: Rafael Laboissière 
Sent: 30 November 2022 12:40
To: PLplot development list 
Subject: [Plplot-devel] CMake fails to detect NaN for Fortran

Caution: This message was sent from outside of Deltares. Please do not click 
links or open attachments unless you recognize the source of this email and 
know the content is safe. Please report all suspicious emails to 
"servicedesk-...@deltares.nl" as an attachment.


Dear PLplot developers,

When building the plplot package for Debian, using the latest version of 
gfortran:

 $ gfortran --version | head -n1
 GNU Fortran (Debian 12.2.0-9) 12.2.0

The CMake configuration fails to detect the NaN capability:

 -- Check if isnan function is available in fortran
 -- Check for isnan in fortran - not found

I see the following in CMakeFiles/CMakeError.log:

 Determining if fortran has isnan function failed with the following output:
 Change Dir: [path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

 Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_58c30/fast && 
gmake[2]: Entering directory 
'[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
 /usr/bin/gmake  -f CMakeFiles/cmTC_58c30.dir/build.make 
CMakeFiles/cmTC_58c30.dir/build
 gmake[3]: Entering directory 
'[path]/plplot/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
 Building Fortran object CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
 /usr/bin/gfortran   -g -O2 -ffile-prefix-map=[path]/plplot=. 
-fstack-protector-strong -fvisibility=hidden  -c 
[path]/plplot/cmake/modules/TestFortran
 Isnan.f -o CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o
 [path]/plplot/cmake/modules/TestFortranIsnan.f:5:19:

 5 |   if (isnan(0.0/0.0)) then
   |   1
 Error: Division by zero at (1)
 [path]/plplot/cmake/modules/TestFortranIsnan.f:7:9:

 7 |   endif
   | 1
 Error: Expecting END PROGRAM statement at (1)
 gmake[3]: *** [CMakeFiles/cmTC_58c30.dir/build.make:78: 
CMakeFiles/cmTC_58c30.dir/TestFortranIsnan.f.o] Error 1

The patch attached to this message fixes the problem. I think that the problems 
arises because the gfortran compiler is trying to do the computation "0.0/0.0" 
at compile-time.

Best,

Rafael Laboissière
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Native build problems when cross-compiling PLplot

[Arjen Markus]

Hi Sebastian,

Alan informed me about earlier experiences with cross-compilation. I copy his 
answer below:

===
Hi Arjen:

Andrew Ross got cross-compilation to work (with some limitations) back in 2009. 
 I suggest if you haven't done so already you review that mailing list thread 
(which you can find with a subject line search for "cross compilation" in the 
plplot_devel mailing list archive at SF).

Andrew commented in that thread that he had documented some of his 
cross-compilation experiences in our old wiki.  All the contents of that old 
wiki were transferred to our SF wiki back when I established that SF wiki so 
his (dated) documentation/comments about cross-compilation should be accessible 
at our SF wiki.  Indeed, if you search there, there are 7 wiki pages that 
mention "cross" so if you follow up on those hits (which I did not) I assume 
you will find what Andrew (and others?) wrote about cross compilation back in 
2009 or so.

Of course, if you make some modern progress with cross-compilation, please 
update the SF wiki accordingly following the wiki update procedure in 
README.developers.

Cheers,

Alan
===

I have not had time yet to look into this information or the mailing list's 
archive.

Regards,

Arjen



-Original Message-
From: Sebastian Ehlert 
Sent: 24 February 2022 12:15
To: plplot-devel@lists.sourceforge.net
Subject: [Plplot-devel] Native build problems when cross-compiling PLplot

Hi everybody,

I'm currently trying to cross-compile PLplot for Linux/ppc64le,
Linux/aarch64 and MacOS/arm64 using the conda-forge toolchain [1].

[1]:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fconda-forge%2Fplplot-feedstock%2Fpull%2F1data=04%7C01%7C%7C2ffc86b57cc94f978ced08d9f787029c%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637812981507864811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=NP%2F81%2BvuCTVIY6lONGAiDo%2Ff6BKxJVemV0s%2F2hO%2BP%2BU%3Dreserved=0

>From the PLplot wiki [2] I figured I need a native build first, to get access 
>to some intermediary binaries, which are than used in a cross build done in a 
>second step. However, getting the native build running in the cross 
>environment is giving me some grief. Linking lib/qsastime/tai-utc-gen in the 
>native build fails for me because I can't get CMake to *not* find and *not* 
>prefer the sysroot of cross- compiler (pc_libplplot_LINK_FLAGS is including 
>the libm for the host platform).

[2]:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fplplot%2Fwiki%2FBuilding_PLplot_with_a_cross-compiler%2Fdata=04%7C01%7C%7C2ffc86b57cc94f978ced08d9f787029c%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C1%7C637812981507864811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ygGiPYPnsA57l4xNzMut1kuit6QcmWOgADzapiNu2F4%3Dreserved=0

What I can't do is have two different environments here (native first and cross 
later), because I run inside conda-build to make the packaging automatic with 
the conda-forge toolchain for future PLplot releases. While I can install a 
native PLplot version and point to its prefix, this is insufficient to get 
lib/qsastime/tai-utc-gen and co for the cross build.

I attached the log from the last build on Linux/aarch64, but you can also find 
the logs online at Azure [1]. Note that I can run the Linux builds with QEMU if 
cross-compiling is not possible (it is just very slow), but I can't use 
hardware emulation for the MacOS/arm64 host.

Any pointers, tips or tricks are much appreciated.

All the best
Sebastian
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Cross-compilation of PLplot

[Arjen Markus]

Hi Alan,

Thanks for this information - I will look up these pages (and forward this 
information to Sebastian ).

Regards,

Arjen

-Original Message-
From: Alan W. Irwin 
Sent: 23 February 2022 21:50
To: Arjen Markus 
Cc: PLplot development list 
Subject: Re: [Plplot-devel] Cross-compilation of PLplot

On 2022-02-23 07:23- Arjen Markus wrote:

> Hi,
>
> Sebastian Ehlert asked me about cross-compilation of PLplot for different 
> platforms as part of cond-forge/plplot-feedstock. He found out that this 
> needs to be done in two steps, one to build the auxiliary programs for use on 
> the native platform and the second for the actual cross-compilation. Does 
> anyone have experience with this? What procedure would you recommend? Is 
> there an easy way to make this build scenario easier?

Hi Arjen:

Andrew Ross got cross-compilation to work (with some limitations) back in 2009. 
 I suggest if you haven't done so already you review that mailing list thread 
(which you can find with a subject line search for "cross compilation" in the 
plplot_devel mailing list archive at SF).

Andrew commented in that thread that he had documented some of his 
cross-compilation experiences in our old wiki.  All the contents of that old 
wiki were transferred to our SF wiki back when I established that SF wiki so 
his (dated) documentation/comments about cross-compilation should be accessible 
at our SF wiki.  Indeed, if you search there, there are 7 wiki pages that 
mention "cross" so if you follow up on those hits (which I did not) I assume 
you will find what Andrew (and others?) wrote about cross compilation back in 
2009 or so.

Of course, if you make some modern progress with cross-compilation, please 
update the SF wiki accordingly following the wiki update procedure in 
README.developers.

Cheers,

Alan

__
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy, University 
of Victoria, Victoria, BC, Canada.

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.org); 
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.

___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Cross-compilation of PLplot

[Arjen Markus]

Hi,

Sebastian Ehlert asked me about cross-compilation of PLplot for different 
platforms as part of cond-forge/plplot-feedstock. He found out that this needs 
to be done in two steps, one to build the auxiliary programs for use on the 
native platform and the second for the actual cross-compilation. Does anyone 
have experience with this? What procedure would you recommend? Is there an easy 
way to make this build scenario easier?

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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] D language support topic

[Arjen Markus]

Hi Alan,

I have the first results from this exercise. I will send the details in an 
off-list message, but the short story is that CMake seems to choke on 
generating the makefiles when support for D is included. From my inspection of 
the output files the reason for the failure is not at all clear. The D bindings 
are turned on but then CMake tells me something went wrong during the last 
stage, writing the actual makefiles.

Regards,

Arjen

-Original Message-
From: Alan W. Irwin 
Sent: 02 September 2019 12:27
To: Arjen Markus 
Cc: Takeshi Enomoto ; PLplot development list 

Subject: RE: [Plplot-devel] D language support topic

On 2019-09-02 07:47- Arjen Markus wrote:

> Hi Alan,
>
> I will have a look at this - I have built CMake before, that should not be a 
> problem . I have no experience, however, with the D compiler you mention.

Hi Arjen:

Thanks for your willingness to do the requested test_d tests on MSYS2 with dmd. 
 The results of those tests should help me to get our CMake D language support 
working correctly for the Windows-dmd case for both test_d and PLplot.

Alan

>
> -Original Message-
> From: Alan W. Irwin 
> Sent: 01 September 2019 01:40
> To: Takeshi Enomoto ; Arjen Markus
> ; PLplot development list
> 
> Subject: Re: [Plplot-devel] D language support topic
>
> To Takeshi and Arjen:
>
> I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this
> topic to the PLplot master branch at SourceForge.  This new D language
> support (see README.release for details) works perfectly on Linux (all
> comprehensive tests have passed perfectly on my Debian Buster
> platform), and I hope Takeshi (who contributed part of the changes
> that have gone into this push) would be willing to test this new D
> language support for PLplot on the MacPorts platform and Arjen on the
> MSYS2 platform.
>
> @Takeshi: as MacPorts maintainer of the plplot package for that distribution, 
> this push cannot help you immediately with dmd because the push only works 
> for that compiler if you have first built an extremely recent version of 
> CMake, and it will take quite a while until that recent version of CMake 
> propagates officially to MacPorts.
> But if you are still interested in testing for your future dmd MacPorts 
> benefit (or want to test gdc instead which should work with the current 
> official MacPorts version of CMake), then please follow the directions in 
> cmake/test_d/README (which include building an extremely recent version of 
> CMake to use for all testing) to generate a report tarball in the two ways 
> requested so I can analyze those results and adjust the "Darwin" Platform 
> files accordingly.
>
> @Arjen: the only D compiler you have access to on Windows is one you download 
> for yourself [from Digital 
> Mars](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdlang.org%2Fdownload.htmldata=02%7C01%7C%7C109db2fc5d8c42715d0308d72f90094d%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637030167988327359sdata=ZWqaEu0F4OLFU0m6yjhdjTn%2FuyI3KvPd1WUdGKGGdaI%3Dreserved=0).
> I would appreciate you testing our new D language support on MSYS2 with that 
> compiler.
> As in Takeshi's case I suggest you start with the test_d project for an 
> extremely recent version of CMake from its git master branch that you have 
> built yourself.
>
> Alan
> __
> Alan W. Irwin
>
> 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.org); 
> 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.
>

__
Alan W. Irwin

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.org); 
the libLAS

Re: [Plplot-devel] D language support topic

[Arjen Markus]

Hi Alan,

I will have a look at this - I have built CMake before, that should not be a 
problem . I have no experience, however, with the D compiler you mention.

Regards,

Arjen


-Original Message-
From: Alan W. Irwin 
Sent: 01 September 2019 01:40
To: Takeshi Enomoto ; Arjen Markus 
; PLplot development list 

Subject: Re: [Plplot-devel] D language support topic

To Takeshi and Arjen:

I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this topic to 
the PLplot master branch at SourceForge.  This new D language support (see 
README.release for details) works perfectly on Linux (all comprehensive tests 
have passed perfectly on my Debian Buster platform), and I hope Takeshi (who 
contributed part of the changes that have gone into this push) would be willing 
to test this new D language support for PLplot on the MacPorts platform and 
Arjen on the
MSYS2 platform.

@Takeshi: as MacPorts maintainer of the plplot package for that distribution, 
this push cannot help you immediately with dmd because the push only works for 
that compiler if you have first built an extremely recent version of CMake, and 
it will take quite a while until that recent version of CMake propagates 
officially to MacPorts.
But if you are still interested in testing for your future dmd MacPorts benefit 
(or want to test gdc instead which should work with the current official 
MacPorts version of CMake), then please follow the directions in 
cmake/test_d/README (which include building an extremely recent version of 
CMake to use for all testing) to generate a report tarball in the two ways 
requested so I can analyze those results and adjust the "Darwin" Platform files 
accordingly.

@Arjen: the only D compiler you have access to on Windows is one you download 
for yourself [from Digital 
Mars](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdlang.org%2Fdownload.htmldata=02%7C01%7C%7Ca962fd3984664e88519308d72e6c7d4b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637028915813958706sdata=Q5GbOISrDsA%2Fyxn16s2s4FeEor02in2aGUIFKRSkRLA%3Dreserved=0).
I would appreciate you testing our new D language support on MSYS2 with that 
compiler.
As in Takeshi's case I suggest you start with the test_d project for an 
extremely recent version of CMake from its git master branch that you have 
built yourself.

Alan
__
Alan W. Irwin

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.org); 
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.

___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] CMake problem with hyphen in path

[Arjen Markus]

Hi Alan, Phil,

-Original Message-
From: Alan W. Irwin 
Sent: 13 July 2019 21:15
To: Phil Rosenberg 
Cc: PLplot development list 
Subject: Re: [Plplot-devel] CMake problem with hyphen in path

On 2019-07-13 08:05- Phil Rosenberg wrote:

> Hi Alan
> You may be right.
> I tried commenting out the offending regex replace, which meant cmake 
> finished with no issues. But, when I tried to compile I found I had a similar 
> problem with header files. I couldn't actually find the offending code that 
> is causing that problem. I tried adding some quotes, but that didn't seem to 
> help.
>
> So whatever workload you thought it was, it is actually double!

Actually there is at least one or two orders of magnitude more work according 
to my Linux tests if you consider dealing with this problem for all external 
free software libraries that PLplot depends on rather than just wxwidgets.  And 
the results would depend on all external libraries (and CMake itself) dealing 
with blank in pathname issues correctly which some preliminary tests I have 
done appears to be far from the case.  So the fundamental issue is PLplot has 
been responsible about its own internal source, build, and install tree blanks 
in pathname issues, but other free software has not been that responsible.  And 
a large supplementary issue is that even if external software eventually 
becomes completely responsible about this case, there would still be a lot more 
to do on the PLplot side to make "space in external library prefix" case work 
properly for all external libraries.

>>AM: FWIW, a check that the install directory does not include space would be 
>>inline with what a package like Anaconda for Python is doing on Windows. 
>>Instead of the more commonly used directory "C:\Program Files", it installs 
>>in "C:\ProgramData", to avoid the issue that packages do not take 
>>responsibility for spaces in directory names. PLplot might simply issue a 
>>warning if the user tries to use such names anyway.

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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Testing of the next PLplot release

[Arjen Markus]

Hi Alan,

See my answers below.

Regards,

Arjen

-Original Message-
From: Alan W. Irwin 
Sent: 21 May 2019 22:12
To: Arjen Markus 
Cc: 'Phil Rosenberg' ; PLplot development list 

Subject: RE: Testing of the next PLplot release

On 2019-05-21 07:05- Arjen Markus wrote:

>>> AM: If you ask for "git" via "pacman -Ss git", youget a long list of 
>>> packages that are maintained via git and therefore have "git" in their 
>>> name. The only package that I could find which was about git itself, was 
>>> "msys/git". And indeed, that works.

In principle, we should depend on as few packages from the msys repo as 
possible.  So to finish this discussion could you please use the normal pacman 
technique (I cannot recall the details, but you have used it before) to list 
all installed AND uninstalled packages that contain the file git.exe?  That's 
the definitive test of whether there is a package containing git.exe from the 
mingw repo.  Of course, if such a package doesn't exist, then git.exe from the 
msys version of the git package appears to be working well.

>>AM: I have tried finding out what package contains git.exe, but the command 
>>for that (pacman -Ql or pacman -Sl) fails - either the package or the 
>>repository is not found.
From the packages listed via "pacman -Ssy git" I see two possible candidates:

mingw64/mingw-w64-x86_64-git-repo 0.4.20-1 (mingw-w64-x86_64)
The multiple Git repository tool (mingw-w64)

msys/git 2.21.0-1 (VCS) [installed]
The fast distributed version control system

I have the second one installed as that seemed the most likely to be the 
correct one.

>>> AM: I turned it (python) off because I had seen a compile error with SWIG. 
>>> When I tried it yesterday in the straightforward build, all was well and I 
>>> have Qt drivers, including qtwidget. So I intend to allow Python again for 
>>> the comprehensive testing.

Good.

>>> AM: Just an aside: while the programs you get with MinGW-w64/MSYS2 do not 
>>> depend on the installation of MinGWw-w64/MSYS2 and can there in principle 
>>> be run outside the mingw64 shell, there are dependencies on various 
>>> run-time libraries: the C examples depend on libwinpthread-1.dll, 
>>> libshp-2.dll, libfreetype-6.dll, libqhull.dll and possibly others (I just 
>>> listed the ones mentioned in message boxes I got when trying to run a 
>>> sample program). For the Fortran examples I got a dependency on 
>>> libgfortran-4.dll, libfreetype-6.dll and libshp-2.dll. So deployment is not 
>>> entirely as simple as all that.

I don't want to beat this to death, but my point was all those dll's you 
mentioned as dependencies are all native, i.e., they do not depend on any 
special msys2.dll that turns an ordinary Windows environment into something 
unique/non-native.  So I am virtually positive any PLplot executable or library 
that is linked to them should just work (e.g., in an ordinary Windows CMD 
environment) so long as the PATH is set to include the location of the MSYS2 
native dll's that are built by PLplot or provided as dependencies of PLplot by 
the native mingw repo provided by MSYS2.  And even that PATH requirement 
disappears if you can figure out how to convince CMake to link a static PLplot 
against the static libraries provided by the mingw repo.

>>AM: That is personal frustration speaking . It makes things difficult that 
>>you always have to hunt down the DLLs that a program depends on. On Windows 
>>these can be hidden deeply and a tool like dependency walker cannot always 
>>detect the right ones.
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Testing of the next PLplot release

[Arjen Markus]

Hi Alan,

I have added my responses and findings below.

Regards,

Arjen

-Original Message-
From: Alan W. Irwin 
Sent: 17 May 2019 23:21
To: Arjen Markus 
Cc: 'Phil Rosenberg' ; PLplot development list 

Subject: RE: Testing of the next PLplot release

Hi Arjen:

See my review of your changes below.  Note depending on how quickly you can 
respond to the three minor issues that are left, we might have a release by 
early next week so I am sharing this post with the PLplot development list so 
other developers will also be aware that release is coming soon.

By the way, for all developers here I am declaring a push freeze on code or 
build-system changes unless it is a specific response to a bug that we discover 
in the next few days.

Note, that freeze still allows you to update our DocBook-generated 
documentation.

On 2019-05-17 07:31- Arjen Markus wrote:

> Hi Alan, Phil,
>
> I made some progress - see the attached tarball.

>> -Original Message-
>> From: Alan W. Irwin 
>> Sent: 16 May 2019 12:20
>> To: Arjen Markus 
>> Cc: 'Phil Rosenberg' 
>> Subject: RE: Testing of the next PLplot release
>>
>> That leaves just the following issues:
>>
>> * Specify -DENABLE_java=OFF to avoid non-MSY2 java being found (which in 
>> turn causes run-time errors).

DONE.

>>
>> * Find MSYS2 perl rather than the Cygwin version.  (The CMAKE_PREFIX_PATH 
>> trick may also have
>>   solved this issue.)

SOLVED.

>> * Install git (from the "mingw" repository for MinGW-w64/MSYS2).

LIKELY SOLVED.

The git you are using (from CMakeCache.txt) is

GITCOMMAND:FILEPATH=C:/msys64/usr/bin/git.exe

which is from the msys repo rather than the mingw repo.  However, that git 
clearly works (as you can see from the first few lines of 
comprehensive_test.sh.out) so I think it is OK.

>>AM: If you ask for "git" via "pacman -Ss git", youget a long list of packages 
>>that are maintained via git and therefore have "git" in their name. The only 
>>package that I could find which was about git itself, was "msys/git". And 
>>indeed, that works.

>> * Specify -DENABLE_ada=OFF (for now).

DONE.

That leaves the following issues:

>> * Use "MSYS Makefiles" to work around a wxwidgets cmake find bug for the 
>> "Unix Makefiles" case.

NOT TRIED YET.

>>AM: Not yet indeed, I seem not to have installed wxwidgets yet .

>> * Fix our build system to find the ".exe" version of lua.

> [out of order] But lua is still presenting the problem we have seen last year 
> (I updated it, but to no avail):

> One possible workaround for this is
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fmsys2%2FMINGW-packages%2Fissues%2F949data=02%7C01%7C%7C9
> e4efd85aac14134bb2508d6db0d7ffa%7C15f3fe0ed7124981bc7cfe949af215bb%7C0
> %7C0%7C636937248363105436sdata=G%2FK%2BBoN9YABlwFrgM6fRybkGikd9UM
> So6M5a2YZAHHk%3Dreserved=0, but I do not know how well this will
> work (I probably need to move the lua.exe executable to a different
> location or rename it or some such trick)

That's an ugly workaround, and it looks even uglier if you follow the link to 
further discussion.  So I don't think we should even attempt to use it, and 
instead until this upstream general Windows issue for lua is correctly solved, 
and that fix becomes part of MSYS2, we should simply specify -DENABLE_lua=OFF.  
(And similarly for the Cygwin case if you run into the same issue there.)

>>AM: That saves a lot of messing about . I was not particularly fond of this 
>>workaround, as there might be considerable confusion between a script file 
>>lua and an executable lua.exe - on Windows the file extension does play a 
>>role in how things are started and I am not sure how MinGW-w64/MSYS2 handles 
>>that.

* Python currently disabled.

I assume you did that because of some pyqt5 issue.  Instead, I suggest you use 
-DENABLE_pyqt5=OFF to allow ordinary python testing.

>>AM: I turned it off because I had seen a compile error with SWIG. When I 
>>tried it yesterday in the straightforward build, all was well and I have Qt 
>>drivers, including qtwidget. So I intend to allow Python again for the 
>>comprehensive testing.

In sum, use the "MSYS Makefiles" generator, disable lua, and be more specific 
about what python component you disable, and you will likely (since all this 
has worked before) be completely done with testing this platform for the 
release.

By the way.  With regard to that release I consider that
MinGW-w64/MSYS2 is our primary Windows platform because it gives access to 
almost all the same PLplot-relevant free software as Cygwin, but with the very 
large advantage that that software is in Windows

Re: [Plplot-devel] 5.14.0 release status

[Arjen Markus]

Hi Alan

-Original Message-
From: Alan W. Irwin 
Sent: zondag 2 december 2018 03:35
To: Arjen Markus ; PLplot development list 

Subject: Re: [Plplot-devel] 5.14.0 release status

The current status of the PLplot-5.14.0 release process is as follows:

The PLplot development freeze that started on October 27th contines, i.e., do 
not push any topics other than documentation updates or well-tested bug fixes.

As part of the release process I have summarized (commit
plplot-5.13.0-153-g0d50e2a2a) Arjen's recent Cygwin and
MinGW-w64/MSYS2 comprehensive test reports as the first two entries in the 
table at <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>.

@Arjen:

Could you please review those table entries to make sure my summaries of your 
comprehensive tests are correct?

My next planned step is to update that table again with my own recent 
comprehensive test reports, and then continue with the remaining parts of 
README.Release_Manager_Cookbook to finish the 5.14.0 release.


--
AM: Sure, I will do that - I have been looking at the "comprehensive 
testing"page and I have a few suggestions. I will combine that.

Regards,

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


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Intermittent Ada example build failures are now back again (SOLVED by gnat-8)

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:alan.w.irwin1...@gmail.com]
>
> By the way, it is a bit of a concern for the Cygwin rolling release that the 
> CMake,
> gcc, and gnat versions are getting pretty far behind what is available with 
> MinGW-
> w64/MSYS2, but, of course, those packaging delays could all be special cases.
> Does the overall health of the Cygwin project seem fine (e.g., all legitimate
> questions answered in a timely way by Cygwin developers, and packaging 
> progress
> continuing to be made for a large number of packages) from what you have been
> reading on the Cygwin mailing list?
>
The Cygwin mailing list is actively used for both announcements of updates to 
packages (many of which I do not use myself, but that is another matter) and to 
answer questions and solve problems. In that respect the whole project seems 
healthy enough. That said, I have seen several questions about packages like 
CMake lagging behind the developments and not all questions get answered 
properly. Perhaps it does not hurt to ask about the plans regarding the 
packages we are interested in in the context of PLplot.

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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Intermittent Ada example build failures are now back again (SOLVED by gnat-8)

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:alan.w.irwin1...@gmail.com]
> To Jerry and Arjen:
>
> On Sunday (just before commit 7ec926fae) I discovered that my installs of 
> gdc-7
> and gnat-7 were probably not good choices because although I had both gcc-7 
> and
> gcc-8 installed, PLplot was being built with gcc-8 rather than gcc-7 on my 
> Debian
> Buster system.  So in this case at least Debian does not have tight version
> consistency requirements between either gdc or gnat and gcc.  And perhaps 
> that is
> justified since previously I was getting perfect results with the combination 
> of gdc-7
> and gcc-8.
> However, the above parallel build issue with gnat-7 encouraged me to try 
> gnat-8,
> and I decided to install gdc-8 as well just to be consistent with gcc-8.
> It turns out (see the above commit message for the details) the combination 
> of gdc-
> 8, gnatmake-8, and gcc-8 produces perfect massively
> (-j10) parallel build and test results
> for a comprehensive set of of configurations and build trees, and for three 
> different
> CMake versions.
>
> So it seems once again that on Linux at least, parallel builds of our Ada 
> bindings
> and examples work well, and I advise on other platforms to avoid gnat-7 in 
> all cases,
> to use parallel builds with caution, and at least for the sake of consistency 
> use the
> same version of gdc, gnat, and gcc (e.g., gdc-8, gnat-8, and gcc-8).
>

I just checked the Cygwin set-up: there is at this moment at least no version 8 
available within that environment. I do not know if there are any plans to 
incorporate it, but I will keep an eye 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.


___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Recent bump of CMake minimum version

[Arjen Markus]

Hi Alan,
Thanks for this warning - I will have to see then how the building of CMake 
goes ...
Regards,
Arjen

> -Original Message-
> From: Alan W. Irwin [mailto:alan.w.irwin1...@gmail.com]
> Sent: Sunday, September 09, 2018 1:19 PM
> To: Arjen Markus; PLplot development list
> Subject: Recent bump of CMake minimum version
>
> Hi Arjen:
>
> For your information I have recently obtained perfect (no configure, build, 
> or install
> issues, and perfect PostScript difference reports) comprehensive test results 
> for the
> noninteractive case for CMake versions 3.7.2, 3.11.0, and 3.12.2.  I have also
> bumped the CMake minimum version from 3.6.2 for all platforms to 3.7.2 for the
> Linux platform and 3.11.0 for all other platforms.  The principal positive 
> impact of
> this change is to reduce our exposure to bugs which occur in older CMake 
> versions
> (especially for non-Linux platforms).  But for Cygwin users like you, the 
> negative
> impact of this change is that you will have to build your own CMake with 
> version >=
> 3.11.0 before you can build PLplot.  I am sorry about that inconvenience for 
> you
> and other Cygwin users, but this situation is due to the CMake package on 
> Cygwin
> being unmaintained since the date some time ago when CMake version 3.6.2 was
> released.  So perhaps the way to resolve this issue is to volunteer on the 
> Cygwin
> list to maintain that Cygwin CMake package yourself?
>
> Alan
> __
> Alan W. Irwin
>
> 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.
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Installed version of PLplot working again!

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:alan.w.irwin1...@gmail.com]
> Sent: Monday, August 27, 2018 3:26 AM
> To: PLplot development list
> Subject: [Plplot-devel] Installed version of PLplot working again!
>
> As of commit e298aa70a, the installed version of PLplot works again after a 
> long
> time (since early April) where it did not work.

Congratulations on completing this work - from the commit message I understand 
that you have had to deal with a plethora of details not all of which are 
obvious or trivial.

The fact that the installation is working again seems a good opportunity to 
turn your attention to this thread in comp.lang.fortran: 
https://groups.google.com/forum/?hl=en#!topic/comp.lang.fortran/N_tU-hVJEt0

We considered offering a binary version a long time ago, but never settled on a 
useful solution. Reading (and participating in) this thread I think this might 
be a good time to think about it again. Of course this adds a burden to the 
maintenance, but perhaps we can come up with a minimal but still useable and 
useful binary installation - perhaps merely to see how many people are 
interested in such a ready-made package. I will give the matter some serious 
thought.

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.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:alan.w.irwin1...@gmail.com]
> Sent: Monday, August 13, 2018 9:56 PM
> To: Arjen Markus
> Cc: Orion Poplawski; PLplot development list
> Subject: RE: Status of our octave binding and examples for version 4.4.0 of 
> octave
>
>
> Let's ignore octave for a bit and look at the more general picture.
> If you like the goal (in its own right) of learning to build packages for the 
> MinGW-
> w64/MSYS2 platform, then I suggest you follow the package build documentation
> examples under the heading "Re-building a package" at
> <https://github.com/msys2/msys2/wiki/Creating-packages>.
> Can you use those steps to build both their examples (flex and python3)?  If 
> not,
> then you should take the problem to the MSYS2 mailing list to get help with 
> that
> documentation.  But if that general procedure works for you, then the next 
> obvious
> step is to help out with the PLplot packaging at
> <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-plplot>
> by first building that package as is, fixing it according to your own 
> experience (e.g.,
> by moving to Python 3, and by enabling qt), and drawing Alex's attention to 
> your
> improvements (likely via a pull
> request) so they will be made part of the official Plplot package for this 
> platform.
>
I can certainly try ...

> Moving back to the octave case, I am pretty sure unless that semi-official 
> package
> is completely broken, that the same procedures used to build flex, python3, 
> and
> PLplot should also work fine for octave without all the issues you encountered
> above.  Assuming you can build that octave package, then the next steps would 
> be
> to evaluate the result for our needs, and assuming it does work for those 
> needs (or
> can easily be fixed), advocate making it an official package that the PLplot 
> package
> depends on.
>
> > I guess an alternative could be to simply build Octave and install it 
> > without
> pacman, but I have not tried that yet.
>
> I would advise against that since unofficial octave builds are not going to 
> help our
> octave users that much on this particular platform and may turn out to be a 
> black
> hole sucking up a lot of your time.
> Instead, I think it would be better in the long-run to help get an official 
> octave
> package running for this platform as I have outlined above.
>

Last night I tried to build Octave out of the box, as the computer would do 
most of the work - run configure, make, make install ... However, the make step 
fails:

  CXX  libinterp/corefcn/libinterp_corefcn_libcorefcn_la-pr-output.lo
libinterp/corefcn/pr-output.cc: In function 'float_display_format 
make_format(const T&) [with T = intNDArray >]':
libinterp/corefcn/pr-output.cc:1736:59: error: call of overloaded 'abs(signed 
char)' is ambiguous
   (std::floor (log10 (double (abs (nda(i).value ( + 1));  \
   ^
libinterp/corefcn/pr-output.cc:1748:1: note: in expansion of macro 
'MAKE_INT_MATRIX_FORMAT'
 MAKE_INT_MATRIX_FORMAT (octave_int8)
 ^~
In file included from C:/msys64/mingw64/include/c++/6.2.0/cmath:45:0,
 from libinterp/corefcn/pr-output.cc:27:
C:/msys64/mingw64/x86_64-w64-mingw32/include/math.h:254:15: note: candidate: 
int abs(int)
   int __cdecl abs(int _X);
   ^~~
In file included from 
C:/msys64/mingw64/include/c++/6.2.0/ext/string_conversions.h:41:0,
 from 
C:/msys64/mingw64/include/c++/6.2.0/bits/basic_string.h:5402,
 from C:/msys64/mingw64/include/c++/6.2.0/string:52,
 from 
C:/msys64/mingw64/include/c++/6.2.0/bits/locale_classes.h:40,
 from C:/msys64/mingw64/include/c++/6.2.0/bits/ios_base.h:41,
 from C:/msys64/mingw64/include/c++/6.2.0/iomanip:40,
 from libinterp/corefcn/pr-output.cc:29:
C:/msys64/mingw64/include/c++/6.2.0/cstdlib:185:3: note: candidate: __int128 
std::abs(__int128)
   abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
   ^~~
C:/msys64/mingw64/include/c++/6.2.0/cstdlib:180:3: note: candidate: long long 
int std::abs(long long int)
... (a lot more complaints)

So that is the end of that road as well as far as I am concerned.

It would seem that the only way we can proceed is indeed by obtaining an 
official Octave package, as you indicate.

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

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

[Arjen Markus]

Hi Alan,

> However, I hope those comments (such as the possibility mentioned above of
> building an octave MinGW-w64/MSYS2 package for yourself using the pacman
> packaging information at
> )
> are still of some use to you.
>
I have tried to build Octave under MinGW-w64/MSYS2 using that webpage. However:
- I had to remove the references to the patches, as these do not seem to be 
available. No idea what the effect is
- The build failed on a mismatch in the checksums:

$ makepkg -sCLf
==> Making package: mingw-w64-octave-hg r19590.6d75f1683ce8-1 (Sun, Aug 12, 
2018 15:56:07)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating gnulib git repo...
Fetching origin
  -> Found tip.tar.bz2
==> ERROR: Integrity checks (sha256) differ in size from the source array.

This is the point where I stopped. I have no clue as to whether this is a 
serious issue or not.

I guess an alternative could be to simply build Octave and install it without 
pacman, but I have not tried that yet.

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.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:alan.w.irwin1...@gmail.com]
> Sent: Thursday, August 09, 2018 1:07 AM
>
> Thanks for that confirmation on Cygwin.  That is the first time in a long 
> time (if
> ever?) that octave has worked on that platform for us which I regard as a big 
> step
> forward.
>

:)

> And as far as MinGW-w64/MSYS2 is concerned, my guess is the information at
> 
> is for a pacman package for octave that has not matured yet so the package 
> build
> results are not included in the official pacman packages for MinGW-w64/MSYS2.
> But the small part of that package that we use for our octave binding build 
> and tests
> might work well.  So if you want to follow up further, I suggest you build 
> the pacman
> package for octave following the cookbook located at
> .
>

I guess it is worth a try ... Will keep you informed on progress.

> As you know, my long-term dream has been to use Wine to help you out more with
> both Cygwin and MinGW-w64/MSYS2 testing so recently I looked into that again.
> But currently it does not look good.  For example, both Cygwin and MinGW-
> w64/MSYS2 upgraded from Windows XP to Windows Vista functionality a couple of
> years back, but according to discussion at  packages/issues/682>
> Wine has a lot of missing Vista functionality that has to be implemented 
> before
> either of those two distributions will work on Wine again.  So until that 
> happens, I
> am limited to just commenting from the sidelines concerning those 
> distributions.
> However, I hope those comments (such as the possibility mentioned above of
> building an octave MinGW-w64/MSYS2 package for yourself using the pacman
> packaging information at
> )
> are still of some use to you.
>

Pity about Wine, but it seems quite difficult to keep up with a moving target 
like Windows.

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.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

[Arjen Markus]

Hi Alan,

I can confirm clean test results for Octave 4.2.2 on Cygwin - I cannot do the 
same for MinGW-w64/MSYS2 as that does not provide an octave package as far as I 
can tell. There is an Octave pacakge on github 
(https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg) but 
its status is completely unclear to me. As is how it should be installed 
(pacman does not recognise it)

Regards,

Arjen

> -Original Message-
> From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
> Sent: Monday, August 06, 2018 2:33 PM
> To: Alan W. Irwin; Orion Poplawski
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Status of our octave binding and examples for 
> version
> 4.4.0 of octave
>
> Hi Alan,
>
> I am back from my holiday, so I should have the opportunity to test the new 
> binding.
>
> Regards,
>
> Arjen
>
> > -Original Message-
> > From: Alan W. Irwin [mailto:alan.w.irwin1...@gmail.com]
> > Sent: Thursday, August 02, 2018 12:40 AM
> > To: Orion Poplawski; Arjen Markus
> > Cc: PLplot development list
> > Subject: Re: Status of our octave binding and examples for version
> > 4.4.0 of octave
> >
> > On 2018-07-31 21:10-0700 Alan W. Irwin wrote:
> >
> > > To Orion and Arjen:
> > >
> > > As of
> > > <https://sourceforge.net/p/plplot/plplot/ci/d7310aa9864ce1676177f393
> > > 23 c9daf593ae0765/> our octave binding and all
> > > examples/octave/x??c.m examples give a perfect PostScript difference
> > > report for Octave 4.4.0 for Debian Buster == Debian Testing.  Please
> > > do equivalent checks (i.e., by simply building the
> > > test_noninteractive target in the build
> > > tree) for Cygwin, MinGW-w64/MSYS2, and Fedora to check all is well
> > > on platforms other than Debian Buster.  I emphasize build-tree
> > > checks because install-tree checks currently won't work []
> >
> > That request for testing help still applies, but I can now report (see
> > the log for commit 391ec0ad0 for the details) that I have been able to
> > replace the cellstr-based workaround with an actual fix for the issue
> > which should work for late octave-3 as well as all versions of octave-4.
> >
> > Alan
> > __
> > Alan W. Irwin
> >
> > 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.
>
> --
> Check out the vibrant tech community on one of the world's most engaging tech
> sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> 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.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

[Arjen Markus]

Hi Alan,

I am back from my holiday, so I should have the opportunity to test the new 
binding.

Regards,

Arjen

> -Original Message-
> From: Alan W. Irwin [mailto:alan.w.irwin1...@gmail.com]
> Sent: Thursday, August 02, 2018 12:40 AM
> To: Orion Poplawski; Arjen Markus
> Cc: PLplot development list
> Subject: Re: Status of our octave binding and examples for version 4.4.0 of 
> octave
>
> On 2018-07-31 21:10-0700 Alan W. Irwin wrote:
>
> > To Orion and Arjen:
> >
> > As of
> > <https://sourceforge.net/p/plplot/plplot/ci/d7310aa9864ce1676177f39323
> > c9daf593ae0765/> our octave binding and all examples/octave/x??c.m
> > examples give a perfect PostScript difference report for Octave 4.4.0
> > for Debian Buster == Debian Testing.  Please do equivalent checks
> > (i.e., by simply building the test_noninteractive target in the build
> > tree) for Cygwin, MinGW-w64/MSYS2, and Fedora to check all is well on
> > platforms other than Debian Buster.  I emphasize build-tree checks
> > because install-tree checks currently won't work []
>
> That request for testing help still applies, but I can now report (see the 
> log for
> commit 391ec0ad0 for the details) that I have been able to replace the 
> cellstr-based
> workaround with an actual fix for the issue which should work for late 
> octave-3 as
> well as all versions of octave-4.
>
> Alan
> __
> Alan W. Irwin
>
> 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.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] -h command-line issue on Cygwin

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> Hi Arjen:
>
> Since both x01c and x01f have special command-line parsing, I suggest the 
> first
> thing you should do is try other C and Fortran examples (e.g., x00c or x00f) 
> to see
> if the -h option works in those less special cases. My guess is it won't 
> work, i.e., the
> problem you discovered with the -h option on Cygwin is a general one for our
> standard C and Fortran examples rather than specific to just x01f.
>
Same behaviour ;).

> I looked up the popen man page on Linux which states it "opens a process by
> creating a pipe, forking, and invoking the shell". So I assume what the above 
> code
> fragment does is redirect the normal output of the -h option from stdout to 
> whatever
> you have specified as the PAGER environment variable or the "more" pager as a
> fallback if you have not specified PAGER.
>
> So I suspect what has happened on your Cygwin platform is you don't have any
> pager installed.  You should be able to fix that by installing "more" via the 
> "util-linux"
> package and/or "less" via the "less" package (while setting your PAGER
> environment variable to "less").
>
> Let me know whether one or the other of those two measures fixes the above -h
> issue.

No, there is a "more" installed in /usr/bin/more and that works fine when 
invoked through the command line. For some reason the plplarse routine seems to 
try and start a bare-Windows command: "c:\program" in the error message is just 
the start of the directory name under which commands and programs can be found. 
A workaround would be not to use this feature on any Windows platform.

>
> By the way, I highly recommend "less" as a much better pager than "more".  So 
> the
> developers of "less" used some self-deprecating humor when they picked the 
> name
> of their pager.  :-)
>

Why exactly? They have similar functionality, don't they?

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Saturday, January 06, 2018 3:30 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: Command-line parsing improvements for both C and Fortran
>
> On 2018-01-05 13:38- Arjen Markus wrote:
>
> [...]
>
> > That [extra printouts of locations reached] limits the possibilities
> considerably ;). I have narrowed it further to the call of 
> max_cstring_length, but of
> course this is merely the location where it is noted something is wrong, not
> necessarily the cause.
>
> Hi Arjen:
>
> Your experiments appear to have nailed exactly where the issue was. So much
> thanks for that work!  As a direct result of that work I discovered I had 
> forgotten an
> essential slice specification in the call to max_cstring_length which I have 
> now fixed
> (commit 70ec495).
> As a result my strong expectation is your next test of Fortran example
> 1 for the allocated length and size case will give perfect results for both 
> modern
> gfortran and ifort

I can now confirm that it works for both compilers. There is a small issue 
though with the gfortran compiler under Cygwin. I do not understand it (*) but 
here is the output to screen if I use the -h option:
$ ./x01f -h
pl_parse_dynamic =  T
argv before call to plparseopts(..., PL_PARSE_SKIP)
i =   0, argument = ./x01f
i =   1, argument = -h
/bin/sh: C:\Program: command not found


This does not happen for Intel Fortran - then I get an overview of all the 
options that are available.

(*) From a closer look at the code I think this is due to the fragment:

#ifdef HAVE_POPEN

FILE *pager = NULL;

if ( getenv( "PAGER" ) != NULL )

pager = (FILE *) popen( "$PAGER", "w" );

if ( pager == NULL )

pager = (FILE *) popen( "more", "w" );

if ( pager != NULL )

outfile = pager;

#endif

It is probably trying to run a pager program like "more" but that does not 
quite work on Cygwin.

BTW, I had to adjust the .def file for Intel Fortran to get it all to build 
correctly. I will submit the changes.

>
> By the way, this fix has nothing to do with the gfortran-4.9.2 issue where the
> allocate length and size command in plget_arguments_dynamic (that already 
> works
> for your modern gfortran and ifort cases) overflows when doing a simple 
> internal
> calculation of the amount of memory needed.  I double-checked with gdb that 
> the
> length and size are properly defined for that allocate command.  Therefore my
> conclusion must be that gfortran-4.9.2 is just plain broken for such allocate
> commands (while your ifort and more modern gfortran are obviously not broken 
> in
> this regard).
>
Pity, that means a newer version is still needed.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



The crash I reported before occurs somewhere between the call to 
interface_plparseopts(...) and max_cstring_length:


$ ./x01f -dev wingcc
pl_parse_dynamic =  T
argv before call to plparseopts(..., PL_PARSE_SKIP)
i =   0, argument = ./x01f
i =   1, argument = -dev
i =   2, argument = wingcc
In plparse_opts_dynamic
After character_array_to_c
After interface_plparseopts

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:



That limits the possibilities considerably ;). I have narrowed it further to 
the call of max_cstring_length, but of course this is merely the location where 
it is noted something is wrong, not necessarily the cause.

Regards,

Arjen

From: Arjen Markus
Sent: Friday, January 05, 2018 9:10 AM
To: 'Alan W. Irwin'
Cc: PLplot development list
Subject: RE: Command-line parsing improvements for both C and Fortran


Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]

> Furthermore, I would appreciate you following the parsing testing advice in
> README.release section 2.7.2 to discover which parts of this API work for 
> gfortran
> with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as
> well as the ifort compiler you have access to (and possibly the nagfor 
> compiler you
> have arranged access to in the past).
>
> By the way, I am not sure of the correct terminology for character arrays 
> that have
> both length and size allocated.  I refer to them above as "dynamic length and 
> size",
> but I have also seen the term "deferred-length" used for character strings 
> with
> allocated length.
>
I did the tests yesterday and found quite some problems with the dynamic case, 
but also with the C example.

First the C example:

"x01c -dev wingcc" complains that I did not give the value for the -dev option. 
If I give other options like "a b c", I get complaints that these are unknown. 
If I run "x02c -dev wingcc", all works as usual.
$ ./x01c -dev wingcc
Argument missing for -dev option.

Usage:
./x01c [options]

x01c options:
[-pl_parse_skip] [-locate] [-xor] [-font number] [-save filename]

PLplot options:

...

Then the Fortran example:

-With the static-character-length, allocatable array option, all works, 
also for the static-character-length, fixed-size array option. Surprisingly, I 
can specify "-dev wingcc" and the window pops up immediately. This is for both 
gfortran 6.4.0 and Intel Fortran 2015.

-However, with both compilers the deferred-character-length, 
allocatable array option fails miserably. The result is a coredump like the one 
you have seen with the older version of gfortran.

My conclusion therefore is that there is something wrong with the code. I have 
not been able to figure out yet what is wrong - which part, but I will try to 
do so today, using a few strategic print statements to at least find the point 
where things go awry.

(A minor pleasant surprise is that maybe after correction the code will work 
for gfortran 4.x 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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]


> Furthermore, I would appreciate you following the parsing testing advice in
> README.release section 2.7.2 to discover which parts of this API work for 
> gfortran
> with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as
> well as the ifort compiler you have access to (and possibly the nagfor 
> compiler you
> have arranged access to in the past).
>
> By the way, I am not sure of the correct terminology for character arrays 
> that have
> both length and size allocated.  I refer to them above as "dynamic length and 
> size",
> but I have also seen the term "deferred-length" used for character strings 
> with
> allocated length.
>
I did the tests yesterday and found quite some problems with the dynamic case, 
but also with the C example.

First the C example:

"x01c -dev wingcc" complains that I did not give the value for the -dev option. 
If I give other options like "a b c", I get complaints that these are unknown. 
If I run "x02c -dev wingcc", all works as usual.
$ ./x01c -dev wingcc
Argument missing for -dev option.

Usage:
./x01c [options]

x01c options:
[-pl_parse_skip] [-locate] [-xor] [-font number] [-save filename]

PLplot options:

...

Then the Fortran example:

-With the static-character-length, allocatable array option, all works, 
also for the static-character-length, fixed-size array option. Surprisingly, I 
can specify "-dev wingcc" and the window pops up immediately. This is for both 
gfortran 6.4.0 and Intel Fortran 2015.

-However, with both compilers the deferred-character-length, 
allocatable array option fails miserably. The result is a coredump like the one 
you have seen with the older version of gfortran.

My conclusion therefore is that there is something wrong with the code. I have 
not been able to figure out yet what is wrong - which part, but I will try to 
do so today, using a few strategic print statements to at least find the point 
where things go awry.

(A minor pleasant surprise is that maybe after correction the code will work 
for gfortran 4.x 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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> This commit completes my parsing API changes in bindings/fortran/*.f90 and my
> changes to examples/fortran/x01f.f90 to test all of these parsing API's.  I 
> would
> appreciate your review of my implementation.
> Furthermore, I would appreciate you following the parsing testing advice in
> README.release section 2.7.2 to discover which parts of this API work for 
> gfortran
> with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as
> well as the ifort compiler you have access to (and possibly the nagfor 
> compiler you
> have arranged access to in the past).
>
> By the way, I am not sure of the correct terminology for character arrays 
> that have
> both length and size allocated.  I refer to them above as "dynamic length and 
> size",
> but I have also seen the term "deferred-length" used for character strings 
> with
> allocated length.
>
Unless I am mistaken the official term is deferred-length.

I have not yet tested this with my compilers, but I have reviewed the 
implementation. I have very few comments about it:

-It is a pity that we cannot disambiguate on the deferred/assumed 
length alone, but that is an issue of the language rules (the type of 
"assumed-length character string" simply encompasses the type of 
"deferred-length character string". Elaborate workaround might be possible, 
using classes/derived types, but that is not worth the trouble I think).

-If we decide at some point that we need to keep the various 
implementations, then perhaps we could "layer" the versions:

o   The deferred-length variant can call the assumed-length + allocated size 
variant

o   This can in turn call the fixed size variant

It would reduce the amount of code, by a small amount of source lines. But 
again, that may not be worth our while.

I should have time to test the implementation tomorrow. Maybe that will bring 
out more comments ;).

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



I am currently catching up with my e-mail (Christmas is a busy time ...), so 
this is the first opportunity I have found to respond to your mails. Sure, I 
will have a look at this. (I even have a generic solution for this type of 
programming problem, but it may not be better than yours ;) - I respond before 
having seen it.)



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, December 26, 2017 9:16 AM
> To: Arjen Markus; PLplot development list
> Subject: Command-line parsing improvements for both C and Fortran
>
> Hi Arjen:
>
> I have just finished (commit 71944db) implementing the C and Fortran command-
> line parsing improvements that I first brought up with you
> (off-list) just a few days ago. Please see the revised version of 
> README.release
> for the details concerning these changes. Since your modern Fortran 
> experience is
> more extensive than mine, and I felt right on the edge of the limit of my own 
> modern
> Fortran expertise when implementing this, I would appreciate you reviewing the
> Fortran part of this topic, for substance (should it work perfectly in all 
> cases),
> standards-compliance (i.e., should it work for nagfor), and overall style.
>
> On that style point, in the new function c_to_character_array that appears in
> bindings/fortran/plplot_small_modules.f90 I implemented
>
> do i_local = 1, length_column_local
>  character_array(j_local)(i_local:i_local) = string_ptr(i_local) enddo
>
> to copy from a pointer vector of size length_column_local one-byte characters 
> to
> character_array(j_local), an element of a character array whose length is the 
> same
> as the string_ptr size. Is there a more modern Fortran method of implementing 
> the
> equivalent of this loop with just one assignment statement or are we stuck 
> with this
> do-loop style?
>
> One caveat I discussed in README.release with the present parsing-related
> additions to the Fortran API is that API needs to be converted from the 
> present
> assumed shape character arrays to allocatable character arrays to simplify the
> arguments and reduce the necessary size checking required with the present 
> static
> array approach.  But I am holding off from doing that change because 
> allocatable
> character arrays are not reliable on my present Debian Jessie (gfortran-4.9.2)
> platform.  For example, this simple test code,
>
> irwin@raven> cat test_allocatable_character_arrays.f
> c test of allocatable character arrays
>character(len=100), dimension(10)  :: argv_array
> !  character(len=:), dimension(:), allocatable  :: argv_array
> !  allocate(character(len=100) :: argv_array(10))
>
>argv_array(5)(1:10) = "hello, world"
>write(*,'(a)') argv_array(5)(1:10)
>end
>
> works fine as is on my platform, i.e. has perfect Valgrind results (0 errors, 
> no leaks
> are possible). However, if you comment the second line and uncomment the 3rd
> and 4th lines to change this from a static character array test to an 
> allocatable
> character array test, it spectacularly fails (outputs gibberish) and valgrind 
> also
> shows all sorts of memory management issues.
>
> Would you be willing to build and run both versions of the above test code on
> Cygwin (with gfortran-6.4.0) to make sure no obvious problems occur with that
> gfortran version? If your tests indicate no such problems then I would 
> encourage
> you to try updating the API to the allocatable version as indicated in
> README.release, and test that change as indicated there as well.  But if you 
> don't
> have time for that just now, I plan to make the change myself just as soon as 
> I
> upgrade to Debian Stretch.  I am assuming here (especially if you get good 
> results
> for the above test) that gfortran-6.3.0 that comes with that platform will 
> have no
> trouble with the above simple example and also the allocatable version of the 
> new
> code.
>
> Merry Christmas to you, your family, and all others interested in PLplot that 
> are
> lurking here on this list!
>
> 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.

Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, November 07, 2017 11:20 PM
>
> Hi Arjen:
>
> To clean up some preliminary stuff, please don't set GNAT_LIB unless 
> absolutely
> necessary.  Specifying that variable is a workaround that bypasses all 
> testing of the
> find_library command (see
>  for why that 
> is so.

Oh, that was a stupid mistake - too many little tasks clogging my head and thus 
I simply followed the advice from the error message: an unaided 
"comprehensive_test_ada.sh" does not find the Gnat library.

With CMAKE_LIBRARY_PATH set to the right directory the test does succeed but 
fails in the same way as before. So the CMake build script finds the proper 
library, but there is something going on with the library itself.

I have attached two tarballs: one with only the CMAKE_LIBRARY_PATH set and one 
excluding the shared build, leaving the static case. This fails on account of 
duplicate symbols again.

No time right now to look into your other suggestions.

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.


comprehensive_test_shared.tar.gz
Description: comprehensive_test_shared.tar.gz


comprehensive_test_static.tar.gz
Description: comprehensive_test_static.tar.gz
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

[Arjen Markus]

Hi Alan,



I got an odd error while running the comprehensive test script for Ada - see 
the attached tarball. The good news is that it was a crash in running the 
program, not an interruption of the build process.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, November 07, 2017 11:16 AM
...

>
> Once you have complete success with the test_ada project, than I will want to
> make a similar change to the PLplot project, but I haven't done that yet.
>
As indicated above, only partial success.

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.


comprehensive_test.tar.gz
Description: comprehensive_test.tar.gz
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Friday, November 03, 2017 8:37 PM
> When you get a chance please commit this change on a local topic branch using
> "git am" and try it out on Cygwin using
>
> cmake/test_ada/scripts/comprehensive_test.sh
>
I applied the patch and got some encouraging results:

- With -DCMAKE_LIBRARY_PATH=/path/to/ada-libraries I go the same errors as 
before

- With -DGNAT_LIB=/path/and/name/of/import-library I got - finally - working 
Ada examples. Both the standard and traditional versions work fine.

(I did notice something odd about example x03: with both the C and Ada examples 
using the wingcc and X Window the window is empty. The PostScript file shows 
only a partial plot - labels around the radial diagram. I have attached it for 
further discussion. Very strange - other examples work fine)

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.


aa.ps
Description: aa.ps
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin

[Arjen Markus]

Hi Alan,



I will look into this, but it may be a few days before I have the opportunity 
to sit down for this. In the meantime, I see there is activity on the Cygwin 
mailing list regarding the issue. So the maintainers are aware of the problem 
and are working on it.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, October 30, 2017 7:33 PM
> To: Arjen Markus; PLplot development list
> Subject: Possible fix for the test_ada project on Cygwin
>
> Hi Arjen (returning this discussion to the plplot-devel list):
>
> Thanks for sending me (off list) the output from the
>
> gnatmake -v hello.adb -cargs -fPIC -bargs -shared -largs -v -shared
>
> gnatmake -v hello.adb -bargs -static -largs -v -static
>
> commands on Cygwin.  Based on that information I have come up with the 
> attached
> local commit (prepared with "git format-patch") to workaround (just for the 
> test_ada
> project for now) the Cygwin Ada packaging issue revealed by the first of the 
> above
> commands.
>
> Could you let me know if that commit works for you, i.e., once it is locally 
> applied
> with "git am" does
>
> cmake/test_ada/scripts/comprehensive_test.sh
>
> finally work for you on Cygwin?  Also, win or lose, I would like to see the 
> report
> tarball from this test.
>
> 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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, October 10, 2017 1:36 PM
>
> My understanding is non-POSIX Cygwin is a thing of the past, i.e., you have 
> the
> POSIX version where no variant of WIN32 is #defined.  But to be absolutely 
> sure
> on this point, write a simple programme which includes the
> following:
>
> #if defined(WIN32) || defined(_WIN32) || defined (__WIN32__) #error Cygwin
> defines at least one of the variants of the WIN32 macro #endif
>


That was easily tested - just for good measure (and to be sure something was 
happening) I added an #else case. Compiling that gave me the assurance that 
none of these macros is defined by the gcc compiler on Cygwin.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32

[Arjen Markus]

Hi Alan,



I have had a look at the two discussions Alaric and you mention, and I agree 
that the best choice seems to be _WIN32 to indicate the Windows platform. I 
hesitate, however, to be absolutely sure, on the following grounds:

-The tip on detecting the operating systems mentions that there is no 
64-bits Cygwin system, but that was the case back in 2012. I have been using 
Cygwin 64-bits for a couple of years now.

-There is also mention of Cygwin in a POSIX and in a non-POSIX variant. 
I have no clue as to how to determine which one I am working with or how to 
specify that at install time.

-Also the table "Windows, Cygwin (non-POSIX), and MinGW" has columns 
for the "Windows target" and the "MinGW target". It is unclear to me what they 
mean by that.

-Furthermore: is "MinGW" the old-style MinGW or the new one, 
MinGW-w64/MSYS2? From the date of the post, I would say the former.



All that does not mean that we should not consistently use _WIN32, but perhaps 
some care is to be taken. The page 
https://msdn.microsoft.com/en-us/library/b0084kay.aspx indicates that Visual 
C++ does define _WIN32 for both the 32-bits and 64-bits platforms. On the other 
hand, this page from the GNU C compiler documentation says that macros whose 
name starts with two (!) underscores are to be considered reserved and does not 
mention the one-underscore macros as being special (only historical): 
https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/System-specific-Predefined-Macros.html#System-specific%20Predefined%20Macros.



I guess that only adds to the confusion :(.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, October 09, 2017 8:02 PM
> To: Arjen Markus; PLplot development list
> Subject: [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32
>
> Hi Arjen:
>
> I am addressing you because you are our primary Windows platform expert, but I
> would be happy to hear from others here as well (including Alaric) with some
> knowledge of that platform.
>
> What would be your advice concerning replacing our use of the WIN32 and
> __WIN32__ macros in our source code?
>
> Basically, Alaric (see his bug report below) has found a platform where the 
> _WIN32
> macro is #defined but not WIN32, and the stackoverflow discussion he 
> referenced
> appears to say the two macros ordinarily have the same meaning but the
> underscored one is a bit safer to use because there is a convention it should 
> not be
> changed by anyone other than the compiler vendor.
>
> Note, however, that Alaric's bug report does not cover the entire problem in 
> our
> code because we also make use of the __WIN32__ macro.
> Another stackoverflow discussion concerning that macro referenced
> <https://web.archive.org/web/20140625123925/http://nadeausoftware.com/articles/
> 2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system
> >.
>
> My conclusion from reading the "Windows, Cygwin (non-POSIX), and MinGW"
> section of that article is the safest course for supporting all Windows 
> compilers is
> for us to replace all use of the WIN32 and __WIN32__ macros in our C and C++
> code with use of the _WIN32 macro instead.  Do you agree?
>
> If so, I would be willing to take responsibility for the actual code change 
> since Linux
> has excellent facilities (find and
> sed) for automatic mass-editing of code.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project 
> (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi 
> project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the 
> Linux
> Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
>
> -- Forwarded message --
> Date: Mon, 09 Oct 2017 15:52:10 +
> From: Alaric Senat <alaric1...@users.sf.net>
> Reply-To: Ticket 189 <1...@bugs.plplot.p.re.sf.net>
> To: Ticket 189 <1...@bugs.plplot.p.re.sf.net>
> Subject: [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32
>
>
>
>
> ---
>
> ** [bugs:#189] Using WIN32 Macro instead of _WIN32**
>
> **Status:** open
> **Group:**
> **Created:** Mon Oct 09, 2017 03:52 PM UTC by Alaric Senat **Last Updated:**
> Mon Oct 09, 2017 03:52 PM UTC
> **Owner:** nobody
>
>
> Hello,
>
> This ticket is j

Re: [Plplot-devel] wingcc and wingdi build bugs

[Arjen Markus]

Hi Alan,



My system is Windows 7 and I do not have easy access to a Windows 10 machine 
with a suitable development environment. Perhaps there are release notes at 
MSDN that can shed some light on the matter?



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, October 05, 2017 5:10 AM
> To: Phil Rosenberg; Jim Dishaw; Arjen Markus; PLplot development list
> Subject: Re: wingcc and wingdi build bugs
>
> On 2017-10-05 00:57+0100 Phil Rosenberg wrote:
>
> > The my cmake command and its output are attached. I noted particularly
> > the lines
> >
> > -- Looking for gdi32 header and library
> > -- Looking for gdi32 header and library - not found
> > -- WARNING: Setting PLD_wingcc to OFF.
> >
>
> > I do set the cmake lib directory in my command to point it to the
> > location of shapelib, I don't know if that affects anything.
>
> Setting CMAKE_LIBRARY_PATH to help CMake find shapelib should not interfere
> with CMake's ability to find other libraries.
>
> > I am on Windows 10 64 bit.
>
> Thanks for that important information concerning your Windows version.
>
> The cmake messages above come from cmake/modules/wingcc.cmake and the
> first part of the relevant logic is
>
>find_library(GDI32_LIBRARY gdi32 HINTS ${MINGWLIBPATH}
> ${BORLANDLIBPATH})
>if(GDI32_LIBRARY)
>find_library(COMDLG32_LIBRARY comdlg32 HINTS ${MINGWLIBPATH}
> ${BORLANDLIBPATH})
>endif(GDI32_LIBRARY)
>
> If you read through the rest of the logic, the above output is telling you 
> that either
> the gdi32 (gdi) or comdlg32 (dialog box) libraries cannot be found by CMake in
> standard system locations (as determined by CMake) for your platform.
>
> What does your cache file say about the variables GDI32_LIBRARY and
> (possibly) COMDLG32_LIBRARY?  From those values you can determine whether
> gdi32 was not found (and therefore comdlg32 never looked for) or gdi32 found 
> but
> comdlg32 not found.
>
> If both those libraries are installed on your system but in a non-standard 
> location
> that CMake doesn't know about, then you may have to give CMake a hint where
> they are by setting CMAKE_LIBRARY_PATH appropriately.
>
> However, I suspect instead the problem may be that the GDI API and Dialog Box
> API (which apparently are still used heavily on all Windows platforms 
> including
> Windows 10) are located in libraries with names other than
> gdi32 and comdlg32 for your 64-bit Windows 10 platform.  If so, and you know
> those alternate names, then all you have to do is to change the above logic to
>
>find_library(GDI32_LIBRARY NAMES gdi32  HINTS
> ${MINGWLIBPATH} ${BORLANDLIBPATH})
>if(GDI32_LIBRARY)
>find_library(COMDLG32_LIBRARY NAMES comdlg32  comdlg32> HINTS ${MINGWLIBPATH} ${BORLANDLIBPATH})
>endif(GDI32_LIBRARY)
>
> @Arjen and Jim:
>
> Please chime in as well especially on the question of what library names 
> provide the
> GDI API and Dialog Box API for the 64-bit Windows 10 platform if Phil doesn't
> figure those names out before you.
>
> 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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Update of the Wiki: obsolete information?

[Arjen Markus]

Hi Alan, others,



I have updated the Wiki page on the status of PLplot for the Windows platforms. 
I noticed however that we list information about the Borland and Open Watcom 
compilers, as well as the CGM device. I have not seen any mention of the two 
compilers or of the CGM device for many years now. Is it really convenient to 
continue displaying that information?



By the way, I have added the newer languages to the overview and some of the 
newer components as well. I would appreciate comments - especially as far as 
the restrictions are concerned. If someone can point me to the missing 
components for Ocaml for instance or to a D compiler for Windows platforms, 
that would be great.



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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

[Arjen Markus]

Hi Alan,



I can confirm that it works:



D:\plplot-svn\build-mingw-alt>cmake ..\plplot-git -G "MSYS Makefiles" 
-DBUILD_TEST=ON -DCMAKE_CXX_FLAGS="-fabi-version=8"



...

-- WARNING: PLPLOT_USE_QT5 is OFF so setting ENABLE_pyqt5 to OFF

-- pyqt: SIP_EXECUTABLE = C:/msys64/mingw64/bin/sip.exe

-- SIP_VERSION = 4.18

-- PYQT_SIP_DIR = C:/msys64/mingw64/share/sip/Py2-Qt4

-- PyQt4: PYQT_SIP_FLAGS = -x;VendorID;-t;WS_WIN;-t;Qt_4_8_7;-x;Py_v3



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, September 06, 2017 10:46 AM
>
> Thanks, Arjen.  I have now used the above information to update the NAMES and
> HINTS used to discover PYQT_SIP_DIR.
>
> Could you try the first stages again of the comprehensive test, but this time 
> without
> specifying PYQT_SIP_DIR?  Our build system should now (commit e3e0f15)
> automatically be able to determine PYQT_SIP_DIR on MinGW-w64/MSYS2 without
> you needing to specify it, and I hope the above test will confirm that.
>


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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, September 05, 2017 8:07 PM

>
> > To settle this question of the various names for the various
> > combinations of Python2 versus Python3 and Qt4 versus Qt5, on
> > MinGW-w64/MSYS2 could you please give me the complete results for
> >
> > pkgfile QtCoremod.sip
> >
> > ? Once I have that information, I can update our HINTS so our users
> > don't have to specify PYQT_SIP_DIR on this platform regardless of what
> > combination of Python and Qt they try.
>
> Just to clarify, the remaining question above is not noise.  :-) That is, I 
> am still
> interested in those pkgfile results.
>
Here is the output from that command - it does not tell you where the file 
is/will be installed though:

mingw32/mingw-w64-i686-python2-pyqt4

mingw32/mingw-w64-i686-python2-pyqt5

mingw32/mingw-w64-i686-python3-pyqt4

mingw32/mingw-w64-i686-python3-pyqt5

mingw64/mingw-w64-x86_64-python2-pyqt4

mingw64/mingw-w64-x86_64-python2-pyqt5

mingw64/mingw-w64-x86_64-python3-pyqt4

mingw64/mingw-w64-x86_64-python3-pyqt5

This is really all I got. Oh wait, after a bright moment and "pkgfile --help", 
I ran "pkgfile -v QtCoremod.sip" and got instead the more useful output below:

mingw32/mingw-w64-i686-python2-pyqt4 4.11.4-2
/mingw32/share/sip/Py2-Qt4/QtCore/QtCoremod.sip

mingw32/mingw-w64-i686-python2-pyqt5 5.8-1 
/mingw32/share/sip/Py2-Qt5/QtCore/QtCoremod.sip

mingw32/mingw-w64-i686-python3-pyqt4 4.11.4-2  
/mingw32/share/sip/PyQt4/QtCore/QtCoremod.sip

mingw32/mingw-w64-i686-python3-pyqt5 5.8-1 
/mingw32/share/sip/PyQt5/QtCore/QtCoremod.sip

mingw64/mingw-w64-x86_64-python2-pyqt4 4.11.4-2   
/mingw64/share/sip/Py2-Qt4/QtCore/QtCoremod.sip

mingw64/mingw-w64-x86_64-python2-pyqt5 5.8-1
/mingw64/share/sip/Py2-Qt5/QtCore/QtCoremod.sip

mingw64/mingw-w64-x86_64-python3-pyqt4 4.11.4-2
/mingw64/share/sip/PyQt4/QtCore/QtCoremod.sip

mingw64/mingw-w64-x86_64-python3-pyqt5 5.8-1   
/mingw64/share/sip/PyQt5/QtCore/QtCoremod.sip



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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

[Arjen Markus]

Hi Alan,



See below.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Sunday, September 03, 2017 4:47 AM
> To: Arjen Markus; PLplot development list
> Subject: Missing pyqtconfig module issue should now be fixed
>
> Hi Arjen:
>
> You reported some time ago that the deprecated pyqtconfig module was not
> available on the MinGW-w64/MSYS2 platform.  Since that deficiency is obviously
> likely to spread to other platforms as well, I have now (commit b3ef719) 
> updated
> our pyqt-related CMake logic to replace the pyqtconfig approach with our own
> approach for finding PYQT_SIP_DIR, the directory whose subdirectories contain 
> all
> PyQT *.sip files.
>
> I am pretty sure this new pyqt-related CMake logic will work OK for you now on
> MinGW-w64/MSYS2, but if not, please let me know what PYQT_SIP_DIR value
> you needed to specify to work around this issue so I can improve those HINTS 
> for
> the PyQt4 case for finding that directory prefix on MinGW-w64/MSYS2.
>

Okay, sounds interesting - I will give it a try tonight.

> Similarly, if on MSVC you have installed a third-party binary package that 
> supplies
> PyQT4, then I think the present code is likely to work, but if not I would 
> appreciate
> your PYQT_SIP_DIR feedback for that platform as well so I can improve our
> HINTS for the PyQt4 case.
>
> And similarly for PyQt5 on both platforms.
>
> For the Cygwin case I already know from using their file-location GUI that I 
> have
> the correct HINTS for both PyQt4 and PyQt5.
>
I had some problems with Cygwin during the last round of comprehensive tests. I 
will have to see if this change solves the problem.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is it time to remove our old fortran and our old Tcl bindings and examples?

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, August 29, 2017 6:00 AM
> To: Arjen Markus; PLplot development list
> Subject: Is it time to remove our old fortran and our old Tcl bindings and 
> examples?
>
> Hi Arjen:
>
> This e-mail concerns cruft removal for both the Fortran and Tcl cases.
>
> Fortran:
>
> We introduced the new Fortran binding and corresponding examples as of
> PLplot-5.12.0 (released on 2017-01-29), but as a safety measure supplied the 
> old
> Fortran binding and examples if the user specified the CMake option -
> DPL_DEPRECATED_fortran=ON (which gave access to bindings/old_fortran and
> examples/old_fortran).
>
> Since that release I think we have gotten not even one complaint about the new
> fortran binding which introduced many backwards incompatible changes.  (There
> was one complaint about lack of Fortran support in CMake for a non-mainstream
> Fortran compiler, but that is a different issue that affects both our old and 
> new
> fortran binding for that one user.) Furthermore, the next release is likely 
> coming out
> in early 2018 or roughly one year later than PLplot-5.12.0.
> Therefore, I believe this release cycle is the right time to get rid of the 
> cruft
> consisting of the -DPL_DEPRECATED_fortran=ON option and bindings/old_fortran
> and examples/old_fortran.
>
> If you agree with this timing, and assuming nobody on the plplot-general list 
> objects
> (i.e., there is nobody there who is still actually using the old fortran 
> binding), then I
> would plan to remove this cruft within a few days from now (just to make this
> change early in the release cycle so it gets maximum testing before the 
> release in
> early 2018).

I agree - keeping the old stuff around (especially with the extra logic 
required for its support) is an unnecessary complication.

>
> Tcl:
>
> There is a similar story with the redacted Tcl API introduced in 
> PLplot-5.12.0.
> There have been no complaints about that large backwards incompatible change,
> and the next release will be roughly a year away from the release where this
> change was introduced.
> Therefore, I believe this release cycle is the right time to get rid of the 
> cruft
> consisting of the -DUSE_NON_REDACTED_TCL_TK=ON option and the
> corresponding bindings/non_redacted_tcl, bindings/non_redacted_tk,
> bindings/non_redacted_tk-x-plat, examples/examples/non_redacted_tcl,
> and examples/non_redacted_tk.
>
> If you agree with this timing, and assuming nobody on the plplot-general list 
> objects
> (i.e., nobody there is using the -DUSE_NON_REDACTED_TCL_TK=ON option),
> then I would plan to remove this cruft within a few days from now just as in 
> the
> fortran cruft removal case and for similar reasons.
>
Here the same remark holds.

> General remarks about this cruft removal:
>
> I am pushing this cruft removal because keeping those old files around 
> implies we
> should sometimes test the -DPL_DEPRECATED_fortran=ON and -
> DUSE_NON_REDACTED_TCL_TK=ON options (which I don't want to do) and also
> do minimal maintenance to the old versions of the files (which I also don't 
> want to
> do).  For example, I am about to remove the long-deprecated plrgb, plrgb1, 
> plhls,
> and plwid.  But some of those are assumed to be available (when -
> DPL_DEPRECATED=ON) in the old versions of the Fortran and Tcl bindings.
> Which implies I need to either maintain those old versions consistent with the
> removal of plrgb, plrgb1, plhls, and plwid or do the much simpler task of 
> deleting
> those old versions.
>
I see that some of the source files for Tcl/Tk contain these macros. These can 
be simplified as well then.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] On-going Windows testing, and our Wiki summary of it

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, August 28, 2017 10:05 AM
> Hi Arjen:
>
> Could you please take a look at
> 
> where I have recently added a summary of your latest noninteractive
> comprehensive test for MinGW-w64/MSYS2?  In that summary I had to guess at
> the wxwidgets version number. If I guessed wrong, please update that version, 
> and
> please also update any other thing in the
> MinGW-w64/MSYS2 summary which you feel I got wrong as well.
>

Sure, I will have a look.

> (By the way, my recent commit to change how we test for wxwidgets version
> number also outputs the wxwidgets version that has been found.  So I shouldn't
> have to guess any more about that from now on.)
>
That will definitely be useful - it was puzzling in the past.

> Now that you have essentially complete noninteractive comprehensive testing
> success with MinGW-w64/MSYS2, our wiki page
>  needs to be updated
> from Greg's two-year-old experience to yours on this platform.
> Also, all the MSYS2 URL's on that page have to be updated to refer to the 
> github
> version of the MSYS2 wiki, and the recommended list of MinGW-w64/MSYS2,
> packages needs updating. Would you be willing to take responsibiltiy for these
> updates to this wiki page?
>
I will take care of that, but not rightaway. There are several other things 
besides PLplot that require my attention, I am afraid ;).

> Note, I haven't bothered in the above table of reports to summarize your 
> latest
> Cygwin and MSVC noninteractive tests because I don't view those as complete 
> yet,
> see my quoted question to you above about the next comprehensive test you plan
> to do.
>
There is indeed a whole bunch of smallish things that need to be sorted out, 
for the three Windows-based platforms in fact.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, August 21, 2017 9:04 PM
>
> By the way, we had absolutely clear weather this morning for looking at the 
> partial
> solar eclipse that was visible from here and which reached ~90 per cent 
> obscuration.
> It wasn't nearly as spectacular as the total eclipse experience that is 
> occurring
> south of here on the totality path, but it was still pretty special because 
> the solar
> crescent that was left at maximum obscuration was quite narrow. So I was glad 
> I
> took some time out to look at it with my eclipse viewer, and even without the 
> viewer
> it was obvious that the sunlight was a lot less than normal.
>
I envy you. The first time I saw it, a long time ago, the eclipse was partial, 
something like 40% (wild guess) and the second and last time, when there was 
the promise of something like 90% or more, the sky was clouded. I did notice a 
drop in light intensity and I had the radio at hand for a live report from 
France, but that is a poor surrogate ;).

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen Markus]

Hi Alan,



I have uploaded the full contents of the examples directory, as you requested. 
It was your earlier estimate of 62 MB that prompted me to limit it to merely 
the PostScript files ;).



Anyway, I agree: the remaining issues with the various Windows-based platforms 
can be examined after the release. They seem to be relatively minor and solving 
them may take quite some time, if only the complete test runs take a long time.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Saturday, August 19, 2017 2:38 AM
>
> In sum, in the interest of getting this release done in a timely manner, I am 
> fine with
> you putting off the above 3 comprehensive test efforts until later.  So 
> assuming you
> agree, I am very much looking forward to releasing 5.13.0 on or before 
> Tuesday,
> August 22nd 16:00 UTC.
>
> Thanks once again for all your testing and other help that has made the 
> PLplot-
> 5.13.0 release so much better than it would have been otherwise.
>


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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen Markus]

Hi Alan,



Okay, a bit more grumpiness:



I expand the path to get access to git in the comprehensive tests, but then 
CMake fails:



-- Looking for gdi32 header and library

-- Looking for gdi32 header and library - found

CMake Error at cmake/modules/FindwxWidgets.cmake:933 (message):

  wxWidgets wx/version.h file not found in

  
C:/progra~1/git/mingw64/lib/wx/include/msw-unicode-3.0;C:/progra~1/git/mingw64/include/wx-3.0.

Call Stack (most recent call first):

  cmake/modules/wxwidgets.cmake:49 (find_package)

  cmake/modules/drivers.cmake:99 (include)

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

  CMakeLists.txt:125 (include)



I will turn off the expansion of the PATH, losing "git", but hopefully getting 
a useable CMake output.



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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Friday, August 11, 2017 6:33 PM
>
> Once you perform (1), (2'), and (3), I should have two report tarballs to 
> look at as
> well as one ~62MB tarball collection of plot file results, and assuming those 
> reveal
> no more issues (other than the "missing pyqtconfig.py" issue we will be 
> dealing with
> after the release), then these should be the last noninteractive tests you 
> need to
> make on this platform before the release.
>
This is turning out to be very frustrating - a sort of spring procession of 
Echternach.

While my installation of MinGW-w64/MSYS2 is clean (I did not mess with it other 
than via pacman), I thought it would be a good idea to do a parallel 
installation anyway - as a test for my automated installation procedure and as 
future help to others.

So:

-The automated installation went fairly smooth, but CMake did not 
acknowledge the MSYS or Unix generators that my original installation did have.

-I had to resort to the MinGW generator, but then you have to move 
"sh.exe" out of the way.

-I had some trouble getting "git" to be available via the 
MinGW-w64/MSYS2 shell - I later realised that was my fault. So I corrected that 
this morning by expanding the PATH correcrly. Only to discover that the git 
installation then brings in its own "sh.exe".

-Yesterday I got stuck because CMake was invoking the MicroSoft version 
of make - despite the fact that "which make" in the MinGW-w64/MSYS2 shell 
reports "/usr/bin/make". The MicroSoft make utility does not do anything useful 
with the makefiles as they are generated by CMake in this constellation :(. 
Except perhaps causing the process to hang.

-I realised, however, that I could instruct the comprehensive test 
script to explicitly use "/usr/bin/make". So I added that option to the 
invocation.

-To my surprise CMake did acknowledge the "MSYS generator" this morning 
(*), but because I had moved "sh.exe" out of the way, "/usr/bin/make" refused 
to do its job, as it could not find the "sh.exe" executable. So CMake failed. 
Sigh.

Sorry to sound so grumpy, but it was rather frustrating as I already said. The 
whole thing is requiring more of my attention than I can actually spare for the 
next few days (I have to revise an article and that is mostly in my spare 
time). I will try to get bits and pieces of the tests done inbetween all other 
stuff, but I am not going to promise anything as far as time of delivery is 
concerned.

Regards,

Arjen

(*) MinGW-w64 seems to require that you restart the shell after installing 
things if you want to take full advantage of the freshly installed package. 
That may be an explanation for yesterday's failure with CMake. A small mistake 
in my install script required me to install CMake manually.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0 - findings regarding Cygwin

[Arjen Markus]

Hi Alan,



I will ignore wxWidgets for the moment. Cmake seems to find something, but is 
quiet about the reasons for its final decision:



-- wxWidgets_FOUND : FALSE

-- wxWidgets_INCLUDE_DIRS  : 
/usr/lib/wx/include/gtk3-unicode-3.0;/usr/include/wx-3.0

-- wxWidgets_LIBRARIES :

-- wxWidgets_LIBRARY_DIRS  :

-- wxWidgets_DEFINITIONS   : _FILE_OFFSET_BITS=64;WXUSINGDLL;__WXGTK__

-- wxWidgets_DEFINITIONS_DEBUG :

-- WARNING: wxWidgets or its libraries not found so setting all wxwidgets 
devices to OFF.

-- WARNING: PLD_wxwidgets is OFF so setting ENABLE_wxwidgets to OFF.

-- WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to OFF.



But analysing that will be for another time.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, August 14, 2017 11:27 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Planning for the release of 5.13.0 - findings 
> regarding
> Cygwin
>
> On 2017-08-14 08:19- Arjen Markus wrote:
>
> > It looks as if some component is missing - as it still didn't work
> when I removed version 2.8. Which component is a riddle though. At least it 
> does
> not seem to be the shear logic itself.
>
> Where is the find process failing?  If the cmake output does not get to the 
> version
> check and instead says that wxwidgets is not found, then my educated guess is
> there is some issue with cmake/modules/Findwxwidgets.cmake for the Cygwin 
> case.
> You have debugged that logic previously for the MinGW-w64/MSYS2 case so you
> know what to do which is to insert some message(STATUS...) and/or try the 
> cmake
> --debug-output and --trace options to see what is going on with that find 
> module for
> the Cygwin case.
>
> Anyhow, wxwidgets does not matter for the noninteractive comprehensive test on
> Cygwin so please finish that test first and also the corresponding 
> noninteractive
> comprehensive test for MinGW-w64/MSYS2, and deal with this Cygwin wxwidgets
> issue later (or even post-release since interactive testing on Cygwin is so 
> slow
> compared to your other platforms).
>
> 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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0 - findings regarding Cygwin

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, August 14, 2017 10:16 AM
> > This 2.8 versus 3.0 issue is something we need to look into. For the moment 
> > I will
> just continue with 3.0 only.
>
> I don't really understand the module, but from the comments in
> cmake/modules/FindwxWidgets.cmake, that module supports version selection,
> and does the right thing if multiple versions are available.  So I have put 
> into my
> post-release ToDo list that we should drop our own brute-force version check
> (which doesn't work for multiple versions like you had installed) and use the
> FindwxWidgets.cmake version check instead.
>
> But for now, you can work around the problem (as you have stated
> above) by installing 3.0 only,
>
It looks as if some component is missing - as it still didn't work when I 
removed version 2.8. Which component is a riddle though. At least it does not 
seem to be the shear logic itself.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0 - findings regarding Cygwin

[Arjen Markus]

Hi Alan,



As promised: I have found that currently wxWidgets is not acknowledged by 
PLplot on my laptop and I had a look at the report to find out why, because in 
previous tests I did have it. Here is the situation:

-In december last year, the build did include wxWidgets, as witnessed 
by a CMake output report from that date that I have on my computer. Currently, 
however, it is refused because PLplot finds a version 2.8 of wxWidgets and not 
3.0.

-My Cygwin installation has both 2.8 and 3.0 - the latter was updated 
after said report (a matter of comparing the file dates).

-Why PLplot now does not find that 3.0 version is not clear to me. I 
guess unstalling version 2.8 should work.

-I updated the setup utility for Cygwin a weeks ago, but that new 
version works differently than the previous one. Searching for "wxWidgets" does 
not show which packages were installed, but I just found out that searching for 
"wx" does. So I can uninstall 2.8 and try again.



This 2.8 versus 3.0 issue is something we need to look into. For the moment I 
will just continue with 3.0 only.



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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Finding the sip system directory and sip command flags for PyQt4 and PyQt5

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, August 10, 2017 11:19 PM
...

> * The PyQt4 case
>
>In this case we currently depend on the pyqtconfig Python module to
>find the sip system directory and sip command flags, and although
>both the Debian and Cygwin packagers of PyQt4 provide this
>deprecated (by the PyQt4 developers) module, the MinGW-w64/MSYS2
>packager of PyQt4 does not.  For more details about this situation,
>see the recent discussion on the MSYS2 mailing list that Arjen
>started with the subject line "How to complete the installation of
>PyQt4?" Arjen is going to submit a MinGW-w64/MSYS2 bug report
>concerning this MinGW-w64/MSYS2 issue.  However, they may decide not to
>supply this deprecated module, and by definition of what deprecated
>means, it is virtually guaranteed that all software distributions
>will eventually stop providing pyqtconfig so we have to find
>an alternative to use for our build system.
>
>

FIY, I have reported this issue in https://github.com/msys2/msys2/issues/69.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, August 08, 2017 11:46 AM
>
> So if you use make -j8 (or so) and ctest -j8 for your comprehensive test it 
> will really
> go ~4 times faster because those -j options will utilize your four cores 
> completely.
> But you have found in the past that the -j option gives unreliable results 
> for both
> make and ctest for both the Cygwin and MinGW-w64/MSYS2 platforms.  So you
> have dropped these -j options with the result that you only use one of your 
> cores,
> but at least you do get slow but reliable results that way.
>
I explicitly use the build command "make" because of that, but I still see four 
instances of make running, as well as six instances of bash. This is with 
message "make VERBOSE=1 test_noninteractive in the installed examples build 
tree" as the last visible text.

Not at all sure what this means, the information I get from the task manager 
does not reveal much about what these processes are actually doing (like in 
which directory etc.)

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen Markus]

Hi Alan,



See below.



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, August 08, 2017 1:59 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Planning for the release of 5.13.0
>
> On 2017-08-07 11:05- Arjen Markus wrote:
>
> > This certainly fixed the "Bad Address" problem - see the attached
> tarball.
>
> Hi Arjen:
>
> I did my usual checks of this report, and I am thrilled that error is gone 
> AND you
> were able to finish the script this time without any further showstopping 
> errors.
> However, this test result is still incomplete, and your platform needs to be 
> updated
> to address those issues, see below.
>
> [...]
> > As the full run takes half a day
>
> [...]
>
> The fairly equivalent test here (although I test substantially more 
> components of
> PLplot because Linux has allowed me to install virtually all of the PLplot 
> soft
> dependencies) takes ~2 hours here on a decade-old (but still fairly high end) 
> two-
> cpu box with each of those cpu's running at 2.4GHz.  So I would predict it 
> would
> take roughly 4 hours there on your one-cpu box if that single cpu also runs at
> roughly 2.4GHz.  So out of curiosity does your "half a day" correspond to 
> half a
> working day, i.e., 4 hours or do you mean something much longer than that?
>

No, half a working day :).

> [out of order]
> > I noticed that the MinGW-w64/MSYS2 installation that I used
> does not have the diff or cmp command, so a comparison is missing.
> [...] I will add diff later (and check the other components that are not 
> accepted right
> now).
>
> I am really pleased that you are planning to do get rid of this (and other, 
> see below)
> platform deficiencies by making this important update of your MinGW-w64/MSYS2
> platform before you do any more PLplot testing on this platform.
>
> There is one important caveat you should keep in mind about this platform 
> update.
> My judgement from listening to complaints for a long time on the MSYS2 list 
> is a
> given snapshot of this platform is not always in a self-consistent or even 
> working
> state from one day to the next.  So most days seem to be OK, but sometimes 
> not.
> So to make yourself fairly immune to that uncertainty I suggest you attempt no
> additional package installs of any kind for your present platform.
> Instead, you should install a completely new version of
> MinGW-w64/MSYS2 from scratch using a unique installation prefix so you can go
> back to your current working but somewhat limited version of this platform if 
> the
> new snapshot of MinGW-w64/MSYS2 does not work.
> Of course that new install should be automated as much as possible with a 
> script to
> make it trivially easy for you to do further installs of MinGW-w64/MSYS2 from
> scratch as needed, i.e., one or two days later if that new version does not 
> work for
> today's snapshot.
>
> That installation script should include a well-maintained list of packages 
> that are
> needed for PLplot testing (and general full use of PLplot on this platform by 
> users).
> That list of packages should include the ones you currently have installed 
> plus "git"
> and "diffutils" (where the lack of prefix on these package names means you 
> will be
> installing from the "msys" repository of MinGW-w64/MSYS2), and either "mingw-
> w64-x86_64-qt4" (preferably if your package installation allows that without 
> conflicts
> since Qt4 is a more reliable library than Qt5 right now) or 
> "mingw-w64-x86_64-qt5".

I checked the list of packages for "git", but there is nothing obvious that 
will bring git into the mix. According to Google hits, you should simply 
install git for Windows.

I have Qt4 now in the installation, but not pyqt4 due to the lack of "SIP" for 
this platform. The information on SIP for MinGW-w64 is a trifle convoluted. 
That is for later.
>
> All three package installs are important. The git package needs to be 
> installed so
> that the comprehensive test script can figure out what git commit you are 
> testing for
> PLplot.  The diffutils package needs to be installed to supply the 
> all-important
> diff.exe executable (as you independently discovered above).  And qt4 (or qt5)
> needs to be installed so you can test on this platform our qt device driver 
> which is
> potentially a source of many high-quality noninteractive devices on this 
> platform (as
> well as one important high-quality interactive device, qtwidget, that you 
> might wish
> to test post-release as a basis of compar

Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen Markus]

Hi Alan,



Thanks for this analysis and the suggested steps for further investigation of 
this puzzle. I hope to have time this weekend to investigate this.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, August 03, 2017 8:56 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Planning for the release of 5.13.0
>
> On 2017-08-02 19:36- Arjen Markus wrote:
>
> >> -Original Message-
> >> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> >> Sent: Tuesday, August 01, 2017 9:57 AM
> >>
> > ...
> >> 1.  If you get good results in the Cygwin case, but not the
> >> MinGW-w64/MSYS2 case, then that is pretty good evidence of a bug in
> >> the
> >> MinGW-w64/MSYS2 "make" package.
> >>
> >> 2. If both don't work, then that means long command lines work in
> >> neither, and perhaps we have to write off this PLplot issue for the
> >> MinGW-w64/MSYS2 case to longer path names/longer command lines in
> >> that case compared to the Cygwin case.  But I consider this result to
> >> be unlikely because according to
> >> <https://stackoverflow.com/questions/19354870/bash-command-line-
> >> and-input-limit>
> >> the Cygwin bash line limit is 32000 bytes, i.e., well above the 2001
> >> bytes generated above.
> >>
> >> 3. But if both work, then you will have to dig deeper.
> >>
> >>
> > There is but a single bash.exe on the system and the makefile you sent works
> perfectly on both Cygwin and MinGW.
>
> Hi Arjen:
>
> Actually, you must have at least two different bash.exe executables installed 
> on
> your computer, one from Cygwin and one from MinGW-w64/MSYS2. So I think you
> meant the following, but just to be absolutely clear, can you double check 
> that only
> the Cygwin-installed version version of bash.exe was on your PATH for the 
> Cygwin
> experiment and only the MinGW-w64/MSYS2-installed version of bash.exe was on
> your PATH for the MinGW-w64/MSYS2 experiment?  Each are likely installed in 
> the
> "/usr/bin/bash.exe" location on both platforms, but those are two very 
> different
> places so, e.g., "ls -l /usr/bin/bash.exe" will show different dates and 
> lengths for
> those two different files when run from Cygwin and MinGW-w64/MSYS2.  Of
> course, the best thing to do in each case for your tests is to run bash.exe 
> using its
> full path name starting with a drive letter which is unambigous.  And as I 
> said before,
> you should be doing the same for make.exe (and cmake.exe and
> ctest.exe) when your invocation script runs the comprehensive test script.
>
> > Your example did inspire me to try "gcc -o x x.c
> -DLONG=01234.89" instead of "echo".
>
> > That, however, works perfectly
> as well. There must be something much more specific that is causing this. For 
> the
> moment I have run out of easy-to-test ideas though.
>
> Such experiments as the one you tried above (and the further one you tried in 
> a
> later post) are extremely useful.
>
> So assuming you really are using two different versions of bash for this 
> test, then
> you have confirmed there are no line-length issues for make for either Cygwin 
> or
> MinGW-w64/MSYS2 which is a big step forward.
>
> Stepping back a bit from these details, it seems to me the fundamental issue 
> here
> is you have a comprehensive test failure that you have not yet been able to
> reproduce by hand.  So let's go back and see exactly why you cannot (so far)
> replicate by hand. Furthermore, to take advantage of the results accumulated 
> on
> disk by your last comprehensive test with -DNON_TRANSITIVE=ON, let's stick
> with those.
> (Those results were identical to your previous ones without that option other 
> than
> linking commands were much shorter.)
>
> The key here is to attempt to reproduce the bad script result by following 
> all the
> essential steps that script does.  For example, from the report you sent of 
> the -
> DNON_TRANSITIVE=ON case just prior to the error there was this messaged
> emitted by the script:
>
> 'Prepend "/d/plplot-
> svn/comprehensive_test_disposeable/nondynamic/noninteractive/install_tree/bin"
>  to
> the original PATH
>
> That's really important since it sets the exact (nondynamic) versions of the 
> PLplot
> libraries that are being used for this part of the test you are trying to 
> replicate.
>
> That original PATH (according to that report) is
>
> PATH="/d/cmak

Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen Markus]

Hi Alan,



I thought that perhaps it was due to the number of arguments, but even that 
does not seem to be the case:



all:

gcc -o x x.c -DX0-0 -DX1=1 ... -DX199=199



will produce an executable x.exe without any problems.



Regards,



Arjen

From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
Sent: Wednesday, August 02, 2017 9:37 PM
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] Planning for the release of 5.13.0


Hi Alan,



See below - we are no closer to a solution, sigh.



Regards,



Arjen


Your example did inspire me to try "gcc -o x x.c -DLONG=01234.89" instead 
of "echo". That, however, works perfectly as well. There must be something much 
more specific that is causing this. For the moment I have run out of 
easy-to-test ideas though.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0

[Arjen Markus]

Hi Alan,



See below - we are no closer to a solution, sigh.



Regards,



Arjen

> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, August 01, 2017 9:57 AM
>
...
> 1.  If you get good results in the Cygwin case, but not the
> MinGW-w64/MSYS2 case, then that is pretty good evidence of a bug in the
> MinGW-w64/MSYS2 "make" package.
>
> 2. If both don't work, then that means long command lines work in neither, and
> perhaps we have to write off this PLplot issue for the
> MinGW-w64/MSYS2 case to longer path names/longer command lines in that case
> compared to the Cygwin case.  But I consider this result to be unlikely 
> because
> according to  and-input-limit>
> the Cygwin bash line limit is 32000 bytes, i.e., well above the 2001 bytes 
> generated
> above.
>
> 3. But if both work, then you will have to dig deeper.
>
>
There is but a single bash.exe on the system and the makefile you sent works 
perfectly on both Cygwin and MinGW.

Your example did inspire me to try "gcc -o x x.c -DLONG=01234.89" instead 
of "echo". That, however, works perfectly as well. There must be something much 
more specific that is causing this. For the moment I have run out of 
easy-to-test ideas though.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Planning for the release of 5.13.0 --Cygwin Ada issue

[Arjen Markus]

Hi Alan,



See below in context.

Regards,

Arjen

> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, August 01, 2017 5:02 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Planning for the release of 5.13.0 --Cygwin Ada issue
>
> On 2017-07-31 07:13- Arjen Markus wrote:
>
> > Here are some results from my most recent, i.e. yesterday's, testing 
> > session.
>
> Hi Arjen:
>
> I first want to emphasize that I am well aware I am asking for a lot of 
> testing from
> you, and thanks in advance for anything you can do!
>

:) It was surprising that it took so much time - I have most of this automated 
by a collection of ad hoc scripts, but some nursing is needed, especially if 
things do not work out as before.

> It turns out this is a long-standing issue, see your post from more than a 
> year ago
>
> 2016-03-17 Arjen Markus(21K) RE: comprehensive testing results on Cygwin -
> Ada build errors
>

Forgot all about that. The script I use for cdash reports takes care of the 
extra information needed for Ada, so I thought it worked fine.

> However, I think I have a lot better understanding of the issue now, then I 
> did back
> then.
>
...

>
> So to test that possibility, please use the -DNON_TRANSITIVE=ON cmake option
> for this test to see if (a) you get further with Ada, and (b) if that option 
> causes
> issues for other parts of our comprehensive tests for the Cygwin platform.  
> And
> depending on what combination of (a) and (b) you obtain, I will take it from 
> there.
>
Very much the same thing: link errors concerning doubly defined symbols. There 
do not seem to be - at first sight - other issues, but they might come later in 
the build process.

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.


comprehensive_test.tar.gz
Description: comprehensive_test.tar.gz
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The wxwidgets version you use for MSVC - solved (not quite though)

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, July 12, 2017 3:21 AM
>
> By the way, this is really good news that MSVC found this issue and you 
> reported it
> because previously I was having trouble figuring out why that code was not
> producing correct superscript/subscript results.
> But I suspect once I fix this uninitialized variable bug, that other problem 
> will
> become understandable and solveable as well.
>
Good luck with that one :). Of course, others may be surfacing as well when the 
logic is complex.

>
> So it sounds like you want to drop your previous commit to
> cmake/modules/FindwxWidgets.cmake.
>
Most definitely. This change would open up the same sort of trouble for others 
who make this mistake. Perhaps the error message can be made clearer - 
suggesting a solution as I found it. The list of packages is quite long, as for 
each version of MSVC that is supported there are at least four different 
choices and the link errors indicate nothing of the sort.

I will commit the reversal in the manner you advocate.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The wxwidgets version you use for MSVC - solved (not quite though)

[Arjen Markus]

Hi Alan, Phil,

> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, July 10, 2017 11:36 PM
>
> Anyhow, I now think you have had all the input you need from Phil and me to 
> fix or
> work around this wxwidgets linking issue you have discovered, and I look 
> forward to
> hearing from you what the solution turns out to be.
>
I use VERBOSE=1 to get insight in the build process, but that was of little use 
- most of the details are hidden in temporary files. So I checked the 
dependencies file (CXX.includecache) and saw only include files from 
d:\wxwidgets. Then I compiled the source file using the flags in flags.make and 
the -E option to get the preprocessed source and found that both wxString and 
wxSize were defined as expected (and used all over the place). So I sought the 
.lib files (so-called import libraries) for the symbols that were missing. None 
contained exactly those strings.

Okay, I went back to the wxWidgets site, downloaded the latest version (as that 
was advertised). Exact same problem. Then I noticed something - there were 
separate distributions for 32 bits and 64 bits environments. And then it hit 
me: I had downloaded the _wrong_ bits version. From there on it went quite 
smoothly. After some struggles with the path I got the build to succeed and got 
an example to run. The only (!) problem left is that on line 378 in 
wxwidgets_dev.cpp the variable "offset" is used but was not previously set. 
This causes a debug error under MSVC:

[cid:image001.png@01D2FA8F.0E63E220]

A quick check of the source code did not tell me how to solve that, so I will 
have to leave that to you.

By the way, the correct 64-bits libraries are installed in a directory 
containing the "x64" suffix. So my earlier change was (a) not necessary (b) an 
indication I had downloaded the wrong libraries. If only they had used "x86" or 
"x32" or something for 32-bits versions ...

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The wxwidgets version you use for MSVC

[Arjen Markus]

Hi Alan, Phil,



Thanks for all the input and suggestions. I will try and find time this evening 
to hunt down the cause of these problems.

Regards,

Arjen


> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, July 10, 2017 11:36 PM
> To: Arjen Markus; Phil Rosenberg; plplot-devel@lists.sourceforge.net
> Subject: Re: [Plplot-devel] The wxwidgets version you use for MSVC
>
> On 2017-07-10 11:20-0700 Alan W. Irwin wrote:
>
> > On 2017-07-10 11:05- Arjen Markus wrote:
> >
> > [...]
> >> As far as I can tell, the build should be picking up everything from
> > the installation and not gather stuff from elsewhere. It is unlikely
> > it is scavenging the MinGW or Cywin installations. Anyway, got to
> > check that.
> >
> > Hi Arjen:
> >
> > I assume you are going to do that check using the nmake VERBOSE=1
> > option to discover the actual -I options your PLplot build uses for
> > the wxwidgets components.  At the same time you should check whether
> > those -I options refer to locations that are too deep into the
> > wxwidgets header tree so you are finding a private header rather than
> > the correct public version of the header.  And another option is for
> > you to try a wxwidgets version that you built yourself with the exact
> > build options you need in case that makes any difference. So there
> > appears to be plenty of things you can try here to help you find the
> > solution to the MSVC link error you discovered.
>
> Hi again, Arjen:
>
> Although it would be good to quickly check the above possibility that CMake 
> might
> incorrectly find a private header rather than the desired public header, I 
> now think
> the probability of that happening is low.
> The reason is the official version of the find module is heavily maintained 
> (and
> therefore likely to get the -I options right).
> Furthermore, I have also checked all our changes to
> cmake/modules/FindwxWidgets.cmake relative to the official version, and they 
> are
> completely straightforward and have nothing to do with -I options.
>
> Anyhow, I now think you have had all the input you need from Phil and me to 
> fix or
> work around this wxwidgets linking issue you have discovered, and I look 
> forward to
> hearing from you what the solution turns out to be.
>
> 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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The wxwidgets version you use for MSVC

[Arjen Markus]

Hi Phil,



I will have to check that later. As far as I can tell, the build should be 
picking up everything from the installation and not gather stuff from 
elsewhere. It is unlikely it is scavenging the MinGW or Cywin installations. 
Anyway, got to check that.



Regards,



Arjen



> -Original Message-
> From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
> Sent: Monday, July 10, 2017 12:31 PM
> To: Arjen Markus; Alan W. Irwin; plplot-devel@lists.sourceforge.net
> Subject: Re: The wxwidgets version you use for MSVC
>
> Last email of speculation
>
> I have found in the latest source that the file include/wx/gdicmn.h includes 
> the inline
> definition for the constructor, but the file interface/wx/gdicmn.h does not 
> include the
> inline definition for the constructor. The former should be used by external
> applications like ours, the latter is for building the wx libraries 
> themselves. Is it
> possible that you are loading the latter somehow from somewhere?
>
> On 10 July 2017 at 11:18, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> > Hi Arjen
> > Doing a git blame on GitHub indicates that the relevant constructor
> > line was last edited 10 years ago, which seems strange. However that
> > is probably the header used when building the library rather than put
> > in the include directory for use by external programs. Maybe the two
> > are not the same :-s.
> >
> > If you are building with Visual studio, then you can find an example
> > of wxSize being used and right click it, then go to
> > definition/declaration. This should take you to the actual header file
> > being parsed and you can check it is the one you expect (hover over
> > the filename tab to show the full path or right click the tab and hit
> > open containing folder) and you can check the constructor is inlined.
> >
> > Phil
> >
> > On 10 July 2017 at 11:10, Arjen Markus <arjen.mar...@deltares.nl> wrote:
> >> Hi Phil,
> >>
> >>
> >>
> >> I am using MSVC and nmake to compile this under bare Windows. I
> >> remember seeing some confusion over what installation CMake came up
> >> with exactly, but I do not recall the details. That may have been with the 
> >> MinGW
> experiments.
> >>
> >>
> >>
> >> I will have to check this - tonight if possible.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Arjen
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
> >>
> >>> Sent: Monday, July 10, 2017 12:04 PM
> >>> To: Arjen Markus
> >>> Subject: Re: The wxwidgets version you use for MSVC
> >>>
> >>> Ah, so you do have the inlined function definition. In that case I
> >>> am confused.
> >>>
> >>> Is there any possibility that you have more than one set of
> >>> wxWidgets headers installed, the one you are looking at and a latest
> >>> dev version?
> >>>
> >>> What are you using to compile are you using visual studio or minGW?
> >>>
> >>> Phil
> >>>
> >>> On 10 July 2017 at 10:52, Arjen Markus <arjen.mar...@deltares.nl> wrote:
> >>> > Hi Phil,
> >>> >
> >>> >
> >>> >
> >>> >> -Original Message-
> >>> >> From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
> >>> >> Sent: Monday, July 10, 2017 11:49 AM
> >>> >> To: Arjen Markus; plplot-devel@lists.sourceforge.net
> >>> >> Cc: Alan W. Irwin
> >>> >> Subject: Re: The wxwidgets version you use for MSVC
> >>> >>
> >>> >> Hi Arjen
> >>> >> That looks like the class you are looking for. Those comments
> >>> >> shouldn't be important. They just mean that you can access x and
> >>> >> y exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
> >>> >> But the comment says please don't do this.
> >>> >>
> >>> >
> >>> > Right, I misread that as meaning the data AND the method members,
> >>> > but it only refers to the data members.
> >>> >
> >>> >> Further down in that class is there a constructor? it will look
> >>> >> something like wxSize( int w, int h). It looks like a function
> >>> >> declaration, but w

Re: [Plplot-devel] The wxwidgets version you use for MSVC

[Arjen Markus]

Hi Phil,



Quite the same - see my earlier reply.



Regards,



Arjen



> -Original Message-
> From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
> Sent: Monday, July 10, 2017 12:02 PM
> To: Arjen Markus; plplot-devel@lists.sourceforge.net
> Cc: Alan W. Irwin
> Subject: Re: The wxwidgets version you use for MSVC
>
> I just checked in my version. I have
>
> class WXDLLIMPEXP_CORE wxSize
> {
> public:
> // members are public for compatibility, don't use them directly.
> int x, y;
> // constructors
> wxSize() : x(0), y(0) { }
> wxSize(int xx, int yy) : x(xx), y(yy) { }
>
> The last line is the important one. What does it look like in your version?
>
> I have just looked on GitHub on the latest source
> (https://github.com/wxWidgets/wxWidgets/blob/master/interface/wx/gdicmn.h)
> and this constructor has indeed changed to not inlined and instead looks like
>
> wxSize(int width, int height);
>
> I would suggest that there is some mismatch between the headers you have and
> the dll. The dll used inlined version, so includes no definition and the 
> headers have
> the non inlined version so also includes no definition. The linker is 
> therefore
> rightfully complaining there is no definition. If this is the case then it's 
> a bug with the
> wxWidgets distribution.
>
> Phil
>
> On 10 July 2017 at 10:48, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> > Hi Arjen
> > That looks like the class you are looking for. Those comments
> > shouldn't be important. They just mean that you can access x and y
> > exactly like in a C struct, for example wxSize mySize; mySize.x=4;.
> > But the comment says please don't do this.
> >
> > Further down in that class is there a constructor? it will look
> > something like wxSize( int w, int h). It looks like a function
> > declaration, but with no return type. The variable names may be
> > different too - probably some variation on width and height or x and
> > y.
> >
> > On 10 July 2017 at 10:25, Arjen Markus <arjen.mar...@deltares.nl> wrote:
> >> Hi Phil,
> >>
> >>
> >>
> >> That is definitely a possibility. I had another search for wxSize. At
> >> first I only found wxSizer (which is not the class I was looking
> >> for), but finally I did - in a header file "gdicmn.h":
> >>
> >>
> >>
> >> class WXDLLIMPEXP_CORE wxSize
> >>
> >> {
> >>
> >> public:
> >>
> >> // members are public for compatibility, don't use them directly.
> >>
> >> int x, y;
> >>
> >>
> >>
> >> I have no idea what to make of the comment ...
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Arjen
> >>
> >>
> >>
> >>
> >>
> >> From: p.d.rosenb...@gmail.com [mailto:p.d.rosenb...@gmail.com]
> >> Sent: Monday, July 10, 2017 10:59 AM
> >> To: Arjen Markus; Alan W. Irwin
> >>
> >>
> >> Subject: RE: The wxwidgets version you use for MSVC
> >>
> >>
> >>
> >> Hmm, I wonder if wxUSE_STRING_POS_CACHE is set during the wxWidgets
> >> build of the dlls, but then not during the build of plplot. That
> >> would explain a linker error there i think.
> >>
> >>
> >>
> >> You could search for wxSize::wxSize which should locate the
> >> constructors for that class, if they exist.
> >>
> >>
> >>
> >> Phil
> >>
> >>
> >>
> >> Sent from my Windows 10 phone
> >>
> >>
> >>
> >> From: Arjen Markus
> >> Sent: 10 July 2017 08:22
> >> To: p.d.rosenb...@gmail.com; Alan W. Irwin
> >> Subject: RE: The wxwidgets version you use for MSVC
> >>
> >>
> >>
> >> Hi Phil,
> >>
> >>
> >>
> >> See my answers below in context.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Arjen
> >>
> >>
> >>
> >>
> >>
> >> From: p.d.rosenb...@gmail.com [mailto:p.d.rosenb...@gmail.com]
> >> Sent: Monday, July 10, 2017 12:24 AM
> >> To: Alan W. Irwin
> >> Cc: Arjen Markus
> >> Subject: RE: The wxwidgets version you use for MSVC
> >>
> >>
> >>
> >> Hi Arjen
> >>
> >> Have you built any other wxWidgets applications with this li

Re: [Plplot-devel] The wxwidgets version you use for MSVC

[Arjen Markus]

Hi Phil,



> -Original Message-
> From: Phil Rosenberg [mailto:p.d.rosenb...@gmail.com]
> Sent: Monday, July 10, 2017 11:49 AM
> To: Arjen Markus; plplot-devel@lists.sourceforge.net
> Cc: Alan W. Irwin
> Subject: Re: The wxwidgets version you use for MSVC
>
> Hi Arjen
> That looks like the class you are looking for. Those comments shouldn't be
> important. They just mean that you can access x and y exactly like in a C 
> struct, for
> example wxSize mySize; mySize.x=4;.
> But the comment says please don't do this.
>

Right, I misread that as meaning the data AND the method members, but it only 
refers to the data members.

> Further down in that class is there a constructor? it will look something like
> wxSize( int w, int h). It looks like a function declaration, but with no 
> return type. The
> variable names may be different too - probably some variation on width and 
> height
> or x and y.
>
There are two in fact:

// constructors

wxSize() : x(0), y(0) { }

wxSize(int xx, int yy) : x(xx), y(yy) { }

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, July 05, 2017 8:38 PM
> @Arjen:
>
> Glad you solved the find issue.  Please commit your fix to
> cmake/modules/FindwxWidgets.cmake
>

Will do - I will have to clean up the file a bit though - sundry debug output 
statements added ;).

> I did a google search for the terms  __declspec(dllimport) public: __cdecl wxSize::wxSize(int,int)> (related to 
> the second
> linking error message above) and found
>  errors>
> where it indicates that such linking errors generally occur if the 
> preprocessor macro
> WXUSINGDLL is not #defined when shared libraries are used.
>
> Apparently cmake/modules/FindwxWidgets.cmake does set this macro in certain
> circumstances, but I wonder if those have actually occurred in your case.  To 
> find
> out, please look at your cmake output.  Does the line
>
> -- wxWidgets_DEFINITIONS  
>
> include WXUSINGDLL in the list?
>

It does:

-- wxWidgets_FOUND : TRUE

-- wxWidgets_INCLUDE_DIRS  : 
D:/wxwidgets/lib/vc120_dll/mswu;D:/wxwidgets/include

-- wxWidgets_LIBRARIES : 
debug;D:/wxwidgets/lib/vc120_dll/wxbase30ud.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxbase30u.lib;debug;D:/wxwidgets/lib/vc120_dll/wxmsw30ud_core.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxmsw30u_core.lib;debug;D:/wxwidgets/lib/vc120_dll/wxpngd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxpng.lib;debug;D:/wxwidgets/lib/vc120_dll/wxtiffd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxtiff.lib;debug;D:/wxwidgets/lib/vc120_dll/wxjpegd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxjpeg.lib;debug;D:/wxwidgets/lib/vc120_dll/wxzlibd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxzlib.lib;debug;D:/wxwidgets/lib/vc120_dll/wxregexud.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxregexu.lib;debug;D:/wxwidgets/lib/vc120_dll/wxexpatd.lib;optimized;D:/wxwidgets/lib/vc120_dll/wxexpat.lib;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32

-- wxWidgets_LIBRARY_DIRS  :

-- wxWidgets_DEFINITIONS   : WXUSINGDLL;UNICODE;_UNICODE;UNICODE;_UNICODE

-- wxWidgets_DEFINITIONS_DEBUG : _DEBUG;__WXDEBUG__

-- Checking whether wxwidgets version >= 3.0.0

-- Performing Test WX_VERSION_LARGE_ENOUGH

-- Performing Test WX_VERSION_LARGE_ENOUGH - Success

An excerpt from the output of CMake, but it is the _only_ file that contains 
the wxwidgets_DEFINITIONS macro.

> Assuming so, does "nmake VERBOSE=1" confirm that -DWXUSINGDLL is being
> used in your compilations of wxwidgets-related code?
>
The flag is used, I can see that in the generated files that together comprise 
the makefile, but unfortunately the nmake output (even verbose) merely shows 
that all manner of flags are incorporated in temporary files.

> I expect you will find no problems with WXUSINGDLL (since you had visibility
> issues with just a few symbols and not all of them), but you should 
> double-check as
> above simply as part of your "due diligence".  But ultimately the answer may 
> be to
> use a different wxwidgets installation, see my question to Phil and Pedro 
> above.
>
I cannot be 100% certain, but the flag occurs plainly in the various files, no 
extra conditions. So the answer will probably lie in the use of a different 
installation.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, July 04, 2017 11:08 PM
>
> I would advise concentrating on debugging the results of each relevant find
> command (e.g., find_library, find_path, find_file, and possibly
> find_program) within that code since there are relatively few such commands 
> within
> that find module logic, and it is pretty likely that find module is failing 
> to find your
> installation because one or more of those find commands is failing.
>
I have found the omission that caused wxWidgets not to be recognised. The 
libraries are stored in d:\wxWidgets\lib\vc120_dll and that was not a pattern 
that was checked (the existing patterns all have the architecture - 32 or 64 
bits - included). So when I added a pattern consistent with the directory from 
my installation, CMake recognised the wxWidgets installation (no extra 
parameters required).

However, the make step failed:

cd D:\plplot-svn\build-windows-alt

[ 20%] Linking CXX shared library ..\..\dll\plplotwxwidgets.dll

cd D:\plplot-svn\build-windows-alt\bindings\wxwidgets

D:\cmake3.8.0\bin\cmake.exe -E vs_link_dll 
--intdir=CMakeFiles\plplotwxwidgets.dir --manifests  -- 
C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\link.exe /nologo 
@CMakeFiles\plplotwxwidgets.dir\objects1.rsp 
@C:\Users\markus\AppData\Local\Temp\nm4431.tmp

Visual Studio Incremental Link with embedded manifests

Create CMakeFiles\plplotwxwidgets.dir/manifest.rc

RC Pass 1:

C:/Program Files (x86)/Windows Kits/8.1/bin/x64/rc.exe 
/foCMakeFiles\plplotwxwidgets.dir/manifest.res 
CMakeFiles\plplotwxwidgets.dir/manifest.rc

LINK Pass 1:

C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\link.exe /nologo 
@CMakeFiles\plplotwxwidgets.dir\objects1.rsp /out:..\..\dll\plplotwxwidgets.dll 
/implib:..\..\dll\plplotwxwidgets.lib 
/pdb:D:\plplot-svn\build-windows-alt\dll\plplotwxwidgets.pdb /dll /version:1.2 
/machine:x64 /debug /INCREMENTAL ..\..\dll\plplotcxx.lib 
D:\wxwidgets\lib\vc120_dll\wxbase30ud.lib 
D:\wxwidgets\lib\vc120_dll\wxmsw30ud_core.lib 
D:\wxwidgets\lib\vc120_dll\wxpngd.lib D:\wxwidgets\lib\vc120_dll\wxtiffd.lib 
D:\wxwidgets\lib\vc120_dll\wxjpegd.lib D:\wxwidgets\lib\vc120_dll\wxzlibd.lib 
D:\wxwidgets\lib\vc120_dll\wxregexud.lib 
D:\wxwidgets\lib\vc120_dll\wxexpatd.lib winmm.lib comctl32.lib oleacc.lib 
rpcrt4.lib shlwapi.lib version.lib wsock32.lib ..\..\dll\plplot.lib 
..\..\dll\csirocsa.lib ..\..\dll\qsastime.lib kernel32.lib user32.lib gdi32.lib 
winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib 
advapi32.lib /MANIFEST 
/MANIFESTFILE:CMakeFiles\plplotwxwidgets.dir/intermediate.manifest 
CMakeFiles\plplotwxwidgets.dir/manifest.res

   Creating library ..\..\dll\plplotwxwidgets.lib and object 
..\..\dll\plplotwxwidgets.exp

wxPLplotstream.cpp.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) public: __cdecl wxString::~wxString(void)" 
(__imp_??1wxString@@QEAA@XZ) referenced in function "public: void * __cdecl 
wxString::`vector deleting destructor'(unsigned int)" 
(??_EwxString@@QEAAPEAXI@Z)

wxPLplotstream.cpp.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) public: __cdecl wxSize::wxSize(int,int)" 
(__imp_??0wxSize@@QEAA@HH@Z) referenced in function "public: void __cdecl 
wxPLplotstream::SetSize(int,int)" (?SetSize@wxPLplotstream@@QEAAXHH@Z)

..\..\dll\plplotwxwidgets.dll : fatal error LNK1120: 2 unresolved externals

LINK Pass 1 failed. with 1120

NMAKE : fatal error U1077: 'D:\cmake3.8.0\bin\cmake.exe' : return code 
'0x'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'

Stop.

As far as I can tell, all the wxWidgets libraries are present, but I admit I 
did not make a thorough investigation into this.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, July 04, 2017 12:30 AM
>
> To answer your question above, now that you have had this success, I would
> appreciate you doing the following:
>
> 1. Run (all on one line rather than mail wrapped)
>
> scripts/comprehensive_test.sh --generator_string "MSYS Makefiles"
> --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON
> -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -
> DENABLE_cxx=ON"
> --build_command make --ctest_command ctest --do_test_noninteractive no --
> do_ctest no --do_nondynamic no --do_static no --do_test_install_tree no --
> do_test_traditional_install_tree no
>
> on the MinGW-w64/MSYS2 platform.  The cmake_added_options value limits this
> comprehensive test to just the wxwidgets components of PLplot.


I ran this last night and it was almost completely successful. However, example 
x14c will not stop - I had to kill it manually and that, of course, upsets the 
test script. I tried this example standalone: it brings up two windows, when 
you click in them, they disappear but ultimately the program itself remains 
active.

We are therefore not quite there yet. I had not turned on the debugging output, 
so I cannot share an extra output file.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, July 04, 2017 12:30 AM
>
> Hi Arjen:
>
> Congratulations on this success after a number of iterations between us. It 
> is a
> great feeling to not have this uncertainty hanging over us.
>
Most definitely :)

> If your MinGW-w64/MSYS and MSVC follow ups (see below) show no wxwidgets
> problems of any urgent kind on those platforms, then I intend to disable the 
> CMake
> PL_WXWIDGETS_IPC3 option by forcing it to ON, (the default option you just
> tested) on all platforms for the
> 5.13.0 release with the further plan later (if experience through a couple of 
> releases
> shows no problems with that disabling) to remove this CMake
> PL_WXWIDGETS_IPC3 option (and also the large amount of code associated with
> when the C++ macro PL_WXWIDGETS_IPC3 is _not_ #defined).
>
> To answer your question above, now that you have had this success, I would
> appreciate you doing the following:
>
> 1. Run (all on one line rather than mail wrapped)
>
> scripts/comprehensive_test.sh --generator_string "MSYS Makefiles"
> --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON
> -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -
> DENABLE_cxx=ON"
> --build_command make --ctest_command ctest --do_test_noninteractive no --
> do_ctest no --do_nondynamic no --do_static no --do_test_install_tree no --
> do_test_traditional_install_tree no
>
> on the MinGW-w64/MSYS2 platform.

I will do that tonight.

>
> 2. Do a simple test of wxwidgets on MSVC
>

Ah, I tried it yesterday, but my wxWidgets installation was not recognised, 
despite the hints I gave (the FindWxWidgets.cmake file documents a few 
variables that you can use). I have studied the find method, added a bunch of 
debug statements to see what is going on, but sofar I have failed to make any 
progress. (Note: The code is five or six pages long!)

> 3. If 2. works, then run the above comprehensive test (presumably with NMake
> Makefiles
> generator) on the MSVC platform (+ MinGW-w64/MSYS2 Unix tools on the PATH
> like what worked before for your noninteractive MSVC comprehensive test).  I
> would stick with the suggested constraints to start, and then if all is well 
> extend the
> test further as discussed above.
>
> 3 obviously should come some time after 2, but otherwise I don't care strongly
> about the order of these tests so long as they are all done (since they are 
> all
> important).
>
> In any case, please commit your setup scripts (bash scripts where you set
> environment variables and run scripts/comprehensive_test.sh) for each kind of
> comprehensive test you want to run for any given platform).  Probably, the 
> best
> place to commit those scripts is in newly created directories for each 
> platform, e.g.,
> scripts/setup/linux (which I plan to populate soon), scripts/setup/mingw_msys
> (which I also plan to populate soon), scripts/setup/mingw_w64_msys2, and
> scripts/setups/msvc_nmake. Those setup scripts should have a tailored section
> which contains all the idiosyncrasies of your particular personal platform 
> (e.g.,
> directory prefix locations that would need to be changed by other users.  For 
> an
> example of this approach please take a look at, e.g., scripts/setup/mingw_msys
> files once I populate those files with what I did recently in the 
> Wine/MINGW/MSYS
> case. Such setup scripts allow us to replicate and document exactly how we 
> launch
> our comprehensive tests. They should also help other users in general with 
> setting
> up builds and tests of PLplot on the various platforms.
>
Souds useful indeed, although it is tempting to try and make them less 
idiosyncratic. I do have a bunch of such scripts, so populating the directories 
you suggest ought not to be too difficult. I do lack time this week and this 
weekend to do much about it. Next week provides better oportunities.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Saturday, July 01, 2017 11:08 PM
>
> Hi Arjen:
>
> After reviewing the code, I spotted a fundamental error in the Windows 
> variant of
> the three-semaphores case which is that code used three Windows mutexes rather
> than three named Windows semaphores. When I originally coded that variant, I
> naively assumed that a two-state semaphore was effectively the same as a 
> mutex,
> but the semantics are slightly different, and now that I have discovered named
> Windows semaphores I would prefer to use them to keep the Windows variant of
> the 3-semaphores approach as close as possible to the Posix variant of this
> approach.  Therefore, I have now (commit b779495) addressed this issue by 
> using
> named Windows semaphores in the Windows variant of the three semaphores
> approach, but I cannot even build test this modified Windows variant of the 
> three-
> semaphores approach here. So I need you to do that.

I rebuilt PLplot using this latest commit and it all worked fine :). So the 
three-semaphores approach you have now implemented was the right way. I will 
try and see whether I can get the same result with the MSVC compiler.

>
> To be specific about what test I want you to run, please freshly configure 
> PLplot
> with the -DPLPLOT_WX_DEBUG_OUTPUT=ON option (which adds lots of useful
> information if there are any remaining errors with the three-semaphores 
> approach).
>
Unless you think this is necessary, given the completely positive results, I 
will concentrate on MSVC.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, June 28, 2017 9:44 PM
>
>
> I am now looking forward to your -fabi-version=8 wxwidgets results for
> MinGW-w64/MSYS2 as well as your wxwidgets results for MSVC.
>
I added the option -DCMAKE_CXX_FLAGS="-fabi-version=8" to the CMake invocation 
and that did the trick insofar that the runtime error message about the ABI 
mismatch has disappeared, but still no luck otherwise:
< 8> wxwidgets  wxWidgets Driver
< 9> svgScalable Vector Graphics (SVG 1.1)
<10> pdfPortable Document Format PDF
<11> pdfcairo   Cairo PDF Driver
<12> pscairoCairo PS Driver
<13> epscairo   Cairo EPS Driver
<14> svgcairo   Cairo SVG Driver
<15> pngcairo   Cairo PNG Driver
<16> memcairo   Cairo Memory Driver
<17> extcairo   Cairo External Context Driver
<18> wincairo   Cairo Microscoft Windows Driver

Enter device number or keyword:
*** PLPLOT WARNING ***
wxPLViewer failed to signal it has found the shared memory.

markus@L01259 MINGW64 /d/plplot-svn/build-mingw-alt/examples/c
$ ../../utils/wxPLViewer
wxPlViewerApp::OnInit: error when creating wxPlFrame instance.  The message was 
Error initializing the shared memory and/or mutex needed for the application. 
The application will close

markus@L01259 MINGW64 /d/plplot-svn/build-mingw-alt/examples/c
$

Running an example with the wxWidgets driver gave the message about wxPLViewer 
failing and running the wxPLViewer independently gave the error about the 
shared memory/mutex.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, June 28, 2017 9:44 PM
>
> Yes, you are certainly correct to be concerned about that issue; I assume the 
> same
> ABI incompatibility issues occur on the MSVC side of things as occur on the 
> g++
> side of things.  But the MSVC ABI changes might not occur so often as they do 
> for
> g++ so your wxwidgets distribution might still be ABI compatible with the 
> version of
> the MSVC compiler you are using. So it is "try it and see" with MSVC.
>
I originally only found the source distribution for wxWidgets, but it seems 
that a binary distribution is available on 
www.wxwidgets.org for a range of MSVC compiler 
versions (2008-2017). I plan to use the 3.0.3 release from that site.

> Actually I am quite impressed with wxwidgets popping an error box concerning 
> ABI
> incompatibility (at least for the g++ case but hopefully for the MSVC case as 
> well).
> Most software projects typically have lower standards then that and simply 
> make no
> effort to detect ABI incompatibility issues so the user has to discover for
> themselves such problems via run-time issues such as segfaults.
>
> I am now looking forward to your -fabi-version=8 wxwidgets results for
> MinGW-w64/MSYS2 as well as your wxwidgets results for MSVC.
>
Hopefully I will know more tonight.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, June 28, 2017 9:48 AM
>
>
> In the heat of the moment I forgot to say something that I will say now.  It 
> was a
> huge milestone to get the PLplot components of wxwidgets building on MinGW-
> w64/MSYS2 considering where we started from.  So I think congratulations are 
> in
> order for both of us.  :-)
>

True, true, but stumbling just before the finish has a disappointing effect :).

> Of course, now that the build issues are fixed, and you found this one run 
> time error,
> the pessimistic view is there might be other run-time issues to be dealt with 
> after
> this one is dealt with, but I am more optimistic than that.  Thus, I am 
> hoping this is
> the last wxwidgets error you will have to deal with that is specific to MinGW-
> w64/MSYS2, and I am hoping that -fabi-version=8 will fix this issue on that 
> platform.
> So I was glad to hear you are going to give this experiment a try.
>
There may be a way out for the MSVC constellation as well - I just found that 
in my distribution of wxWidgets there _are_ prebuilt libraries contained. I 
just do not know if these are compatible with my compiler. The directory 
structure is vast so they escaped my first survey.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, June 28, 2017 3:01 AM
>
> Hi Arjen:
>
>
> When faced with a fatal error like that, google is your friend.


It was getting late, my laptop's battery was nearing its limit and I thought 
perhaps some conflicting versions of the wxWidgets were being accessed. ldd, 
though, did not show anything untowards. So then I focussed on the 
MSVC/wxWidgets constellation ...

First disappointment: a quick search did not bring up any ready-made 
distributions but instead the advice to build it yourself from source. So I 
tried this. And that was the second disappointment. There is a so-called 
solution (MicroSoft's answer to makefiles) in the source distribution I 
retrieved, so I could load it into Visual Studio (whereas the wxWidgets Wiki 
described only the now virtually extinct Developer Studio, which uses a 
different approach). Building the solution (that is: the set of libraries) 
quickly brought up 92 compile errors of the type:

..\..\src\stc\scintilla\lexers\LexA68k.cxx(131): error C2664: 
'StyleContext::StyleContext(unsigned int,unsigned int,int,LexAccessor &,char)' 
: cannot convert parameter 4 from 'Accessor' to 'LexAccessor &'

Not the sort of things I enjoy debugging.

> Indeed, when I made a google search for the terms <"c++" abi 1008
> 1010>, I quickly found a discussion about how strict wxwidgets should
> be concerning its default rule that C++ ABI version numbers should be exactly
> identical (as you discovered above). Furthermore,
>  states the ABI
> versioning scheme for a relatively old version of gcc is
>
> In sum from this google research based on the above error message, I am pretty
> sure what happened is that the MinGW-w64/MSYS2 wxwidgets libraries were built
> with some g++ version from 4.9.z through g++ 5.1.z, and you are building the
> wxwidgets components of PLplot using
> g++ version 6.x.y, where x is 1 or greater.  Furthermore, from
> the above Dialect options site, I believe all you have to do to avoid this 
> issue is
> specify -fabi-version=8 as a g++ option (e.g., by adding that option to the
> CXXFLAGS environment variable).
>
That is certainly worth a try

> I am going to follow up with a short version of this to the MSYS2 mailing 
> list asking
> if setting -fabi-version=8 is the right response to the above error message, 
> but
> please go ahead and try that experiment right away, and don't wait for their
> comments (if any).
>
Seen that. I will write a short reply - the annoying thing is that this is only 
detected at run-time, not at build-time.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



I could say "I have good news and bad news". First of all, with this latest 
version I can indeed build the wxWidgets driver without complaints, using the 
64-bits version of MinGW-w64/MSYS2, but when I run an example I get:



[cid:image001.png@01D2EF82.D7F76F70]



I guess this means that I should be using _exactly_ the same compiler to build 
PLplot as was used to build the wxWidgets libraries. Quite possibly the easiest 
way is to build these libraries from source, so that there can be no mismatch - 
sigh.



Hm, if that is true, why was I able to create a small example? That ran and did 
not have this issue. Any thoughts?



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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, June 27, 2017 9:12 AM
>
> However, (see commit message for details) I ran into one other build issue
> concerning the declaration of rand_s which is implemented in
> drivers/wxwidgets_dev.cpp with the following two lines:
>
> #define _CRT_RAND_S
> #include 
>
> This declaration method is exactly what is suggested by
> , and appeared to work
> fine for Phil during his pre-release testing of PLplot-5.12.0 on the MSVC 
> platform,
> and I suspect (but need confirmation from you) it also won't be a problem on 
> that
> platform for this version of the code.  But at least my version 4.7.2 of g++ 
> on
> MinGW/MSYS is complaining about that declaration so my guess (which needs
> confirmation from you) is you will run into the same issue for modern
> g++ on MinGW-w64/MSYS2 (either 32-bit or 64-bit).  In which case, I
> hope you have the C++ expertise (which I don't have) to figure out what 
> change you
> have to make in the rand_s declaration to convince g++ to compile that code.
>

An inspection of the code did not bring up a glaring mistake, so I am puzzled 
as well. At the very least at the moment. The only thing I can imagine is that 
the stdlib.h header file is not actually included.

> In sum, please run a MinGW-w64/MSYS2 (either 32-bit or 64-bit) test and an
> MSVC test for this latest code base to insure my present fix works for the 
> "cannot
> convert" LPCTSTR to LPCWSTR issue works on those platforms.  And if for either
> one you run into a problem with the above declaration of rand_s, I hope you 
> know
> how to fix it (since I don't).
>
Okay, that is clear enough. I will try this.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, June 27, 2017 1:06 AM
> To: Arjen Markus; PLplot development list; Phil Rosenberg; Pedro Vicente
> Subject: RE: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2
>
> To Arjen, Phil, and Pedro:
>
>
> @Phil and Pedro: what set of wxwidgets libraries do you use to test PLplot
> wxwidgets components on the MSVC platform?  That information would be useful
> to Arjen (see the last part of the rest of this post).
>
> @Arjen: the rest of this is largely for you.
>
> It turns out I can now finally replicate the wxwidgets build bug you 
> discovered! I got
> this result on my Windows platform consisting of Wine staging 2.10 + an 
> ancient
> (but thankfully still working) snapshot of MinGW/MSYS (4.7.2) + epa_build (on
> Wine-stagine/MinGW/MSYS) of wxwidgets-3.0.2.  Note that this is a 32-bit 
> platform
> because the wine command (as opposed to the wine64
> command) implements 32-bit Windows, and, in any case, MinGW/MSYS was
> always 32-bit as well (unlike MinGW-w64/MSYS2 which implements both 32-bit and
> 64-bit versions).  So all the web reports saying this issue was limited to 
> 64-bit
> platforms is obviously incorrect.

Well, not entirely - see below.

>
> For some reason, the wxwidgets find on this platform plus some of our further 
> logic
> in cmake/modules/wxwidgets.cmake to test the wxwidgets version failed because
> wxWidgets_INCLUDE_DIRS was in // form.  To get around that
> limitation I have locally implemented some logic to append a variant of
> wxWidgets_INCLUDE_DIRS to wxWidgets_INCLUDE_DIRS that has been
> converted from that form to the corresponding :/ form.  I have 
> no idea
> why this change is necessary but it does work, and I don't think it will 
> interfere with
> anything else so I plan to finalize and commit this change (even though you 
> don't
> seem to have encountered this issue on MinGW-w64/MSYS2).
>
> The initial error message (similar to what you reported) is
>
> z:/home/wine/wine_staging/build_results/install-
> 2.10_jessie_wine_staging/include/wx-3.0/wx/msw/winundef.h:38:20:
> error: cannot convert 'LPCTSTR {aka const char*}' to 'LPCWSTR {aka const
> wchar_t*}' for argument '2' to 'HWND__* CreateDialogParamW(HINSTANCE,
> LPCWSTR, HWND, DLGPROC, LPARAM)'
>
...

>
> Since I can now replicate the issue you found, and I still view this issue as 
> release
> critical I intend to work on it until I solve it.
> Of course, you are welcome to continue to work on this issue (e.g., by trying 
> a 32-
> bit MinGW-w64/MSYS2 build [which from the above 32-bit evidence will probably
> generate the equivalent build error, but you never know], beating me to a 
> solution,
> or adding some essential insight that helps me find a solution). However, it 
> would
> likely be more efficient (in terms of reaching the goal of getting the next 
> release out
> in a timely manner) if you switched to testing wxwidgets for the MSVC case.
> According to Phil's tests, wxwidgets did work fine for the MSVC platform just 
> before
> we released PLplot-5.12.0 so it is definitely release critical if it turns 
> out wxwidgets
> no longer works on that platform!
>
Last night I installed the 32-bits version of MinGW-w64/SYS2 and that built 
wxWidgets without any trouble. So the reports about "64 bits MinGW" being at 
fault are not entirely incorrect.

The trouble came from a different source: the haru library needed for the PDF 
device. This turns out to be built using the "stdcall" convention (one of the 
reasons I greatly prefer to work with 64 bits on Windows!) and thus I got error 
messages like the ones below:

[ 19%] Linking C shared module ../dll/pdf.dll

cd /D/plplot-svn/build-mingw-alt/drivers && /D/mingw32/mingw32/bin/cmake.exe -E 
remove -f CMakeFiles/pdf.dir/objects.a

cd /D/plplot-svn/build-mingw-alt/drivers && /D/mingw32/mingw32/bin/ar.exe cr 
CMakeFiles/pdf.dir/objects.a "CMakeFiles/pdf.dir/pdf.c.obj"

cd /D/plplot-svn/build-mingw-alt/drivers && /D/mingw32/mingw32/bin/gcc.exe 
-shared -o ../dll/pdf.dll -Wl,--major-image-version,0,--minor-image-version,0 
-Wl,--whole-archive CMakeFiles/pdf.dir/objects.a -Wl,--no-whole-archive 
../dll/libplplot.dll.a /D/mingw32/mingw32/lib/libhpdf.dll.a 
/D/mingw32/mingw32/lib/libshp.dll.a /D/mingw32/mingw32/lib/libfreetype.dll.a 
../dll/libcsirocsa.dll.a ../dll/libcsironn.dll.a 
/D/mingw32/mingw32/lib/libqhull.dll.a ../dll/libqsastime.dll.a -lkernel32 
-luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 
-ladvapi32

CMakeFiles/pdf.dir/objects.a(pdf.c.obj):pdf.c:(.text+0x293): undefined 
reference to `_imp__HPDF_New'

CMakeFiles/pdf.dir/objects.a(pdf.c.obj)

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Friday, June 23, 2017 1:04 PM
>
> Hi Arjen:
>
> Thanks very much for that quick turnaround.
>
You're welcome :)

> > I get compile errors as can be seen in the attached tarball (output
> from CMake and make, as well as the config header file). We need to sort out 
> these
> things before a comprehensive build is going to stand any chance.
>
> From what I can tell from your current extremely limited make.out (please 
> generate
> that next time with VERBOSE=1), it looks like these build issues have nothing 
> to do
> with PLplot code and instead are wxwidgets header incompatibilities _for the
> compile flags that are being generated by your current  Unix wxwidgets find
> method_.
>
> Therefore, I am pretty sure the current build issue is caused by your build 
> using
> Unix wxwidgets compile and link flags when it should be using Windows 
> wxwidgets
> compile and link flags for the MinGW-w64/MSYS2 platform. So to get access to 
> the
> latter flags, I suggest you use the _Windows_ wxwidgets find method (which I
> understand you automatically obtain if you use the "MSYS Makefiles" 
> generator.)
>

I do not think so, the condition definitely says "AND NOT MSYS" - so that would 
use the Unix method.

> If I have understood correctly what you said before, the Windows wxwidgets 
> find
> method currently does not work for the MinGW-w64/MSYS2 platform. Nevertheless,
> since our wxwidgets code with old IPC method did build correctly on MSVC 
> before
> with this find method, I assume whatever correction you have to make to
> cmake/modules/findwxWidgets.cmake to get the Windows find method to work
> correctly on the MinGW-w64/MSYS2 platform should be quite small.
> And as per usual, the cmake options --debug-output --trace are extremely 
> useful for
> debugging find modules, but if those are not sufficient to discover the 
> problem, you
> can always locally insert
> message(...) commands in cmake/modules/findwxWidgets.cmake.
>

Ah, but the issue is that under MinGW-w64/MSYS2 things are installed in 
different directories and possibly a different structure than under Windows 
with MSVC. MinGW-w64/MSYS2 is a bit of a hybrid system, though leaning towards 
the Unix way.

> Anyhow, good luck with this debugging of the Windows wxwidgets find method on
> MinGW-w64/MSYS2.
>

Thanks, it looks like some more experimenting is required.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, June 21, 2017 3:02 AM
>
> To Arjen and Phil:
>
> I have now made these 4 additional wxwidgets-related commits:
>
> 2bc0626 IPC for wxwidgets: Reenable the PL_WXWIDGETS_IPC3 option
> e07d5e5 IPC for wxwidgets: Purge PL_HAVE_UNNAMED_POSIX_SEMAPHORES
> 2faff23 IPC for wxwidgets: Fix use of WIN32 and PL_WXWIDGETS_IPC3
> preprocessor macros
> 8fd52f8 Build System: Implement the
> PAUSE_CERTAIN_INTERACTIVE_DEVICES option
>
I tried the new code, but it fails on properly finding wxWidgets again, as 
CMake identifies the search method as "Windows". The method is rather elaborate 
and fails on finding the libraries. When I tried it before using the "Unix" 
method it did work, so I am inclined to use that instead (reinstating the extra 
check). Then the IPC3 option should kick in properly if I understand the 
changes correctly. I have not had time to try it yet though, but it seems more 
fruitful than hunting down and fixing the bug/quirk/mistake/misunderstanding in 
FindWxWidgets.cmake.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Wednesday, June 21, 2017 3:02 AM
>
> To Arjen and Phil:
>
> I have now made these 4 additional wxwidgets-related commits:
>
> 2bc0626 IPC for wxwidgets: Reenable the PL_WXWIDGETS_IPC3 option
> e07d5e5 IPC for wxwidgets: Purge PL_HAVE_UNNAMED_POSIX_SEMAPHORES
> 2faff23 IPC for wxwidgets: Fix use of WIN32 and PL_WXWIDGETS_IPC3
> preprocessor macros
> 8fd52f8 Build System: Implement the
> PAUSE_CERTAIN_INTERACTIVE_DEVICES option
>
> 2faff23 is the most important one and fixes and obvious preprocessor bug in 
> the
> code that should likely sort out the build issue that Arjen found.
>
Great, I hope this works - I am unlikely to have to have time today though to 
test this. Tomorrow I will stand a better chance. I will keep you posted on the 
progress.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



Ah, this came in after I had finished writing up my adventures. I will have a 
closer look later to see what needs to be done.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, June 20, 2017 8:37 PM
...

> To Arjen and Phil:
>
> Actually, I think the simpleness of that condition should be fine on MinGW-
> w64/MSYS2.  After all, in that case you are building a native Windows version 
> of
> PLplot where everything inside the #ifdef WIN32 stanzas should be available.
>
> Also now that I have finally found a partner who is willing to test the 
> wxwidgets IPC
> methods on a native Windows platform, I have a number of IPC build system and
> code changes in mind.
>
> If you have looked at the code at all now, you can see it is a bit of a 
> complex #ifdef
> thicket that is therefore hard to understand by definition.  But (see
> cmake/modules/wxwidgets.cmake) the macro
> PL_HAVE_UNNAMED_POSIX_SEMAPHORES is permanently disabled.  That
> disablement (done several months ago) is because although the #ifdef
> PL_HAVE_UNNAMED_POSIX_SEMAPHORES code stanzas currently work in the
> Linux case, they are superseded by the named semaphores approach that works
> for all POSIX platforms including Linux. So my first order of business is to 
> follow up
> on that permanent disablement by removing all #ifdef
> PL_HAVE_UNNAMED_POSIX_SEMAPHORES code stanzas (and, in fact, all
> references to PL_HAVE_UNNAMED_POSIX_SEMAPHORES in our source tree) to
> reduce the #ifdef complexity of the IPC code.
>
> Also, if you look at cmake/modules/wxwidgets.cmake you will see the macro
> PL_WXWIDGETS_IPC3 is permanently enabled.  My second order of business is
> to turn that temporarily back into an option which will be ON by default.  
> The old
> IPC code that is enabled when that option is turned OFF by the user used to 
> work
> OK on both Windows and Linux.  So turning this temporarily back into an option
> should allow us to test both -DPL_WXWIDGETS_IPC3 ON and OFF on both Linux
> and Windows.
> Previously -DPL_WXWIDGETS_IPC3 OFF worked OK on both the Linux platform
> and the native Windows MSVC platform so my guess is it should also work on
> MinGW-w64/MSYS2 to provide a benchmark to test how well
> -DPL_WXWIDGETS_IPC3 ON works on that platform.  And ultimately once we
> make the code corrections so that -DPL_WXWIDGETS_IPC3 ON builds and runs
> fine on that native Windows platform, I intend to remove all the "old" IPC 
> code that
> is used when -DPL_WXWIDGETS_IPC3 OFF in the interests of reducing
> complexity.
>
> @Phil: your participation in these proposed IPC tests in the MSVC case (or any
> platform you can get your hands on) would be most welcome. And if you could 
> let
> Arjen know your source of reliable wxwidgets libraries for the MSVC case, that
> would be most welcome as well.
>
> More later...
>
> 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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



I just concluded a rather unsuccessful session to get the wxWidgets driver to 
build:



Step 1: I changed the line #ifdef WIN32 in wxwidgets_comms.h to:



#if defined(WIN32) && !defined(__MINGW32__)



The macro __MINGW32__ is defined on MinGW-w64/MSYS2 32-bits and 64-bits.



Step 2: compiling the new source code gave a problem with a missing header file 
"mman.h". I have tried to find out where in MinGW-w64 this might be found, but 
nothing worked. The exception, perhaps, is a package that is not supported by 
MinGW-w64. I did not try that.

Instead I commented out the include statement.



Step 3: the result was another compile error. See the attached file "make.out". 
This turned out to be part of a rather intricate set of C macros to select the 
right semaphore dialect. And then I stopped. I know zilch about this ;).



So, that is the current situation. As you have been working on this intensely 
you may see what is wrong more easily than I do.



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.


build-mingw.tgz
Description: build-mingw.tgz
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, June 20, 2017 12:12 PM
>
> In general, many small focussed commits (each with a good commit message) are
> better than one massive commit.  So please go ahead and commit your change to
> cmake/modules/FindwxWidgets.cmake immediately.  Is there also a Tcl change
> you are holding back from committing?  If so, please make a separate commit 
> for
> that as well.
>
No, this is the only thing at the moment.

> To answer your question, anything to do with three semaphores involves my 
> "new"
> wxwidgets IPC code that I finished several months ago.  That code works well 
> on
> Linux, but my request to Phil to test that code on Windows at that time must 
> have
> gotten lost in his e-mail stack for PLplot. So thanks very much for this 
> first Windows
> test of my code!
>
> From the error message above, something is obviously wrong with the build for 
> that
> case, but it likely is something very simple (e.g., likely a missing #ifdef 
> WIN32
> section inside an existing #ifdef
> PL_WXWIDGETS_IPC3 section in drivers/wxwidgets_comms.h) that I forgot to do
> with those three-semaphore changes for the Windows case.  So if you don't beat
> me to a solution, I will take a look at finding this Windows build fix for 
> wxwidgets
> starting ~8 hours or so from now after I get some sleep.
>
Hm, it seems to be due to the simpleness of the condition: #ifdef WIN32 - quite 
probably this is defined for MinGW-w64/MSYS2 to indicate that the platform is 
"Windowy". So a refinement is required. I will see what I can do here.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Problem with wxWidgets under MinGW-w64/MSYS2

[Arjen Markus]

Hi everyone,



I made a small adjustment to the FindwxWidgets.cmake file so that it would 
properly recognise the installation of wxWidgets under MinGW-w64/MSYS2. CMake 
was happy with it, but when I tried building PLplot, I got a compiler error:



Scanning dependencies of target wxwidgets

[ 18%] Building CXX object drivers/CMakeFiles/wxwidgets.dir/wxwidgets.cpp.obj

In file included from D:/plplot-svn/plplot-git/drivers/wxwidgets.h:28:0,

 from D:/plplot-svn/plplot-git/drivers/wxwidgets.cpp:41:

D:/plplot-svn/plplot-git/drivers/wxwidgets_comms.h: In member function 'void 
PLMemoryMap::initializeSemaphoresToValid(const char*)':

D:/plplot-svn/plplot-git/drivers/wxwidgets_comms.h:219:64: error: 
'm_threeSemaphores' was not declared in this scope

 void initializeSemaphoresToValid( const char *baseName ) { 
m_threeSemaphores.initializeToValid( baseName ); }


^

make[2]: *** [drivers/CMakeFiles/wxwidgets.dir/build.make:64: 
drivers/CMakeFiles/wxwidgets.dir/wxwidgets.cpp.obj] Error 1

make[1]: *** [CMakeFiles/Makefile2:3396: drivers/CMakeFiles/wxwidgets.dir/all] 
Error 2

make: *** [Makefile:161: all] Error 2

Can anyone shed some light on this problem? I am not at all familiar with the 
code.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] PyQt4 on MinGw-w64/MSYS2 - pyqtconfig

[Arjen Markus]

Hi Alan, Hazen,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Friday, June 02, 2017 9:08 PM
>
> Correction: wherever I said "packfile" above should be replaced with 
> "pkgfile".
> (Sorry about that!) Furthermore, if you look at
>  it appears that the pkgfile 
> functionality
> is now just part of the pacman package. So since you have pacman automatically
> installed as part of the base packages, then my educated guess is the 
> "pkgfile"
> command should just work with nothing additional you have to install.
>
I had the SIP package already installed and I tried pkgfile with various 
invocations, but I do not get any (!) output, even from files and packages I 
know are present. So, that seems to be the end of that possible solution.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] PyQt4 on MinGw-w64/MSYS2 - pyqtconfig

[Arjen Markus]

Hi everyone,



I have a simple question regarding PyQt4 on MinGW-w64/MSYS2. I have installed 
the package but when I run Cmake to build PLplot, I get the message that 
pyqtconfig is missing - is this something I need to install separately? If so, 
how? (I have a version for Cygwin, but I do not know if that is exactly the 
same)



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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Space in full pathname issues

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Friday, May 12, 2017 9:44 PM
>
> To keep this organized, here is a summary of what you have discovered so far:
>
> (1) You have an infinite loop for any version of a "spaced" install prefix 
> for the
> Cygwin version of cmake.  I suggest you report that clear bug to the Cygwin 
> list and
> see what the response is.
>
Will do - as my experiment with Cmake built from sources indicates, it is a 
Cygwin-specific bug.

> (2) You don't have that infinite loop with the Kitware version of Windows 
> CMake,
> but there are find troubles with that version.
>
Correct, but that is because of confusion between various utilities called 
"find.exe".

> So for now (until (1) is solved) you could simply write off this platform for 
> the
> "spaced" install prefix case and document that in our wiki.
>
> However, there is another alternative which is to try an unpatched CMake 
> version
> that you have built for yourself on the Cygwin platform.
> I believe there is a reasonable chance that experiment would work since Cygwin
> does try to be POSIX compatible so the result you get should be similar to the
> result I get on Linux which is no infinite loop bug and CMake find works well.
>
I used CMake version 3.8.1, built from sources, and that did work. One problem: 
no plplot.pc file, so I could not build the examples. These files are not 
installed. I will have to look into this.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Space in full pathname issues

[Arjen Markus]

Hi Alan,



See my remarks in context.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, May 09, 2017 10:10 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Space in full pathname issues
>
> On 2017-05-09 11:31- Arjen Markus wrote:
>
> > Hi Alan,
>
> Hi Arjen:
>
> The CMake developers have been notoriously lax concerning how the cmake
> command parses its command-line arguments.  So when there is some error in 
> that
> parsing you do often get a hang. But I would strongly advise you when that
> happens to not let it run more than a minute or two (i.e., the maximum time 
> that
> cmake normally takes to configure PLplot).  After all, with a hang, there is 
> some
> indefinite loop happening, and if there are any memory leaks in that loop you 
> could
> end up with an out-of-memory error and take down your whole system!
>

I tried the \ variant for incorporating spaces in an option - same result, 
CMake hangs. However, I have found what it is doing: it writes a file 
export_plplot.cmake.tmp which contains:

...

# Compute the installation prefix relative to this file.

get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)

get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)

get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)

... (1.5 GB of such identical messages)

I tried this with the Windows 3.6.2 version as well, that simply works as 
expected. No problem with a hanging CMake. So it appears to be specific to 
Cygwin.

As Cygwin's CMake is tuned for that environment, I did not expect success with 
the next experiment, using Windows' CMake, version 3.6.2, on Cygwin. Nor was I 
proven wrong - that version of CMake can't find the various tools, so it stops 
with a configuration error.

> That said, whatever the quirks in cmake command-line processing, those quirks
> should be consistent for a given version of CMake (unless the guy that 
> packages
> CMake for Cygwin has applied a specific patch to have unique command-line
> processing for the Cygwin version of CMake which in my opinion would be a huge
> mistake on his part.)  Up to now all my space in pathname checking has been 
> done
> from the bash shell and for CMake-3.7.2.
>
> To check whether you are also running the bash shell, what is the result of 
> the
> "echo $0" command there?  Here it is
>
> software@raven> echo $0
> /bin/bash
>
I get an unexpected "-bash". So, bash, but slightly different ...

> If you get an empty response or a non-bash response, please switch to the bash
> shell for your tests by simply executing the "bash" command.
>
> Just to make sure what you have encountered is not a quirk for
> CMake-3.6.2 that has been fixed for 3.7.2, I tried CMake-3.6.2 here (built by 
> me
> from unpatched source code provided by Kitware using the bootstrap method on
> Debian Jessie just like I build 3.7.2), and the above experiment worked fine.
>

I have not tried that method yet - might be an idea indeed. It is just a wee 
bit more work.

> For the record, here is what I did ...

>
> If the Kitware version works and the Cygwin one does not on Cygwin for the 
> above
> form of the cmake command, then that is a clear bug in the Cygwin version 
> that you
> should report to the Cygwin list, and meanwhile continue with the above 
> experiment
> using the Kitware version (contrary to how I have argued before since my
> assumption was any patches added by the Cygwin packager would add some value
> for this platform rather than introducing a bug).
>
> Of course, if both the Kitware version and Cygwin version of
> CMake-3.6.2 fail to work, then I assume the cause is some unknown Cygwin issue
> that is likely nothing to do with CMake or the bash shell.  In which case you 
> really
> are stuck, and we have to emphasize in our wiki that blanks in the install 
> prefix are
> simply not allowed by the Cygwin platform for unknown reasons.  But hopefully 
> it is
> just a bug in the Cygwin version of cmake that can be worked around (until 
> that bug
> is fixed) by using the Kitware CMake (or you were using a slightly different 
> form
> than above, and in fact both the Kitware CMake and Cygwin CMake work if you 
> use
> the exact form above).
>
Well, that will have to wait for me to build CMake on Cygwin from the sources. 
No time for that right now, I am afraid.

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

Re: [Plplot-devel] Space in full pathname issues

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, May 08, 2017 7:18 PM
>
> Assuming the form I suggested on Cygwin
>
> cmake   "-CMAKE_INSTALL_PREFIX=d:/plplot-src/install with spaces"
>
> does work there, please check that same form (used by the comprehensive test
> script) works on this platform as well.
>
Unfortunately, it doesn't. CMake gets stuck again - this time I left it running 
over lunch and it had made no progress whatsoever when I came back (except 
writing lots of bytes according to the task monitor).

Conclusion for now: a bug in CMake on Cygwin is preventing this.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Space in full pathname issues

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, May 09, 2017 9:50 AM
>
> Hi Arjen:
>
> The diff executable from the MinGW-w64/MSYS2 Unix tools should "just work" if
> run from a bash script (as in comprehensive testing, ctest,
> etc.) Is the issue simply that our build system is finding something other 
> than
> /usr/bin/diff.exe from the MinGW-w64/MSYS2 diffstat package?
>
> If the issue is more complicated than that, please send me the relevant report
> tarball.
>
That is what I expect too, but CMake (being the "bare Windows" version, not the 
MinGW-w64/MSYS2 one) picks up an executable by that very name, which is almost 
but not quite unrelated to the diff utility we want. (It comes with 
Subversion.) So I have to instruct Windows-Cmake to use a 
MinGW-w64/MSYS2-utility.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Space in full pathname issues

[Arjen Markus]

Hi Alan,



I will be using this message to answer the other two as well ;).



See below.



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, May 08, 2017 7:18 PM
> To: Arjen Markus
> Cc: Chris Marshall; PLplot development list
> Subject: RE: [Plplot-devel] Space in full pathname issues
>
> On 2017-05-08 08:03- Arjen Markus wrote:
>
> > Hi Alan, Chris,
> >
> >
> >
> > I tried the same thing with MinGW-w64/MSYS2. This succeeded in so far, that:
> >
> > -CMake produced a full report and makefiles
>
> Assuming the form I suggested on Cygwin
>
> cmake   "-CMAKE_INSTALL_PREFIX=d:/plplot-src/install with spaces"
>
> does work there, please check that same form (used by the comprehensive test
> script) works on this platform as well.
>
I have thought of that form too - it might do the trick indeed. I just hadn't 
expected the phenomenon I got - CMake in an infinite loop.

> >
> > -make succeeded
> >
> > -make install succeeded as well
>
> Congratulations.  This is all very encouraging.
>
> > -making the examples worked, except for Java - the path to the Java
> compiler was not quoted
>
> Interesting.  According to <http://repo.msys2.org/mingw/x86_64/>,
> MinGW-w64/MSYS2 does not provide Java.  The conclusion that this is a non-
> platform version of Java also seems to be confirmed by the space in the Java
> compiler pathname since I assume this particular test was for an ordinary 
> "non-
> space" installation of this platform.  If it is true this is a non-platform 
> Java, I am
> pretty sure you are going to have ABI issues when attempting to use it on 
> MinGW-
> w64/MSYS2 so you should take some measure to exclude Java there.  Brute force
> would be -DENABLE_java=OFF (with a big note in your submission script), but
> perhaps a better overall choice would be to adjust your PATH on this platform 
> so
> CMake does not find non-platform software like this.
>
> That said, note if this version of Java is ABI compatible with the MSVC 
> compilers,
> then it should be expected to work for your MSVC tests, and the case (4) 
> issue you
> have found with our build system (Java compiler not quoted) will need to be
> addressed, and I look forward to your commit to that effect.

Sure, I think CMake found the "bare Windows" version of Java. I expect it will 
work, once the spaces issue is solved.

>
> And by the way, I thought you had solved some Tcl build system issue?
> If so, you should commit it before you lose it.
>
In theory I have, I just haven't had the opportunity yet to test it :). I 
didn't want to commit the changes beforehand.

>
> > -running a C example didn't work, as the drivers are not installed
> > The latter is an omission in the installation procedure - I never noticed 
> > that before
> but I seldom use this full build procedure.
>
> I am virtually positive from your and Greg's previous comprehensive test 
> successes
> on this platform that "make install" does install the drivers.  However, if 
> you look at
> the comprehensive test script, special measures had to be used to put the 
> installed
> driver location on the PATH.  But I hasten to add this PATH change should 
> only be
> done when the install tree is being tested, and otherwise (e.g., when testing 
> the
> build tree) the installation location for the drivers should be removed from 
> the PATH
> (as you will see the comprehensive test script implements).
>
Argh, sorry for the noise - they are indeed installed, but under a different 
directory than I thought. Okay, that sorts out that issue.

>From your last message:

Hi Arjen:



It sounds like you are making good progress on this platform as well.

For all three Windows platforms I look forward to your commits solving the 
straightforward issues that you find and I assume the problem above is of that 
type.



However, if this or some other issue is tricky for you to solve, feel free to 
consult in detail with me using the normal report tarball method (which 
typically is required to give me all the details that I need to help you).

Well, there is indeed a conundrum - the diff executable. I have a solution in 
mind (using a temporary environment variable) to transfer the context from the 
shell script to CMake (this involves effectively going from one operating 
environment - MinGW-w64/MSYS2 - to another - "bare Windows") and I expect it to 
work, but I need to test it. And it may be there is a more elegant and robust 
way. Will keep you informed.

Regards,

Arjen





DISCLAIMER: This message is intended exclusively for 

Re: [Plplot-devel] Space in full pathname issues

[Arjen Markus]

Hi Alan, Chris,



Just repeated the build experiment for "bare" Windows:

-CMake, make and make install all work with a destination directory 
whose name contains spaces

-However, nmake on the installed examples produces an error message:



Microsoft (R) Program Maintenance Utility Version 12.00.21005.1

Copyright (C) Microsoft Corporation.  All rights reserved.



cd c; "C:\Program Files (x86)\Microsoft Visual Studio 
12.0\VC\BIN\amd64\nmake.exe"

The filename, directory name, or volume label syntax is incorrect.

NMAKE : fatal error U1077: 'cd' : return code '0x1'

Stop.


The problem is probably in the combining of two commands via a semicolon. If I 
try "cd c; nmake" manually, I get the message "The system cannot find the path 
specified". It is not splitting up the line into two commands.

Probably this has nothing to do with the spaces issue.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Space in full pathname issues

[Arjen Markus]

Hi Alan, Chris,



I tried the same thing with MinGW-w64/MSYS2. This succeeded in so far, that:

-CMake produced a full report and makefiles

-make succeeded

-make install succeeded as well

-making the examples worked, except for Java - the path to the Java 
compiler was not quoted

-running a C example didn't work, as the drivers are not installed



The latter is an omission in the installation procedure - I never noticed that 
before but I seldom use this full build procedure.



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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Space in full pathname issues

[Arjen Markus]

Hi Alan, Chris,



Here are my first experiences with directories containing spaces in their 
names. See below in context.

Regards,

Arjen

> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Friday, May 05, 2017 10:40 PM
> To: Arjen Markus; Chris Marshall; PLplot development list
> Subject: Re: [Plplot-devel] Space in full pathname issues
>
> To Arjen and Chris:
>
> @Arjen:
>
> I saw your remark that you were going to write off the Cygwin platform for 
> case (4)
> testing, but please hold off on that decision until Chris clarifies what he 
> said below:
>
> On 2017-05-05 08:24-0400 Chris Marshall wrote:
>
> > cygwin doesn't handle install directories with whitespace fully or at all.
>

My first step was to build in a directory whose name contains spaces, but 
nothing else. This worked smoothly for both Cygwin and MinGW-w64/MSYS2.

My next step was to build in that same directory and explicitly install in a 
(different) directory whose name contains spaces:

cmake  -DCMAKE_INSTALL_PREFIX="d:/plplot-src/install with spaces"

(I simply added this option to the existing CMake invocation)

This experiment was less successful: CMake started but never got beyond 
"configuration done" - no further output was produced, but according to the 
Task Manager it was writing a lot of data - after 15 minutes of CPU it had 
produced 52 MB of output. No idea though where this got to - the subdirectories 
of the build directory contain less than 10 MB. After that time I simply killed 
the program.

> @Chris:
>
> To clarify what you said, are you concerned that basic functionality 
> (compilers,
> CMake, C, library, Unix tools like bash) just won't work at all on Cygwin if a
> "spaced" install prefix is used?  Or are you concerned that some libaries 
> which are
> soft dependencies of PLplot but which are not fundamental to Cygwin's basic
> functionality won't work for this "spaced" case?  If the latter, I agree 
> there are likely
> to be such cases (since free software has historically struggled with spaces 
> in full
> pathnames just like PLplot is doing now), but that does not preclude us 
> testing for
> case (4) issues for PLplot on Cygwin.
>

My Cygwin installation is in an ordinary directory, no spaces involved. Given 
the behaviour I saw, the first problem one would encounter is one in CMake 
itself.

CMake under Cygwin is version 3.6.2.

> @ Both:
>
> The argument is if a PLplot build with all bindings and devices that depend on
> external libraries disabled is a success for this "spaced"
> install prefix case, then that proves the basic functionality of Cygwin works 
> for this
> case. And if you then follow up by removing all those constraints from the 
> PLplot
> build, then you will likely encounter (as I stated above) some problems for 
> certain
> PLplot components.  However, for these cases a quick visual check of "make
> VERBOSE=1" results should tell you whether the command that is failing has 
> been
> set up properly by our build system so that the blanks are quoted or escaped
> properly.  And if we fix all such issues (or there are none) and the command 
> still
> fails, then we will have to blacklist that component of PLplot (i.e., disable 
> it) for
> "spaced" install prefixes until the external package sorts out its own 
> problems for
> that scenario.
>
> Note, this argument is a general one so it also applies to both the
> MinGW-w64/MSYS2 and epa_build platforms.  If the platform fundamentals work
> for a "spaced" installation prefix (which is true almost by definition for at 
> least the
> epa_build case) then sorting out whether the trouble for a given component of
> PLplot is due to an issue with our build system or the external software 
> component
> for the platform should be completely straightforward.
>
Unfortunately, I am not getting this far.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel