On 2015-08-01 12:52-0700 Alan W. Irwin wrote:
> Just to keep you guys informed, it looks doubtful that I will be able
> to finish the release process today, but I hope to finish that tomorrow.
Update: one of the first essential items is to update comprehensive
test results on our Wiki so our release notes can just refer to that
wiki item, but SF has just deployed a new markdown editor that
completely sucks/is unusable for complex wiki pages like ours. That
"completely sucks/unusable" phrase is not hyperbole. For example, the
cursor position is misidentified so if you try to insert a line of
text at what appears to be the cursor position it actually appears 5
lines higher in the editing GUI for the tables part of the page I was
attempting to edit. (This occurs for both konqueror and iceweasel
(the Debian form of firefox.) Elsewhere in that page the cursor is
correctly identified. So nothing is predictable. Similarly, any
attempt to delete stuff ends up deleting the wrong stuff. And the
usual normal cut and paste with the mouse no longer works. I have
been fighting with these issues for several hours today and have got
precisely nowhere.
Anyhow, I am hoping for a quick response from SF staff concerning how
they can make it possible to update complex wiki pages like ours again
(e.g., by giving us the option to use the old editor that actually
works), but if I don't get that quick response, I guess as a temporary
measure, I could put all the markdown format for tables filled with
recent comprehensive test reports from Arjen, Greg, and myself
directly into our release notes and copy those markdown data to our
wiki later when it is finally possible to do so.
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
__________________________

Just to keep you guys informed, it looks doubtful that I will be able
to finish the release process today, but I hope to finish that tomorrow.
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
__________________________

There exist parallel build issues on the MinGW/MSYS, Cygwin, and
MinGW-w64/MSYS2 windows platforms (see below) so I have looked for
race conditions caused by ill-considered CMake logic in our build
system concerning target and file dependencies, but have not found
any instances of that (although the timing conditions of my tests
may just not be right to trigger such a race condition).
An example of such ill-considered logic is if you have two separate
custom targets file depend directly or indirectly on the same custom
command. Under these conditions, the custom command gets executed once
for each target which is normally not an issue for non-parallel builds
or parallel builds where the two custom targets happen to be executed
at separate times. However, when by chance the two custom targets are
being executed at the same time for parallel builds the resulting race
condition will cause substantial build issues. We have lots of custom
commands and custom targets in our build so historically we have had a
lot of such race conditions to deal with. But as far as I know (hah!)
CMake code review of the various custom commands and targets that are
generated has by now found them all.
Furthermore, here is a run-time test to discover whether any such race
conditions are occurring. N.B. such race conditions critically depend
on timing (e.g., the N value used in the -jN make option, the hardware
platform, etc.) so this is a necessary but not sufficient test that we
have gotten rid of all such race conditions via CMake code review.
It turns out that even if race conditions that occur for a given
timing enviroment do not cause obvious build issues, they are still
easy to spot because each time a custom command is executed at build
time (whenever its OUTPUT files are non-existent or older than its
file depends), there is a correponding build message
Generating <list of OUTPUT files from the custom command>.
So that message will be duplicated if two separate custom targets
attempt to build the custom command at the same time, i.e., whenever
a race condition occurs for the given timing regardless of the symptoms
(or lack of symptoms) from such a race.
I have created the following set of commands to test for
duplicate messages of that form for both the test_noninteractive target
and the all target
# test_noninteractive target
# Do this test for an absolutely fresh build, i.e., cmake with
# -DBUILD_TEST=ON option in an initially empty build tree followed by
make -j4 test_noninteractive >& test_noninteractive.out
# Find essentially all occurrences of commands being run by looking for
# anything with "ing" with some exceptions. Sort the result once
# without duplicates being eliminated and sort once with duplicates
# eliminated.
grep ing test_noninteractive.out |\
sed -e 's?\[.*\] ??g' |\
grep -vE 'Scanning|Differing|Missing' |\
grep -v bindings |\
grep -v "using command" |\
grep -v "Testing" |\
grep -v "switching to" |\
sort -u >| unique_builds.out
grep ing test_noninteractive.out |\
sed -e 's?\[.*\] ??g' |\
grep -vE 'Scanning|Differing|Missing' |\
grep -v bindings |\
grep -v "using command" |\
grep -v "Testing" |\
grep -v "switching to" |\
sort >| builds.out
# Compare the two results to see whether anything extra in builds.out
# compared to unique_builds.out
diff -au unique_builds.out builds.out |less
It turns out there is some extra data consisting of
duplicate instances of
Generating tclIndex
and duplicate instances of
Generating x00
and similarly for almost every other x?? file.
These all turned out to be false alarms. The two tclIndex files are
actually created by distinct custom commands in bindings/tcl and
examples/tcl. And similarly the x?? files are actually created by
distinct custom commands in examples/python and examples/tcl.
The one peculiarity that I found from the above test is that
Generating x01
Generating x25
Generating x26
did not have duplicate instances. However, I double checked that two
files were created in each case (one in examples/tcl and one in
examples/python) so the conclusion must be I have turned up a minor
bug in CMake (3.0.2) where it does not always emit a
Generating <filename>
message when a custom command generates an OUTPUT file at run time.
# all target
I also did the equivalent test for the "all" target starting from
an initially empty build tree with similar good results concerning
the lack of race conditions for the given timing conditions.
There were duplicate messages for
plgrid.tcl, plplot.tcl, tclIndex (4 instances instead of the 2 that
occurred for the test_noninteractive target), x??, and x??.tcl.
In all cases, further analysis showed these were all false alarms due to a
file with the same name being created by different custom commands in
different directories.
So my conclusion is there is no evidence of parallel build race
conditions for the "test_noninteractive" or "all" targets in the core
build tree for the given timing conditions which is a limited but
still satisfactory conclusion. Note at some point I should do a
similar test for the test_interactive target in the build tree and
also for the all, test_noninteractive, and test_interactive targets
for the installed examples, but I don't have time for that now.
The big motivation for the above experiment to look for parallel race
conditions is due to following parallel build issues that show up in
all our current comprehensive tests on various Windows platforms:
1. For my comprehensive test on MinGW/MSYS in the last release using
parallel builds with -j4, I ran into the following message intermittently (i.e.,
just once, and the repeat test did not encounter the problem)
make.exe error: "INTERNAL: Exiting with 1 jobserver tokens available;
should be 4!"
That along with the historical MSYS make.exe hangs for parallel builds (see
<https://sourceforge.net/p/mingw/bugs/1950/&gt;) lead me to the
conclusion that for the most reliable results you should never use
parallel builds on the MinGW/MSYS platform. Arjen's recent test of
MinGW/MSYS followed that recommendation and (probably as a result) did
not have any build or ctest problems. However, the above bug report
now claims the hang issue has finally been solved so it might be
worth it to experimentally try parallel builds on this platform when
we test it again some time in the next release cycle.
2. Greg Jung has also recently encountered a similar warning message
for -j4:
make: INTERNAL: Exiting with 3 jobserver tokens available; should be 4!
on MinGW-w64/MSYS2. That build warning was
was accompanied by parallel
ctest just hanging until Greg killed the job. Since then, Greg has had
no further trouble with the issue if he uses the
--ctest_command "ctest"
--build_command "make"
--traditional_build_command "make"
options to the comprehensive_test.sh script, i.e., drops both the
parallel build and parallel ctest on the MinGW-w64/MSYS2 platform.
3. Both Greg and Arjen have experienced the
make: INTERNAL: Exiting with 3 jobserver tokens available; should be 4!
warning on Cygwin. However, that does not seem to interfere with parallel builds, and
parallel ctest works fine on that platform as well.
My conclusions are as follows:
* PLplot has no parallel build race conditions for the
test_noninteractive and all targets that I can detect for the given
timing conditions. So this is a necessary test to prove no race
conditions but not a conclusive test so we are still really relying
on our CMake code review here to keep us out of race condition
trouble for all timing conditions.
* Cygwin, MSYS, and MSYS2 make all emit warnings for parallel builds
with -j4 consisting of messages similar to
make: INTERNAL: Exiting with 3 jobserver tokens available; should be 4!
Until the issue (most likely a Windows make.exe bug, but it could also
be a race condition for the given timings in each case) that causes
these warning messages is addressed, all parallel build results on
Cygwin, MinGW/MSYS, and MinGW-w64/MSYS2 should be viewed with some
suspicion.
* Parallel ctest hangs on MinGW-w64/MSYS. It is currently not clear
if this is strictly a ctest issue or a byproduct of some parallel
build issue that occurred. Therefore, more experimentation on this
platform post-release, e.g., with non-parallel build but parallel
ctest will be needed to help sort out the true cause of this issue.
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
__________________________

On 2015-07-30 06:42-0400 Jim Dishaw wrote:
>> On Jul 30, 2015, at 6:36 AM, Jim Dishaw <jim@...> wrote:
[...]
>> That patch [to insert a XSynchronize call] 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 would work and we wouldn't be any worse off then we were before.
OK. I have pushed [d64d9c6] for now to revert your "multiple keypress
bug on page advance" fix for the cairo device driver, and you should
be able to straightforwardly revert d64d9c6 post-release as a start to
finding the right approach for getting the multiple keypress bug on
page advance fixed for the cairo device driver without compromising
the test_extXdrawable target result.
Late in release cycles like this there is lots of time pressure on the
release manager to make quick decisions so my thanks for the immediate
responses you made to my questions about this tricky issue.
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
__________________________

> On Jul 30, 2015, at 6:36 AM, Jim Dishaw <jim@...> wrote:
>
>
>
>
>
>>> On Jul 30, 2015, at 3:21 AM, Alan W. Irwin <irwin@...> wrote:
>>>
>>> On 2015-07-30 01:08-0400 Jim Dishaw wrote:
>>>
>>>
>>>> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <irwin@...> 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
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

> On Jul 30, 2015, at 3:21 AM, Alan W. Irwin <irwin@...> wrote:
>
>> On 2015-07-30 01:08-0400 Jim Dishaw wrote:
>>
>>
>>> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <irwin@...> 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>

On 2015-07-30 01:08-0400 Jim Dishaw wrote:
>
>> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <irwin@...> 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
__________________________

> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <irwin@...> 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@...> 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
> __________________________

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

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
__________________________

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

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/&gt; 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
__________________________

@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/&gt; 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
__________________________

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

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
__________________________

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/&gt;.
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/&gt; 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&gt;.
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
__________________________

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 <irwin@...>
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
> __________________________
>

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 <gvjung@...> 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 <irwin@...>
> wrote:
>
>> I just now finally found what appear to be definitive CMake
>> instructions (see
>> <http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2&gt;) 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
>> Plplot-devel@...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
>

No objection on my part. I'm working towards the next release.
> On Jul 15, 2015, at 11:59 AM, Alan W. Irwin <irwin@...> 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&gt;.
> 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
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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&gt;.
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
__________________________

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
__________________________

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 <irwin@...>
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&gt; 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
> __________________________
>

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&gt; 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
__________________________