plplot-devel — Technical discussion about PLplot development

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

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

Hi Alan,



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

Regards,

Arjen

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

Re: [Plplot-devel] Pause behavior while minimized

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

Makes sense to me. I might make it an option on the wingdi to test the concept. 

Minimized is the same concept as iconified. 

> On Jun 21, 2017, at 2:29 AM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2017-06-21 00:26-0400 James Dishaw wrote:
>> 
>> I have been working on a wingcc bug that was reported and I am not sure what
>> the correct behavior should be for a pause when a window is minimized.
>> 
>> 
>> 
>> I think the correct behavior is that a minimized window should be treated
>> like a normal window (in Windows a minimized window is given a size of
>> 160x31).  That would mean pauses are honored and a user would need to
>> restore the window in order to advance the page.
> [...]
>> Thoughts?
> 
> Hi Jim:
> 
> I think pause should be honored completely independent of any windows
> manipulations that are being done.  I am unfamiliar with the concept
> of Windows minimized windows, but on Linux desktops you can resize the
> window, iconify it, etc., and for the case when a plot is paused and
> such manipulations occur, then I would expect the pause to still be in
> effect when the window is restored. So the above alternative seems the
> correct choice to me.
> 
> 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] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,

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

Regards,

Arjen





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

Re: [Plplot-devel] Pause behavior while minimized

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

On 2017-06-21 00:26-0400 James Dishaw wrote:

> I have been working on a wingcc bug that was reported and I am not sure what
> the correct behavior should be for a pause when a window is minimized.
>
>
>
> I think the correct behavior is that a minimized window should be treated
> like a normal window (in Windows a minimized window is given a size of
> 160x31).  That would mean pauses are honored and a user would need to
> restore the window in order to advance the page.
[...]
> Thoughts?

Hi Jim:

I think pause should be honored completely independent of any windows
manipulations that are being done.  I am unfamiliar with the concept
of Windows minimized windows, but on Linux desktops you can resize the
window, iconify it, etc., and for the case when a plot is paused and
such manipulations occur, then I would expect the pause to still be in
effect when the window is restored. So the above alternative seems the
correct choice to me.

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] Pause behavior while minimized

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

I have been working on a wingcc bug that was reported and I am not sure what
the correct behavior should be for a pause when a window is minimized.

 

I think the correct behavior is that a minimized window should be treated
like a normal window (in Windows a minimized window is given a size of
160x31).  That would mean pauses are honored and a user would need to
restore the window in order to advance the page.

 

Alternatively, the pause feature can be ignored while minimized and the
pages advance automatically.

 

The third option is to make the first option the default and to make the
autoadvance an option that can be enabled.

 

Thoughts?

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

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

On 2017-06-20 11:36-0700 Alan W. Irwin wrote:

> Also now that I have finally found a partner who is willing to test
> the wxwidgets IPC methods on a native Windows platform, I have a
> number of IPC build system and code changes in mind.
>
> If you have looked at the code at all now, you can see it is a bit of
> a complex #ifdef thicket that is therefore hard to understand by
> definition.  But (see cmake/modules/wxwidgets.cmake) the macro
> PL_HAVE_UNNAMED_POSIX_SEMAPHORES is permanently disabled.  That
> disablement (done several months ago) is because although the #ifdef
> PL_HAVE_UNNAMED_POSIX_SEMAPHORES code stanzas currently work in the
> Linux case, they are superseded by the named semaphores approach that
> works for all POSIX platforms including Linux. So my first order of
> business is to follow up on that permanent disablement by
> removing all #ifdef PL_HAVE_UNNAMED_POSIX_SEMAPHORES code stanzas
> (and, in fact, all references to PL_HAVE_UNNAMED_POSIX_SEMAPHORES in
> our source tree) to reduce the #ifdef complexity of the IPC code.
>
> Also, if you look at cmake/modules/wxwidgets.cmake you will see the
> macro PL_WXWIDGETS_IPC3 is permanently enabled.  My second order of
> business is to turn that temporarily back into an option which will be
> ON by default.  The old IPC code that is enabled when that option is
> turned OFF by the user used to work OK on both Windows and Linux.  So
> turning this temporarily back into an option should allow us to test
> both -DPL_WXWIDGETS_IPC3 ON and OFF on both Linux and Windows.
> Previously -DPL_WXWIDGETS_IPC3 OFF worked OK on both the Linux
> platform and the native Windows MSVC platform so my guess is it should
> also work on MinGW-w64/MSYS2 to provide a benchmark to test how well
> -DPL_WXWIDGETS_IPC3 ON works on that platform.  And ultimately once we
> make the code corrections so that -DPL_WXWIDGETS_IPC3 ON builds and
> runs fine on that native Windows platform, I intend to remove all
> the "old" IPC code that is used when -DPL_WXWIDGETS_IPC3 OFF in the
> interests of reducing complexity.
>
> @Phil: your participation in these proposed IPC tests in the MSVC case
> (or any platform you can get your hands on) would be most welcome. And
> if you could let Arjen know your source of reliable wxwidgets
> libraries for the MSVC case, that would be most welcome as well.
>
> More later...

