To Arjen, Phil, and Pedro:
Note new subject line:
@Phil and Pedro:
Have you guys ever tested example 14 with -dev wxwidgets on Windows?
That's an important question since your answers might help us to figure
out if this example 14 wxwidgets issue is a long-standing one for the
"new" version of this device or some recently introduced regression.
On 2017-07-05 12:21-0000 Arjen Markus wrote:
-----Original Message-----
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
Sent: Tuesday, July 04, 2017 12:30 AM
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.
I ran this last night and it was almost completely successful. However, example
x14c will not stop - I had to kill it manually and that, of course, upsets the
test script. I tried this example standalone: it brings up two windows, when
you click in them, they disappear but ultimately the program itself remains
active.
We are therefore not quite there yet. I had not turned on the debugging output,
so I cannot share an extra output file.
@Arjen:
The short story is please try the comprehensive test again with the
latest version (commit b05d501) which is not a fix for this issue but
instead simply ignores example 14 for comprehensive testing of
wxwidgets. I cannot replicate this hang on Linux, but there
are enough problems there, that I think we should fix those (likely
post-release) before worrying about example 14 for wxwidgets on
Windows (in case there is one bug that manifests itself as an early
exit for the slave GUI on Linux and as a hang on Windows).
The longer story is I further investigated the Linux case by doing the
following test for three different fresh configurations:
# Build prerequisites:
(make VERBOSE=1 wxwidgets; make VERBOSE=1 wxPLViewer; make VERBOSE=1 x14c) >&
build.out
# Normal run
examples/c/x14c -dev wxwidgets
# -np run (that option is also used in comprehensive tests).
examples/c/x14c -dev wxwidgets -np
The different configurations and the corresponding results are as
follows:
1. Default configuration (what you used above corresponding to
-DOLD_WXWIDGETS=OFF -DPL_WXWIDGETS_IPC3=ON). This is
the 3 semaphores approach for the IPC required for the
"new" wxwidgets device driver.
For the normal run, the first page of the master GUI appeared and the
first page of the slave GUI appeared (which had the same size box as
the master GUI). However, that page of the slave GUI immediately
disappeared again (which is a bug). Hitting the enter key on the
master GUI advanced to the second page of the master GUI (with no
corresponding slave GUI at all). Hitting the enter key again for the
second page of the master GUI exited normally. There were no hangs,
leftover jobs running in the background, or leftover files in /dev/shm
(where the shared memory and named semaphores "files" appear on
Linux).
For the -np run, two empty boxes appeared and then disappeared
(consistent with the first results since the -np option is supposed to
remove the necessity for hitting the enter key to move between pages
and exit the GUI. The empty pages were the result of the
long-standing -np bug for wxwidgets where only empty boxes are
displayed). There were no hangs, leftover jobs running in the
background, or leftover files in /dev/shm (where the shared memory and
named semaphores "files" appear on Linux).
2. Specified -DPL_WXWIDGETS_IPC3=OFF (for default -DOLD_WXWIDGETS=OFF).
This is the mutex (Windows) or one-semaphore approach (Linux) using a circular
buffer and timed wait loops for the IPC for the "new" wxwidgets device
driver.
All these results were identical to those in 1. above except that the
slave GUI box was 3/4ths the size of the master GUI box (presumably
due to some minor issue with this approach, but I am not going to
worry about that issue since I believe the PL_WXWIDGETS_IPC3 variant
of the IPC method is what we should be developing moving forward).
3. -DOLD_WXWIDGETS=ON.
This is the old version of the wxwidgets device driver that does not use IPC at
all
and which is only minimally maintained.
Example 14 shows no bugs for this old version of device driver
compared to the two bugs found above for the new version of this
device driver. For the normal run both the master and slave GUIs
appear (and both stay displayed) and hitting the enter key on either
of them advances both to the next page (when they are both on their
respective first pages) or exits both (when they are both on their
respective second pages). For the -np run, both the master and slave
GUIs appear and actually show plotted results (as opposed to the empty
GUI boxes that appear for the new version of this device above). Like
the new version of this device driver, there were no hangs and no
leftover jobs running in the background.
For both types of runs there were the following set of warnings:
../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in wxFreePoolGC():
Wrong GC
../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in wxFreePoolGC():
Wrong GC
../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in wxFreePoolGC():
Wrong GC
../src/gtk/dcclient.cpp(250): assert "Assert failure" failed in wxFreePoolGC():
Wrong GC
These warnings appear to be due to some wxwidgets-3.x constraint that
our old version of the device driver (which was developed for
wxwidgets-2) is violating, and therefore, these warning are likely the
result of our decision to do only minimal maintenance for the old
version of this device driver.
My conclusion from the sobering results of these tests is there is
still lots of work we need to do to bring the new version of this
device driver up to the standards of the old version even just for
this one example on the Linux platform. (The bug with regard to the
slave GUI disappearing is only demonstrated by this example, but the
empty box bug for the -np option is shown by all examples.) And from
your experience there is even a worse issue (a hang) for this example
on Windows. So I have decided (commit b05d501) to temporarily ignore
example 14 for our tests of -dev wxwidgets for all platforms, and this
change should likely allow you to complete the comprehensive testing
of wxwidgets on MinGW-w64/MSYS2. But please check that by repeating
the comprehensive test on that platform!
My further general conclusion is we still want to deal with these
issues of the new version rather than simply abandoning it and using
the old version instead. The reason for that conclusion is the
complexity of the old version (actually 3 kinds of wxwidgets devices)
made it extremely difficult to maintain or understand, and if I recall
correctly what Phil said about his new design, the IPC used in the new
version to send data between -dev wxwidgets and the new independent
viewer, wxPLViewer, makes it possible to isolate the known
thread-safety issues of PLplot from the thread-safe wxwidgets
environment while that lack of isolation was an important issue for
the old wxwidgets approach.
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
