plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] [Plplot-general] More questions about install

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

Hi David
Can I as what toolset you are using to build with?
Libltdl appears to be gnu related, but I thought you were building with the standard windows toolset.

Phil

Get Outlook for Android<https://aka.ms/ghei36>



From: David Bergman
Sent: Sunday, February 4, 03:41
Subject: Re: [Plplot-general] More questions about install
To: Phil Rosenberg


Scratch this last email, I discovered a typo in my cmake command.  However, after getting past this I am now getting the following,

Could not open driver module wxwidgets
libltdl error: No error information
NMAKE : fatal error U1077: '..\dll\test-drv-info.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return code '
0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return code '
0x2'
Stop.



On Saturday, February 3, 2018, 8:59:14 PM EST, David Bergman <dav...@ya...> wrote:


Phil,

I have the latest but I'm getting new build errors.
The IDE install failed for most projects and eventually hung.  This occurred before but restarting usually fixes.
The DOS install failed on the nmake command,

NMAKE : fatal error U1073: don't know how to make 'C:\\all'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return code '
0x2'
Stop.

There were no errors in the cmake command and I'm doing this the same as before (after help from Arjen to turn off cairo devices).

Could I manually add the code snippet to the header or do the libs need to be rebuilt with the change?

Thanks,
David




On Saturday, February 3, 2018, 4:12:57 PM EST, Phil Rosenberg <p.d...@gm...> wrote:


Hi David
I just had another look at the code comparing to the release you are using and you were absolutely right, there is a bug there. I have just fixed that and pushed the resulting code up to our git repo. You can pull the latest code from there at https://sourceforge.net/p/<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>plplot<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>plplot<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>ci<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/master/tree/<https://sourceforge.net/p/plplot/plplot/ci/master/tree/> in your browser, or using git using the command

git clone git://git.code.sf.net/p/plplot/plplot

Let us know if you are having any difficulties grabbing it.

Phil
From: David Bergman <dav...@ya...>
Sent: Saturday, February 3, 2018 6:49:13 PM
To: Phil Rosenberg
Subject: Re: [Plplot-general] More questions about install

Phil,
Would the bug be in the header or the the call in the test code *.cpp?
If it's the header then I'd like the new version.  But if it's the driver then would the documentation on wxWidgets classes be informative?
I notice typical declarations have wxTemplate<Type> * x = something(NULL), to initialize the variable.
No such input appears in the driver.
Thanks,
David


On Saturday, February 3, 2018, 11:20:08 AM EST, Phil Rosenberg <p.d...@gm...> wrote:


Hi David
Can I just confirm which version of PLplot you are using or if it is a version grabbed from the git repo?

I ask because the line numbers don't seem to match up with the version I have. But looking at my code I have a feeling that bug has been fixed.

Phil


On Feb 3, 2018 15:56, "David Bergman" <davidrbergman<mailto:dav...@ya...>@yahoo.com<mailto:dav...@ya...>> wrote:
I tried running the wxPLplotDemo example and got the following compilation error:

error C4703: potentially uninitialized local pointer variable 'drawDc' used on line 378 of wxplplotwindow.h

Looking through the code it appears that every declaration of drawDC is as follows

wxDC *drawDc = m_memoryDc;

except the last function

void wxPLplotwindow<WXWINDOW>:: setUseGraphicsContext( bool useGraphicsContext )
{
    wxDC *drawDc;
...
}

I am not familiar with the details of the code but it appears that the variable is set to something before it is used.  This is not modified code.

Please advise.
Thanks,
David








On Saturday, February 3, 2018, 4:01:05 AM EST, Phil Rosenberg <p.d...@gm...<mailto:p.d...@gm...>> wrote:


Hi David
Yes, that's exactly what you need to do. <Type> can be pretty much any wxWidget window class, although I suggest using wxPanel. Using wxFrame works on Windows, but is apparently not good practice and some things don't work properly if you render directly to a wxFrame on Linux.

In terms of a demo, check out wxPLplotDemo.cpp in the PLplot source code. It is in examples/c++

Phil

From: David Bergman <davidrbergman<mailto:dav...@ya...>@yahoo.com<mailto:dav...@ya...>>
Sent: Saturday, February 3, 2018 1:59:39 AM
To: plplot<mailto:plp...@li...>-<mailto:plp...@li...>devel<mailto:plp...@li...>@lists. sourceforge.net<mailto:plp...@li...>; Phil Rosenberg
Subject: Re: [Plplot-general] More questions about install

Phil,

I am at the point where I have been able to successfully build new projects for wxWidgets and PLplot independently from scratch, compile-link-run.
I copied some code from a wxPLplotDemo into a new GUI I've developed.

The following declaration gives an error,

wxPLplotwindow* plotwindow;

"argument list missing"

Should the format be

wxPLplotwindow<type> etc

or is there still an issue with the wx drivers?  I have header, lib, and dll for wxwidgets functions, and enable_wxwidgets = ON was present in the cmake output.

Thanks in advance for our help.
David


On Friday, February 2, 2018, 12:14:04 PM EST, Phil Rosenberg <p.d...@gm...<mailto:p.d...@gm...>> wrote:


Hi David
Integrating wxWidgets into PLplot should be as simple as defining the WXWIN system variable before running cmake. Cmake should see that and automagically find wxWidgets and build that backend for the library along with the example.

Where things may get complicated is matching the library settings for Unicode, static vs dynamic runtimes and debug vs release builds. I'm not sure if these only need matching for static libraries or if dlls need these matching too.

If you have any trouble just drop us an email.

Phil

On Feb 2, 2018 14:37, "David Bergman" <davidrbergman<mailto:dav...@ya...>@yahoo.com<mailto:dav...@ya...>> wrote:
Phil,

Thanks for reaching out.
At this point the VS IDE build and install has never worked right, without massive errors.  The latest trial produced the release version without error but not the debug.

Following the instructions for a command line build, with help from Arjen, in windows (not Cygwin) produced a directory without errors.  The IDE build and the command prompt build are significantly different in the content (in my opinion).

I've been able to build a VS project from scratch using PLplot headers and dll and it worked.  So, I'm counting that as a success.  I have not yet had a chance to do more complex plots, fully test the functions, or integrate with widgets which is my intent.  I may need more help in the future.

I will say that there was one dll that the VS compiler/linker said was corrupted but I don't recall which one.
Just to get past it and get something working I deleted this from the project.  It may come back to bite me later.

David



On Friday, February 2, 2018, 9:23:06 AM EST, Phil Rosenberg <p.d...@gm...<mailto:p.d...@gm...>> wrote:


Hi David
I would have gotten involved in this thread earlier if I had realised it had moved to Visual Studio an wxWidgets and away from Cygwin. Sorry for just reading the title and not the text.

I always use the visual studio IDE, I don't know if that is the route you ended up going down. Have you found the instructions at https://sourceforge.net/p/ <https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/> plplot<https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/>/wiki/Configure_PLplot_ for_the_Visual_Studio_IDE/<https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/>? They are a little out of date, but I don't think much has changed.

Phil

On 26 January 2018 at 14:57, David Bergman via Plplot-general <plplot<mailto:plp...@li...>-general@lists. sourceforge.net<mailto:plp...@li...>> wrote:
That worked.  Are there any good tutorials for using this with wxWidgets and VC++?
I think I need to set up the wxWidgets driver.
You may hear from me again...
David