To Arjen and Phil:

I have now made these 4 additional wxwidgets-related commits:

2bc0626 IPC for wxwidgets: Reenable the PL_WXWIDGETS_IPC3 option
e07d5e5 IPC for wxwidgets: Purge PL_HAVE_UNNAMED_POSIX_SEMAPHORES
2faff23 IPC for wxwidgets: Fix use of WIN32 and PL_WXWIDGETS_IPC3 preprocessor macros
8fd52f8 Build System: Implement the PAUSE_CERTAIN_INTERACTIVE_DEVICES option

2faff23 is the most important one and fixes and obvious preprocessor
bug in the code that should likely sort out the build issue that Arjen
found.

With these changes, the IPC code now has been reduced to either using the 3 named
semaphores approach (-DPL_WXWIDGETS_IPC3=ON) to communicate between
wxPLViewer and -dev wxwidgets or the old version of the IPC code that
used one named semaphore + a circular buffer (-DPL_WXWIDGETS_IPC3=OFF)
to communicate between wxPLViewer and -dev wxwidgets.  So please test
both the default -DPL_WXWIDGETS_IPC3=ON and the
-DPL_WXWIDGETS_IPC3=OFF cases (as I have just done for Linux).

@Arjen: if the above fix solves the build issue you found on
MinGW-w64/MSYS2 and run-time results for the test_c_wxwidgets target
look good for -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON, please follow up
with a comprehensive test report on that platform for just wxwidgets
which you should be able to obtain (without
-DPAUSE_CERTAIN_INTERACTIVE_DEVICES set to avoid interactive pain) as
follows (subject to any additional script parameters you need to set for the
MinGW-w64/MSYS2 platform):

scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON" --do_test_noninteractive no --do_ctest no

I just tried the above command on Linux (Debian Jessie), and obtained
complete success in a relatively short amount of time (~15 minutes).

@Phil and Arjen:

A similar comprehensive test of wxwidgets on the MSVC platform would be useful as well.

@Those with access to Mac OS X:

A similar comprehensive test of wxwidgets on Mac OS X would be useful 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] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi Alan,



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



Regards,



Arjen



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

