On 2017-07-03 18:22-0000 Arjen Markus wrote:
-----Original Message-----
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
Sent: Saturday, July 01, 2017 11:08 PM
After reviewing the code, I spotted a fundamental error in the Windows variant
of
the three-semaphores case which is that code used three Windows mutexes rather
than three named Windows semaphores.
[...] Therefore, I have now (commit b779495) addressed this issue by using
named Windows semaphores in the Windows variant of the three semaphores
approach, but I cannot even build test this modified Windows variant of the
three-
semaphores approach here. So I need you to do that.
I rebuilt PLplot using this latest commit and it all worked fine :).
So the three-semaphores approach you have now implemented was the
right way. I will try and see whether I can get the same result with
the MSVC compiler.
To be specific about what test I want you to run, please freshly configure
PLplot
with the -DPLPLOT_WX_DEBUG_OUTPUT=ON option (which adds lots of useful
information if there are any remaining errors with the three-semaphores
approach).
Unless you think this is necessary, given the completely positive results, I
will concentrate on MSVC.
Hi Arjen:
Congratulations on this success after a number of iterations between
us. It is a great feeling to not have this uncertainty hanging over
us.
If your MinGW-w64/MSYS and MSVC follow ups (see below) show no
wxwidgets problems of any urgent kind on those platforms, then I
intend to disable the CMake PL_WXWIDGETS_IPC3 option by forcing it to
ON, (the default option you just tested) on all platforms for the
5.13.0 release with the further plan later (if experience through a
couple of releases shows no problems with that disabling) to remove
this CMake PL_WXWIDGETS_IPC3 option (and also the large amount of code
associated with when the C++ macro PL_WXWIDGETS_IPC3 is _not_
#defined).
To answer your question above, now that you have had this success, I
would appreciate you doing the following:
1. Run (all on one line rather than mail wrapped)
scripts/comprehensive_test.sh --generator_string "MSYS Makefiles"
--cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON
-DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON"
--build_command make --ctest_command ctest
--do_test_noninteractive no --do_ctest no
--do_nondynamic no --do_static no
--do_test_install_tree no --do_test_traditional_install_tree no
on the MinGW-w64/MSYS2 platform. The cmake_added_options value limits
this comprehensive test to just the wxwidgets components of PLplot.
Those last 4 options limit the test to shared library only (to reduce
the testing time by a factor of three) and build-tree only (to reduce
the testing time by another factor of three). But if that script run
is a success, and a nine-times longer run would not take too much of
your time compared to the other noninteractive comprehensive tests you
need to complete, then I would also suggest you extend the test by
dropping the last 4 options (or changing their values from no to yes)
to check all is well for the nondynamic and static cases and for the
two kinds of build systems for the install tree.
2. Do a simple test of wxwidgets on MSVC
3. If 2. works, then run the above comprehensive test (presumably with NMake
Makefiles
generator) on the MSVC platform (+ MinGW-w64/MSYS2 Unix tools on the
PATH like what worked before for your noninteractive MSVC
comprehensive test). I would stick with the suggested constraints
to start, and then if all is well extend the test further as discussed
above.
3 obviously should come some time after 2, but otherwise I don't care
strongly about the order of these tests so long as they are all done
(since they are all important).
In any case, please commit your setup scripts (bash scripts where you
set environment variables and run scripts/comprehensive_test.sh) for
each kind of comprehensive test you want to run for any given
platform). Probably, the best place to commit those scripts is in
newly created directories for each platform, e.g., scripts/setup/linux
(which I plan to populate soon), scripts/setup/mingw_msys (which I
also plan to populate soon), scripts/setup/mingw_w64_msys2, and
scripts/setups/msvc_nmake. Those setup scripts should have a tailored
section which contains all the idiosyncrasies of your particular
personal platform (e.g., directory prefix locations that would need to
be changed by other users. For an example of this approach please
take a look at, e.g., scripts/setup/mingw_msys files once I populate
those files with what I did recently in the Wine/MINGW/MSYS case. Such
setup scripts allow us to replicate and document exactly how we launch
our comprehensive tests. They should also help other users in general
with setting up builds and tests of PLplot on the various platforms.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