On Friday, January 26, 2018, 9:38:32 AM EST, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote:


Hi David,

That is easier – did you install the stuff via “nmake install” or are you working from the build directory?

That is what I usually do and then I have to expand the PATH environment variable:

set PATH=d:\plplot-build-dir\dll;% PATH%
cd examples\cxx
x01.exe

Fill in the right directory for “plplot-build-dir” above.

Regards,

Arjen

From: David Bergman [mailto:davidrbergman@yahoo. com<mailto:dav...@ya...>]
Sent: Friday, January 26, 2018 3:34 PM
To: Arjen Markus
Cc: Plplot<mailto:Plp...@li...>-general@lists. sourceforge.net<mailto:Plp...@li...> (plplot<mailto:plp...@li...>-general@lists. sourceforge.net<mailto:plp...@li...>)
Subject: Re: RE: RE: [Plplot-general] More questions about install

Arjen,
Thanks, that worked to get past this hurdle.  nmake and nmake install worked.
Frankly, I'm not sure what state plplot is in but I tried running an example exe and got an error message that plplotcxx.dll is not installed on my computer.
However, this *.dll does exists in the dll folder.
How does that work?
David


On Friday, January 26, 2018, 8:15:24 AM EST, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote:


Hi David,

I was a bit hasty, I think – the cairo device driver actually consists of a whole slew of them and you would have to set all of them to off to avoid the cairo device (things like PLD_wincairo and PLD_epscairo). If I read the CMake files correctly, then you should be able to turn off that family of devices by -DDEFAULT_NO_CAIRO_DEVICES=ON. (I hope I am right this time)

Regards,

Arjen


From: David Bergman [mailto:davidrbergman@yahoo. com<mailto:dav...@ya...>]
Sent: Thursday, January 25, 2018 2:12 PM
To: Arjen Markus
Cc: Plplot<mailto:Plp...@li...>-general@lists. sourceforge.net<mailto:Plp...@li...> (plplot<mailto:plp...@li...>-general@lists. sourceforge.net<mailto:plp...@li...>)
Subject: Re: RE: [Plplot-general] More questions about install

Arjen,
Thanks.  I tried again with your suggestion but the following warning.

CMake Warning:
  Manually-specified variables were not used by the project:

PLD_cairo

I tried variant, e.g. all cap, etc, just in case there was a typo.  No luck.

Any other suggestions would be appreciated.
On another note, not sure is you saw my other email status.  Installing from the IDE seemed to work for the Release build but not the Debug, several projects failed to build.  I cannot decipher why one would build and the other not.  Additionally the *.exe for the examples did not get created as in previous installs.  It seems that each try produces a different state.

Thank you in advance.
David



On Thursday, January 25, 2018, 2:44:51 AM EST, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote:


Hi David,

Wrt your message (it got caught in my spam filter for reasons best known to itself):

“Arjen,

I just installed CMake 3.9.4 and tried the build from a DOS command prompt (not using VS INSTALL).  Same issues, partial output is attached.
It crashes at ciaro [26%].  Do I need ciaro to use plplot?

David”

Apparently the build system is finding libraries that are connected to the cairo device. Unfortunately, they are not truly compatible. The best way to take care of that is to use the option –DPLD_cairo=OFF, forcing the build system to ignore that device. This kind of things sometimes happens.

Regards,

Arjen



Arjen Markus
Sr. Adviseur/Onderzoeker
T

+31(0)88 335 8559

E

<mailto:Arj...@de...>
Arj...@de...




 www.deltares.com<http://www.deltares.com/>

Postbus<http://www.deltares.com/>
177<http://www.deltares.com/>

2600 MH Delft<http://www.deltares.com/>



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

------------------------------ ------------------------------ ------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
______________________________ _________________
Plplot-general mailing list
Plplot<mailto:Plp...@li...>-general@lists. sourceforge.net<mailto:Plp...@li...>
https://lists.sourceforge.net/ lists/<https://lists.sourceforge.net/lists/listinfo/plplot-general>listinfo<https://lists.sourceforge.net/lists/listinfo/plplot-general>/<https://lists.sourceforge.net/lists/listinfo/plplot-general>plplot<https://lists.sourceforge.net/lists/listinfo/plplot-general>-general<https://lists.sourceforge.net/lists/listinfo/plplot-general>

Re: [Plplot-devel] [Plplot-general] More questions about install

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

Hi David
Yes, that's exactly what you need to do. <Type> can be pretty much any wxWidget window class, although I suggest using wxPanel. Using wxFrame works on Windows, but is apparently not good practice and some things don't work properly if you render directly to a wxFrame on Linux.

In terms of a demo, check out wxPLplotDemo.cpp in the PLplot source code. It is in examples/c++

Phil

________________________________
From: David Bergman <dav...@ya...>
Sent: Saturday, February 3, 2018 1:59:39 AM
To: plp...@li...; Phil Rosenberg
Subject: Re: [Plplot-general] More questions about install

Phil,

I am at the point where I have been able to successfully build new projects for wxWidgets and PLplot independently from scratch, compile-link-run.
I copied some code from a wxPLplotDemo into a new GUI I've developed.

The following declaration gives an error,

wxPLplotwindow* plotwindow;

"argument list missing"

Should the format be

wxPLplotwindow<type> etc

or is there still an issue with the wx drivers?  I have header, lib, and dll for wxwidgets functions, and enable_wxwidgets = ON was present in the cmake output.

Thanks in advance for our help.
David


On Friday, February 2, 2018, 12:14:04 PM EST, Phil Rosenberg <p.d...@gm...> wrote:


Hi David
Integrating wxWidgets into PLplot should be as simple as defining the WXWIN system variable before running cmake. Cmake should see that and automagically find wxWidgets and build that backend for the library along with the example.

Where things may get complicated is matching the library settings for Unicode, static vs dynamic runtimes and debug vs release builds. I'm not sure if these only need matching for static libraries or if dlls need these matching too.

If you have any trouble just drop us an email.

Phil

On Feb 2, 2018 14:37, "David Bergman" <dav...@ya...<mailto:dav...@ya...>> wrote:
Phil,

Thanks for reaching out.
At this point the VS IDE build and install has never worked right, without massive errors.  The latest trial produced the release version without error but not the debug.

Following the instructions for a command line build, with help from Arjen, in windows (not Cygwin) produced a directory without errors.  The IDE build and the command prompt build are significantly different in the content (in my opinion).

I've been able to build a VS project from scratch using PLplot headers and dll and it worked.  So, I'm counting that as a success.  I have not yet had a chance to do more complex plots, fully test the functions, or integrate with widgets which is my intent.  I may need more help in the future.

I will say that there was one dll that the VS compiler/linker said was corrupted but I don't recall which one.
Just to get past it and get something working I deleted this from the project.  It may come back to bite me later.

David



On Friday, February 2, 2018, 9:23:06 AM EST, Phil Rosenberg <p.d...@gm...<mailto:p.d...@gm...>> wrote:


Hi David
I would have gotten involved in this thread earlier if I had realised it had moved to Visual Studio an wxWidgets and away from Cygwin. Sorry for just reading the title and not the text.

