plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Need help with test_extXdrawable target regression introduced by "Fix to the multiple keypress bug on page advance"

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

> On Jul 30, 2015, at 6:36 AM, Jim Dishaw <ji...@di...> wrote:
> 
> 
> 
> 
> 
>>> On Jul 30, 2015, at 3:21 AM, Alan W. Irwin <ir...@be...> wrote:
>>> 
>>> On 2015-07-30 01:08-0400 Jim Dishaw wrote:
>>> 
>>> 
>>>> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <ir...@be...> wrote:
>>>> 
>>>> Hi Jim:
>>>> 
>>>> I have just discovered the regression mentioned by the subject line.
>>>> 
>>>> My apologies for not spotting this issue earlier in the release cycle.
>>>> I guess I did all sorts of spot checking after your multiple keypress
>>>> changes to make sure the cairo device driver built and ran without
>>>> issues, but I did not test all cairo capabilities like a simple build
>>>> of the test_interactive target (which caught this problem now) would
>>>> have done at the time.
>> 
>>> The interesting thing is that at least one of the sources for the
>> error message is in the plD_init_xcairo() function. The XInternAtom()
>> call generates some of the messages.  Furthermore, the XCloseDisplay()
>> in plD_tidy_xcairo() generates the error message.  I thought it might
>> be due to a synchronization issue with the X server, so I put an
>> XSync() call to make sure everything was processed in the event queue.
>> Unfortunately, the error “migrated” to the XSync() call.  I then
>> enabled synchronization via XSynchronize() (the sledgehammer
>> approach).  That eliminated some of the runtime error messages.
>> 
>>> I think this bug is a latent problem that has not cropped up
>> earlier.  I am not quite sure of the root cause, but I don’t think
>> 78344df is the cause, rather it exposed the problem.
>> 
>>> I am not familiar enough with the external drawable functionality
>> and, unfortunately, I don’t have time to dig into right now.  If you
>> insert "XSynchronize( aStream->Display, TRUE );” some where after the
>> XOpenDisplay() call, I think that will fix the bug for this release. I will revisit the issue after the weekend.
>> 
>> I inserted the following change (which is what I think you meant
>> by the above suggestion, but please confirm that.
>> 
>> --- a/drivers/cairo.c
>> +++ b/drivers/cairo.c
>> @@ -1995,6 +1995,7 @@ void plD_init_xcairo( PLStream *pls )
>>            plexit( "Failed to open X Windows display\n" );
>>            // some sort of error here
>>        }
>> +       XSynchronize( aStream->XDisplay, TRUE );
>>        XScreen    = DefaultScreen( aStream->XDisplay );
>>        rootWindow = RootWindow( aStream->XDisplay, XScreen );
>> If that is what you had in mind, that change does not seem to affect the ordinary use of xcairo or
>> the results from building the test_extcairo target.  However, building
>> the test_extXdrawable target still generates the same error message,
>> i.e.,
>> 
>> Scanning dependencies of target test_extXdrawable
>> The program 'extXdrawable_demo' received an X Window System error.
>> This probably reflects a bug in the program.
>> The error was 'BadWindow (invalid Window parameter)'.
>> (Details: serial 178 error_code 3 request_code 2 minor_code 0)
>> (Note to programmers: normally, X errors are reported asynchronously;
>>  that is, you will receive the error a while after causing it.
>>  To debug your program, run it with the --sync command line
>>  option to change this behavior. You can then get a meaningful
>>  backtrace from your debugger if you break on the gdk_x_error() function.)
>> make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
>> make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
>> make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
>> make: *** [test_extXdrawable] Error 2
> 
> That patch fixes the problem when PLPlot is creating the window. Try adding one more inside the "then" case at line 1983. 

Oops, that won't work. I think the only solution right now is to roll back the patch. 

> 
>> Jim, since the above idea does not appear to work do you see any issue
>> with instead reverting your changes just for the cairo device driver
>> using the attached patch?
>> 
>> That patch is, of course, just a temporary measure until you can look
>> in more detail at this whole problem post-release, but it does seem to
>> give good results for all of the test_c_xcairo, test_extcairo, and
>> test_extXdrawable targets consistent with what we had before for 5.11.0.
>> 
> That would work and we wouldn't be any worse off then we were before. 
> 
>> 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
>> __________________________
>> <cairo.patch.gz>
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Need help with test_extXdrawable target regression introduced by "Fix to the multiple keypress bug on page advance"

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

> On Jul 30, 2015, at 3:21 AM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-07-30 01:08-0400 Jim Dishaw wrote:
>> 
>> 
>>> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <ir...@be...> wrote:
>>> 
>>> Hi Jim:
>>> 
>>> I have just discovered the regression mentioned by the subject line.
>>> 
>>> My apologies for not spotting this issue earlier in the release cycle.
>>> I guess I did all sorts of spot checking after your multiple keypress
>>> changes to make sure the cairo device driver built and ran without
>>> issues, but I did not test all cairo capabilities like a simple build
>>> of the test_interactive target (which caught this problem now) would
>>> have done at the time.
> 
>> The interesting thing is that at least one of the sources for the
> error message is in the plD_init_xcairo() function. The XInternAtom()
> call generates some of the messages.  Furthermore, the XCloseDisplay()
> in plD_tidy_xcairo() generates the error message.  I thought it might
> be due to a synchronization issue with the X server, so I put an
> XSync() call to make sure everything was processed in the event queue.
> Unfortunately, the error “migrated” to the XSync() call.  I then
> enabled synchronization via XSynchronize() (the sledgehammer
> approach).  That eliminated some of the runtime error messages.
> 
>> I think this bug is a latent problem that has not cropped up
> earlier.  I am not quite sure of the root cause, but I don’t think
> 78344df is the cause, rather it exposed the problem.
> 
>> I am not familiar enough with the external drawable functionality
> and, unfortunately, I don’t have time to dig into right now.  If you
> insert "XSynchronize( aStream->Display, TRUE );” some where after the
> XOpenDisplay() call, I think that will fix the bug for this release. I will revisit the issue after the weekend.
> 
> I inserted the following change (which is what I think you meant
> by the above suggestion, but please confirm that.
> 
> --- a/drivers/cairo.c
> +++ b/drivers/cairo.c
> @@ -1995,6 +1995,7 @@ void plD_init_xcairo( PLStream *pls )
>             plexit( "Failed to open X Windows display\n" );
>             // some sort of error here
>         }
> +       XSynchronize( aStream->XDisplay, TRUE );
>         XScreen    = DefaultScreen( aStream->XDisplay );
>         rootWindow = RootWindow( aStream->XDisplay, XScreen );
> If that is what you had in mind, that change does not seem to affect the ordinary use of xcairo or
> the results from building the test_extcairo target.  However, building
> the test_extXdrawable target still generates the same error message,
> i.e.,
> 
> Scanning dependencies of target test_extXdrawable
> The program 'extXdrawable_demo' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadWindow (invalid Window parameter)'.
>  (Details: serial 178 error_code 3 request_code 2 minor_code 0)
>  (Note to programmers: normally, X errors are reported asynchronously;
>   that is, you will receive the error a while after causing it.
>   To debug your program, run it with the --sync command line
>   option to change this behavior. You can then get a meaningful
>   backtrace from your debugger if you break on the gdk_x_error() function.)
> make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
> make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
> make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
> make: *** [test_extXdrawable] Error 2

That patch fixes the problem when PLPlot is creating the window. Try adding one more inside the "then" case at line 1983. 

> Jim, since the above idea does not appear to work do you see any issue
> with instead reverting your changes just for the cairo device driver
> using the attached patch?
> 
> That patch is, of course, just a temporary measure until you can look
> in more detail at this whole problem post-release, but it does seem to
> give good results for all of the test_c_xcairo, test_extcairo, and
> test_extXdrawable targets consistent with what we had before for 5.11.0.
> 
That would work and we wouldn't be any worse off then we were before. 

> 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
> __________________________
> <cairo.patch.gz>

Re: [Plplot-devel] Need help with test_extXdrawable target regression introduced by "Fix to the multiple keypress bug on page advance"

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

On 2015-07-30 01:08-0400 Jim Dishaw wrote:

>
>> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <ir...@be...> wrote:
>>
>> Hi Jim:
>>
>> I have just discovered the regression mentioned by the subject line.
>>
>> My apologies for not spotting this issue earlier in the release cycle.
>> I guess I did all sorts of spot checking after your multiple keypress
>> changes to make sure the cairo device driver built and ran without
>> issues, but I did not test all cairo capabilities like a simple build
>> of the test_interactive target (which caught this problem now) would
>> have done at the time.
>>
>

> The interesting thing is that at least one of the sources for the
error message is in the plD_init_xcairo() function. The XInternAtom()
call generates some of the messages.  Furthermore, the XCloseDisplay()
in plD_tidy_xcairo() generates the error message.  I thought it might
be due to a synchronization issue with the X server, so I put an
XSync() call to make sure everything was processed in the event queue.
Unfortunately, the error “migrated” to the XSync() call.  I then
enabled synchronization via XSynchronize() (the sledgehammer
approach).  That eliminated some of the runtime error messages.

> I think this bug is a latent problem that has not cropped up
earlier.  I am not quite sure of the root cause, but I don’t think
78344df is the cause, rather it exposed the problem.

> I am not familiar enough with the external drawable functionality
and, unfortunately, I don’t have time to dig into right now.  If you
insert "XSynchronize( aStream->Display, TRUE );” some where after the
XOpenDisplay() call, I think that will fix the bug for this release. 
I will revisit the issue after the weekend.

I inserted the following change (which is what I think you meant
by the above suggestion, but please confirm that.

--- a/drivers/cairo.c
+++ b/drivers/cairo.c
@@ -1995,6 +1995,7 @@ void plD_init_xcairo( PLStream *pls )
              plexit( "Failed to open X Windows display\n" );
              // some sort of error here
          }
+       XSynchronize( aStream->XDisplay, TRUE );
          XScreen    = DefaultScreen( aStream->XDisplay );
          rootWindow = RootWindow( aStream->XDisplay, XScreen );

If that is what you had in mind, that change does not seem to affect the ordinary use of xcairo or
the results from building the test_extcairo target.  However, building
the test_extXdrawable target still generates the same error message,
i.e.,

Scanning dependencies of target test_extXdrawable
The program 'extXdrawable_demo' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
   (Details: serial 178 error_code 3 request_code 2 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() function.)
make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
make: *** [test_extXdrawable] Error 2

Jim, since the above idea does not appear to work do you see any issue
with instead reverting your changes just for the cairo device driver
using the attached patch?

That patch is, of course, just a temporary measure until you can look
in more detail at this whole problem post-release, but it does seem to
give good results for all of the test_c_xcairo, test_extcairo, and
test_extXdrawable targets consistent with what we had before for 5.11.0.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Need help with test_extXdrawable target regression introduced by "Fix to the multiple keypress bug on page advance"

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

> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> Hi Jim:
> 
> I have just discovered the regression mentioned by the subject line.
> 
> My apologies for not spotting this issue earlier in the release cycle.
> I guess I did all sorts of spot checking after your multiple keypress
> changes to make sure the cairo device driver built and ran without
> issues, but I did not test all cairo capabilities like a simple build
> of the test_interactive target (which caught this problem now) would
> have done at the time.
> 