> To Arjen and Phil:
>
> Actually, I think the simpleness of that condition should be fine on MinGW-
> w64/MSYS2.  After all, in that case you are building a native Windows version of
> PLplot where everything inside the #ifdef WIN32 stanzas should be available.
>
> Also now that I have finally found a partner who is willing to test the wxwidgets IPC
> methods on a native Windows platform, I have a number of IPC build system and
> code changes in mind.
>
> If you have looked at the code at all now, you can see it is a bit of a complex #ifdef
> thicket that is therefore hard to understand by definition.  But (see
> cmake/modules/wxwidgets.cmake) the macro
> PL_HAVE_UNNAMED_POSIX_SEMAPHORES is permanently disabled.  That
> disablement (done several months ago) is because although the #ifdef
> PL_HAVE_UNNAMED_POSIX_SEMAPHORES code stanzas currently work in the
> Linux case, they are superseded by the named semaphores approach that works
> for all POSIX platforms including Linux. So my first order of business is to follow up
> on that permanent disablement by removing all #ifdef
> PL_HAVE_UNNAMED_POSIX_SEMAPHORES code stanzas (and, in fact, all
> references to PL_HAVE_UNNAMED_POSIX_SEMAPHORES in our source tree) to
> reduce the #ifdef complexity of the IPC code.
>
> Also, if you look at cmake/modules/wxwidgets.cmake you will see the macro
> PL_WXWIDGETS_IPC3 is permanently enabled.  My second order of business is
> to turn that temporarily back into an option which will be ON by default.  The old
> IPC code that is enabled when that option is turned OFF by the user used to work
> OK on both Windows and Linux.  So turning this temporarily back into an option
> should allow us to test both -DPL_WXWIDGETS_IPC3 ON and OFF on both Linux
> and Windows.
> Previously -DPL_WXWIDGETS_IPC3 OFF worked OK on both the Linux platform
> and the native Windows MSVC platform so my guess is it should also work on
> MinGW-w64/MSYS2 to provide a benchmark to test how well
> -DPL_WXWIDGETS_IPC3 ON works on that platform.  And ultimately once we
> make the code corrections so that -DPL_WXWIDGETS_IPC3 ON builds and runs
> fine on that native Windows platform, I intend to remove all the "old" IPC code that
> is used when -DPL_WXWIDGETS_IPC3 OFF in the interests of reducing
> complexity.
>
> @Phil: your participation in these proposed IPC tests in the MSVC case (or any
> platform you can get your hands on) would be most welcome. And if you could let
> Arjen know your source of reliable wxwidgets libraries for the MSVC case, that
> would be most welcome as well.
>
> More later...
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux
> Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

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

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

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

Hi Alan,



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



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



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



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



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

Instead I commented out the include statement.



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



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



Regards,



Arjen

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

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

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

On 2017-06-20 13:18-0000 Arjen Markus wrote:

>> From the error message above, something is obviously wrong with the build for that
>> case, but it likely is something very simple (e.g., likely a missing #ifdef WIN32
>> section inside an existing #ifdef
>> PL_WXWIDGETS_IPC3 section in drivers/wxwidgets_comms.h) that I forgot to do
>> with those three-semaphore changes for the Windows case.  So if you don't beat
>> me to a solution, I will take a look at finding this Windows build fix for wxwidgets
>> starting ~8 hours or so from now after I get some sleep.
>>
> Hm, it seems to be due to the simpleness of the condition: #ifdef WIN32 - quite probably this is defined for MinGW-w64/MSYS2 to indicate that the platform is "Windowy". So a refinement is required. I will see what I can do here.

To Arjen and Phil:

Actually, I think the simpleness of that condition should be fine on
MinGW-w64/MSYS2.  After all, in that case you are building a native
Windows version of PLplot where everything inside the #ifdef WIN32
stanzas should be available.

Also now that I have finally found a partner who is willing to test
the wxwidgets IPC methods on a native Windows platform, I have a
number of IPC build system and code changes in mind.

If you have looked at the code at all now, you can see it is a bit of
a complex #ifdef thicket that is therefore hard to understand by
definition.  But (see cmake/modules/wxwidgets.cmake) the macro
PL_HAVE_UNNAMED_POSIX_SEMAPHORES is permanently disabled.  That
disablement (done several months ago) is because although the #ifdef
PL_HAVE_UNNAMED_POSIX_SEMAPHORES code stanzas currently work in the
Linux case, they are superseded by the named semaphores approach that
works for all POSIX platforms including Linux. So my first order of
business is to follow up on that permanent disablement by
removing all #ifdef PL_HAVE_UNNAMED_POSIX_SEMAPHORES code stanzas
(and, in fact, all references to PL_HAVE_UNNAMED_POSIX_SEMAPHORES in
our source tree) to reduce the #ifdef complexity of the IPC code.

Also, if you look at cmake/modules/wxwidgets.cmake you will see the
macro PL_WXWIDGETS_IPC3 is permanently enabled.  My second order of
business is to turn that temporarily back into an option which will be
ON by default.  The old IPC code that is enabled when that option is
turned OFF by the user used to work OK on both Windows and Linux.  So
turning this temporarily back into an option should allow us to test
both -DPL_WXWIDGETS_IPC3 ON and OFF on both Linux and Windows.
Previously -DPL_WXWIDGETS_IPC3 OFF worked OK on both the Linux
platform and the native Windows MSVC platform so my guess is it should
also work on MinGW-w64/MSYS2 to provide a benchmark to test how well
-DPL_WXWIDGETS_IPC3 ON works on that platform.  And ultimately once we
make the code corrections so that -DPL_WXWIDGETS_IPC3 ON builds and
runs fine on that native Windows platform, I intend to remove all
the "old" IPC code that is used when -DPL_WXWIDGETS_IPC3 OFF in the
interests of reducing complexity.