I always use the visual studio IDE, I don't know if that is the route you ended up going down. Have you found the instructions at https://sourceforge.net/p/ plplot/wiki/Configure_PLplot_ for_the_Visual_Studio_IDE/<https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/>? They are a little out of date, but I don't think much has changed.

Phil

On 26 January 2018 at 14:57, David Bergman via Plplot-general <plplot-general@lists. sourceforge.net<mailto:plp...@li...>> wrote:
That worked.  Are there any good tutorials for using this with wxWidgets and VC++?
I think I need to set up the wxWidgets driver.
You may hear from me again...
David


On Friday, January 26, 2018, 9:38:32 AM EST, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote:



Hi David,



That is easier – did you install the stuff via “nmake install” or are you working from the build directory?



That is what I usually do and then I have to expand the PATH environment variable:



set PATH=d:\plplot-build-dir\dll;% PATH%

cd examples\cxx

x01.exe



Fill in the right directory for “plplot-build-dir” above.



Regards,



Arjen



From: David Bergman [mailto:davidrbergman@yahoo. com<mailto:dav...@ya...>]
Sent: Friday, January 26, 2018 3:34 PM
To: Arjen Markus
Cc: Plplot-general@lists. sourceforge.net<mailto:Plp...@li...> (plplot-general@lists. sourceforge.net<mailto:plp...@li...>)
Subject: Re: RE: RE: [Plplot-general] More questions about install



Arjen,

Thanks, that worked to get past this hurdle.  nmake and nmake install worked.

Frankly, I'm not sure what state plplot is in but I tried running an example exe and got an error message that plplotcxx.dll is not installed on my computer.

However, this *.dll does exists in the dll folder.

How does that work?

David





On Friday, January 26, 2018, 8:15:24 AM EST, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote:





Hi David,



I was a bit hasty, I think – the cairo device driver actually consists of a whole slew of them and you would have to set all of them to off to avoid the cairo device (things like PLD_wincairo and PLD_epscairo). If I read the CMake files correctly, then you should be able to turn off that family of devices by -DDEFAULT_NO_CAIRO_DEVICES=ON. (I hope I am right this time)



Regards,



Arjen





From: David Bergman [mailto:davidrbergman@yahoo. com<mailto:dav...@ya...>]
Sent: Thursday, January 25, 2018 2:12 PM
To: Arjen Markus
Cc: Plplot-general@lists. sourceforge.net<mailto:Plp...@li...> (plplot-general@lists. sourceforge.net<mailto:plp...@li...>)
Subject: Re: RE: [Plplot-general] More questions about install



Arjen,

Thanks.  I tried again with your suggestion but the following warning.



CMake Warning:
  Manually-specified variables were not used by the project:



PLD_cairo



I tried variant, e.g. all cap, etc, just in case there was a typo.  No luck.



Any other suggestions would be appreciated.

On another note, not sure is you saw my other email status.  Installing from the IDE seemed to work for the Release build but not the Debug, several projects failed to build.  I cannot decipher why one would build and the other not.  Additionally the *.exe for the examples did not get created as in previous installs.  It seems that each try produces a different state.



Thank you in advance.

David







On Thursday, January 25, 2018, 2:44:51 AM EST, Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote:





Hi David,



Wrt your message (it got caught in my spam filter for reasons best known to itself):



“Arjen,



I just installed CMake 3.9.4 and tried the build from a DOS command prompt (not using VS INSTALL).  Same issues, partial output is attached.

It crashes at ciaro [26%].  Do I need ciaro to use plplot?



David”



Apparently the build system is finding libraries that are connected to the cairo device. Unfortunately, they are not truly compatible. The best way to take care of that is to use the option –DPLD_cairo=OFF, forcing the build system to ignore that device. This kind of things sometimes happens.



Regards,



Arjen





Arjen Markus
Sr. Adviseur/Onderzoeker

T


+31(0)88 335 8559


E


Arj...@de...<mailto:Arj...@de...>








 www.deltares.com<http://www.deltares.com/>


Postbus 177
2600 MH Delft<http://www.deltares.com/>



<http://www.deltares.com/>






Please consider the environment before printing this email<http://www.deltares.com/>

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. <http://www.deltares.com/>

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

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

------------------------------ ------------------------------ ------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
______________________________ _________________
Plplot-general mailing list
Plplot-general@lists. sourceforge.net<mailto:Plp...@li...>
https://lists.sourceforge.net/ lists/listinfo/plplot-general<https://lists.sourceforge.net/lists/listinfo/plplot-general>

Re: [Plplot-devel] [Plplot-general] More questions about install

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

Hi David
Integrating wxWidgets into PLplot should be as simple as defining the WXWIN
system variable before running cmake. Cmake should see that and
automagically find wxWidgets and build that backend for the library along
with the example.

Where things may get complicated is matching the library settings for
Unicode, static vs dynamic runtimes and debug vs release builds. I'm not
sure if these only need matching for static libraries or if dlls need these
matching too.

If you have any trouble just drop us an email.

Phil

On Feb 2, 2018 14:37, "David Bergman" <dav...@ya...> wrote:

> Phil,
>
> Thanks for reaching out.
> At this point the VS IDE build and install has never worked right, without
> massive errors.  The latest trial produced the release version without
> error but not the debug.
>
> Following the instructions for a command line build, with help from Arjen,
> in windows (not Cygwin) produced a directory without errors.  The IDE build
> and the command prompt build are significantly different in the content (in
> my opinion).
>
> I've been able to build a VS project from scratch using PLplot headers and
> dll and it worked.  So, I'm counting that as a success.  I have not yet had
> a chance to do more complex plots, fully test the functions, or integrate
> with widgets which is my intent.  I may need more help in the future.
>
> I will say that there was one dll that the VS compiler/linker said was
> corrupted but I don't recall which one.
> Just to get past it and get something working I deleted this from the
> project.  It may come back to bite me later.
>
> David
>
>
>
> On Friday, February 2, 2018, 9:23:06 AM EST, Phil Rosenberg <
> p.d...@gm...> wrote:
>
>
> Hi David
> I would have gotten involved in this thread earlier if I had realised it
> had moved to Visual Studio an wxWidgets and away from Cygwin. Sorry for
> just reading the title and not the text.
>
> I always use the visual studio IDE, I don't know if that is the route you
> ended up going down. Have you found the instructions at
> https://sourceforge.net/p/plplot/wiki/Configure_PLplot_
> for_the_Visual_Studio_IDE/? They are a little out of date, but I don't
> think much has changed.
>
> Phil
>
> On 26 January 2018 at 14:57, David Bergman via Plplot-general <
> plp...@li...> wrote:
>
> That worked.  Are there any good tutorials for using this with wxWidgets
> and VC++?
> I think I need to set up the wxWidgets driver.
> You may hear from me again...
> David
>
>
> On Friday, January 26, 2018, 9:38:32 AM EST, Arjen Markus <
> Arj...@de...> wrote:
>
>
> Hi David,
>
>
>
> That is easier – did you install the stuff via “nmake install” or are you
> working from the build directory?
>
>
>
> That is what I usually do and then I have to expand the PATH environment
> variable:
>
>
>
> set PATH=d:\plplot-build-dir\dll;% PATH%
>
> cd examples\cxx
>
> x01.exe
>
>
>
> Fill in the right directory for “plplot-build-dir” above.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
> *From:* David Bergman [mailto:davidrbergman@yahoo. com
> <dav...@ya...>]
> *Sent:* Friday, January 26, 2018 3:34 PM
> *To:* Arjen Markus
> *Cc:* Plplot-general@lists. sourceforge.net
> <Plp...@li...> (plplot-general@lists.
> sourceforge.net <plp...@li...>)
> *Subject:* Re: RE: RE: [Plplot-general] More questions about install
>
>
>
> Arjen,
>
> Thanks, that worked to get past this hurdle.  nmake and nmake install
> worked.
>
> Frankly, I'm not sure what state plplot is in but I tried running an
> example exe and got an error message that plplotcxx.dll is not installed on
> my computer.
>
> However, this *.dll does exists in the dll folder.
>
> How does that work?
>
> David
>
>
>
>
>
> On Friday, January 26, 2018, 8:15:24 AM EST, Arjen Markus <
> Arj...@de...> wrote:
>
>
>
>
>
> Hi David,
>
>
>
> I was a bit hasty, I think – the cairo device driver actually consists of
> a whole slew of them and you would have to set all of them to off to avoid
> the cairo device (things like PLD_wincairo and PLD_epscairo). If I read the
> CMake files correctly, then you should be able to turn off that family of
> devices by -DDEFAULT_NO_CAIRO_DEVICES=ON. (I hope I am right this time)
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> *From:* David Bergman [mailto:davidrbergman@yahoo. com
> <dav...@ya...>]
> *Sent:* Thursday, January 25, 2018 2:12 PM
> *To:* Arjen Markus
> *Cc:* Plplot-general@lists. sourceforge.net
> <Plp...@li...> (plplot-general@lists.
> sourceforge.net <plp...@li...>)
> *Subject:* Re: RE: [Plplot-general] More questions about install
>
>
>
> Arjen,
>
> Thanks.  I tried again with your suggestion but the following warning.
>
>
>
> CMake Warning:
>   Manually-specified variables were not used by the project:
>
>
>
> PLD_cairo
>
>
>
> I tried variant, e.g. all cap, etc, just in case there was a typo.  No
> luck.
>
>
>
> Any other suggestions would be appreciated.
>
> On another note, not sure is you saw my other email status.  Installing
> from the IDE seemed to work for the Release build but not the Debug,
> several projects failed to build.  I cannot decipher why one would build
> and the other not.  Additionally the *.exe for the examples did not get
> created as in previous installs.  It seems that each try produces a
> different state.
>
>
>
> Thank you in advance.
>
> David
>
>
>
>
>
>
>
> On Thursday, January 25, 2018, 2:44:51 AM EST, Arjen Markus <
> Arj...@de...> wrote:
>
>
>
>
>
> Hi David,
>
>
>
> Wrt your message (it got caught in my spam filter for reasons best known
> to itself):
>
>
>
> “Arjen,
>
>
>
> I just installed CMake 3.9.4 and tried the build from a DOS command prompt
> (not using VS INSTALL).  Same issues, partial output is attached.
>
> It crashes at ciaro [26%].  Do I need ciaro to use plplot?
>
>
>
> David”
>
>
>
> Apparently the build system is finding libraries that are connected to the
> cairo device. Unfortunately, they are not truly compatible. The best way to
> take care of that is to use the option –DPLD_cairo=OFF, forcing the build
> system to ignore that device. This kind of things sometimes happens.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
>
> *Arjen Markus*
> Sr. Adviseur/Onderzoeker
>
> T
>
> +31(0)88 335 8559
>
> E
>
> Arj...@de...
>
>
>
>
>
> * www.deltares.com* <http://www.deltares.com/>
>
> Postbus 177
> 2600 MH Delft <http://www.deltares.com/>
>
>
> <http://www.deltares.com/>
>
>
> Please consider the environment before printing this email
> <http://www.deltares.com/>
>
> 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. <http://www.deltares.com/>
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is
> strictly prohibited. The foundation 'Stichting Deltares', which has its
> seat at Delft, The Netherlands, Commercial Registration Number 41146461, is
> not liable in any way whatsoever for consequences and/or damages resulting
> from the improper, incomplete and untimely dispatch, receipt and/or content
> of this e-mail.
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is
> strictly prohibited. The foundation 'Stichting Deltares', which has its
> seat at Delft, The Netherlands, Commercial Registration Number 41146461, is
> not liable in any way whatsoever for consequences and/or damages resulting
> from the improper, incomplete and untimely dispatch, receipt and/or content
> of this e-mail.
>
> ------------------------------ ------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ______________________________ _________________
> Plplot-general mailing list
> Plplot-general@lists. sourceforge.net
> <Plp...@li...>
> https://lists.sourceforge.net/ lists/listinfo/plplot-general
> <https://lists.sourceforge.net/lists/listinfo/plplot-general>
>
>
>

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

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

> On Jan 14, 2018, at 4:30 PM, Greg Jung <gv...@gm...> wrote:
> 
> Hi Jim,
>   I've looked at the wingdi I was earlier working with, and the commoncontrols initialization was commented out
> for the #ifdef _WIN64 case.  I'm unsure whether I tested with w64, I think so.  But in the current attempt, I 
> was definitely confined to a 32-bit system - it may be the case that this function is unavailable.
> 
> in module wingdi_modul_initialize( void ) :
> #ifdef _WIN64
> 	
> 	// Initialize common controls
> 	init_controls.dwSize = sizeof(INITCOMMONCONTROLSEX);
> 	init_controls.dwICC = ICC_BAR_CLASSES;
> 	if( ! InitCommonControlsEx( &init_controls ) )
> 	{
> 		plwarn( "wingdi:  Failed to initialize common Window controls\n" );
> 	}
> #endif
> 

The InitCommonControlsEx is available in both WIN32 and WIN64.  When I was looking at how to patch, the minimum supported version is Windows Vista and it is also available in Wine.  I guess the main question is what is the minimum version of Windows that we want to support in Plplot.  I would say Windows Vista is the minimum because it is becoming more of a challenge to keep supporting XP (particularly when I need to test).  If I had a preference, I would draw the line at Windows 7 and 10 with Windows 8 being unsupported.

I am not sure why your cmake failed, because it should have worked.