The interesting thing is that at least one of the sources for the error message is in the plD_init_xcairo() function. The XInternAtom() call generates some of the messages.  Furthermore, the XCloseDisplay() in plD_tidy_xcairo() generates the error message.  I thought it might be due to a synchronization issue with the X server, so I put an XSync() call to make sure everything was processed in the event queue.  Unfortunately, the error “migrated” to the XSync() call.  I then enabled synchronization via XSynchronize() (the sledgehammer approach).  That eliminated some of the runtime error messages.

I think this bug is a latent problem that has not cropped up earlier.  I am not quite sure of the root cause, but I don’t think 78344df is the cause, rather it exposed the problem.

I am not familiar enough with the external drawable functionality and, unfortunately, I don’t have time to dig into right now.  If you insert "XSynchronize( aStream->Display, TRUE );” some where after the XOpenDisplay() call, I think that will fix the bug for this release.  I will revisit the issue after the weekend.

> Here is a quick summary of the relevant range of commits that I
> discovered via git bisect:
> 
> software@raven> git log --oneline 78344dfc901e^^^^..78344dfc901e
> 78344df Corrections to the cairo.c file to fix compilation error
> 009fa6b Updated the wingcc driver to reflect the changes for the keypress bug
> 5867959 Fix to the multiple keypress bug on page advance
> 602bb49 Driver documentation: use correct names of files that need updating for new device driver
> 
> If I build the test_extXdrawable target for 602bb49, all is well.  If
> I try that for 5867959 or 009fa6b there are cairo build errors that
> are fixed in 78344df.  Building test_extXdrawable for
> 78344df (or any later commit including master tip) gives the following
> run-time error:
> 
> [100%] Built target test_cairo_dyndriver
> The program 'extXdrawable_demo' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadWindow (invalid Window parameter)'.
>  (Details: serial 178 error_code 3 request_code 2 minor_code 0)
>  (Note to programmers: normally, X errors are reported asynchronously;
>   that is, you will receive the error a while after causing it.
>   To debug your program, run it with the --sync command line
>   option to change this behavior. You can then get a meaningful
>   backtrace from your debugger if you break on the gdk_x_error() function.)
> make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
> make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
> make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
> make: *** [test_extXdrawable] Error 2
> 
> Note for this commit the test_extcairo target builds without issues
> and the output examples/ext-cairo-test.ps from that example has the
> expected plot box.
> 
> Also
> 
> make cairo
> make x01c
> examples/c/x01c -dev xcairo
> 
> works without any run-time issues for this commit.
> 
> So the conclusion is your change only introduced some issue for the
> external X drawable cairo example examples/c/extXdrawable_demo.c and nothing
> else.  So I am hoping only a small change to that demo will fix the
> issue rather than having to do some further core change to PLplot.
> 
> I view this regression as release critical since I don't want to make
> a release where the external X drawable capability of the cairo device
> driver might be compromised. Therefore, I would appreciate your
> solution for this issue as soon as possible, please, since the current
> plan is to release on Saturday.
> 
> If you are having trouble replicating this issue on your Mac OS X box,
> let me know, and I would be happy to run any test on my Linux box that
> might help you figure this out.
> 
> 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] Need help with test_extXdrawable target regression introduced by "Fix to the multiple keypress bug on page advance"

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

Hi Jim:

I have just discovered the regression mentioned by the subject line.

My apologies for not spotting this issue earlier in the release cycle.
I guess I did all sorts of spot checking after your multiple keypress
changes to make sure the cairo device driver built and ran without
issues, but I did not test all cairo capabilities like a simple build
of the test_interactive target (which caught this problem now) would
have done at the time.

Here is a quick summary of the relevant range of commits that I
discovered via git bisect:

software@raven> git log --oneline 78344dfc901e^^^^..78344dfc901e
78344df Corrections to the cairo.c file to fix compilation error
009fa6b Updated the wingcc driver to reflect the changes for the keypress bug
5867959 Fix to the multiple keypress bug on page advance
602bb49 Driver documentation: use correct names of files that need updating for new device driver

If I build the test_extXdrawable target for 602bb49, all is well.  If
I try that for 5867959 or 009fa6b there are cairo build errors that
are fixed in 78344df.  Building test_extXdrawable for
78344df (or any later commit including master tip) gives the following
run-time error:

[100%] Built target test_cairo_dyndriver
The program 'extXdrawable_demo' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
   (Details: serial 178 error_code 3 request_code 2 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() function.)
make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
make: *** [test_extXdrawable] Error 2

Note for this commit the test_extcairo target builds without issues
and the output examples/ext-cairo-test.ps from that example has the
expected plot box.

Also

make cairo
make x01c
examples/c/x01c -dev xcairo

works without any run-time issues for this commit.

So the conclusion is your change only introduced some issue for the
external X drawable cairo example examples/c/extXdrawable_demo.c and nothing
else.  So I am hoping only a small change to that demo will fix the
issue rather than having to do some further core change to PLplot.

I view this regression as release critical since I don't want to make
a release where the external X drawable capability of the cairo device
driver might be compromised. Therefore, I would appreciate your
solution for this issue as soon as possible, please, since the current
plan is to release on Saturday.

If you are having trouble replicating this issue on your Mac OS X box,
let me know, and I would be happy to run any test on my Linux box that
might help you figure this out.

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] wxWidgets Ubuntu bug

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

On 2015-07-29 14:36+0100 Phil Rosenberg wrote:

> HI Alan
> I have looked at the Ubuntu bug and have found the issue. I thought I
> had removed all instances of creating a wxFont from the driver in the
> console mode side, but I missed one. This causes a crash on wxWidgets
> 3.0 on my Ubuntu machine for every example.
>
> I thought I had created a fix, but it turns out that I have now
> generated a heap corruption, so I need to go back and work out what is
> going on there. In addition the fix is not a trivial one liner. (Once
> I have fixed it) it will end up having knock on effects through the
> wxWidgets text rendering code.
>
> So it is up to you what you think is the best course of action. On one
> hand it is a fairly serious bug to let slip through a release, but on
> the other it only affects a subset of users and if you want only
> trivial changes at this late stage in the cycle then I understand
> that. I would be happy either way.

Hi Phil:

Thanks for that clear overview of the implications of this bug fix. It
does sound like it is non-trivial so my decision is to avoid such a
last-minute change and instead delay pushing this until post-release
so we have a full release cycle to test the effects of this bug fix.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] wxWidgets Ubuntu bug

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

HI Alan
I have looked at the Ubuntu bug and have found the issue. I thought I
had removed all instances of creating a wxFont from the driver in the
console mode side, but I missed one. This causes a crash on wxWidgets
3.0 on my Ubuntu machine for every example.

I thought I had created a fix, but it turns out that I have now
generated a heap corruption, so I need to go back and work out what is
going on there. In addition the fix is not a trivial one liner. (Once
I have fixed it) it will end up having knock on effects through the
wxWidgets text rendering code.

So it is up to you what you think is the best course of action. On one
hand it is a fairly serious bug to let slip through a release, but on
the other it only affects a subset of users and if you want only
trivial changes at this late stage in the cycle then I understand
that. I would be happy either way.

Phil

Re: [Plplot-devel] Plans for the release of 5.11.1

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

On 2015-07-22 22:24-0700 Alan W. Irwin wrote:

> @Phil: how is it going with your bug fix?  The sooner the better,
> please, so we know what sort of fix is required, and whether we should
> put it in the release or wait until post release.  In light of your
> progress do the plans below make sense?
>
> On 2015-07-21 10:22-0700 Alan W. Irwin wrote:
>
>> IMPORTANT.  I am declaring now that a complete freeze on any pushes to
>> our SF repository will be in effect once SF staff restores our
>> repository from their backups and makes it available to us. The reason
>> for this freeze is I need some time to check that restored repository
>> against my local repository using similar extensive checking
>> procedures that I originally used when converting from svn to git.
>
> According to <http://sourceforge.net/blog/> git service is back up so
> I plan to start the detailed checking process early tomorrow
> (Thursday) consisting of comparison of the working directory of my old
> repository at various key release tags with a freshly cloned
> repository.  I also plan to do a detailed comparison of log results
> between the two repositories to make sure those are identical.
>
> Once that checking process is completed I will let you all know here
> and at that point set the release date for about a week later.  So if
> I can get that detailed checking process done in a timely manner (i.e.
> by this weekend) with no issues showing up, then I will plan to
> release 5.11.1 on August 1st (i.e., 10 days from now).
>
> And from the date when the repository check is completed to the
> release date ~1 week later, we will move from the above hard freeze to
> a slightly slushy freeze more typical of the last week before a
> release.  That slightly slushy freeze will still allow substantial
> epa_build and documentation updates, and also no-brainer bug fixes to
> our code with no side effects. However, more complicated bug fixes to
> our code should be discussed/negotiated here before pushing, and, of
> course, merging of major code updates to master are not allowed (since
> those are not allowed in any case after the first month of a release
> cycle).

I have just thoroughly checked (see details in commit id 9b86385) the
git repository that was restored by SF staff after their "great
outage" against my own local repository.  All is well, which should
let us all breathe a huge sigh of relief!

As a result of this git repository testing success, the hard freeze
has now been changed to the slightly slushy freeze described above,
and I have pushed the 5 commits I had accumulated since this SF outage
started (all of which qualify under the above slighly slushy freeze
rules). Phil has not yet responded to the important question above so
I assume his bug-fix progress has been slow, and therefore, unless I
hear further objections from him or anyone else here who would really
like to get their completed bug fix into this release, I plan to go
ahead with the release of PLplot-5.11.1 on Saturday, August 1st.

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] multi platform configurations in a Windows system

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

Does that C:/msys64 prefix contain both the 32-bit MinGW-w64/MSYS2 and
64-bit MinGW-w64/MSYS2 that can be installed with the MSYS2 pacman
installer?  And assuming the answer is yes, is there a different
extension to that prefix for the 32-bit case versus the 64-bit case,
and is 32-bit and 64-bit MinGW-w64/MSYS2 _all_ that the overall
C:/msys64 prefix contains?