@Phil: your participation in these proposed IPC tests in the MSVC case
(or any platform you can get your hands on) would be most welcome. And
if you could let Arjen know your source of reliable wxwidgets
libraries for the MSVC case, that would be most welcome as well.

More later...

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

Hi Alan,



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

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

Regards,

Arjen





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

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

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

On 2017-06-20 06:37-0000 Arjen Markus wrote:

> Hi everyone,
>
>
>
> I made a small adjustment to the FindwxWidgets.cmake file so that it would properly recognise the installation of wxWidgets under MinGW-w64/MSYS2. CMake was happy with it, but when I tried building PLplot, I got a compiler error:
>
>
>
> Scanning dependencies of target wxwidgets
>
> [ 18%] Building CXX object drivers/CMakeFiles/wxwidgets.dir/wxwidgets.cpp.obj
>
> In file included from D:/plplot-svn/plplot-git/drivers/wxwidgets.h:28:0,
>
>                 from D:/plplot-svn/plplot-git/drivers/wxwidgets.cpp:41:
>
> D:/plplot-svn/plplot-git/drivers/wxwidgets_comms.h: In member function 'void PLMemoryMap::initializeSemaphoresToValid(const char*)':
>
> D:/plplot-svn/plplot-git/drivers/wxwidgets_comms.h:219:64: error: 'm_threeSemaphores' was not declared in this scope
>
>     void initializeSemaphoresToValid( const char *baseName ) { m_threeSemaphores.initializeToValid( baseName ); }
>
>                                                                ^~~~~~~~~~~~~~~~~
>
> make[2]: *** [drivers/CMakeFiles/wxwidgets.dir/build.make:64: drivers/CMakeFiles/wxwidgets.dir/wxwidgets.cpp.obj] Error 1
>
> make[1]: *** [CMakeFiles/Makefile2:3396: drivers/CMakeFiles/wxwidgets.dir/all] Error 2
>
> make: *** [Makefile:161: all] Error 2
>
> Can anyone shed some light on this problem? I am not at all familiar with the code.

In general, many small focussed commits (each with a good commit message) are
better than one massive commit.  So please go ahead and commit your
change to cmake/modules/FindwxWidgets.cmake immediately.  Is there also
a Tcl change you are holding back from committing?  If so, please
make a separate commit for that as well.

To answer your question, anything to do with three semaphores involves
my "new" wxwidgets IPC code that I finished several months ago.  That
code works well on Linux, but my request to Phil to test that code on
Windows at that time must have gotten lost in his e-mail stack for
PLplot. So thanks very much for this first Windows test of my code!

>From the error message above, something is obviously wrong with the
build for that case, but it likely is something very simple (e.g.,
likely a missing #ifdef WIN32 section inside an existing #ifdef
PL_WXWIDGETS_IPC3 section in drivers/wxwidgets_comms.h) that I forgot
to do with those three-semaphore changes for the Windows case.  So if
you don't beat me to a solution, I will take a look at finding this
Windows build fix for wxwidgets starting ~8 hours or so from now after
I get some sleep.

Best wishes,

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] Problem with wxWidgets under MinGW-w64/MSYS2

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

Hi everyone,



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



Scanning dependencies of target wxwidgets

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

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

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

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

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

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

                                                                ^~~~~~~~~~~~~~~~~

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

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

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

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

Regards,

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

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

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

Hi Alan, Hazen,



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

Regards,

Arjen



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

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

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

On 2017-06-02 11:46-0700 Alan W. Irwin wrote:

> On 2017-06-02 11:52-0400 Hazen Babcock wrote:
>
>> On 06/02/2017 08:40 AM, Arjen Markus wrote:
>>> Hi everyone,
>>> 
>>> I have a simple question regarding PyQt4 on MinGW-w64/MSYS2. I have 
>>> installed the package but when I run Cmake to build PLplot, I get the 
>>> message that pyqtconfig is missing – is this something I need to install 
>>> separately? If so, how? (I have a version for Cygwin, but I do not know if 
>>> that is exactly the same)
>> 
>> Maybe pyqtconfig is part of the sip package?
>
> Hi Arjen:
>
> Finding the software package that contains a particular file is a
> fundamental skill you need to develop for each free software
> distribution such as MinGW-w64/MSYS2. To
> help you develop that skill, I did a google search using the terms
> <msys2 find which package contains file> and found
>
> <https://sourceforge.net/p/msys2/mailman/message/34359435/>
>
>> From that mailing list thread it appears you should be using packfile
> to find uninstalled packages which contain files that you need such as
> pyqtconfig.py.  Note, I did a similar search on Debian (using the
> apt-file command in that case which is NOT available for
> MinGW-w64/MSYS2, but I suspect packfile is roughly equivalent) and
> discovered the answer depends in that case on whether you are using
> python2 (working but deprecated for PLplot needs) or python3
> (recommended for PLplot needs).  You have a similar Python 2 or 3
> choice on MinGW-w64/MSYS2 so you should make that choice before using
> packfile to find other python-related and sip packages that you need
> to install.  Also, I strongly urge you to keep a complete list of the
> package names you need to install both for the purpose of updating the
> package list at https://sourceforge.net/p/plplot/wiki/MinGW-w64-MSYS2/
> and also so that your next complete install snapshot of
> MinGW-w64/MSYS2 can be created with a batch command file in a
> completely automatic way.

Hi Arjen:

Correction: wherever I said "packfile" above should be replaced with
"pkgfile".  (Sorry about that!) Furthermore, if you look at
<https://wiki.archlinux.org/index.php/Pkgfile> it appears that the
pkgfile functionality is now just part of the pacman package. So since
you have pacman automatically installed as part of the base packages,
then my educated guess is the "pkgfile" command should just work with
nothing additional you have to install.

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] PyQt4 on MinGw-w64/MSYS2 - pyqtconfig

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

On 2017-06-02 11:52-0400 Hazen Babcock wrote:

> On 06/02/2017 08:40 AM, Arjen Markus wrote:
>> Hi everyone,
>> 
>> I have a simple question regarding PyQt4 on MinGW-w64/MSYS2. I have 
>> installed the package but when I run Cmake to build PLplot, I get the 
>> message that pyqtconfig is missing – is this something I need to install 
>> separately? If so, how? (I have a version for Cygwin, but I do not know if 
>> that is exactly the same)
>
> Maybe pyqtconfig is part of the sip package?

Hi Arjen:

Finding the software package that contains a particular file is a
fundamental skill you need to develop for each free software
distribution such as MinGW-w64/MSYS2. To
help you develop that skill, I did a google search using the terms
<msys2 find which package contains file> and found

<https://sourceforge.net/p/msys2/mailman/message/34359435/>

>From that mailing list thread it appears you should be using packfile
to find uninstalled packages which contain files that you need such as
pyqtconfig.py.  Note, I did a similar search on Debian (using the
apt-file command in that case which is NOT available for
MinGW-w64/MSYS2, but I suspect packfile is roughly equivalent) and
discovered the answer depends in that case on whether you are using
python2 (working but deprecated for PLplot needs) or python3
(recommended for PLplot needs).  You have a similar Python 2 or 3
choice on MinGW-w64/MSYS2 so you should make that choice before using
packfile to find other python-related and sip packages that you need
to install.  Also, I strongly urge you to keep a complete list of the
package names you need to install both for the purpose of updating the
package list at https://sourceforge.net/p/plplot/wiki/MinGW-w64-MSYS2/
and also so that your next complete install snapshot of
MinGW-w64/MSYS2 can be created with a batch command file in a
completely automatic way.

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] PyQt4 on MinGw-w64/MSYS2 - pyqtconfig

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

On 06/02/2017 08:40 AM, Arjen Markus wrote:
> Hi everyone,
> 
> I have a simple question regarding PyQt4 on MinGW-w64/MSYS2. I have 
> installed the package but when I run Cmake to build PLplot, I get the 
> message that pyqtconfig is missing – is this something I need to install 
> separately? If so, how? (I have a version for Cygwin, but I do not know 
> if that is exactly the same)

Maybe pyqtconfig is part of the sip package?

-Hazen

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

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

Hi everyone,



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



Regards,



Arjen



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

[Plplot-devel] Substantial OCaml improvement

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