>   Also to mention, it would be a great convenience if HWND - plot and HDC - hdc were again placed at the top of 
> the wingdi_Dev struct.   As such, the replacement of wingcc with wingdi is already accommodated in GDL as a compile-time macro.
> // Device-specific info per stream
> struct wingdi_Dev
> {
> 	//
>     // WIN32 API variables
>     //
> 	HWND     		  plot;       // Handle for the plot area
> 	HDC               hdc;        // Plot window device context
> 	HPEN              pen;        // Current pen used for drawing
>       …

That seems reasonable.  No real reason why I put them down lower other than a desire to put some common members at the top.

> Thanks,
> Greg
> 
> On Sun, Dec 31, 2017 at 5:14 AM, Jim Dishaw <ji...@di... <mailto:ji...@di...>> wrote:
> I think that is a Windows vs Windows 8. I will look at that today and patch. 
> 
> On Dec 31, 2017, at 1:10 AM, Greg Jung <gv...@gm... <mailto:gv...@gm...>> wrote:
> 
>> Hi guys,
>>    Because my main PC (win 7) is busted I am working with a backup system which is windows 8.1 pro 32-bits
>> and I was interested in deploying the new wingdi for GDL on windows.  Although no errors were anticipated from the
>>  cmake processing (required setting  PLD_wingdi=ON) the build came up short finding a library:
>> Scanning dependencies of target wingdi
>> [ 67%] Building C object drivers/CMakeFiles/wingdi.dir/wingdi.c.obj
>> [ 67%] Linking C shared module ../dll/wingdi.dll
>> CMakeFiles/wingdi.dir/objects.a(wingdi.c.obj):wingdi.c:(.text+0x1bb7): undefined reference to `_imp__InitCommonControlsEx@4'
>> collect2.exe: error: ld returned 1 exit status
>> make[2]: *** [drivers/CMakeFiles/wingdi.dir/build.make:104: dll/wingdi.dll] Error 1
>> make[1]: *** [CMakeFiles/Makefile2:1263: drivers/CMakeFiles/wingdi.dir/all] Error 2
>> make: *** [Makefile:152: all] Error 2
>> 
>> I also found, although it isn't important for me downstream, that my QHULL installation was not found correctly. I checked where they were to be found, here is a partial listing of that:
>> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>> %FILES%
>> mingw32/
>> mingw32/bin/
>> mingw32/bin/qconvex.exe
>> mingw32/bin/qdelaunay.exe
>> mingw32/bin/qhalf.exe
>> mingw32/bin/qhull.exe
>> mingw32/bin/qvoronoi.exe
>> mingw32/bin/rbox.exe
>> mingw32/include/
>> mingw32/include/qhull/
>> mingw32/include/qhull/geom.h
>> mingw32/include/qhull/libqhull.h
>> 
>> 
>> On Fri, Oct 6, 2017 at 11:06 AM, Alan W. Irwin <ir...@be... <mailto:ir...@be...>> wrote:
>> On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
>> 
>> Given that the libraries in question are in the standard c and C++
>> libraries. I just tested to see what the impact is of simply
>> commenting out the checks for these two libraries.
>> 
>> The result is that wingcc is accepted onto the driver list, appears in
>> my plplot VC++ project, everything builds correctly and I can run the
>> examples and select the wingcc device and everything runs fine.
>> 
>> Given that this is the case is there even a need to check for these
>> libraries? Or is this test needed for Cygwin or minGW builds?
>> 
>> The present library finding has "just worked" for a long time for a
>> large variety of Windows users on many different Windows platforms so
>> I am somewhat reluctant to change it.  On the other hand, I guess it
>> is possible if you don't need it, then nobody needs it, but I am not
>> at all sure about that.  So before making any decisions here, I think
>> we need to collect more information.  For example, I would like you to
>> try 3.9.4 (see other thread concerning CMake versions) to see if this
>> particular problem persists (and also to determine whether CMake-3.9.4
>> satisfies all PLplot build-system needs for your Windows SDK version.)
>> 
>> 
>> Alan
>> __________________________
>> Alan W. Irwin
>> 
>> Astronomical research affiliation with Department of Physics and Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca <http://astrowww.phys.uvic.ca/>).
>> 
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net <http://freeeos.sf.net/>); the Time
>> Ephemerides project (timeephem.sf.net <http://timeephem.sf.net/>); PLplot scientific plotting
>> software package (plplot.sf.net <http://plplot.sf.net/>); the libLASi project
>> (unifont.org/lasi <http://unifont.org/lasi>); the Loads of Linux Links project (loll.sf.net <http://loll.sf.net/>);
>> and the Linux Brochure Project (lbproject.sf.net <http://lbproject.sf.net/>).
>> __________________________
>> 
>> Linux-powered Science
>> __________________________
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li... <mailto:Plp...@li...>
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel <https://lists.sourceforge.net/lists/listinfo/plplot-devel>
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>_______________________________________________
>> Plplot-devel mailing list
>> Plp...@li... <mailto:Plp...@li...>
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel <https://lists.sourceforge.net/lists/listinfo/plplot-devel>
> 

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

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

Hi Jim,
  I've looked at the wingdi I was earlier working with, and the
commoncontrols initialization was commented out
for the #ifdef _WIN64 case.  I'm unsure whether I tested with w64, I think
so.  But in the current attempt, I
was definitely confined to a 32-bit system - it may be the case that this
function is unavailable.

in module wingdi_modul_initialize( void ) :

> #ifdef _WIN64
>
> // Initialize common controls
>
> init_controls.dwSize = sizeof(INITCOMMONCONTROLSEX);
>
> init_controls.dwICC = ICC_BAR_CLASSES;
>
> if( ! InitCommonControlsEx( &init_controls ) )
>
> {
>
> plwarn( "wingdi:  Failed to initialize common Window controls\n" );
>
> }
>
> #endif
>
>
>   Also to mention, it would be a great convenience if HWND - plot and HDC
- hdc were again placed at the top of
the wingdi_Dev struct.   As such, the replacement of wingcc with wingdi is
already accommodated in GDL as a compile-time macro.

> // Device-specific info per stream
>
> struct wingdi_Dev
>
> {
>
> //
>
>     // WIN32 API variables
>
>     //
>
> HWND        plot;       // Handle for the plot area
>
> HDC               hdc;        // Plot window device context
>
> HPEN              pen;        // Current pen used for drawing
>
>       ...
Thanks,
Greg

On Sun, Dec 31, 2017 at 5:14 AM, Jim Dishaw <ji...@di...> wrote:

> I think that is a Windows vs Windows 8. I will look at that today and
> patch.
>
> On Dec 31, 2017, at 1:10 AM, Greg Jung <gv...@gm...> wrote:
>
> Hi guys,
>    Because my main PC (win 7) is busted I am working with a backup system
> which is windows 8.1 pro 32-bits
> and I was interested in deploying the new wingdi for GDL on windows.
> Although no errors were anticipated from the
>  cmake processing (required setting  PLD_wingdi=ON) the build came up
> short finding a library:
>
>> Scanning dependencies of target wingdi
>>
>> [ 67%] Building C object drivers/CMakeFiles/wingdi.dir/wingdi.c.obj
>>
>> [ 67%] Linking C shared module ../dll/wingdi.dll
>>
>> CMakeFiles/wingdi.dir/objects.a(wingdi.c.obj):wingdi.c:(.text+0x1bb7):
>>> undefined reference to `_imp__InitCommonControlsEx@4'
>>
>> collect2.exe: error: ld returned 1 exit status
>>
>> make[2]: *** [drivers/CMakeFiles/wingdi.dir/build.make:104:
>>> dll/wingdi.dll] Error 1
>>
>> make[1]: *** [CMakeFiles/Makefile2:1263: drivers/CMakeFiles/wingdi.dir/all]
>>> Error 2
>>
>> make: *** [Makefile:152: all] Error 2
>>
>>
> I also found, although it isn't important for me downstream, that my QHULL
> installation was not found correctly. I checked where they were to be
> found, here is a partial listing of that:
>
>> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>>
>> %FILES%
>>
>> mingw32/
>>
>> mingw32/bin/
>>
>> mingw32/bin/qconvex.exe
>>
>> mingw32/bin/qdelaunay.exe
>>
>> mingw32/bin/qhalf.exe
>>
>> mingw32/bin/qhull.exe
>>
>> mingw32/bin/qvoronoi.exe
>>
>> mingw32/bin/rbox.exe
>>
>> mingw32/include/
>>
>> mingw32/include/qhull/
>>
>> mingw32/include/qhull/geom.h
>>
>> mingw32/include/qhull/libqhull.h
>>
>>
>>
> On Fri, Oct 6, 2017 at 11:06 AM, Alan W. Irwin <ir...@be...>
> wrote:
>
>> On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
>>
>> Given that the libraries in question are in the standard c and C++
>>> libraries. I just tested to see what the impact is of simply
>>> commenting out the checks for these two libraries.
>>>
>>> The result is that wingcc is accepted onto the driver list, appears in
>>> my plplot VC++ project, everything builds correctly and I can run the
>>> examples and select the wingcc device and everything runs fine.
>>>
>>> Given that this is the case is there even a need to check for these
>>> libraries? Or is this test needed for Cygwin or minGW builds?
>>>
>>
>> The present library finding has "just worked" for a long time for a
>> large variety of Windows users on many different Windows platforms so
>> I am somewhat reluctant to change it.  On the other hand, I guess it
>> is possible if you don't need it, then nobody needs it, but I am not
>> at all sure about that.  So before making any decisions here, I think
>> we need to collect more information.  For example, I would like you to
>> try 3.9.4 (see other thread concerning CMake versions) to see if this
>> particular problem persists (and also to determine whether CMake-3.9.4
>> satisfies all PLplot build-system needs for your Windows SDK version.)
>>
>>
>> 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
>> __________________________
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
> ------------------------------------------------------------
> ------------------
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

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

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> 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.

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

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

On 2018-01-07 11:03-0000 Arjen Markus wrote:

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

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.

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.

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.  :-)

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