C:/msys64 is "mounted" (ala msys-2.0.dll) as "/" and so it also contains
/usr, /lib, /etc for the bash/posix "msys".   It is also host to the .bat
files that initiate
the bash shell.
greg@linux-gc09:/home/bld/gdl> ls -l /c/msys64
total 28398
-rwxrwxrwx 2 root root       68 Nov  7  2014 autorebase.bat
-rwxrwxrwx 2 root root      974 Nov 15  2014 components.xml
drwxrwxrwx 1 root root        0 Nov 15  2014 dev
-rwxrwxrwx 1 root root      541 Apr  7 00:54 dir
drwxrwxrwx 1 root root     8192 Jul 17 17:36 etc
drwxrwxrwx 1 root root     4096 Feb  2 14:06 home
-rwxrwxrwx 2 root root     7470 Jan 25 14:02 InstallationLog.txt
-rwxrwxrwx 2 root root  1661045 Nov 15  2014 maintenancetool.dat
-rwxrwxrwx 2 root root 27323952 Nov 15  2014 maintenancetool.exe
-rwxrwxrwx 2 root root     3515 Jan 25 14:01 maintenancetool.ini
drwxrwxrwx 1 root root     4096 Jul 14 12:17 mingw32
-rwxrwxrwx 2 root root     1265 Apr 26 03:32 mingw32_shell.bat
drwxrwxrwx 1 root root     4096 Apr  7 00:59 mingw64
-rwxrwxrwx 2 root root     1265 Apr 26 03:32 mingw64_shell.bat
-rwxrwxrwx 1 root root    25758 Apr 26 03:32 msys2.ico
-rwxrwxrwx 2 root root     1258 Jul 17 14:49 msys2_shell.bat
-rwxrwxrwx 1 root root      362 Jan 25 14:01 network.xml
drwxrwxrwx 1 root root        0 Apr  5 13:17 opt
lrwxrwxrwx 1 root root      116 Jan 31 12:03 opt32 ->
/c/.NTFS-3G/D:/mingw/opt32-psxdw2/
lrwxrwxrwx 1 root root      116 Jan 31 11:56 opt64 ->
/c/.NTFS-3G/D:/mingw/opt64-psxseh/
drwxrwxrwx 1 root root        0 Apr  7 00:59 $Recycle.Bin
drwxrwxrwx 1 root root        0 Jan  5  2015 retired
lrwxrwxrwx 1 root root       80 Apr 26 03:32 tmp ->
/c/.NTFS-3G/D:/temp/msys2
drwxrwxrwx 1 root root     4096 Jul 14 14:57 usr
lrwxrwxrwx 1 root root       68 Jan 18 03:14 usrbin -> /c/usr/bin
drwxrwxrwx 1 root root     4096 Nov 15  2014 var
-rwxrwxrwx 1 root root        0 Mar 27 22:33 x01c_.txt

The directory links, opt32 and op64, shown above are NTFS directory links
which
Linux can't negotiate.  The other directory link, usrbin, is an NTFS
junction, which behaves much more like a simple directory in windows.
 opt32 and opt64 hold a repository of my libraries, augmenting the standard
collections in /mingw32/ or /mingw64/:

greg@linux-gc09:/c/msys64> ls /d/mingw/opt32-psxdw2/
bin  cmake  include  lib  share  testfile.x

The three .bat files are nearly identical except for the MSYSTEM setting
which will be used in /etc/profile to set up the environment:
greg@linux-gc09:/home/bld/gdl> diff /c/msys64/msys2_shell.bat
/c/msys64/mingw32_shell.bat
25c25
< set MSYSTEM=MSYS
---
> set MSYSTEM=MINGW32
27c27
< set MSYS=winsymlinks:nativestrict
---
> rem set MSYS=winsymlinks:nativestrict
44c44
< start console -t "MSys2" -r "%*"
---
> start console -t "MinGW" -r "%*"


Please clarify the various shells and their sources.  For example,
could you confirm that the cygwin shell comes from your Cygwin platform
installation, and the mingw.org/msys-1 shell from your MinGW/MSYS
installation?

There are similar bat scripts that start up cygwin64, in the cygwin
location,
and for msys-1 (mingw.org) in its location.  Each of these is executed from
a desktop link associated with a command shell, or via an entry in the
"start menu".

I don't think cygwin1.dll has anything to do with MSYS2.  So I assume
> you meant cygwin1.dll for Cygwin, but please confirm that.
>
>
> Confirmed

>
> < etc. anything you think you need>
>

That last line concerns me since the primary motivation for these
comprehensive tests is to help other Cygwin, MinGW/MSYS, and
MinGW-w64/MSYS2 users with PLplot.  So you should establish the firm


  The biggest messes are usually coming from the underlying windows system,
I've had troubles because the env variables "SHELL" and "PATH_SEPARATOR"
have been set by installations without my knowledge, blocking proper
operation.


> Also, in the past you have said your MinGW-w64/MSYS2 installation
> provides 3 shells.  Was that a mistake, and the MSYS one you referred
> to was actually from your MinGW/MSYS installation, and the two others
> from your separate installs of 32-bit MinGW-w64/MSYS2 and 64-bit
> MinGW-w64/MSYS2?
>
> except for the MSYSTEM environment variable (MSYS || MINGW32 || MINGW64)
they are the same.  I.e. start with MSYS shell (like a cygwin shell) then
add
the compiler tree, with accompanied libs, to the front of the $PATH.  And
adjust other variables (CFLAGS, LDFLAGS) accordingly.

>
>> or, when the MSYS link is used,
>>
>> greg@Homerw7 MSYS ~
>> $ echo $PATH
>>
>> /usr/local/bin:/usr/bin:/bin:/opt64/bin:/c/Windows:/c/Windows/system32:/c/Windows/system32/Wbem:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
>>
>> and finally
>>
>> greg@Homerw7 MINGW64 ~
>
> $ echo $PATH
>>
>> /mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows:/c/Windows/system32:/c/Windows/system32/Wbem:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
>>
>> in cygwin64
>>
>> This table is, of course, completely separated from the mounts in msys2
 but co-existing in Windows 7 without clashes.

> greg@Homerw7 ~
>> $ mount
>> E:/MinGW/sources on /sources type ntfs (binary)
>> E:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
>> E:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
>> E:/cygwin64 on / type ntfs (binary,auto)
>> C: on /c type ntfs (binary,posix=0,user,noumount,auto)
>> D: on /d type ntfs (binary,posix=0,user,noumount,auto)
>> E: on /e type ntfs (binary,posix=0,user,noumount,auto)
>> F: on /f type ntfs (binary,posix=0,user,noumount,auto)
>>
>> $  echo $PATH
>>
>> /opt/local/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/system32:/c/Windows:/c/Windows/Wbem
>>
>>

>
>> ===========================================================
>>   How 32- and 64-bit programs can run.
>>
>
> If my working hypothesis above is correct that the shells
> actually present on your system are
>
> 1. The Cygwin shell you get from 64-bit Cygwin installation.
>
> 2. The MSYS shell you get from MinGW/MSYS installation.
>
> 3. The MSYS2 shell you get from 32-bit MinGW-w64/MSYS2 installation.
>
> 4. The MSYS2 shell you get from 64-bit MinGW-w64/MSYS2 installation.
>
> 3. The MSYS2 shell you get from MSYS2 installation.
 Mine happens to be 64-bit but there is a 32-bit version, which it may as
well have been - its an irrelevant detail because plplot will not be built
for msys, but for MingW.
shell #2 can also host a Mingw-w64: in fact mine is one. and shell#2 can
also be
configured to host an x86_64- compiler version.  MSYS2 can also be set up
to operate the mingw of shell#2.

  Although you can call it a different shell, MINGW32 or MINGW64 is
identical to MSYS2 with one extra directory inserted into the path.


greg@linux-gc09:/c/msys64> ls usr/lib

automode.o          gettext        libbfd.a      libltdl.a
libpython2.7.dll.a  libyasm.a  ssh
awk                 gio            libbinmode.a  libltdl.dll.a
libresolv.a         man-db     tar
binmode.o           git-core       libc.a        libm.a          librt.a
          openssl    terminfo
cpp.exe             gnupg          libdl.a       libmagic.dll.a
 libtextmode.a       p11-kit    textmode.o
crt0.o              groff          libfl.a       libmsys-2.0.a
libtextreadmode.a   perl5      textreadmode.o
default-manifest.o  guile          libfl_pic.a   libopcodes.a    libtz.a
          pkcs11     tmpfiles.d
gawk                help2man       libg.a        libopts.a
libunrar.dll.a      pkgconfig  w32api
gcc                 libalpm.a      libgmon.a     libopts.dll.a   libutil.a
          python2.7
gcrt0.o             libautomode.a  libiberty.a   libpthread.a    liby.a
         python3.4

greg@linux-gc09:/c/msys64> ls usr/lib/gcc
x86_64-pc-msys
greg@linux-gc09:/c/msys64> ls /mingw32/lib/gcc
ls: cannot access /mingw32/lib/gcc: No such file or directory
greg@linux-gc09:/c/msys64> ls mingw32/lib/gcc
i686-w64-mingw32
greg@linux-gc09:/c/msys64> ls mingw64/lib/gcc
x86_64-w64-mingw32
greg@linux-gc09:/c/msys64>


Add to that the packages


greg@linux-gc09:/c/msys64> ls mingw64

bin  bsd-xdr-mingw64  doc  etc  include  lib
  locale  share  ssl  x86_64-w64-mingw32

greg@linux-gc09:/c/msys64> ls mingw32

bin  cmake.org.html  etc  i686-w64-mingw32
  include  lib  share  ssl  var


>

Re: [Plplot-devel] Plans for the release of 5.11.1

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

@Phil: how is it going with your bug fix?  The sooner the better,
please, so we know what sort of fix is required, and whether we should
put it in the release or wait until post release.  In light of your
progress do the plans below make sense?

On 2015-07-21 10:22-0700 Alan W. Irwin wrote:

> IMPORTANT.  I am declaring now that a complete freeze on any pushes to
> our SF repository will be in effect once SF staff restores our
> repository from their backups and makes it available to us. The reason
> for this freeze is I need some time to check that restored repository
> against my local repository using similar extensive checking
> procedures that I originally used when converting from svn to git.

According to <http://sourceforge.net/blog/> git service is back up so
I plan to start the detailed checking process early tomorrow
(Thursday) consisting of comparison of the working directory of my old
repository at various key release tags with a freshly cloned
repository.  I also plan to do a detailed comparison of log results
between the two repositories to make sure those are identical.

Once that checking process is completed I will let you all know here
and at that point set the release date for about a week later.  So if
I can get that detailed checking process done in a timely manner (i.e.
by this weekend) with no issues showing up, then I will plan to
release 5.11.1 on August 1st (i.e., 10 days from now).

And from the date when the repository check is completed to the
release date ~1 week later, we will move from the above hard freeze to
a slightly slushy freeze more typical of the last week before a
release.  That slightly slushy freeze will still allow substantial
epa_build and documentation updates, and also no-brainer bug fixes to
our code with no side effects. However, more complicated bug fixes to
our code should be discussed/negotiated here before pushing, and, of
course, merging of major code updates to master are not allowed (since
those are not allowed in any case after the first month of a release
cycle).

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] Octave 4.0.0

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

To Andrew and Orion:

I am handing off the octave-4 segfault issue that is described below
to you guys because I have run out of ideas and you both have more
octave/swig knowledge than I do.  There is a small bit at the end
where I solved all the valgrind reporting problems that were stopping
valgrind analysis, but the extremely simple run-time test of our
octave4 bindings still segfaults (presumably because the octave API
has changed significantly between octave 3 and octave 4), and I don't
know where to start to fix it because the full valgrind report
(attached as plplot_valgrind.out.gz) still isn't helping me very much.
But maybe one of you can figure it out or come up with an additional
octave option to make the valgrind results more useful for diagnosing
whatever the problem is that is causing the segfault.

More below.

On 2015-07-14 00:28-0700 Alan W. Irwin wrote:

> On 2015-07-11 19:27-0700 Alan W. Irwin wrote:
>> [...Y]our build
>> success motivates me to expand the epa_build implementation to see how
>> far I can get with an epa_build of Octave-4.0.0 and patched versions
>> of swig-2 and swig-3.  Assuming I can epa_build all of those, then
>> that would allow me to do the above run-time check here for patched
>> versions of both swig-2 and swig-3, and thus help build the case to
>> get your swig patch (or two variants of that if your patch has to be
>> modified for swig-2) into the next official releases of both swig-2
>> and swig-3.
>
> Hi Orion:
>
> The current status of this effort is I am done with all the relevant
> epa_build configuration, but the result segfaults at run time.
>
> Here is what I have done so far.
>
> 1. Implemented an epa_build of lapack and blas.  ctest of that build
> passed 100 per cent of all the many tests.
>
> 2. Upgraded the epa_build of swig-2.0.11 to swig-3.0.6 with your patch applied.
> The result works well with PLplot for the non-octave case.  For
> example, the swig-generated Python, Lua, and Java bindings all work
> well.
>
> 3. Implemented an epa_build of octave_lite which is octave-4.0.0 with
> all optional components disabled.  This version passes the simple test
>
> octave:1> x=-pi:0.1:pi;
> octave:2> plot(x,sin(x))
> octave:3> exit
>
> with the plot done with the default gnuplot.  However, valgrind of
> that simple test loses control of octave_lite (see below).
>
> 4. epa_built plplot_lite against this octave-lite version with no issues.
>
> 5. However, when I try the above simple test in a directory which
> contains the following file (to enable the PLplot version of plotting)
>
> wine@raven> cat .octaverc
> warning("off","Octave:shadowed-function");
> addpath("/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/bindings/octave/PLplot","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/bindings/octave/PLplot/support","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/bindings/octave/misc","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/build_plplot_lite/examples/octave","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/bindings/octave","/home/wine/newstart/build_script/build_dir-linux/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/bindings/octave/PLplot");
> global pl_automatic_replot
> pl_automatic_replot=1;
>
> where the form of this file has been suggested by bindings/octave/USAGE
>
> the above simple plot test segfaults (where normally with PLplot built
> against octave-3.x.y, this simple test generates a plot using the xwin device).
>
> I would like to do further debugging of this segfault with valgrind,
> but somehow valgrind is losing control of octave_lite so never
> generates any messages after the normal burst of initial messages and
> the commands go the same speed as usual (not the slow speed you
> normally get with valgrind) regardless of whether I use gnuplot
> (without segfault) or the .octaverc trick above to attempt to use
> plplot (with segfault).

That issue had a simple solution; for valgrind to trace octave4 requires
the valgrind option --trace-children=yes.  However, that in turn shows
a very extensive call stack where the number of callers is much larger
than the typical limit of 50 for --num-callers used for older valgrind
versions like provided by Debian wheezy.  Thus, to access a recent
valgrind version that allows --num-callers=500 at maximum, I epa_built
valgrind-3.10.1 (as opposed to Debian wheezy's 3.7.0).  And I generated
valgrind results with the following (wrapped) command:

/home/wine/newstart/build_script/install-linux_buildtools/bin/valgrind
--num-callers=500 --trace-children=yes octave 2>| plplot_valgrind.out

where I did the above simple test of the epa_built octave-4.0.0 in the directory where the above
.octaverc existed.  The segfault occurs and valgrind (as you can see
from the attached plplot_valgrind.out.gz) detects a couple of invalid
reads that presumably caused that segfault.

If I do exactly the same test (except for output file named
gnuplot_valgrind.out in a directory without that .octaverc,
then no segfault occurs, gnuplot plots the plot, and the valgrind
result (attached as gnuplot_valgrind.out.gz) is clean

However, I cannot proceed further than that because
plplot_valgrind.out.gz appears to contain no references to PLplot at
all. So I am completely stuck and handing off to you guys.

In any case, getting PLplot ready for octave4 is obviously
post-release material so my plan for the forthcoming release of 5.11.1
is the -DTRY_OCTAVE4=ON cmake option will remain highly experimental,
and unless the user sets that option our build system will either find
and use octave3 or disable octave altogether.

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] Plans for the release of 5.11.1

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

On 2015-07-21 09:45+0100 Phil Rosenberg wrote:

> Hi Alan
> I have been off email for a while. Sorry, I am just catching up.
> I know it is late in the day wrt your schedule, but there is one bug I would like to get fixed before release. On my Ubuntu machine I get a segfault when using the wxWidgets driver. I think it is related to the string length code.
>
> I don't get the same issue on my centos or Windows builds.

@Everybody:

The actual release date for 5.11.1 which was going to be 4 days from
now is in limbo, i.e., "as soon as possible but currently postponed
mode" due to this long SourceForge outage.  For example, although the
mailing lists finally appear to be working again, code repositories
are still not available.

IMPORTANT.  I am declaring now that a complete freeze on any pushes to
our SF repository will be in effect once SF staff restores our
repository from their backups and makes it available to us. The reason
for this freeze is I need some time to check that restored repository
against my local repository using similar extensive checking
procedures that I originally used when converting from svn to git.
Once that check is complete, I will revert the freeze back to any
epa_build change, or document update is acceptable, but extreme
caution should be used with pushing bug fixes.  And I plan to make the
5.11.1 release roughly one week after that complete freeze is done.

@Phil:

My advice is to find the fix for that bug you have found as soon as
possible.  Then once you know what that fix entails, please make your
case (e.g., no-brainer bug fix with no side effects would be a good
case) for pushing this bug fix to master and therefore into the
forthcoming 5.11.1 release just as soon as the above complete freeze
for checking is done.

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] Testing the "vanilla" MinGW-w64/MSYS2 platform

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

On 2015-07-15 14:24-0700 Greg Jung wrote:

> Here is the "trully vanilla" results.  No additional library paths are
> involved (not even /mingw32/lib).

Hi Greg:

Thanks for this report for the 32-bit ?? MinGW-w64/MSYS2 platform.

To help interpret this report accurately I need the following
additional information from you:

1. Can you confirm you were attempting to test 32-bit MinGW-w64/MSYS2?

2. In shared/build_tree/CMakeCache.txt there are a number of different
path prefixes in use.  Could you please state the origin of
the ones I list below or confirm my guess if I have made one?

C:/msys64/mingw32/:            32-bit MinGW-w64/MSYS2?
C:/msys64/opt32/lib:           ????
C:/msys64/usr/:                64-bit MinGW-w64/MSYS2?

Note, Arjen mostly referred to that third prefix and had no references to
the first two prefixes or any other path reference containing "32" so I
am virtually positive he had a pure 64-bit system.  Thus, it appears
to me you have installed a mixture of 32-bit MinGW-w64/MSYS2 and
64-bit MinGW-w64/MSYS2 packages which would not be a good thing to do.

Instead, my advice is to wipe out all of 32-bit MinGW-w64/MSYS2 and
all of of 64-bit MinGW-w64/MSYS2 and proceed thereafter with fresh
installs of both using a unique installation prefix for each of them
so there is no chance of mixing the two.

Here are comments on some of the other files in your report.

====================
I. shared/output_tree/make.out

cd D:/comprehensive_test_disposeable/shared/build_tree/src && C:/msys64/mingw32/bin/gcc.exe  -O2 -mtune=pentium3 -DPLPLOT_HAVE_CONFIG_H
  -Dplplot_EXPORTS -IC:/msys64/mingw32/include  @CMakeFiles/plplot.dir/includes_C.rsp   -DUSINGDLL -o CMakeFiles/plplot.dir/plctrl.c.obj
    -c D:/plplot-gitclone/src/plctrl.c
In file included from D:/plplot-gitclone/src/plcore.c:52:0:
C:/msys64/mingw32/i686-w64-mingw32/include/dirent.h:41:21: error: field 'dd_dta' has incomplete type
   struct _finddata_t dd_dta;
                      ^
C:/msys64/mingw32/i686-w64-mingw32/include/dirent.h:88:22: error: field 'dd_dta' has incomplete type
   struct _wfinddata_t dd_dta;
                       ^

I checked that for both your and Arjen's cases, HAVE_DIRENT_H was
#defined to be 1 so you are both compiling the dirent.h header that is
#included from plcore.c.  However, your compilation lead to the above
build errors for plcore.c, while Arjen's equivalent compilation
had no such issues.  (Note, you should be able to confirm everything I say
by comparing his report with yours and looking at the relevant
src/plcore.c source code.)

I ascribe your problem to the mixture of 32-bit and 64-bit
MinGW-w64/MSYS2 packages you seem to have installed (see above).  Once
you have your pure 32-bit MinGW-w64/MSYS2 platform and your pure
64-bit MinGW-w64/MSYS2 platform installed with unique prefixes so
there is no chance of mixing the two, I predict the problem will go
away for either case.  But if it persists for the pure 32-bit
MinGW-w64/MSYS case, then I would move to the pure 64-bit
MinGW-w64/MSYS2 case which Arjen's build demonstrates does not have
the above problem.
====================
II. comprehensive_test.sh.out:

cmake_added_options=-DENABLE_ada=OFF -DENABLE_octave=OFF

Please do not use -DENABLE_octave=OFF on any platform unless there is
a clear error.  (Arjen had to do this for Cygwin, but I believe I
fixed that error, but the only way my fix can be tested is for further
comprehensive testing not to use this option).

(Also note -DENABLE_ada=OFF is fine for 32-bit or 64-bit
MinGW-w64/MSYS2 because currently that is necessary on all Windows
platforms because of Ada language support limitations for CMake.  But
also note that for Linux (or any other Unix platform) the
-DENABLE_ada=OFF option should be dropped unless there is a
clear error with the Ada component of PLplot.)
====================
III. shared/output_tree/cmake.out

--  MINGWBINPATH = C:/msys64/mingw32/bin
--  include(plplot) coming: CMAKE_GENERATOR=Unix Makefiles. Examine
user-controlled variables:
  CMAKE_LIBRARY_PATH=
  CMAKE_INCLUDE_PATH=

The above is normally not in cmake.out so this means you are using a
modified version of PLplot.  This is harmless if you confine yourself
to just dumping out additional messages like above, but it does add
some uncertainty so it is probably best in future when creating public
reports like this one to simply use unmodified PLplot
for testing.

CMAKE_SYSTEM_NAME:      Windows
UNIX: 
WIN32:                  1
APPLE: 
MSVC:                           (MSVC_VERSION:  )
MINGW:                  1
MSYS:

I must say I am surprised by these variable values for the recommended
combination of MSYS2 version of cmake and "Unix Makefiles" generator
that you are using.  But let's just see how far this recommended combination
takes us for pure 32-bit MinGW-w64/MSYS or pure 64-bit MinGW-w64/MSYS.

-- WARNING: swig not found. Disabling java bindings
-- WARNING: swig not found. Disabling Python bindings

To overcome these issues, install swig with pacman.

There appears to be a package called swig at
<https://github.com/Alexpux/MSYS2-packages/tree/master/>.

There appears to be a package called python at that same location, but that
is no good to us since there is no corresponding numpy package at
that location.

There appears to be packages called mingw-w64-python2 and
mingw-w64-python-numpy at
<https://github.com/msys2/MINGW-packages/tree/master/> so that is the
combination you should install with the pacman installer.

Java and octave packages are not mentioned at the above two sites.

There appears to be a package called mingw-w64-lua at the 2nd site above.

-- WARNING: Disabling Itcl interface code
-- WARNING: Disabling Itk interface code