I have just (commit e2ac60c) finished updating our build system so
that the ocaml binding and examples works reliably for the first time
for the static case (and also the case where the source, build, and
install trees have spaces in their prefixes).

The long-standing PostScript difference issues, i.e.,

ocaml
   Missing examples            :
   Differing graphical output  :  08 16 19 33
   Missing stdout              :
   Differing stdout            :

are still with us and are still a substantial concern.  I am going to
try to fix these issues as my next PLplot priority, but others have
tried and failed at this previously due to lack of experience with
OCaml.  I have that same problem so we will see how far I get.

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] Space in full pathname issues

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

Hi Alan,



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

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

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

Regards,

Arjen

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

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

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

On 2017-05-12 07:30-0000 Arjen Markus wrote:

> [For cmake] I tried the \ variant for incorporating spaces in an option - same result, CMake hangs. However, I have found what it is doing: it writes a file export_plplot.cmake.tmp which contains:
>
> ...
>
> # Compute the installation prefix relative to this file.
>
> get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
>
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
>
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
>
> ... (1.5 GB of such identical messages)
>
> I tried this with the Windows 3.6.2 version as well, that simply works as expected. No problem with a hanging CMake. So it appears to be specific to Cygwin.
>

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

>> Just to make sure what you have encountered is not a quirk for
>> CMake-3.6.2 that has been fixed for 3.7.2, I tried CMake-3.6.2 here (built by me
>> from unpatched source code provided by Kitware using the bootstrap method on
>> Debian Jessie just like I build 3.7.2), and the above experiment worked fine.
>>
>
> I have not tried that method yet - might be an idea indeed. It is just a wee bit more work.

To keep this organized, here is a summary of what you have discovered
so far:

(1) You have an infinite loop for any version of a "spaced" install prefix for the
Cygwin version of cmake.  I suggest you report that clear bug to the Cygwin
list and see what the response is.

(2) You don't have that infinite loop with the Kitware version of
Windows CMake, but there are find troubles with that version.

So for now (until (1) is solved) you could simply write off this
platform for the "spaced" install prefix case and document that
in our wiki.

However, there is another alternative which is to try an unpatched
CMake version that you have built for yourself on the Cygwin platform.
I believe there is a reasonable chance that experiment would work
since Cygwin does try to be POSIX compatible so the result you get
should be similar to the result I get on Linux which is no infinite
loop bug and CMake find works well.

So assuming you do want to pursue that experiment (once you have more
time) here are my notes on my bootstrap builds for Linux.  Note these
are close to instructions that might appear in a bash script, although
for now I just cut and paste these instructions on the bash command
line.

Note, these instructions assume you have used git clone to establish
a local git repository for CMake in a subdirectory called cmake.git.

______________________________________________________

# Choose whatever version you want to build:
export CMAKE_VERSION=3.8.1
TAG_VERSION=v${CMAKE_VERSION}
export CFLAGS='-O3'
export CXXFLAGS='-O3'

# Use current directory as convenient prefix directory for
# all directories below.
PREFIX_DIRECTORY=$(pwd)

# Update master branch of local repository
cd ${PREFIX_DIRECTORY}/cmake.git
git checkout release
git fetch
git merge --ff-only origin/release

# Optional: Check TAG_VERSION from local updated git repository
git tag --verify ${TAG_VERSION}