On 2018-01-07 11:03-0000 Arjen Markus wrote:

> I can now confirm that it [running examples/fortran/x01f built with
local change pl_parse_dynamic = .true.] works for both compilers.

Excellent.  Now that you have confirmed the "_dynamic" versions of
plget_arguments and plparseopts work with modern versions of gfortran
and ifort, I will encourage others with access to other Fortran
compilers to try this test as well.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> 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-0000 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.

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

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

On 2018-01-05 08:09-0000 Arjen Markus wrote:

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

Hi Arjen:

I have responded already to your fortran report with a bug fix, but I
respond here also to the above C issue you discovered.

I get a similar error for

examples/c/x01c -dev xwin

but not for the valgrind-clean variant I checked before

examples/c/x01c -dev psc -o test.psc

I have no idea why the former form does not work while the latter form
works perfectly in all regards, but I will definitely look into this
weird difference between these two different parsing results.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

On 2018-01-05 13:38-0000 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.

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

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

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

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

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

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

Hi Alan,



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


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

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

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

On 2018-01-03 13:28-0000 Arjen Markus wrote:

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> 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 ;).

Thanks for your review of the code and your comments above based on
that review.  With regard to the "layering" idea, I would like to keep
the 3 variants completely independent of each other because the
deferred-length + allocated size variant is preferred and the
assumed-length + allocated size and the assumed-length + assumed size
variants are deprecated. Furthermore, I agree the required
disambiguate parameter on the assumed-length + allocated size variant
is a "wart" for that variant, but I don't think we need to be too
concerned about that wart since it is a deprecated variant.

I did look at
<https://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>
and support for "allocatable character length" (what we now
call deferred-length character) is pretty widespread (e.g.,
gfortran-5.2, ifort 17.0, and nagfor 6.1 and above) so I am pretty
sure your tests tomorrow of the modern gfortran and ifort cases
(and presumably your eventual test of nagfor) as well as
my eventual (once I install Debian Stretch with gfortran-6.3.0) 
test of modern gfortran will all go well.

That said, one notable (because they feature PLplot capability)
holdout is Absoft where the box in the above PDF is blank indicating
support for this important Fortran 2003 feature is unknown.  Absoft do
claim they support "essentially all" of Fortran 2003 so that is a good
sign, but a site:www.absoft.com google search showed no mention of
"character(len=:)" or "deferred length" or "allocatable length" so
that is a bad sign.  Anyhow, I plan to reestablish contact with Absoft
(assuming you can demonstrate good test results of the deferred-length
+ allocated size variant for modern gfortran and ifort) and ask them
to do the same test you are doing and temporarily keep or throw away
the deprecated versions of the above API before the release depending
on those results.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> 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.

Re: [Plplot-devel] qhull import library and corresponding dll missing for MinGW-w64/MSYS2

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

Hi Alan, Greg,



Thanks for the report - I will see to reporting this on the relevant mailing list. I have version r151.5bbc756-1 installed.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, January 01, 2018 2:09 AM
> To: Greg Jung; Arjen Markus
> Cc: PLplot development list
> Subject: qhull import library and corresponding dll missing for MinGW-w64/MSYS2
>
> On 2017-12-30 22:10-0800 Greg Jung wrote:
>
> > I also found, although it isn't important for me downstream, that my
> > QHULL installation was not found correctly. I checked where they were
> > to be found, here is a partial listing of that:
> >
> >> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
> >>
>
> [...]
>
> Hi Greg:
>
> Thanks for that report of your qhull find troubles on the MinGW-w64/MSYS platform.
> The rest of this is addressed to Arjen (or anyone else here with interest in the
> important qhull component of our plgriddata API on that platform) because I think
> he is going to encounter those same troubles soon.
>
> @Arjen:
>
> Your latest latest (2017-08-17) successful test of the mingw64 version of MinGW-
> w64/MSYS2 shows the following qhull-related find results:
>
> -- Found QHULL: D:/mingw64-2/mingw64/include
> -- QHULL_INCLUDE_DIRS = D:/mingw64-2/mingw64/include
> -- HAS_LIBQHULL_INCLUDE = OFF
> -- QHULL_LIBRARIES = D:/mingw64-2/mingw64/lib/libqhull.dll.a
> -- QHULL_RPATH =
>
> So all *was* well in that case.
>
> However, it appears there is qhull trouble ahead for you just like Greg has
> encountered.  Note that the above import library and corresponding dll is available
> for both <http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qhull-git-
> r113.60d5581-3-any.pkg.tar.xz>
> and
> <http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qhull-git-r151.5bbc756-1-
> any.pkg.tar.xz>,
> but they are not available for the latest version,
> <http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qhull-git-r157.f0bd8ce-1-
> any.pkg.tar.xz>.
> and the corresponding latest 32-bit version,
> <http://repo.msys2.org/mingw/i686/mingw-w64-i686-qhull-git-r157.f0bd8ce-1-
> any.pkg.tar.xz>
> that Greg used.  So when you update to that latest 64-bit version of the qhull library
> for MinGW-w64/MSYS2 I assume you will run into the same issue that Greg has
> encountered, and when that occurs you should follow up with an error report to the
> MSYS2 list concerning that missing import library and dll situation for their latest
> qhull package.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux
> Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

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

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

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

On 2017-12-27 14:26-0800 Alan W. Irwin wrote:

> Hi Arjen:
>
> I have done some further investigation and it appears that even today
> allocatable character arrays are problematic to a certain extent for
> Fortran compilers. For example, see
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945>. I have no clue
> whether that particular modern gfortran bug would affect us.  However,
> the existence of such bug reports for a modern version of a Fortran
> compiler indicates we should proceed with caution with allocatable
> character arrays.
>
> Therefore, once we implement allocatable character array variants of
> plget_arguments and plparseopts we should survey the modern versions
> of gfortran, ifort, and nagfor to see which of those work well with
> that API.  Also we will likely want to retain the the current static
> assumed shape character arrays API's for those functions for a while
> so that users with access only to older Fortran compilers (e.g.,
> gfortran-4.9.2) that are unreliable with the allocatable character
> array approach have a plget_arguments and plparseopts API that
> they can use.

Hi Arjen:

I have just pushed commit 6f2f4e4 to master which implements dynamic
length and size as well as static length and dynamic size variants of
plget_arguments and plparseopts.  The former does not work with
gfortran-4.9.2, but the latter (as well as the static length and size
variants implemented before) works well.  For more details about how
these tests should be done and results for gfortran-4.9.2, please see
the revised version of README.release section 2.7.2.

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.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] qhull import library and corresponding dll missing for MinGW-w64/MSYS2

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

On 2017-12-30 22:10-0800 Greg Jung wrote:

> I also found, although it isn't important for me downstream, that my QHULL
> installation was not found correctly. I checked where they were to be
> found, here is a partial listing of that:
>
>> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>>

[...]

Hi Greg:

Thanks for that report of your qhull find troubles on the
MinGW-w64/MSYS platform.  The rest of this is addressed to Arjen (or
anyone else here with interest in the important qhull component of our
plgriddata API on that platform) because I think he is going to
encounter those same troubles soon.

@Arjen:

Your latest latest (2017-08-17) successful test of the mingw64 version
of MinGW-w64/MSYS2 shows the following qhull-related find results:

-- Found QHULL: D:/mingw64-2/mingw64/include 
-- QHULL_INCLUDE_DIRS = D:/mingw64-2/mingw64/include
-- HAS_LIBQHULL_INCLUDE = OFF
-- QHULL_LIBRARIES = D:/mingw64-2/mingw64/lib/libqhull.dll.a
-- QHULL_RPATH =

So all *was* well in that case.

However, it appears there is qhull trouble ahead for you just like
Greg has encountered.  Note that the above import library and
corresponding dll is available for both
<http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qhull-git-r113.60d5581-3-any.pkg.tar.xz>
and
<http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qhull-git-r151.5bbc756-1-any.pkg.tar.xz>,
but they are not available for the latest version,
<http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qhull-git-r157.f0bd8ce-1-any.pkg.tar.xz>.
and the corresponding latest 32-bit version, 
<http://repo.msys2.org/mingw/i686/mingw-w64-i686-qhull-git-r157.f0bd8ce-1-any.pkg.tar.xz>
that Greg used.  So when you update to that latest 64-bit version of
the qhull library for MinGW-w64/MSYS2 I assume you will run into the
same issue that Greg has encountered, and when that occurs you should
follow up with an error report to the MSYS2 list concerning that
missing import library and dll situation for their latest qhull
package.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

I think that is a Windows vs Windows 8. I will look at that today and patch. 

> On Dec 31, 2017, at 1:10 AM, Greg Jung <gv...@gm...> wrote:
> 
> Hi guys,
>    Because my main PC (win 7) is busted I am working with a backup system which is windows 8.1 pro 32-bits
> and I was interested in deploying the new wingdi for GDL on windows.  Although no errors were anticipated from the
>  cmake processing (required setting  PLD_wingdi=ON) the build came up short finding a library:
>>> Scanning dependencies of target wingdi
>>> [ 67%] Building C object drivers/CMakeFiles/wingdi.dir/wingdi.c.obj
>>> [ 67%] Linking C shared module ../dll/wingdi.dll
>>> CMakeFiles/wingdi.dir/objects.a(wingdi.c.obj):wingdi.c:(.text+0x1bb7): undefined reference to `_imp__InitCommonControlsEx@4'
>>> collect2.exe: error: ld returned 1 exit status
>>> make[2]: *** [drivers/CMakeFiles/wingdi.dir/build.make:104: dll/wingdi.dll] Error 1
>>> make[1]: *** [CMakeFiles/Makefile2:1263: drivers/CMakeFiles/wingdi.dir/all] Error 2
>>> make: *** [Makefile:152: all] Error 2
> 
> I also found, although it isn't important for me downstream, that my QHULL installation was not found correctly. I checked where they were to be found, here is a partial listing of that:
>>> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>>> %FILES%
>>> mingw32/
>>> mingw32/bin/
>>> mingw32/bin/qconvex.exe
>>> mingw32/bin/qdelaunay.exe
>>> mingw32/bin/qhalf.exe
>>> mingw32/bin/qhull.exe
>>> mingw32/bin/qvoronoi.exe
>>> mingw32/bin/rbox.exe
>>> mingw32/include/
>>> mingw32/include/qhull/
>>> mingw32/include/qhull/geom.h
>>> mingw32/include/qhull/libqhull.h
>> 
> 
> 
>> On Fri, Oct 6, 2017 at 11:06 AM, Alan W. Irwin <ir...@be...> wrote:
>> On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
>> 
>>> Given that the libraries in question are in the standard c and C++
>>> libraries. I just tested to see what the impact is of simply
>>> commenting out the checks for these two libraries.
>>> 
>>> The result is that wingcc is accepted onto the driver list, appears in
>>> my plplot VC++ project, everything builds correctly and I can run the
>>> examples and select the wingcc device and everything runs fine.
>>> 
>>> Given that this is the case is there even a need to check for these
>>> libraries? Or is this test needed for Cygwin or minGW builds?
>> 
>> The present library finding has "just worked" for a long time for a
>> large variety of Windows users on many different Windows platforms so
>> I am somewhat reluctant to change it.  On the other hand, I guess it
>> is possible if you don't need it, then nobody needs it, but I am not
>> at all sure about that.  So before making any decisions here, I think
>> we need to collect more information.  For example, I would like you to
>> try 3.9.4 (see other thread concerning CMake versions) to see if this
>> particular problem persists (and also to determine whether CMake-3.9.4
>> satisfies all PLplot build-system needs for your Windows SDK version.)
>> 
>> 
>> 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
>> __________________________
>> 
>> ------------------------------------------------------------------------------
>> 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
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 
> ------------------------------------------------------------------------------
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

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

Hi guys,
   Because my main PC (win 7) is busted I am working with a backup system
which is windows 8.1 pro 32-bits
and I was interested in deploying the new wingdi for GDL on windows.
Although no errors were anticipated from the
 cmake processing (required setting  PLD_wingdi=ON) the build came up short
finding a library:

> Scanning dependencies of target wingdi
>
> [ 67%] Building C object drivers/CMakeFiles/wingdi.dir/wingdi.c.obj
>
> [ 67%] Linking C shared module ../dll/wingdi.dll
>
> CMakeFiles/wingdi.dir/objects.a(wingdi.c.obj):wingdi.c:(.text+0x1bb7):
>> undefined reference to `_imp__InitCommonControlsEx@4'
>
> collect2.exe: error: ld returned 1 exit status
>
> make[2]: *** [drivers/CMakeFiles/wingdi.dir/build.make:104:
>> dll/wingdi.dll] Error 1
>
> make[1]: *** [CMakeFiles/Makefile2:1263:
>> drivers/CMakeFiles/wingdi.dir/all] Error 2
>
> make: *** [Makefile:152: all] Error 2
>
>
I also found, although it isn't important for me downstream, that my QHULL
installation was not found correctly. I checked where they were to be
found, here is a partial listing of that:

> $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files
>
> %FILES%
>
> mingw32/
>
> mingw32/bin/
>
> mingw32/bin/qconvex.exe
>
> mingw32/bin/qdelaunay.exe
>
> mingw32/bin/qhalf.exe
>
> mingw32/bin/qhull.exe
>
> mingw32/bin/qvoronoi.exe
>
> mingw32/bin/rbox.exe
>
> mingw32/include/
>
> mingw32/include/qhull/
>
> mingw32/include/qhull/geom.h
>
> mingw32/include/qhull/libqhull.h
>
>
>
On Fri, Oct 6, 2017 at 11:06 AM, Alan W. Irwin <ir...@be...>
wrote:

> On 2017-10-06 11:00+0100 Phil Rosenberg wrote:
>
> Given that the libraries in question are in the standard c and C++
>> libraries. I just tested to see what the impact is of simply
>> commenting out the checks for these two libraries.
>>
>> The result is that wingcc is accepted onto the driver list, appears in
>> my plplot VC++ project, everything builds correctly and I can run the
>> examples and select the wingcc device and everything runs fine.
>>
>> Given that this is the case is there even a need to check for these
>> libraries? Or is this test needed for Cygwin or minGW builds?
>>
>
> The present library finding has "just worked" for a long time for a
> large variety of Windows users on many different Windows platforms so
> I am somewhat reluctant to change it.  On the other hand, I guess it
> is possible if you don't need it, then nobody needs it, but I am not
> at all sure about that.  So before making any decisions here, I think
> we need to collect more information.  For example, I would like you to
> try 3.9.4 (see other thread concerning CMake versions) to see if this
> particular problem persists (and also to determine whether CMake-3.9.4
> satisfies all PLplot build-system needs for your Windows SDK version.)
>
>
> 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
> __________________________
>
> ------------------------------------------------------------
> ------------------
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

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

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

On 2017-12-27 09:02-0000 Arjen Markus wrote:

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

Hi Arjen:

I have done some further investigation and it appears that even today
allocatable character arrays are problematic to a certain extent for
Fortran compilers. For example, see
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945>. I have no clue
whether that particular modern gfortran bug would affect us.  However,
the existence of such bug reports for a modern version of a Fortran
compiler indicates we should proceed with caution with allocatable
character arrays.

Therefore, once we implement allocatable character array variants of
plget_arguments and plparseopts we should survey the modern versions
of gfortran, ifort, and nagfor to see which of those work well with
that API.  Also we will likely want to retain the the current static
assumed shape character arrays API's for those functions for a while
so that users with access only to older Fortran compilers (e.g.,
gfortran-4.9.2) that are unreliable with the allocatable character
array approach have a plget_arguments and plparseopts API that
they can use.

By the way, I am already using this new Fortran parsing feature in one of my
te_gen examples where the command-line has a mixture of PLplot options
and a file name, e.g.,

software@raven> examples/f95/test_asteroids \
-dev psc -o test.psc \
/home/software/time_ephemeris/HEAD/asteroid_ephemerides/ephcom_binary_ast343de430

where that last command-line option (although it could have been
anywhere on the command line) is obviously not relevant to PLplot.
After calling plget_arguments(nargv, argv) to get the nargv and argv
corresponding to that command-line, that example then calls 
plparseopts(nargv, argv, PL_PARSE_SKIP) which parses all the
command-line options that are relevant to PLplot and removes them from
argv.  The result is plparseopts returns nargv = 1 and argv(1) equal
to the asteroid ephemeris filename specified on the command line.  The
example then opens that ephemeris file and uses it to help calculate
the many asteroid results that are plotted by that example.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

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...@be...]
> 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.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] Command-line parsing improvements for both C and Fortran

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

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.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] libieee.a is no more

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

On 2017-12-12 17:36-0700 Orion Poplawski wrote:

> Sorry I wasn't clear.  The test was failing because of the compile error. 
> With the patch the test returns "found" and the build is normal/successful.

Hi Orion:

Thanks for that key clarification.  Based on that good news for gcc
NaN awareness with no special options on i686 hardware, I have made a
slightly more conservative upstream change then your patch (just in
case there is any non-gcc i*86 cases where the -mieee-fp compiler
option builds and is still required for the NaN awareness test to
still work). See
<https://sourceforge.net/p/plplot/plplot/ci/5c628406e9a1c941dbe34d3db056f985e1ec8b08>
for details.  For your pure gcc case, your patch and the git master upstream
version, i.e.,

[...]
   if(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86" AND NOT CMAKE_C_COMPILER MATCHES "gcc")
     set(NAN_CFLAGS "${NAN_CFLAGS} -mieee-fp")
   elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
     if(CMAKE_C_COMPILER MATCHES "gcc")
       set(NAN_CFLAGS "${NAN_CFLAGS} -mieee")
     else(CMAKE_C_COMPILER MATCHES "gcc")
       set(NAN_CFLAGS "${NAN_CFLAGS} -ieee")
     endif(CMAKE_C_COMPILER MATCHES "gcc")
   endif(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86" AND NOT CMAKE_C_COMPILER MATCHES "gcc")
[...]

should give the same result (no -mieee-fp option used for gcc
on i*86).  The git master version should become the basis of a PLplot release
in early 2018.

Thanks once again for your key help with PLplot for the cutting-edge versions of
Linux system software that you get with Fedora.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] libieee.a is no more

[Orion P. <or...@nw...>]

On 12/12/2017 04:42 PM, Alan W. Irwin wrote:
> On 2017-12-12 15:36-0700 Orion Poplawski wrote:
> 
>> Apparently glibc is dropping libieee.a in the next release.  In Fedora
>> Rawhide, -mieee-fp on i686 results in:
>>
>> /usr/bin/ld: Cannot find -lieee
>>
>> Dropping -mieee-fp from csiro.cmake fixes it for me.
> 
> Hi Orion:
> 
> For i686 hardware and your patched case, what is the result of the test?
> 
> In other words, does the CMake output say
> 
> "Check for NaN awareness in C compiler - found"
> 
> or
> 
> "Check for NaN awareness in C compiler - not found"
> 
> followed by
> 
> WARNING: Setting PL_HAVE_QHULL and WITH_CSA to OFF.
> 
> ?
> 
> The latter result is a fairly serious constraint on our plgrid
> function for i686 hardware.  So I am hoping for the former result
> since that simply means the gcc option -mieee-fp is no longer required
> to get this NaN test to work correctly on i686 hardware.
> 
> Alan
> __________________________
> Alan W. Irwin

Sorry I wasn't clear.  The test was failing because of the compile 
error.  With the patch the test returns "found" and the build is 
normal/successful.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/