Itcl and Itk packages are not mentioned at the above two sites.

-- WARNING: SHAPELIB not found.  Setting HAVE_SHAPELIB to OFF.

There appears to be a package called mingw-w64-shapelib at the 2nd site above.

-- WARNING: X windows not found. Setting xcairo driver to OFF.
-- WARNING: X11 not found.  Therefore turning off tk and tkwin devices that depend on it

X is not mentioned at the above two sites.

-- WARNING: pango, pangoft2, or lasi not found with pkg-config.

libLASi not mentioned at the above two sites.

-- WARNING: Suitable Qt4 development environment not found so disabling Qt bindings.

There appears to be a packaged called mingw-w64-qt5 at the second site above.

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

There appears to be a package called mingw-w64-wxwidgets at the second site above.

-- Looking for haru pdf header and library
-- Looking for haru pdf header and library - not found
-- WARNING: Setting PLD_pdf to OFF.

haruis not mentioned at the above two sites.  Sometimes the library
name contains hpdf instead, but that alias also not mentioned at the
above two sites.

-- WARNING:camlidl not found. Disabling ocaml bindings

camlidl not mentioned at the above two sites.

In sum, although MSYS2 has many more packages than MSYS, it apparently
(if the above two sites cover all MSYS2 packages) has fewer than
Cygwin.  To be specific, it appears that packages for Java, octave,
Itcl, Itk, X, libLASi, libharu (a.k.a libhpdf), and camlidl are not
available (assuming the above two URL's cover all possible MSYS2
packages) for MSYS2, but you should be able to install the following
MSYS2 packages to allow testing of more PLplot components: swig,
mingw-w64-python2, mingw-w64-python-numpy, mingw-w64-lua,
mingw-w64-shapelib, mingw-w64-qt5, and mingw-w64-wxwidgets.
====================

Suggestions for the next iteration:

1. Use a pure 32-bit or pure 64-bit MinGW-w64/MSYS2 platform rather
than a mixture.  As mentioned above I believe this will fix the
build-time error concerning dirent.h that you ran into this time.

2. Run

pacman -S \
swig \
mingw-w64-python2 \
mingw-w64-python-numpy \
mingw-w64-lua \
mingw-w64-shapelib \
mingw-w64-qt5 \
mingw-w64-wxwidgets

as per the pacman instructions in
<http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2>.
Note the name of the swig package really does not have that "mingw-w64-"
prefix the other package names have.

3. Use the cmake option -DPLPLOT_USE_QT5=ON which allows you to
build PLplot against Qt5.  The version of Qt in mingw-w64-qt5 is
5.3.1, and I have successfully built PLplot against an epa_built
Qt-5.3.1 and 5.3.2 in the past so I think that mingw-w64-qt5 package
should likely work for you.

Good luck with your next iteration, and let me know how it goes.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive test results for MingW-w64/MSYS2

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

I've re-checked my plplot tree with cygwin which completed the
comprehensive test earlier,
it does not have an issue with the build.

On Tue, Jul 14, 2015 at 10:07 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2015-07-14 18:30-0700 Greg Jung wrote:
>
>  I'm working on it, from my point of view (which includes examining the
>> "installed" perspective).
>> I've had now since I adopted Msys2, a well-working cmake system that
>> applies equally to mingw/msys,
>> mingw32/msys2, and mingw64/msys.  All with the standard cmake executable
>> and with only a few
>> module replacements.
>>
>
> Hi Greg:
>
> I appreciate your willingness to do more testing.  However, I frankly
> am guessing a bit about exactly what you meant above because of your
> notation for the various platforms and possibly a typographical error
> in your notation as well.  The problem with your notation is it is
> inconsistent with the actual properly capitalized names of the
> component projects which are MinGW, MSYS, MinGW-w64, and MSYS2. An
> additional complication is MinGW, and MSYS come only in 32-bit form
> while MinGW-w64, and MSYS2 come in both 32-bit and 64-bit form.  So I
> think the notation for the relevant combinations should be MinGW/MSYS
> for the classical platform you get when you use the MinGW installer
> mentioned in the wiki for the <sf.net/projects/mingw> project and the
> designation 32-bit or 64-bit MinGW-w64/MSYS2 for the platform you get
> when you use the MSYS2 "pacman" installer mentioned in the wiki for
> the <sf.net/projects/msys2> project.
>
> So I assume your mingw/msys is actually MinGW/MSYS, your mingw32/msys2
> is actually 32-bit MinGW-w64/MSYS2, and your mingw64/msys (although
> you probably meant to type mingw64/msys2) is actually 64-bit
> MinGW-w64/MSYS2.
>
> If that assumption is correct, and you really are already testing the
> "vanilla" 64-bit MinGW-w64/MSYS2 platform as defined specifically
> above rather than some variant of that you got from elsewhere which
> likely does not have the popularity and heavy user testing that the
> vanilla version receives, then I am very interested in your
> comprehensive test report for that platform.
>
> As you know it typically takes several iterations to get such test
> reports perfected, but once that is done, and assuming you are still
> game for additional testing, then obtaining a perfected test report
> for the 32-bit version of MinGW-w64/MSYS2 should be worth doing as
> well.  But I strongly suggest you concentrate just on the 64-bit
> version of MinGW-w64/MSYS2 to start with to see how that goes.
>
>
> 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] Testing the "vanilla" MinGW-w64/MSYS2 platform

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

  The same error is blocking mingw64/ and mingw32/ builds:

 =========== from make.out:
         ^
cd D:/comprehensive_test_disposeable/shared/build_tree/src &&
C:/msys64/mingw32/bin/gcc.exe  -O2 -mtune=pentium3 -DPLPLOT_HAVE_CONFIG_H
-Dplplot_EXPORTS -IC:/msys64/mingw32/include
 @CMakeFiles/plplot.dir/includes_C.rsp   -DUSINGDLL -o
CMakeFiles/plplot.dir/plctrl.c.obj   -c D:/plplot-gitclone/src/plctrl.c
In file included from D:/plplot-gitclone/src/plcore.c:52:0:
C:/msys64/mingw32/i686-w64-mingw32/include/dirent.h:41:21: error: field
'dd_dta' has incomplete type
  struct _finddata_t dd_dta;
                     ^
C:/msys64/mingw32/i686-w64-mingw32/include/dirent.h:88:22: error: field
'dd_dta' has incomplete type
  struct _wfinddata_t dd_dta;
                      ^
D:/plplot-gitclone/src/plcore.c: In function 'plInBuildTree':
D:/plplot-gitclone/src/plcore.c:2874:49: warning: comparison between
pointer and integer
         if ( getcwd( currdir, PLPLOT_MAX_PATH ) == NULL )
                                                 ^
D:/plplot-gitclone/src/plcore.c:2887:58: warning: comparison between
pointer and integer
                 if ( getcwd( builddir, PLPLOT_MAX_PATH ) == NULL )

 =========== from make.out:
         ^
[ 38%] Generating x18.tcl
[ 39%] In file included from D:/plplot-gitclone/src/plcore.c:52:0:
C:/msys64/mingw64/x86_64-w64-mingw32/include/dirent.h:41:21: error: field
'dd_dta' has incomplete type
  struct _finddata_t dd_dta;
                     ^
C:/msys64/mingw64/x86_64-w64-mingw32/include/dirent.h:88:22: error: field
'dd_dta' has incomplete type
  struct _wfinddata_t dd_dta;
                      ^
D:/plplot-gitclone/src/plcore.c: In function 'plInBuildTree':
D:/plplot-gitclone/src/plcore.c:2874:49: warning: comparison between
pointer and integer
         if ( getcwd( currdir, PLPLOT_MAX_PATH ) == NULL )
                                                 ^
D:/plplot-gitclone/src/plcore.c:2887:58: warning: comparison between
pointer and integer
                 if ( getcwd( builddir, PLPLOT_MAX_PATH ) == NULL )
                                                          ^
Generating x19.tcl
[ 39%] Generating x20.tcl
src/CMakeFiles/plplot.dir/build.make:223: recipe for target
'src/CMakeFiles/plplot.dir/plcore.c.obj' failed


On Wed, Jul 15, 2015 at 2:24 PM, Greg Jung <gv...@gm...> wrote:

> Here is the "trully vanilla" results.  No additional library paths are
> involved (not even /mingw32/lib).
> To get the mingw32/lib in in a clean fashion I suggest the following lines
> in the if(MINGW) ... endif():
>
> # We need the path to the MinGW/Borland compiler in order to find
> # the import libraries for system libraries.
> if(MINGW)
>   unset(MINGWPATH)
>   get_filename_component(MINGWBINPATH ${CMAKE_C_COMPILER} PATH)
>   message(STATUS " MINGWBINPATH = ${MINGWBINPATH}")
>   find_path( MINGWPATH lib
>    PATHS ${MINGWBINPATH}/../
>    NO_DEFAULT_PATH)
>
>   set(MINGWLIBPATH ${MINGWPATH}/lib
>     CACHE FILEPATH
>     DOCSTRING "Path to MinGW import libraries")
>
>   list( APPEND CMAKE_LIBRARY_PATH ${MINGWPATH}/lib)
>   list( APPEND CMAKE_INCLUDE_PATH
> ${CMAKE_INCLUDE_PATH};${MINGWPATH}/include)
>   list(REMOVE_DUPLICATES CMAKE_LIBRARY_PATH)
>   list(REMOVE_DUPLICATES CMAKE_INCLUDE_PATH)
>
> endif(MINGW)
>
>
>
> On Tue, Jul 14, 2015 at 3:03 PM, Alan W. Irwin <ir...@be...>
> wrote:
>
>> I just now finally found what appear to be definitive CMake
>> instructions (see
>> <http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2>) for
>> the MinGW-w64/MSYS2 platform (only the "vanilla" version as defined by
>> the <sf.net/projects/msys2> wiki rather than some "fixed" version)
>> which I think will interest all those here who are planning to test
>> that platform.  The essential points are you should be using the "Unix
>> Makefiles" generator for the MSYS2 version of CMake for that platform.
>>
>> To expand the last point in more detail you should do the following two
>> steps.
>>
>> 1. Install the MSYS2 version of CMake and other essential
>> software, i.e.,
>>
>> pacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-extra-cmake-modules
>> make pkg-config grep sed gzip tar openssh ...
>>
>> 2. "Important: to use packages that are pre-fixed with "mingw" in
>> their name, you need to start a mingw shell. In your Start menu, you
>> will find entries "MinGW-w64 Win64 Shell". ALWAYS start this shell in
>> the future."
>>
>> I believe these two steps are important for CMake; the closely related
>> Cygwin software demands you use a Cygwin version of CMake so it makes
>> sense there is a similar requirement that the MSYS2 platform demands
>> you use a MSYS2 version of CMake.
>>
>> Arjen's current test of MinGW-w64/MSYS2 uses the (incorrect) "MSYS
>> Makefiles" generator for that platform and also may not be using the
>> correct MSYS2 version of CMake.  So it will be interesting to see (the
>> next time he has a chance to run the test which will probably be
>> several weeks from now) how his results change once he moves to the
>> recommended "Unix Makefiles" generator and the MSYS2 version of CMake.
>>
>> Meanwhile, because the popularity of the MinGW-w64/MSYS2 platform is
>> already large and still rising rapidly, I strongly encourage others
>> here with access to the vanilla version of that platform to try
>> comprehensive testing of that platform using the generator and cmake
>> version recommended by the OpenWalnut software project.
>>
>> 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
>> __________________________
>>
>>
>> ------------------------------------------------------------------------------
>> Don't Limit Your Business. Reach for the Cloud.
>> GigeNET's Cloud Solutions provide you with the tools and support that
>> you need to offload your IT needs and focus on growing your business.
>> Configured For All Businesses. Start Your Cloud Today.
>> https://www.gigenetcloud.com/
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
>