# Checkout TAG_VERSION from local updated git repository
git checkout ${TAG_VERSION}
mkdir -p ${PREFIX_DIRECTORY}/build_dir
cd ${PREFIX_DIRECTORY}/build_dir
# Use fresh start every time
rm -rf ${PREFIX_DIRECTORY}/build_dir/* ${PREFIX_DIRECTORY}/install-${CMAKE_VERSION}
nice -19 ${PREFIX_DIRECTORY}/cmake.git/bootstrap \
--prefix=${PREFIX_DIRECTORY}/install-${CMAKE_VERSION} \
--parallel=8 --qt-gui --system-curl  >& bootstrap.out

nice -19 make -j8 >& make.out
nice -19 make -j8 install >& make_install.out

grep -i warning *.out
# N.B. currently there is a warning about COPY_ONLY (which should be
# COPYONLY) in
# /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreMacros.cmake:224.
# That file belongs to qtbase5-dev:amd64 whose version is
# 5.3.2+dfsg-4+deb8u1, but (see
# <https://bugreports.qt.io/browse/QTBUG-44637>) apparently this Qt5
# bug has been fixed in 5.4.1.

grep -i error *.out
# N.B. got errors at this stage until I installed libqt4-dev (and
# qt4-doc and qt4-dev-tools).
cd ${PREFIX_DIRECTORY}
# Optional
rm -f install
ln -s install-${CMAKE_VERSION} install
______________________________________________________

The above search for warnings and errors should guide you on what
additional packages you need to install.  However, from just
eyeballing the above, the git tag --verify command (although that is
optional it is always a good idea to run that command from the
security point of view) requires you to have the Cygwin gnugpg package
installed and you will also need the Cygwin curl development library
package (libcurl-devel) installed.  You likely already have the Cygwin
equivalent of the libqt[45]-dev Debian development package installed
as a PLplot prerequisite so I expect you will only need to install the
qt[45]-devel-tools and qt[45]-doc Cygwin packages in addition to get
rid of all warnings and errors in the above build.

Good luck with the above as a low-priority PLplot item, but for now I
would concentrate first on non-space MinGW-w64/MSYS2 issues (i.e.,
getting all PLplot prerequisites installed and working on that
platform), and getting the comprehensive test script to work on
non-space MSVC (+ MinGW-w64/MSYS2 unix tools) where I believe the
current issue stopping you is simply installing the diff unix tools.
Then once the non-spaced comprehensive testing is working properly on
both those platforms tentatively try the spaced version of the same
with the source, build, and install trees having spaces in their
prefix.

By the way, the status here is I am still far from done with that
"space" experiment on the Linux platform.  I have gotten most
components to work for the non-interactive case which is sufficient to
make it worth your while to try similar experiments on MinGW-w64/MSYS2
and MSVC (once the non-spaced comprehensive tests are working well on
those platforms). However, I am still working on some remaining
noninteractive "space" issues (e.g., an OCaml issue for the static
case, and language support issues for the Ada and D compilers), and I
haven't yet even tried any interactive "space" tests.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

Hi Alan,



See my remarks in context.



Regards,



Arjen



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

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

...

# Compute the installation prefix relative to this file.

get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)

get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)

get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)

... (1.5 GB of such identical messages)

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

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

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

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

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

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

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

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this 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] Space in full pathname issues

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

On 2017-05-09 11:31-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Monday, May 08, 2017 7:18 PM
>>
>> Assuming the form I suggested on Cygwin
>>
>> cmake  .... "-CMAKE_INSTALL_PREFIX=d:/plplot-src/install with spaces"
>>
>> does work there, please check that same form (used by the comprehensive test
>> script) works on this platform as well.
>>

> Unfortunately, it doesn't. CMake gets stuck again - this time I left
it running over lunch and it had made no progress whatsoever when I
came back (except writing lots of bytes according to the task
monitor).

Hi Arjen:

The CMake developers have been notoriously lax concerning how the
cmake command parses its command-line arguments.  So when there is
some error in that parsing you do often get a hang. But I would
strongly advise you when that happens to not let it run more than a
minute or two (i.e., the maximum time that cmake normally takes to
configure PLplot).  After all, with a hang, there is some indefinite
loop happening, and if there are any memory leaks in that loop you
could end up with an out-of-memory error and take down your whole
system!

That said, whatever the quirks in cmake command-line processing,
those quirks should be consistent for a given version of
CMake (unless the guy that packages CMake for Cygwin has applied
a specific patch to have unique command-line processing for the
Cygwin version of CMake which in my opinion would be a huge mistake
on his part.)  Up to now all my space in pathname checking has been
done from the bash shell and for CMake-3.7.2.

To check whether you are also running the bash shell, what is
the result of the "echo $0" command there?  Here it is

software@raven> echo $0
/bin/bash

If you get an empty response or a non-bash response, please switch
to the bash shell for your tests by simply executing the "bash" command.

Just to make sure what you have encountered is not a quirk for
CMake-3.6.2 that has been fixed for 3.7.2, I tried CMake-3.6.2 here
(built by me from unpatched source code provided by Kitware using the
bootstrap method on Debian Jessie just like I build 3.7.2), and the
above experiment worked fine.

For the record, here is what I did (note the CMake constraints to make
this a minimal version of PLplot so those same constraints give you
the highest chance this will also work on your three Windows platforms
including Cygwin assuming you can work around the Cygwin CMake "space"
issue you have discovered. Note the spaces in the prefixes for all of
the source tree, the build tree, and the install tree in this
experiment.

# Create build tree if it did not exist before.
software@raven> mkdir -p /home/software/plplot/HEAD/build_dir\ blank

# Remove contents of build tree (if there are any there) and all of install tree to get a fresh start.
software@raven> rm -rf /home/software/plplot/HEAD/build_dir\ blank/* ~/plplot/installcmake\ blank

# Change directory to (now) empty build tree.
cd /home/software/plplot/HEAD/build_dir\ blank
# Confirm
software@raven> pwd
/home/software/plplot/HEAD/build_dir blank

# Configure minimal PLplot with CMake-3.6.2.
software@raven> /home/software/cmake/install-3.6.2/bin/cmake \
"-DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake blank" \
-DDEFAULT_NO_BINDINGS=ON -DDEFAULT_NO_DEVICES=ON \
"../plplot blank .git" >& cmake.out

# Install
make install >& install.out

A check of cmake.out, install.out and install_manifest.txt all confirm
that the install prefix was consistently
"/home/software/plplot/installcmake blank" on my platform, and you
should get the same result there.

N.B. Please note the exact form above of both -DCMAKE_INSTALL_PREFIX
and the source tree specification in the cmake command and follow that
form for all your experiments. I suggest you stick to this exact order
of arguments as well in case there is some CMake quirk with regard to
that.  If under bash, the above exact form still does not work for
you, please try the Windows native Kitware binary download of
CMake-3.6.2 (note the same version) to see if that works since you
have already had "space" success with a Kitware version of CMake on
MSVC.

If the Kitware version works and the Cygwin one does not on Cygwin for
the above form of the cmake command, then that is a clear bug in the
Cygwin version that you should report to the Cygwin list, and meanwhile
continue with the above experiment using the Kitware version (contrary
to how I have argued before since my assumption was any patches added
by the Cygwin packager would add some value for this platform rather
than introducing a bug).

Of course, if both the Kitware version and Cygwin version of
CMake-3.6.2 fail to work, then I assume the cause is some unknown
Cygwin issue that is likely nothing to do with CMake or the bash
shell.  In which case you really are stuck, and we have to emphasize
in our wiki that blanks in the install prefix are simply not allowed
by the Cygwin platform for unknown reasons.  But hopefully it is just
a bug in the Cygwin version of cmake that can be worked around (until
that bug is fixed) by using the Kitware CMake (or you were using a
slightly different form than above, and in fact both the Kitware CMake
and Cygwin CMake work if you use the exact form above).

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] Space in full pathname issues

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

Hi Alan,



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

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

Regards,

Arjen

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

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

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

On 2017-05-09 09:42-0000 Arjen Markus wrote:

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

The relevant find_program calls (for diff, tail, and cmp) are in
cmake/modules/plplot.cmake.

One preliminary issue is our find of cmp only occurs on Linux, but you
should drop that constraint since I assume that command is available
on all POSIX systems and also Cygwin and MinGW-w64/MSYS2.  But if the
cmp command isn't available, then find_program does the right thing in
any case. The cmp command is significantly faster than the equivalent
combination of tail and diff.  So if cmp is available,
plplot_test/test_diff.sh(.in) uses it rather than tail/diff.

The primary issue, of course, is the one above where our find system
is finding a "subversion" version of diff.  However, if you look at
<https://cmake.org/cmake/help/latest/command/find_program.html>, there
are all sorts of ways to control find_program inside
cmake/modules/plplot.cmake.  For example, our CMake logic could find
tail first (assuming that is not supplied by subversion), then use
HINTS to find cmp and diff by looking in the same directory
as tail was found.  (Or look first for cmp, then follow with the
other two if cmp is the one not supplied by subversion.)

I hope this idea helps, but in any case good luck figuring out how to
change the CMake logic in cmake/modules/plplot.cmake so that the
result is all 3 programmes are found in a consistent directory
(which virtually guarantees that they will be found in the
platform-relevant directory if the user sets the PATH appropriately).

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] Space in full pathname issues

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

Hi Alan,

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

Regards,

Arjen

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