Re: [Plplot-devel] Testing the "vanilla" MinGW-w64/MSYS2 platform

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

Here is the "trully vanilla" results.  No additional library paths are
involved (not even /mingw32/lib).
To get the mingw32/lib in in a clean fashion I suggest the following lines
in the if(MINGW) ... endif():

# We need the path to the MinGW/Borland compiler in order to find
# the import libraries for system libraries.
if(MINGW)
  unset(MINGWPATH)
  get_filename_component(MINGWBINPATH ${CMAKE_C_COMPILER} PATH)
  message(STATUS " MINGWBINPATH = ${MINGWBINPATH}")
  find_path( MINGWPATH lib
   PATHS ${MINGWBINPATH}/../
   NO_DEFAULT_PATH)

  set(MINGWLIBPATH ${MINGWPATH}/lib
    CACHE FILEPATH
    DOCSTRING "Path to MinGW import libraries")

  list( APPEND CMAKE_LIBRARY_PATH ${MINGWPATH}/lib)
  list( APPEND CMAKE_INCLUDE_PATH
${CMAKE_INCLUDE_PATH};${MINGWPATH}/include)
  list(REMOVE_DUPLICATES CMAKE_LIBRARY_PATH)
  list(REMOVE_DUPLICATES CMAKE_INCLUDE_PATH)

endif(MINGW)



On Tue, Jul 14, 2015 at 3:03 PM, Alan W. Irwin <ir...@be...>
wrote:

> I just now finally found what appear to be definitive CMake
> instructions (see
> <http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2>) for
> the MinGW-w64/MSYS2 platform (only the "vanilla" version as defined by
> the <sf.net/projects/msys2> wiki rather than some "fixed" version)
> which I think will interest all those here who are planning to test
> that platform.  The essential points are you should be using the "Unix
> Makefiles" generator for the MSYS2 version of CMake for that platform.
>
> To expand the last point in more detail you should do the following two
> steps.
>
> 1. Install the MSYS2 version of CMake and other essential
> software, i.e.,
>
> pacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-extra-cmake-modules
> make pkg-config grep sed gzip tar openssh ...
>
> 2. "Important: to use packages that are pre-fixed with "mingw" in
> their name, you need to start a mingw shell. In your Start menu, you
> will find entries "MinGW-w64 Win64 Shell". ALWAYS start this shell in
> the future."
>
> I believe these two steps are important for CMake; the closely related
> Cygwin software demands you use a Cygwin version of CMake so it makes
> sense there is a similar requirement that the MSYS2 platform demands
> you use a MSYS2 version of CMake.
>
> Arjen's current test of MinGW-w64/MSYS2 uses the (incorrect) "MSYS
> Makefiles" generator for that platform and also may not be using the
> correct MSYS2 version of CMake.  So it will be interesting to see (the
> next time he has a chance to run the test which will probably be
> several weeks from now) how his results change once he moves to the
> recommended "Unix Makefiles" generator and the MSYS2 version of CMake.
>
> Meanwhile, because the popularity of the MinGW-w64/MSYS2 platform is
> already large and still rising rapidly, I strongly encourage others
> here with access to the vanilla version of that platform to try
> comprehensive testing of that platform using the generator and cmake
> version recommended by the OpenWalnut software project.
>
> 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
> __________________________
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Plans for the release of 5.11.1

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

No objection on my part. I'm working towards the next release. 



> On Jul 15, 2015, at 11:59 AM, Alan W. Irwin <ir...@be...> wrote:
> 
> Unless someone (Phil? or Jim?) objects because they are in the middle
> of a substantial bug fix they would like to get into this release I
> plan to declare a freeze 24 hours from now on pushing anything to
> master except epa_build changes (see below), simple, no-brainer bug
> fixes, and documentation improvements.  I also plan to release
> PLplot-5.11.1 on July 25th (just 10 days from now) unless someone
> objects in the next 24 hours.
> 
> My understanding from off-list discussion with Arjen is he is
> likely done making any further changes for this release cycle.
> 
> @Phil and Jim:
> 
> Is it the same for you guys are do you have any more substantial bug fixing
> plans for this release that should affect when I declare the
> above freeze?
> 
> To review the typical design of PLplot release cycles, the first month
> is devoted to merging in matured topic branches concerning big changes
> or new work (examples once these topics have matured would be Arjen's
> work on the Fortran bindings, and Jim's work on his new Windows device
> driver, plbuf, and new -dev plmeta) to allow long testing by all of us
> during a release cycle of those big changes.  Consistent with that
> idea, one month into the release cycle I normally declare a freeze
> (really just a guideline, but you have all been kind enough to follow
> it) on pushing anything to master other than bug fixes and
> documentation improvements.  Then in the last week or so of the
> release cycle, I tighten the criteria for allowed bug fixes as in the
> freeze plans above.
> 
> Of course, the above release cycle design will not work very well
> if the intervals between releases are too large.  But that is not an
> issue this time since our last release was just 3 months ago, and I
> hope to continue in the future with keeping release cycles to 4 months
> or less.
> 
> Here are my remaining personal plans for this release.
> 
> 1. Work on epa_build with regard to updating many of the packages, and
> trying to figure out the octave-4.0.0 segfaults.  Note that epa_build
> is actually specified as an exception in the above release-cycle rules
> since it is just a testing platform for PLplot.  Note a complete
> failure of epa_build for a release is extremely unlikely to happen
> since I routinely use it for release testing, but in the unlikely
> event that such a failure occurred due to some stupid last-minute
> change I did to epa_build, then it would still have no impact on
> ordinary PLplot users since they don't use epa_build.  Furthermore,
> testers that do use epa_build are most likely to use the latest git
> version rather than some release version in any case.  So I feel
> justified in making even large changes to epa_build in the last few
> days of a release cycle if they "work for me".)
> 
> 2. Monitor the results of your comprehensive testing, and fix the
> build system when problems with certain platforms are revealed by such
> testing.  Thanks to Greg's testing of Cygwin and Arjen's testing of
> Cygwin, MinGW-w64/MSYS2, and MinGW/MSYS we seem to be in pretty good
> shape for those Unix-like Windows platforms.  And thanks to Greg's
> testing of openSUSE and my testing of Debian Wheezy we appear to be in
> fairly good shape for Linux.  But where our current comprehensive
> testing really falls down is there are currently no results for either
> the MSVC Windows platform or Mac OS X, and I hope those of you with
> access to those platforms will address those testing issues soon.
> Additional comprehensive testing of Unix-like Windows platforms and
> especially Linux platforms is strongly encouraged as well.
> 
> 3. Go through the release process documented in
> README.Release_Manager_Cookbook starting very soon (e.g., with
> updating versions, release notes, generating and testing a preliminary
> version of the website, and generating and testing a preliminary
> version of the release tarball) so that effectively we are all testing
> a 5.11.1 release candidate for the next 10 days.
> 
> That is really all I have time for before the release so this means I
> will be putting off the following important topics until post-release:
> 
> * Deal with two bugs I discovered in the pointinpolygon code used by
>   our fill software as a result of looking into what Phil thought was
>   a bug in the notcrossed function.  These bugs only affect results in
>   extremely rare corner cases (one of which Phil hit but cannot
>   reproduce now) so the fixes will require some changes to example 25
>   to hit those corner cases and will also likely require lots of
>   testing by pseudo-random fill events as we test PLplot in our daily
>   use of that software.  So I plan to get these pointinpolygon fixes
>   in during the first month of the next release cycle to maximize
>   testing of the fixes before they are released.
> 
> * Deal with some Ada language support issues for all Windows
>   platforms.  Until this is done all comprehensive testing on Windows
>   should use the -DENABLE_ada=OFF cmake option.  But that option
>   should not be used for Linux or any other Unix platform since Ada
>   language support should currently "just work" on such platforms.
> 
> * Work on extending TEST_DEVICE functionality (e.g., use svg rather
>   than psc) from ctest to the test_noninteractive target for the build
>   tree, install tree, and traditional install tree.
> 
> * Generalize exporting of PLplot targets following
>   <http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html>.
>   This fairly intrusive change should allow Orion and other PLplot
>   packagers a lot more flexibility in how they factor PLplot binary
>   packages.
> 
> 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
> __________________________
> 
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Plans for the release of 5.11.1

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

Unless someone (Phil? or Jim?) objects because they are in the middle
of a substantial bug fix they would like to get into this release I
plan to declare a freeze 24 hours from now on pushing anything to
master except epa_build changes (see below), simple, no-brainer bug
fixes, and documentation improvements.  I also plan to release
PLplot-5.11.1 on July 25th (just 10 days from now) unless someone
objects in the next 24 hours.

My understanding from off-list discussion with Arjen is he is
likely done making any further changes for this release cycle.

@Phil and Jim:

Is it the same for you guys are do you have any more substantial bug fixing
plans for this release that should affect when I declare the
above freeze?

To review the typical design of PLplot release cycles, the first month
is devoted to merging in matured topic branches concerning big changes
or new work (examples once these topics have matured would be Arjen's
work on the Fortran bindings, and Jim's work on his new Windows device
driver, plbuf, and new -dev plmeta) to allow long testing by all of us
during a release cycle of those big changes.  Consistent with that
idea, one month into the release cycle I normally declare a freeze
(really just a guideline, but you have all been kind enough to follow
it) on pushing anything to master other than bug fixes and
documentation improvements.  Then in the last week or so of the
release cycle, I tighten the criteria for allowed bug fixes as in the
freeze plans above.

Of course, the above release cycle design will not work very well
if the intervals between releases are too large.  But that is not an
issue this time since our last release was just 3 months ago, and I
hope to continue in the future with keeping release cycles to 4 months
or less.

Here are my remaining personal plans for this release.

1. Work on epa_build with regard to updating many of the packages, and
trying to figure out the octave-4.0.0 segfaults.  Note that epa_build
is actually specified as an exception in the above release-cycle rules
since it is just a testing platform for PLplot.  Note a complete
failure of epa_build for a release is extremely unlikely to happen
since I routinely use it for release testing, but in the unlikely
event that such a failure occurred due to some stupid last-minute
change I did to epa_build, then it would still have no impact on
ordinary PLplot users since they don't use epa_build.  Furthermore,
testers that do use epa_build are most likely to use the latest git
version rather than some release version in any case.  So I feel
justified in making even large changes to epa_build in the last few
days of a release cycle if they "work for me".)

2. Monitor the results of your comprehensive testing, and fix the
build system when problems with certain platforms are revealed by such
testing.  Thanks to Greg's testing of Cygwin and Arjen's testing of
Cygwin, MinGW-w64/MSYS2, and MinGW/MSYS we seem to be in pretty good
shape for those Unix-like Windows platforms.  And thanks to Greg's
testing of openSUSE and my testing of Debian Wheezy we appear to be in
fairly good shape for Linux.  But where our current comprehensive
testing really falls down is there are currently no results for either
the MSVC Windows platform or Mac OS X, and I hope those of you with
access to those platforms will address those testing issues soon.
Additional comprehensive testing of Unix-like Windows platforms and
especially Linux platforms is strongly encouraged as well.

3. Go through the release process documented in
README.Release_Manager_Cookbook starting very soon (e.g., with
updating versions, release notes, generating and testing a preliminary
version of the website, and generating and testing a preliminary
version of the release tarball) so that effectively we are all testing
a 5.11.1 release candidate for the next 10 days.

That is really all I have time for before the release so this means I
will be putting off the following important topics until post-release:

* Deal with two bugs I discovered in the pointinpolygon code used by
   our fill software as a result of looking into what Phil thought was
   a bug in the notcrossed function.  These bugs only affect results in
   extremely rare corner cases (one of which Phil hit but cannot
   reproduce now) so the fixes will require some changes to example 25
   to hit those corner cases and will also likely require lots of
   testing by pseudo-random fill events as we test PLplot in our daily
   use of that software.  So I plan to get these pointinpolygon fixes
   in during the first month of the next release cycle to maximize
   testing of the fixes before they are released.

* Deal with some Ada language support issues for all Windows
   platforms.  Until this is done all comprehensive testing on Windows
   should use the -DENABLE_ada=OFF cmake option.  But that option
   should not be used for Linux or any other Unix platform since Ada
   language support should currently "just work" on such platforms.

* Work on extending TEST_DEVICE functionality (e.g., use svg rather
   than psc) from ctest to the test_noninteractive target for the build
   tree, install tree, and traditional install tree.

* Generalize exporting of PLplot targets following
   <http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html>.
   This fairly intrusive change should allow Orion and other PLplot
   packagers a lot more flexibility in how they factor PLplot binary
   packages.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive test results for MingW-w64/MSYS2

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

On 2015-07-14 18:30-0700 Greg Jung wrote:

> I'm working on it, from my point of view (which includes examining the
> "installed" perspective).
> I've had now since I adopted Msys2, a well-working cmake system that
> applies equally to mingw/msys,
> mingw32/msys2, and mingw64/msys.  All with the standard cmake executable
> and with only a few
> module replacements.

Hi Greg:

I appreciate your willingness to do more testing.  However, I frankly
am guessing a bit about exactly what you meant above because of your
notation for the various platforms and possibly a typographical error
in your notation as well.  The problem with your notation is it is
inconsistent with the actual properly capitalized names of the
component projects which are MinGW, MSYS, MinGW-w64, and MSYS2. An
additional complication is MinGW, and MSYS come only in 32-bit form
while MinGW-w64, and MSYS2 come in both 32-bit and 64-bit form.  So I
think the notation for the relevant combinations should be MinGW/MSYS
for the classical platform you get when you use the MinGW installer
mentioned in the wiki for the <sf.net/projects/mingw> project and the
designation 32-bit or 64-bit MinGW-w64/MSYS2 for the platform you get
when you use the MSYS2 "pacman" installer mentioned in the wiki for
the <sf.net/projects/msys2> project.

So I assume your mingw/msys is actually MinGW/MSYS, your mingw32/msys2
is actually 32-bit MinGW-w64/MSYS2, and your mingw64/msys (although
you probably meant to type mingw64/msys2) is actually 64-bit
MinGW-w64/MSYS2.

If that assumption is correct, and you really are already testing the
"vanilla" 64-bit MinGW-w64/MSYS2 platform as defined specifically
above rather than some variant of that you got from elsewhere which
likely does not have the popularity and heavy user testing that the
vanilla version receives, then I am very interested in your
comprehensive test report for that platform.

As you know it typically takes several iterations to get such test
reports perfected, but once that is done, and assuming you are still
game for additional testing, then obtaining a perfected test report
for the 32-bit version of MinGW-w64/MSYS2 should be worth doing as
well.  But I strongly suggest you concentrate just on the 64-bit
version of MinGW-w64/MSYS2 to start with to see how that goes.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive test results for MingW-w64/MSYS2

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

I'm working on it, from my point of view (which includes examining the
"installed" perspective).
I've had now since I adopted Msys2, a well-working cmake system that
applies equally to mingw/msys,
mingw32/msys2, and mingw64/msys.  All with the standard cmake executable
and with only a few
module replacements.

On Tue, Jul 14, 2015 at 5:25 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2015-07-14 15:45-0700 Greg Jung wrote:
>
>  From the ..env_out:
>>>
>>
>> PATH=/d/cmake3.2.2/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/ProgramData/Oracle/Java/javapath:/d/CAF/bin:/c/GTK/bin:/c/tcl/bin:/c/windows/system32
>>
>> and:
>> -- Check for working C compiler: C:/msys64/usr/bin/gcc.exe -- works
>>
>> You are running this with the MSYS environment which should only be used
>> for things that
>> will stay under /msys64.  You need to bring up the mingw64 window and run
>> from that.
>>
>
>
>> The /mingw64/bin/: goes to the front and perl puts itself at the rear.
>>
>> /mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows:/c/Windows/system32:/c/Windows/system32/Wbem:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
>>
>> There is a mingw64/bin/cmake that I'm sure Alex would recommend,
>>
>
> Hi Greg:
>
> I wonder who that "Alex" guy might be?  :-)
>
>
>  but I
>> don't know how to work it.
>>
>
> To access the MSYS2 version of cmake, you have to do two steps, see my
> recent post with the subject line 'Testing the "vanilla"
> MinGW-w64/MSYS2 platform'. Actually, I think the advice in that post
> which is derived from the advice in
> <http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2> is
> basically consistent with the advice you gave above although it is
> stated in different terms.
>
>
>> CMAKE_SYSTEM_NAME: Windows
>> UNIX: 1
>> WIN32: 1
>> APPLE:
>> MSVC: (MSVC_VERSION: )
>> MINGW:
>> MSYS: 1
>> CYGWIN: 1
>> BORLAND:
>> WATCOM:
>>
>> SWIG_FOUND: FALSE
>> PERL_FOUND: TRUE
>> X11_FOUND: 0
>>
>> is this "MSYS Makefiles" generator?  How does UNIX get set?
>>
>
> I think the above most peculiar combination of flags with CYGWIN set
> and MINGW not set is all moot now since it was generated with "MSYS
> Makefiles" (see comprehensive_sh.out in Arjen's report) rather than
> the recommended "Unix MakeFiles" and probably a cmake version that is
> not the recommended (MSYS2) version of cmake was used as well. Even
> so, Arjen's first round of testing of limited PLplot components on
> MinGW-w64/MSYS2 was quite encouraging. So it begs for a follow up with
> using the recommended generator and cmake version.  However, my
> understanding is that Arjen will not be able to do that follow up for
> several more weeks, i.e., long past our release date of Saturday, July
> 25th.
>
> So, Greg, would you be willing to do that follow up now instead?  That
> would be a big help for this release. Note that request is for the
> "vanilla" version of that platform which you can obtain by following
> the <sf.net/projects/msys2> wiki instructions for using the official
> "pacman" installer for MSYS2.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>

Re: [Plplot-devel] Comprehensive test results for MingW-w64/MSYS2

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

On 2015-07-14 15:45-0700 Greg Jung wrote:

>> From the ..env_out:
> PATH=/d/cmake3.2.2/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/ProgramData/Oracle/Java/javapath:/d/CAF/bin:/c/GTK/bin:/c/tcl/bin:/c/windows/system32
>
> and:
> -- Check for working C compiler: C:/msys64/usr/bin/gcc.exe -- works
>
> You are running this with the MSYS environment which should only be used
> for things that
> will stay under /msys64.  You need to bring up the mingw64 window and run
> from that.

>
> The /mingw64/bin/: goes to the front and perl puts itself at the rear.
> /mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows:/c/Windows/system32:/c/Windows/system32/Wbem:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
>
> There is a mingw64/bin/cmake that I'm sure Alex would recommend,

Hi Greg:

I wonder who that "Alex" guy might be?  :-)


> but I
> don't know how to work it.

To access the MSYS2 version of cmake, you have to do two steps, see my
recent post with the subject line 'Testing the "vanilla"
MinGW-w64/MSYS2 platform'. Actually, I think the advice in that post
which is derived from the advice in
<http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2> is
basically consistent with the advice you gave above although it is
stated in different terms.

>
> CMAKE_SYSTEM_NAME: Windows
> UNIX: 1
> WIN32: 1
> APPLE:
> MSVC: (MSVC_VERSION: )
> MINGW:
> MSYS: 1
> CYGWIN: 1
> BORLAND:
> WATCOM:
>
> SWIG_FOUND: FALSE
> PERL_FOUND: TRUE
> X11_FOUND: 0
>
> is this "MSYS Makefiles" generator?  How does UNIX get set?

I think the above most peculiar combination of flags with CYGWIN set
and MINGW not set is all moot now since it was generated with "MSYS
Makefiles" (see comprehensive_sh.out in Arjen's report) rather than
the recommended "Unix MakeFiles" and probably a cmake version that is
not the recommended (MSYS2) version of cmake was used as well. Even
so, Arjen's first round of testing of limited PLplot components on
MinGW-w64/MSYS2 was quite encouraging. So it begs for a follow up with
using the recommended generator and cmake version.  However, my
understanding is that Arjen will not be able to do that follow up for
several more weeks, i.e., long past our release date of Saturday, July
25th.

So, Greg, would you be willing to do that follow up now instead?  That
would be a big help for this release. Note that request is for the
"vanilla" version of that platform which you can obtain by following
the <sf.net/projects/msys2> wiki instructions for using the official
"pacman" installer for MSYS2.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive test results for MingW-w64/MSYS2

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

>From the ..env_out:
PATH=/d/cmake3.2.2/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/ProgramData/Oracle/Java/javapath:/d/CAF/bin:/c/GTK/bin:/c/tcl/bin:/c/windows/system32

and:
-- Check for working C compiler: C:/msys64/usr/bin/gcc.exe -- works

You are running this with the MSYS environment which should only be used
for things that
will stay under /msys64.  You need to bring up the mingw64 window and run
from that.

The /mingw64/bin/: goes to the front and perl puts itself at the rear.
/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows:/c/Windows/system32:/c/Windows/system32/Wbem:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

There is a mingw64/bin/cmake that I'm sure Alex would recommend, but I
don't know how to work it.
I'm working on a note to the list about what I do know.


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

SWIG_FOUND: FALSE
PERL_FOUND: TRUE
X11_FOUND: 0

is this "MSYS Makefiles" generator?  How does UNIX get set?


On Mon, Jul 13, 2015 at 11:55 PM, Arjen Markus <Arj...@de...>
wrote:

>  Hi Alan,
>
>
>
> I send you the current results for the comprehensive test on
> MingW-w64/MSYS2, as I found some peculiar things. So this is the result I
> got yesterday, without the extra bits and pieces I intended to install.
>
>
>
> The peculiarities are:
>
> -        There is no wingcc device, because the gdi32 header file and
> library are missing. I just checked: they appear under /usr/include/w32api
> and /usr/lib/w32api.
>
> -        I wanted to know if there are many external dependencies (given
> the remark that MinGW-w64 is building on Cygwin), as that might cause
> problems distributing executable programs. “ldd” only reported the basic
> Windows DLLs but it did not report libplplot.dll. Very strange. Oh, and the
> native Windows tool I use for this type of inquiries reports both
> libplplot.dll AND msys-2.0.dll.
>
> So there actually is a dependency on MSYS stuff.
>
>
>
> Anyway, that is the quick report I can send at this moment.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
>  DISCLAIMER: This message is intended exclusively for the addressee(s)
> and may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is
> strictly prohibited. The foundation 'Stichting Deltares', which has its
> seat at Delft, The Netherlands, Commercial Registration Number 41146461, is
> not liable in any way whatsoever for consequences and/or damages resulting
> from the improper, incomplete and untimely dispatch, receipt and/or content
> of this e-mail.
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

[Plplot-devel] Testing the "vanilla" MinGW-w64/MSYS2 platform

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

I just now finally found what appear to be definitive CMake
instructions (see
<http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2>) for
the MinGW-w64/MSYS2 platform (only the "vanilla" version as defined by
the <sf.net/projects/msys2> wiki rather than some "fixed" version)
which I think will interest all those here who are planning to test
that platform.  The essential points are you should be using the "Unix
Makefiles" generator for the MSYS2 version of CMake for that platform.

To expand the last point in more detail you should do the following two steps.

1. Install the MSYS2 version of CMake and other essential
software, i.e.,

pacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-extra-cmake-modules
make pkg-config grep sed gzip tar openssh ...

2. "Important: to use packages that are pre-fixed with "mingw" in
their name, you need to start a mingw shell. In your Start menu, you
will find entries "MinGW-w64 Win64 Shell". ALWAYS start this shell in
the future."

I believe these two steps are important for CMake; the closely related
Cygwin software demands you use a Cygwin version of CMake so it makes
sense there is a similar requirement that the MSYS2 platform demands
you use a MSYS2 version of CMake.

Arjen's current test of MinGW-w64/MSYS2 uses the (incorrect) "MSYS
Makefiles" generator for that platform and also may not be using the
correct MSYS2 version of CMake.  So it will be interesting to see (the
next time he has a chance to run the test which will probably be
several weeks from now) how his results change once he moves to the
recommended "Unix Makefiles" generator and the MSYS2 version of CMake.

Meanwhile, because the popularity of the MinGW-w64/MSYS2 platform is
already large and still rising rapidly, I strongly encourage others
here with access to the vanilla version of that platform to try
comprehensive testing of that platform using the generator and cmake
version recommended by the OpenWalnut software project.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive test results for MingW-w64/MSYS2

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, July 14, 2015 11:23 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Comprehensive test results for MingW-w64/MSYS2
>
> On 2015-07-14 06:55-0000 Arjen Markus wrote:
>
> > I send you the current results for the comprehensive test on
> MingW-w64/MSYS2, as I found some peculiar things. So this is the result I got
> yesterday, without the extra bits and pieces I intended to install.
>
> Hi Arjen:
>
> Congratulations on creating the first comprehensive test report for MinGW-
> w64/MSYS2!
>
> And I am pleased there were no errors.
>
Thanks, me too.

>
> > The peculiarities are:
>
> > - There is no wingcc device, because the gdi32 header file and
> library are missing. I just checked: they appear under /usr/include/w32api and
> /usr/lib/w32api.
>
> Could you clarify what you mean by that location?  It appears to me from looking at
> shared/output_tree/cmake.out that the MSYS2 stuff found by cmake is located in
> C:/msys64/usr.  Does that mean /usr/include/w32api and /usr/lib/w32api refer to a
> Cygwin location rather than a MSYS2 location?  Or is MSYS2 interpreting those as
> /C/msys64/usr/include/w32api and /C/msys64/usr/lib/w32api?
> I want to clarify that question, because I recall that MSYS reinterprets pathnames
> like that (and maybe Cygwin as well).
>

On my machine the actual directories (as reported by Windows) are c:\msys64\include\w32api and c:\msys64\lib\w32api, but the pwd command in the MSYS shell reports it as /usr/lib/w32api.

> Also, to ask the same question a different way, I noticed you had both /bin and
> /usr/bin on your PATH.  Should those be /C/msys64/bin and /C/msys64/usr/bin
> instead?  Or does MSYS2 interpret the former as the latter?
>
MSYS2 seems to do the same sort of trick Cygwin does. Directories /usr/bin and /bin appear to be one and the same - at least there is only one file "msys-2.0.dbg" according to Windows itself and MSYS2's find reports two of them.

> > - I wanted to know if there are many external dependencies (given
> the remark that MinGW-w64 is building on Cygwin), as that might cause problems
> distributing executable programs. "ldd" only reported the basic Windows DLLs but it
> did not report libplplot.dll.
>
> Is this the MSYS2 ldd command?

Yes, or perhaps the one that comes with the GCC package.


>
> > Very strange.
> Oh, and the native Windows tool I use for this type of inquiries reports both
> libplplot.dll AND msys-2.0.dll.
>
> > So there actually is a dependency on MSYS[2] stuff.
>
> In contrast, here is a result I got recently for the MinGW/MSYS case:
>
> bash.exe-3.1$ objdump -x \
> epa_build/Source/comprehensive_test_disposeable/shared/build_tree/dll/libplplot.dll
> \
> |fgrep -i "dll name:"
>          DLL Name: libcsirocsa.dll
>          DLL Name: libcsironn.dll
>          DLL Name: libqsastime.dll
>          DLL Name: libshp.dll
>          DLL Name: KERNEL32.dll
>          DLL Name: msvcrt.dll
>          DLL Name: msvcrt.dll
>
> i.e., no mention of msys-1.0.dll.  Does this objdump method give you a reliable result
> for the MinGW-w64/MSYS2 case (i.e, confirm your results obtained with the native
> Windows tool)? And if so do you confirm with both methods that there is no mention
> of the msys dll for the MinGW/MSYS case?

The output from ldd:
$ ldd x00c.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x779d0000)
        kernel32.dll => /c/WINDOWS/system32/kernel32.dll (0x777b0000)
        KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7fefd9c0000)

The output from objdump (filtered):
$ objdump -x x00c.exe |grep -i "dll name"
        DLL Name: libplplot.dll
        DLL Name: msys-2.0.dll
        DLL Name: KERNEL32.dll

>
> If that result (i.e., there is no dependency on the msys dll for the MinGW/MSYS
> platform, but there is a dependency on the msys2 dll for
> MinGW-w64-MSYS2 platform) is confirmed by you, then that result appears to be
> disappointing for the latter platform.  However, because we depend on other external
> dll's as well, I guess it doesn't matter so long as the msys2 dll is not that large.  So
> how does its size compare with the cygwin dll?

The sizes of the two are quite comparable - about 3.5 MB. Not all that much, though I have not checked what else is required.


>
> > Anyway, that is the quick report I can send at this moment.
>
> Thanks for that excellent first report for this platform. If you are pressed for time you
> can certainly just stop there until after the release. However, if you feel you have
> sufficient leisure time to broaden the test some time in the next few days by using
> the MSYS2 installer to install a lot more PLplot prerequisites, I would be happy to
> see those broadened test results as well.
>
> Note whenever you do such further MSYS2 installation please keep good notes of
> what packages you install so you can (eventually) use that information to provide
> content for a new page on our wiki documenting your recommendations for setting
> up PLplot builds on the MinGW-w64 platform.
>
Yes, I will do that.

Regards,

Arjen

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

Re: [Plplot-devel] Comprehensive test results for MingW-w64/MSYS2

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

On 2015-07-14 06:55-0000 Arjen Markus wrote:

> I send you the current results for the comprehensive test on
MingW-w64/MSYS2, as I found some peculiar things. So this is the
result I got yesterday, without the extra bits and pieces I intended
to install.

Hi Arjen:

Congratulations on creating the first comprehensive test report for
MinGW-w64/MSYS2!

And I am pleased there were no errors.


> The peculiarities are:

> - There is no wingcc device, because the gdi32 header file and
library are missing. I just checked: they appear under
/usr/include/w32api and /usr/lib/w32api.

Could you clarify what you mean by that location?  It appears to me
from looking at shared/output_tree/cmake.out that the MSYS2 stuff
found by cmake is located in C:/msys64/usr.  Does that mean
/usr/include/w32api and /usr/lib/w32api refer to a Cygwin
location rather than a MSYS2 location?  Or is MSYS2 interpreting
those as /C/msys64/usr/include/w32api and /C/msys64/usr/lib/w32api?
I want to clarify that question, because I recall that MSYS reinterprets
pathnames like that (and maybe Cygwin as well).

Also, to ask the same question a different way, I noticed you had both
/bin and /usr/bin on your PATH.  Should those be /C/msys64/bin and
/C/msys64/usr/bin instead?  Or does MSYS2 interpret the former as the
latter?

> - I wanted to know if there are many external dependencies (given
the remark that MinGW-w64 is building on Cygwin), as that might cause
problems distributing executable programs. "ldd" only reported the
basic Windows DLLs but it did not report libplplot.dll.

Is this the MSYS2 ldd command?

> Very strange.
Oh, and the native Windows tool I use for this type of inquiries
reports both libplplot.dll AND msys-2.0.dll.

> So there actually is a dependency on MSYS[2] stuff.

In contrast, here is a result I got recently for the MinGW/MSYS case:

bash.exe-3.1$ objdump -x \
epa_build/Source/comprehensive_test_disposeable/shared/build_tree/dll/libplplot.dll \
|fgrep -i "dll name:"
         DLL Name: libcsirocsa.dll
         DLL Name: libcsironn.dll
         DLL Name: libqsastime.dll
         DLL Name: libshp.dll
         DLL Name: KERNEL32.dll
         DLL Name: msvcrt.dll
         DLL Name: msvcrt.dll

i.e., no mention of msys-1.0.dll.  Does this objdump method give you a
reliable result for the MinGW-w64/MSYS2 case (i.e, confirm your
results obtained with the native Windows tool)? And if so do you
confirm with both methods that there is no mention of the msys dll for
the MinGW/MSYS case?

If that result (i.e., there is no dependency on the msys dll for the
MinGW/MSYS platform, but there is a dependency on the msys2 dll for
MinGW-w64-MSYS2 platform) is confirmed by you, then that result
appears to be disappointing for the latter platform.  However, because
we depend on other external dll's as well, I guess it doesn't matter
so long as the msys2 dll is not that large.  So how does its size
compare with the cygwin dll?

> Anyway, that is the quick report I can send at this moment.

Thanks for that excellent first report for this platform. If you are
pressed for time you can certainly just stop there until after the
release. However, if you feel you have sufficient leisure time to
broaden the test some time in the next few days by using the MSYS2
installer to install a lot more PLplot prerequisites, I would be happy
to see those broadened test results as well.

Note whenever you do such further MSYS2 installation please keep good
notes of what packages you install so you can (eventually) use that
information to provide content for a new page on our wiki documenting
your recommendations for setting up PLplot builds on the MinGW-w64
platform.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________