plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

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

On 2016-12-23 16:43-0500 Pedro Vicente wrote:

> by the way, what are the commands to do comprehensing testing?

That script should be able to run on all Unix systems and Unix-like
systems (i.e., Cygwin and MinGW-w64/MSYS2), but not currently for MSVC
("raw Windows").  However, Arjen plans to investigate a possibility for
running that script on MSVC platforms as well in 2017.

So for now, on Unix or Unix-like systems, I suggest you run

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

I used exactly those options recently myself.

Those options are constraints on the script to keep it from doing
time-consuming (several hours?) tests that you probably don't
need/want to run right now.

So my suggested options constrain the script to just test the
plplotwxwidgets library and the wxwidgets device driver for our 3
major configurations and 3 different build trees. (So you will see the
tests repeat 9 times for those combinations.) There are no
noninteractive tests of the wxwidgets device driver or plplotwxwidgets
library.  But to avoid the non-interactive C++ tests, we further
constrain the script above to avoid all the non-interactive testing.

As a result of these constraints the script just builds the
test_interactive target for our 9 combinations.  For each of those
combinations, that target in turn depends on test_wxPLplotDemo (to
test the plplotwxwidgets library) and test_c_wxwidgets (to test the
wxwidgets device driver).  You can also reduce the combinations if you
like using additional constraint options for the script.

Run

scripts/comprehensive_test.sh --help

to see about those further possibilities if the 9 combinations turn
out to be too much.  :-)

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Linux testing

[Pedro V. <ped...@sp...>]

@Alan

I changed the thread tittle, because I have all kinds of weird results on my 
comprehensing testing.

first the obvious:

items 1) to 3) below are for the master branch

1) a Fortran error on Ubuntu 14.04

this was a simple
cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install -DCMAKE_BUILD_TYPE=Debug 
 -DBUILD_TEST=ON
make VERBOSE=1 >& make.txt

but it detected gfortran and tried to build the fortran code.
output is attached

2)

then I disabled Fortran

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install -DCMAKE_BUILD_TYPE=Debug 
 -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DBUILD_TEST=ON
make VERBOSE=1
no errors

then (note , running from the build location)

pvicente@glace:~/plplot-plplot/build$ 
../scripts/comprehensive_test.sh --cmake_added_options 
"-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON 
 -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON -DENABLE_f95:BOOL=OFF" 
 --do_test_noninteractive no --do_ctest no

Each of the steps in this comprehensive test may take a while....
cmake in the build tree
ERROR: cmake in the build tree failed

How can I capture the output here? It asks for a interactive (yes/no), can I 
disable this and instead redirect the output to a file?


3)

On another Linux, 16.04,  where *I don't* have gfortran

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/plplot-install -DCMAKE_BUILD_TYPE=Debug 
  -DBUILD_TEST=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON
make VERBOSE=1
make VERBOSE=1 test_wxPLplotDemo

Infinite loop
22:25:42: Debug: Plot() Yielding

pvn@server:~/plplot-plplot/build$ 
../scripts/comprehensive_test.sh --cmake_added_options 
"-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON 
 -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON" --do_test_noninteractive 
no --do_ctest no

then it stays here (I suppose because of the infinite loop)
and I get a blank plviewer window

Each of the steps in this comprehensive test may take a while....
cmake in the build tree
make -j4 VERBOSE=1 test_interactive in the build tree

4)

results for my patch commit

@Phil
I was able to make the example 01 run with no runtime errors by 
re-introduncing the OnCreate() event (but also keeping the Create() call).
But then I got other errors.
I am not sure what are the consequences of these changes, so here it's 
better for me to wait until you provide some insight into this.

to do items:

1)

it would be great if any of you could reproduce my test_wxPLplotDemo 
behavior on Linux

the response from the developer


> This is not completely unexpected, the window is only really created when
> it's "realized" in GTK+/X11 terms, which can take quite some time, in
> particular if a remote X server is used


could this "remote X server is used" be because I am accesing my linux 
machines remotely ? (by using X2Go)


2)

maybe put the master back with one of the workarounds that I don't have the 
infinite loop,
so that I have a better idea of what happens in the comprehensing testing?

-Pedro

----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>; "Phil Rosenberg" 
<p.d...@gm...>; "PLplot development list" 
<plp...@li...>
Sent: Friday, December 23, 2016 5:19 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-23 16:43-0500 Pedro Vicente wrote:
>
>> by the way, what are the commands to do comprehensing testing?
>
> That script should be able to run on all Unix systems and Unix-like
> systems (i.e., Cygwin and MinGW-w64/MSYS2), but not currently for MSVC
> ("raw Windows").  However, Arjen plans to investigate a possibility for
> running that script on MSVC platforms as well in 2017.
>
> So for now, on Unix or Unix-like systems, I suggest you run
>
> scripts/comprehensive_test.sh --cmake_added_options 
> "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON 
>  -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON" --do_test_noninteractive 
> no --do_ctest no
>
> I used exactly those options recently myself.
>
> Those options are constraints on the script to keep it from doing
> time-consuming (several hours?) tests that you probably don't
> need/want to run right now.
>
> So my suggested options constrain the script to just test the
> plplotwxwidgets library and the wxwidgets device driver for our 3
> major configurations and 3 different build trees. (So you will see the
> tests repeat 9 times for those combinations.) There are no
> noninteractive tests of the wxwidgets device driver or plplotwxwidgets
> library.  But to avoid the non-interactive C++ tests, we further
> constrain the script above to avoid all the non-interactive testing.
>
> As a result of these constraints the script just builds the
> test_interactive target for our 9 combinations.  For each of those
> combinations, that target in turn depends on test_wxPLplotDemo (to
> test the plplotwxwidgets library) and test_c_wxwidgets (to test the
> wxwidgets device driver).  You can also reduce the combinations if you
> like using additional constraint options for the script.
>
> Run
>
> scripts/comprehensive_test.sh --help
>
> to see about those further possibilities if the 9 combinations turn
> out to be too much.  :-)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

Re: [Plplot-devel] Linux testing

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

Hi Pedro:

It sounds like you might have some spare time now where you are
willing to help us with comprehensive testing while you wait for Phil
to comment about the wxwidgets errors you are now getting with your
tentative change.  So I assume you have that time below, But, of
course, fixing that release-critical wxwidgets error is the top
priority so you should drop comprehensive testing as soon as he
responds.

More below about comprehensive testing.

On 2016-12-23 22:44-0500 Pedro Vicente wrote:

>
> @Alan
>
> I changed the thread tittle, because I have all kinds of weird results on my 
> comprehensing testing.
>
> first the obvious:
>
> items 1) to 3) below are for the master branch
>
> 1) a Fortran error on Ubuntu 14.04
>
> this was a simple
> cmake ..  -G "Unix Makefiles" 
> -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install 
> -DCMAKE_BUILD_TYPE=Debug -DBUILD_TEST=ON
> make VERBOSE=1 >& make.txt
>
> but it detected gfortran and tried to build the fortran code.
> output is attached

You need to capture and look at your cmake output to confirm this, but
if I am recalling another report correctly, Ubuntu 14.04 installs a three-year-old version of
gfortran that is below our minimum supported version (see
README.release) of 4.9.2.  Which is why you have to disable fortran on
that platform.

> 2)
>
> then I disabled Fortran
>
> cmake ..  -G "Unix Makefiles" 
> -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install 
> -DCMAKE_BUILD_TYPE=Debug -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF 
> -DENABLE_tk:BOOL=OFF -DBUILD_TEST=ON
> make VERBOSE=1
> no errors


>
> then (note , running from the build location)
>
> pvicente@glace:~/plplot-plplot/build$ ../scripts/comprehensive_test.sh 
> --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON 
> -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON 
> -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON -DENABLE_f95:BOOL=OFF" 
> --do_test_noninteractive no --do_ctest no
>
> Each of the steps in this comprehensive test may take a while....
> cmake in the build tree
> ERROR: cmake in the build tree failed
>
> How can I capture the output here? It asks for a interactive (yes/no), can I 
> disable this and instead redirect the output to a file?

First some background on that script.  It is completely independent of
what you do in your build tree (because it creates its own build
tree and runs cmake there itself). So you did not have to run cmake first
or locate yourself in the build tree.  In fact, normally it is more
convenient to run the script from the top-level directory in your source
tree (although that is not a necessity).

The script collects all of its work in its own directory tree whose
top-level directory is by default ../comprehensive_test_disposeable
_always expressed relative to the top-level directory of the source tree_.

I assume from now on you run that script without specifying a prefix
which always gives the same default location for scripts results no
matter where you run the script from.

All the outputs of all non-trivial commands the script runs are
typically stored in

../comprehensive_test_disposeable/*/*/output_tree/*.out

Normally I need all those files (and other information) to help you
with comprehensive test results. Therefore the script collects that
information in the report tarball which is stored in
../comprehensive_test_disposeable/comprehensive_test.tar.gz.

So for each such comprehensive test you run,
you should normally send me that report tarball if you cannot figure out
the issue yourself by looking over the various *.out files that
are collected as above.

But this is not a normal case because you _know_ that a comprehensive
test of wxwidgets is going to fail (because there are still issues
with your present update that you need help from Phil to fix). So
there is not much point to testing wxwidgets this way until you and
Phil have the definitive fix.

Meanwhile, while waiting for Phil, if you want to just help with
systematic comprehensive testing, then I suggest you do that by
dropping both fortran and wxwidgets as follows (assuming you run this
from the top-level directory of the source tree).

time (nice -19 scripts/comprehensive_test.sh --cmake_added_options "-DENABLE_f95=OFF -DPLD_wxwidgets=OFF -DENABLE_wxwidgets=OFF" --do_test_interactive no)

This will drop all interactive testing (so you won't have to babysit
this long test) and drop Fortran and wxwidgets for the reasons stated,
but otherwise give PLplot a useful complete noninteractive test on
Ubuntu 14.04.  (The time and nice parts keep track of the total time
required [likely several hours] and also give this script the lowest
priority so you can carry on with that machine without completely
locking it up while running this script).

And if the script errors out for some reason, please look in the
relevant *.out file and keep a brief note of those reasons, e.g.,
"gfortran 4.8.? had a build error" if you had attempted a
comprehensive test on Ubuntu 14.04 without disabling fortran. Keeping
track of those reasons helps me to enter appropriate footnotes at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>.
Anyhow, after each such script failure, run it again with other added
options to turn off the relevant component of PLplot that is causing
the failure. Once the script successfully finishes send me that report
tarball, and I can use that information (assuming I have your
permission) and your brief notes about which components failed to put
one more much appreciated entry into the above wiki table of such
comprehensive test results.

> 3)
>
> On another Linux, 16.04,  where *I don't* have gfortran
>

Actually, for 16.04 it would be useful if you installed fortran and
included it in the comprehensive test (while still dropping wxwidgets)
because that two years younger Ubuntu version than 14.04 should easily
satisfy our minimum gfortan version requirement.

And once you have the definitive fix for wxwidgets, then it should
be completely straightforward to comprehensively test _just_ that
component as I first suggested.

I won't respond to the rest of your post because I believe only Phil
can answer those wxwidgets-related questions.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Infinite Yielding issue

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

On 2016-12-24 01:13-0500 Pedro Vicente wrote:

> Hi Alan
>
> some more upbeat news about the example error , it's gone :-)

It's gone here too.  :-)

So thanks very much Pedro for this early Christmas present!

[...]
> I also removed this "PLDLLIMPEXP_WX"
>
> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame

That change causes a build issue on Linux if you are using

export CXXFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
export CFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
export FFLAGS="-O3 -Wuninitialized -Wunused"

which I highly recommend on Linux to check for symbol visibility
issues on that platform (and to partially check for visibility
issues on Windows as well, but in this case it sounds like it
was not needed, but it should do no harm on that platform.)

So I had to amend your present (second) commit to put it back.

> I searched  in all the source code and could not find this symbol ?

The unix find command is good for such tasks:

software@raven> find . -type f |grep -v .git |xargs grep PLDLLIMPEXP_WX
./bindings/wxwidgets/wxPLplot_nanosec.h.in:PLDLLIMPEXP_WX void
./bindings/wxwidgets/wxPLplotwindow.h:class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
./bindings/wxwidgets/wxPLplotstream.h:class PLDLLIMPEXP_WX wxPLplotstream : public plstream
./bindings/wxwidgets/deprecated_wxPLplotwindow.h:class PLDLLIMPEXP_WX wxPLplotwindow : public wxWindow
./bindings/wxwidgets/deprecated_wxPLplotstream.h.in:class PLDLLIMPEXP_WX wxPLplotstream : public plstream
./include/pldll.h.in:  #define PLDLLIMPEXP_WX    PLDLLEXPORT
./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )    PLDLLEXPORT type
./include/pldll.h.in:  #define PLDLLIMPEXP_WX    PLDLLIMPORT
./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )    PLDLLIMPORT type

Just in case you are curious about find, the above command says get me
all the names of all the files in the source tree, drop all the .git
ones (i.e., drop the git repository to focus on just files in the working directory),
then search all those remaining files for PLDLLIMPEXP_WX.  The result
was 9 hits (9 lines somewhere in our source tree files that refer to
PLDLLIMPEXP_WX).

>From these results, you can see that the way I use that macro in
wxPLplotwindow.h has also been used for a long time in
wxPLplotstream.h, deprecated_wxPLplotwindow.h, and
deprecated_wxPLplotstream.h.in.  Also, that macro is defined in
include/pldll.h.in (which as you will discover has some complicated
preprocessing logic).

N.B. Use of such *IMPEXP* macros is an integral part of our symbol visibility support.

> let me know if something on my patch is not clear

I slightly amended the commit message on your first (modified) commit
to indicate this complete fix would be in two commits, amended the
second (present) commit to put back PLDLLIMPEXP_WX again, greatly
expanded the commit message of that second commit using your own description
that you made in your post describing that commit, filled in a Tested
by: place-holding section for you that you should later fill out with
all the platforms you tested these two commits on, and finally added
my own Tested by: section.

Would you also look at one compiler warning I got because of the above
-Wuninitialized option?  Here was that complete warning:

/home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp: In member function ‘void wxPLplotwindow::setUseGraphicsContext(bool)’:
/home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp:326:33: warning: ‘drawDc’ may be used uninitialized in this function [-Wmaybe-uninitialized]
          m_stream.SetDC( drawDc );

A lot of the time such warnings are spurious so you have to quiet them
by initializing something that shouldn't really need it.  But
sometimes they really do point to a serious problem with something
that is uninitialized because of bad code logic.

Anyhow, please _amend_ (i.e., do not make a 3rd commit) your second
commit to either quiet this warning if it is spurious or deal with the
bad code logic if that turns out to be the issue, test these two
commits thoroughly on all your platforms including Windows, and fill
in the commit message Tested by: section of the second commit with
that platform list.

Quick directions again for amending the last commit on a topic branch.

If a file is changed (i.e., you fixed the above warning).  Then stage
that changed file with "git add" and get that change into your last
commit by using "git commit --amend".  If there are no file changes,
then simply use "git commit --amend" to modify the commit message of
the last commit.  Note amending a commit is very useful if you
have second thoughts about some aspect of it, want to update the
commit message or whatever.  But the --amend option only works
on the _last_ commit so make it a very strong habit to review your
last commit completely to make sure it is good before you make another
commit because that second commit makes it impossible to amend
the first.  (I used such care this time to amend the first commit
before applying your second commit and amending it.)

Also, once a commit is published (i.e., pushed to our SF server), then
it should never be amended or changed in any way, i.e., further
changes have to be made using further commits rather than modifying an
existing commit.  The reason for that "fundamental courtesy" rule is
someone could clone the SF git repository, and branch a new topic
branch off of any commit they desire, but if you subsequently modify
that particular _public_ branch commit in any way, they get completely
screwed.

I have attached a tarball containing your two commits (both of which
have been revised by me for this iteration as discussed above).  Apply
them both in numerical order to a new topic branch using "git am".  If
you get tired of running git am twice by hand in the correct order,
then use "git help am" to figure out how to do that with just one "git
am" command.

Then generate another iteration consisting of the first
(unchanged by you this time) commit, and the second commit that you revise
as above using

git format-patch -2

Then collect those two files in a tarball using

tar zcf wxwidgets_experimental_commits2.tar.gz 00*

and attach that result to a post to this list for Phil to look at
to make sure he understands and approves of the changes in these
two commits.

Half an hour ago it was the start of Christmas Eve day for me, and
that happened several hours ago for you and quite a while ago for
Phil.  So Merry Christmas and Happy New Year! to both of you and everybody else on this
list.

I will likely check my e-mail again in ~12 hours and again on
Christmas, and the 26th but I will totally understand if I don't here
anything from you until the 27th.  However, by early on that date, I
hope you will have prepared the two commits as specified above
including testing on all your platforms. And I hope we can get in
touch with Phil on that date to get his recommendation for what to do
with regard to those two revised commits and the release.

But right now I feel fairly confident about your two commits because
there exist at least two platforms where they appear to work.  But
hopefully you will have considerably expanded that number of "good"
platforms by the 27th!

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Linux testing

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

Hi Pedro

I hadn't realised you were accessing your machines remotely. I assumed that the VMs were local. Although I was accessing mu ubuntu remotely to, but using the cygwin x server. I'm not sure if the ubuntu bash on windows using xming counts as remote. Maybe this is the cause of the differences.
However we should try to work with this somehow.

However obviously Christmas is here. So I'm likely to be busy with family things until at least the 27th. I'll try to keep up with emails, but that's likely my limit. Maybe I need to actually dig into the wxGTK code and work out what happens properly.

Sent from my Windows 10 phone

From: Pedro Vicente
Sent: 24 December 2016 03:44
To: Alan W. Irwin; Phil Rosenberg; PLplot development list
Subject: Re: [Plplot-devel] Linux testing


@Alan

I changed the thread tittle, because I have all kinds of weird results on my 
comprehensing testing.

first the obvious:

items 1) to 3) below are for the master branch

1) a Fortran error on Ubuntu 14.04

this was a simple
cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install -DCMAKE_BUILD_TYPE=Debug 
 -DBUILD_TEST=ON
make VERBOSE=1 >& make.txt

but it detected gfortran and tried to build the fortran code.
output is attached

2)

then I disabled Fortran

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install -DCMAKE_BUILD_TYPE=Debug 
 -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DBUILD_TEST=ON
make VERBOSE=1
no errors

then (note , running from the build location)

pvicente@glace:~/plplot-plplot/build$ 
../scripts/comprehensive_test.sh --cmake_added_options 
"-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON 
 -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON -DENABLE_f95:BOOL=OFF" 
 --do_test_noninteractive no --do_ctest no

Each of the steps in this comprehensive test may take a while....
cmake in the build tree
ERROR: cmake in the build tree failed

How can I capture the output here? It asks for a interactive (yes/no), can I 
disable this and instead redirect the output to a file?


3)

On another Linux, 16.04,  where *I don't* have gfortran

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/plplot-install -DCMAKE_BUILD_TYPE=Debug 
  -DBUILD_TEST=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON
make VERBOSE=1
make VERBOSE=1 test_wxPLplotDemo

Infinite loop
22:25:42: Debug: Plot() Yielding

pvn@server:~/plplot-plplot/build$ 
../scripts/comprehensive_test.sh --cmake_added_options 
"-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON 
 -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON" --do_test_noninteractive 
no --do_ctest no

then it stays here (I suppose because of the infinite loop)
and I get a blank plviewer window

Each of the steps in this comprehensive test may take a while....
cmake in the build tree
make -j4 VERBOSE=1 test_interactive in the build tree

4)

results for my patch commit

@Phil
I was able to make the example 01 run with no runtime errors by 
re-introduncing the OnCreate() event (but also keeping the Create() call).
But then I got other errors.
I am not sure what are the consequences of these changes, so here it's 
better for me to wait until you provide some insight into this.

to do items:

1)

it would be great if any of you could reproduce my test_wxPLplotDemo 
behavior on Linux

the response from the developer


> This is not completely unexpected, the window is only really created when
> it's "realized" in GTK+/X11 terms, which can take quite some time, in
> particular if a remote X server is used


could this "remote X server is used" be because I am accesing my linux 
machines remotely ? (by using X2Go)


2)

maybe put the master back with one of the workarounds that I don't have the 
infinite loop,
so that I have a better idea of what happens in the comprehensing testing?

-Pedro

----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>; "Phil Rosenberg" 
<p.d...@gm...>; "PLplot development list" 
<plp...@li...>
Sent: Friday, December 23, 2016 5:19 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-23 16:43-0500 Pedro Vicente wrote:
>
>> by the way, what are the commands to do comprehensing testing?
>
> That script should be able to run on all Unix systems and Unix-like
> systems (i.e., Cygwin and MinGW-w64/MSYS2), but not currently for MSVC
> ("raw Windows").  However, Arjen plans to investigate a possibility for
> running that script on MSVC platforms as well in 2017.
>
> So for now, on Unix or Unix-like systems, I suggest you run
>
> scripts/comprehensive_test.sh --cmake_added_options 
> "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON 
>  -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON" --do_test_noninteractive 
> no --do_ctest no
>
> I used exactly those options recently myself.
>
> Those options are constraints on the script to keep it from doing
> time-consuming (several hours?) tests that you probably don't
> need/want to run right now.
>
> So my suggested options constrain the script to just test the
> plplotwxwidgets library and the wxwidgets device driver for our 3
> major configurations and 3 different build trees. (So you will see the
> tests repeat 9 times for those combinations.) There are no
> noninteractive tests of the wxwidgets device driver or plplotwxwidgets
> library.  But to avoid the non-interactive C++ tests, we further
> constrain the script above to avoid all the non-interactive testing.
>
> As a result of these constraints the script just builds the
> test_interactive target for our 9 combinations.  For each of those
> combinations, that target in turn depends on test_wxPLplotDemo (to
> test the plplotwxwidgets library) and test_c_wxwidgets (to test the
> wxwidgets device driver).  You can also reduce the combinations if you
> like using additional constraint options for the script.
>
> Run
>
> scripts/comprehensive_test.sh --help
>
> to see about those further possibilities if the 9 combinations turn
> out to be too much.  :-)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

Re: [Plplot-devel] Linux testing

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

On 2016-12-24 14:06-0000 p.d...@gm... wrote:

> Hi Pedro
>
> I hadn't realised you were accessing your machines remotely. I assumed that the VMs were local. Although I was accessing mu ubuntu remotely to, but using the cygwin x server. I'm not sure if the ubuntu bash on windows using xming counts as remote. Maybe this is the cause of the differences.
> However we should try to work with this somehow.

To Phil and Pedro:

Just for the record, virtually all of my results I reported were run
using an X-terminal (a zero-cost [someone threw it away in my
direction], low-power computer whose disk drive is now a USB stick)
for display, keyboard, and mouse, with the application running on a
comparatively more powerful remote computer (my wife's computer
"raven" in the same office, the 9-year old 2.4GHz box I have referred
to before). However, a couple of times I shifted to her computer and
keyboard so I was running the app and displaying on the same computer,
but that never made any noticable difference in the results.

<Semi-rant> So the classical X "network neutrality" appears to still
be working at least on Debian Jessie, although the way X has been
moving (toward Wayland, etc.) on Linux, that extremely useful network
neutrality will just be a low-priority afterthought in the future.  I
blame this bad trend on the X developers never touching or seeing
low-power boxes of any kind.  :-) </Semi-rant>

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

Hi Alan

Glad it's working !
I'll go through your email later, but a fix for the warning is just changing 
at line 313 of wxPLplotwindow.cpp
wxDC *drawDc;
to
wxDC *drawDc = NULL;
the warning is just because of the preprocessor macro
-Pedro
----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "Phil Rosenberg" <p.d...@gm...>; "PLplot development list" 
<Plp...@li...>
Sent: Saturday, December 24, 2016 3:42 AM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-24 01:13-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> some more upbeat news about the example error , it's gone :-)
>
> It's gone here too.  :-)
>
> So thanks very much Pedro for this early Christmas present!
>
> [...]
>> I also removed this "PLDLLIMPEXP_WX"
>>
>> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
>
> That change causes a build issue on Linux if you are using
>
> export CXXFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
> export CFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
> export FFLAGS="-O3 -Wuninitialized -Wunused"
>
> which I highly recommend on Linux to check for symbol visibility
> issues on that platform (and to partially check for visibility
> issues on Windows as well, but in this case it sounds like it
> was not needed, but it should do no harm on that platform.)
>
> So I had to amend your present (second) commit to put it back.
>
>> I searched  in all the source code and could not find this symbol ?
>
> The unix find command is good for such tasks:
>
> software@raven> find . -type f |grep -v .git |xargs grep PLDLLIMPEXP_WX
> ./bindings/wxwidgets/wxPLplot_nanosec.h.in:PLDLLIMPEXP_WX void
> ./bindings/wxwidgets/wxPLplotwindow.h:class PLDLLIMPEXP_WX wxPLplotwindow 
> : public wxFrame
> ./bindings/wxwidgets/wxPLplotstream.h:class PLDLLIMPEXP_WX wxPLplotstream 
> : public plstream
> ./bindings/wxwidgets/deprecated_wxPLplotwindow.h:class PLDLLIMPEXP_WX 
> wxPLplotwindow : public wxWindow
> ./bindings/wxwidgets/deprecated_wxPLplotstream.h.in:class PLDLLIMPEXP_WX 
> wxPLplotstream : public plstream
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX    PLDLLEXPORT
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )    PLDLLEXPORT 
> type
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX    PLDLLIMPORT
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )    PLDLLIMPORT 
> type
>
> Just in case you are curious about find, the above command says get me
> all the names of all the files in the source tree, drop all the .git
> ones (i.e., drop the git repository to focus on just files in the working 
> directory),
> then search all those remaining files for PLDLLIMPEXP_WX.  The result
> was 9 hits (9 lines somewhere in our source tree files that refer to
> PLDLLIMPEXP_WX).
>
> From these results, you can see that the way I use that macro in
> wxPLplotwindow.h has also been used for a long time in
> wxPLplotstream.h, deprecated_wxPLplotwindow.h, and
> deprecated_wxPLplotstream.h.in.  Also, that macro is defined in
> include/pldll.h.in (which as you will discover has some complicated
> preprocessing logic).
>
> N.B. Use of such *IMPEXP* macros is an integral part of our symbol 
> visibility support.
>
>> let me know if something on my patch is not clear
>
> I slightly amended the commit message on your first (modified) commit
> to indicate this complete fix would be in two commits, amended the
> second (present) commit to put back PLDLLIMPEXP_WX again, greatly
> expanded the commit message of that second commit using your own 
> description
> that you made in your post describing that commit, filled in a Tested
> by: place-holding section for you that you should later fill out with
> all the platforms you tested these two commits on, and finally added
> my own Tested by: section.
>
> Would you also look at one compiler warning I got because of the above
> -Wuninitialized option?  Here was that complete warning:
>
> /home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp: 
> In member function ‘void wxPLplotwindow::setUseGraphicsContext(bool)’:
> /home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp:326:33: 
> warning: ‘drawDc’ may be used uninitialized in this function 
> [-Wmaybe-uninitialized]
>          m_stream.SetDC( drawDc );
>
> A lot of the time such warnings are spurious so you have to quiet them
> by initializing something that shouldn't really need it.  But
> sometimes they really do point to a serious problem with something
> that is uninitialized because of bad code logic.
>
> Anyhow, please _amend_ (i.e., do not make a 3rd commit) your second
> commit to either quiet this warning if it is spurious or deal with the
> bad code logic if that turns out to be the issue, test these two
> commits thoroughly on all your platforms including Windows, and fill
> in the commit message Tested by: section of the second commit with
> that platform list.
>
> Quick directions again for amending the last commit on a topic branch.
>
> If a file is changed (i.e., you fixed the above warning).  Then stage
> that changed file with "git add" and get that change into your last
> commit by using "git commit --amend".  If there are no file changes,
> then simply use "git commit --amend" to modify the commit message of
> the last commit.  Note amending a commit is very useful if you
> have second thoughts about some aspect of it, want to update the
> commit message or whatever.  But the --amend option only works
> on the _last_ commit so make it a very strong habit to review your
> last commit completely to make sure it is good before you make another
> commit because that second commit makes it impossible to amend
> the first.  (I used such care this time to amend the first commit
> before applying your second commit and amending it.)
>
> Also, once a commit is published (i.e., pushed to our SF server), then
> it should never be amended or changed in any way, i.e., further
> changes have to be made using further commits rather than modifying an
> existing commit.  The reason for that "fundamental courtesy" rule is
> someone could clone the SF git repository, and branch a new topic
> branch off of any commit they desire, but if you subsequently modify
> that particular _public_ branch commit in any way, they get completely
> screwed.
>
> I have attached a tarball containing your two commits (both of which
> have been revised by me for this iteration as discussed above).  Apply
> them both in numerical order to a new topic branch using "git am".  If
> you get tired of running git am twice by hand in the correct order,
> then use "git help am" to figure out how to do that with just one "git
> am" command.
>
> Then generate another iteration consisting of the first
> (unchanged by you this time) commit, and the second commit that you revise
> as above using
>
> git format-patch -2
>
> Then collect those two files in a tarball using
>
> tar zcf wxwidgets_experimental_commits2.tar.gz 00*
>
> and attach that result to a post to this list for Phil to look at
> to make sure he understands and approves of the changes in these
> two commits.
>
> Half an hour ago it was the start of Christmas Eve day for me, and
> that happened several hours ago for you and quite a while ago for
> Phil.  So Merry Christmas and Happy New Year! to both of you and everybody 
> else on this
> list.
>
> I will likely check my e-mail again in ~12 hours and again on
> Christmas, and the 26th but I will totally understand if I don't here
> anything from you until the 27th.  However, by early on that date, I
> hope you will have prepared the two commits as specified above
> including testing on all your platforms. And I hope we can get in
> touch with Phil on that date to get his recommendation for what to do
> with regard to those two revised commits and the release.
>
> But right now I feel fairly confident about your two commits because
> there exist at least two platforms where they appear to work.  But
> hopefully you will have considerably expanded that number of "good"
> platforms by the 27th!
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________ 

Re: [Plplot-devel] Infinite Yielding issue

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

On 2016-12-24 12:36-0500 Pedro Vicente wrote:

> Hi Alan
>
> Glad it's working !
> I'll go through your email later, but a fix for the warning is just changing 
> at line 313 of wxPLplotwindow.cpp
> wxDC *drawDc;
> to
> wxDC *drawDc = NULL;
> the warning is just because of the preprocessor macro

Glad it is nothing serious.  Please go ahead and make the above change
to quiet the warning when you amend your second commit.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

Hi Alan

> Then collect those two files in a tarball using
>tar zcf wxwidgets_experimental_commits2.tar.gz 00*

I did the git am as explained, and
wxwidgets_experimental_commits2.tar.gz
is attached

examples/c/x01c -dev wxwidgets
and
test_wxPLplotDemo

run with no problems on all my tests

> Half an hour ago it was the start of Christmas Eve day for me, and
> that happened several hours ago for you and quite a while ago for
> Phil.  So Merry Christmas and Happy New Year! to both of you and everybody 
> else on this
> list.

Merry Christmas and Happy New Year as well to everyone

-Pedro


----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "Phil Rosenberg" <p.d...@gm...>; "PLplot development list" 
<Plp...@li...>
Sent: Saturday, December 24, 2016 3:42 AM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-24 01:13-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> some more upbeat news about the example error , it's gone :-)
>
> It's gone here too.  :-)
>
> So thanks very much Pedro for this early Christmas present!
>
> [...]
>> I also removed this "PLDLLIMPEXP_WX"
>>
>> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
>
> That change causes a build issue on Linux if you are using
>
> export CXXFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
> export CFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
> export FFLAGS="-O3 -Wuninitialized -Wunused"
>
> which I highly recommend on Linux to check for symbol visibility
> issues on that platform (and to partially check for visibility
> issues on Windows as well, but in this case it sounds like it
> was not needed, but it should do no harm on that platform.)
>
> So I had to amend your present (second) commit to put it back.
>
>> I searched  in all the source code and could not find this symbol ?
>
> The unix find command is good for such tasks:
>
> software@raven> find . -type f |grep -v .git |xargs grep PLDLLIMPEXP_WX
> ./bindings/wxwidgets/wxPLplot_nanosec.h.in:PLDLLIMPEXP_WX void
> ./bindings/wxwidgets/wxPLplotwindow.h:class PLDLLIMPEXP_WX wxPLplotwindow 
> : public wxFrame
> ./bindings/wxwidgets/wxPLplotstream.h:class PLDLLIMPEXP_WX wxPLplotstream 
> : public plstream
> ./bindings/wxwidgets/deprecated_wxPLplotwindow.h:class PLDLLIMPEXP_WX 
> wxPLplotwindow : public wxWindow
> ./bindings/wxwidgets/deprecated_wxPLplotstream.h.in:class PLDLLIMPEXP_WX 
> wxPLplotstream : public plstream
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX    PLDLLEXPORT
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )    PLDLLEXPORT 
> type
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX    PLDLLIMPORT
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )    PLDLLIMPORT 
> type
>
> Just in case you are curious about find, the above command says get me
> all the names of all the files in the source tree, drop all the .git
> ones (i.e., drop the git repository to focus on just files in the working 
> directory),
> then search all those remaining files for PLDLLIMPEXP_WX.  The result
> was 9 hits (9 lines somewhere in our source tree files that refer to
> PLDLLIMPEXP_WX).
>
> From these results, you can see that the way I use that macro in
> wxPLplotwindow.h has also been used for a long time in
> wxPLplotstream.h, deprecated_wxPLplotwindow.h, and
> deprecated_wxPLplotstream.h.in.  Also, that macro is defined in
> include/pldll.h.in (which as you will discover has some complicated
> preprocessing logic).
>
> N.B. Use of such *IMPEXP* macros is an integral part of our symbol 
> visibility support.
>
>> let me know if something on my patch is not clear
>
> I slightly amended the commit message on your first (modified) commit
> to indicate this complete fix would be in two commits, amended the
> second (present) commit to put back PLDLLIMPEXP_WX again, greatly
> expanded the commit message of that second commit using your own 
> description
> that you made in your post describing that commit, filled in a Tested
> by: place-holding section for you that you should later fill out with
> all the platforms you tested these two commits on, and finally added
> my own Tested by: section.
>
> Would you also look at one compiler warning I got because of the above
> -Wuninitialized option?  Here was that complete warning:
>
> /home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp: 
> In member function ‘void wxPLplotwindow::setUseGraphicsContext(bool)’:
> /home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp:326:33: 
> warning: ‘drawDc’ may be used uninitialized in this function 
> [-Wmaybe-uninitialized]
>          m_stream.SetDC( drawDc );
>
> A lot of the time such warnings are spurious so you have to quiet them
> by initializing something that shouldn't really need it.  But
> sometimes they really do point to a serious problem with something
> that is uninitialized because of bad code logic.
>
> Anyhow, please _amend_ (i.e., do not make a 3rd commit) your second
> commit to either quiet this warning if it is spurious or deal with the
> bad code logic if that turns out to be the issue, test these two
> commits thoroughly on all your platforms including Windows, and fill
> in the commit message Tested by: section of the second commit with
> that platform list.
>
> Quick directions again for amending the last commit on a topic branch.
>
> If a file is changed (i.e., you fixed the above warning).  Then stage
> that changed file with "git add" and get that change into your last
> commit by using "git commit --amend".  If there are no file changes,
> then simply use "git commit --amend" to modify the commit message of
> the last commit.  Note amending a commit is very useful if you
> have second thoughts about some aspect of it, want to update the
> commit message or whatever.  But the --amend option only works
> on the _last_ commit so make it a very strong habit to review your
> last commit completely to make sure it is good before you make another
> commit because that second commit makes it impossible to amend
> the first.  (I used such care this time to amend the first commit
> before applying your second commit and amending it.)
>
> Also, once a commit is published (i.e., pushed to our SF server), then
> it should never be amended or changed in any way, i.e., further
> changes have to be made using further commits rather than modifying an
> existing commit.  The reason for that "fundamental courtesy" rule is
> someone could clone the SF git repository, and branch a new topic
> branch off of any commit they desire, but if you subsequently modify
> that particular _public_ branch commit in any way, they get completely
> screwed.
>
> I have attached a tarball containing your two commits (both of which
> have been revised by me for this iteration as discussed above).  Apply
> them both in numerical order to a new topic branch using "git am".  If
> you get tired of running git am twice by hand in the correct order,
> then use "git help am" to figure out how to do that with just one "git
> am" command.
>
> Then generate another iteration consisting of the first
> (unchanged by you this time) commit, and the second commit that you revise
> as above using
>
> git format-patch -2
>
> Then collect those two files in a tarball using
>
> tar zcf wxwidgets_experimental_commits2.tar.gz 00*
>
> and attach that result to a post to this list for Phil to look at
> to make sure he understands and approves of the changes in these
> two commits.
>
> Half an hour ago it was the start of Christmas Eve day for me, and
> that happened several hours ago for you and quite a while ago for
> Phil.  So Merry Christmas and Happy New Year! to both of you and everybody 
> else on this
> list.
>
> I will likely check my e-mail again in ~12 hours and again on
> Christmas, and the 26th but I will totally understand if I don't here
> anything from you until the 27th.  However, by early on that date, I
> hope you will have prepared the two commits as specified above
> including testing on all your platforms. And I hope we can get in
> touch with Phil on that date to get his recommendation for what to do
> with regard to those two revised commits and the release.
>
> But right now I feel fairly confident about your two commits because
> there exist at least two platforms where they appear to work.  But
> hopefully you will have considerably expanded that number of "good"
> platforms by the 27th!
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________ 

Re: [Plplot-devel] Infinite Yielding issue

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

On 2016-12-24 20:24-0500 Pedro Vicente wrote:

> Hi Alan
>
>> Then collect those two files in a tarball using
>> tar zcf wxwidgets_experimental_commits2.tar.gz 00*
>
> I did the git am as explained, and
> wxwidgets_experimental_commits2.tar.gz
> is attached
>
> examples/c/x01c -dev wxwidgets
> and
> test_wxPLplotDemo
>
> run with no problems on all my tests
>

Hi Pedro:

Thanks very much for that compiler warning fix and big testing effort
on a Windows platform and 4 Linux platforms for this latest iteration
of your two-commit fix.

I tested this latest version here in the same way I did the previous
iteration, and all was well.

Now that we have such a widely tested solution, would you be willing
to write a short summary paragraph concerning the changes in the
plplotwxwidgets library API?  I cannot write such a summary myself
because I don't know the correct C++ terminology to use.

That summary would likely help Phil make up his mind about whether we
will adopt your latest iteration of the fix or try something else.
However, please write that paragraph with a somewhat larger audience in mind
than just Phil.  Because if he decides to go with your fix, then I
will want to include your summary paragraph in our release notes to
aid those (like you and Greg Jung) who are developing their own
applications and libraries that link with the plplotwxwidgets library
and who will therefore have to change those applications and libraries
to be compatible with our changes.  So the summary should answer the
question what is the minimum that an outside developer need to know about the
the changes to the plplotwxwidgets library API?

To help you figure out what to say, here is how to discover the
changes since plplot-5.11.1 in the library API and our demo that links
with that library:

git diff --ignore-all-space plplot-5.11.1 bindings/wxwidgets/*.h

git diff --ignore-all-space plplot-5.11.1 examples/c++/wxPLplotDemo.cpp

Obviously, the extra include to allow for the possibility of debugging
output in bindings/wxwidgets/wxPLplotstream.h is not an API change,
but it looks like there have been substantial backwards-incompatible
changes in the plplotwxwidgets library API as indicated by
the changes in bindings/wxwidgets/wxPLplotwindow.h.

Those API changes appear also to be confirmed by that second git diff
result above (although some of those changes were an addition of a
locate mode and nothing to do with API changes so your summary doesn't
need to mention that locate mode addition).

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

@Alan, Phil

> Now that we have such a widely tested solution, would you be willing
> to write a short summary paragraph concerning the changes in the
> plplotwxwidgets library API?

here it goes. The API really has no visible changes, but has a loss of 
functionality
(use of templates, i.e, ability to do plots other than in wxFrame windows)

"Fixed a bug that happened in test_wxPLplotDemo for  some Linux 
configurations.
 The effect of the bug was a segmentation fault, due to the fact that an 
invalid
plot stream pointer was used. The cause of the stream pointer being invalid
is that the frame window did not initialize in a timely manner. This 
behaviour is a
wxWidgets feature that can or cannot happen in GTK/X11 window systems.
The solution for test_wxPLplotDemo was to initialize the stream in the 
function
Create(), which is done immediatley, instead of doing it on the function 
OnCreate(),
that is called later and executed at an indeterminated time. Note: the 
possiblility and request of creating
the stream in OnCreate() is still present, because this is a feature of the 
driver needed elsewhere.
A side effect of creating the new function Create() for the class 
wxPLplotwindow,
is that the class cannot be a template. At this time the class is descendant 
from
wxFrame, so only wxFrame windows can be created."


> To help you figure out what to say, here is how to discover the
> changes since plplot-5.11.1 in the library API and our demo that links
> with that library:
>
> git diff --ignore-all-space plplot-5.11.1 bindings/wxwidgets/*.h


I did not got back in time this way, because all the other changes were made 
by Phil.

Basically what I did was start with the current master of wxPLplotwindow and

1) override a function Create()
2) do an auxilirary function CreateStream() that contains the code that was 
previously in
OnCreate(). This function is both called by Create() and OnCreate(). A 
boolean
flag assures that is only executed 1 time.
3) Moved the event trigering that was previously on the wxPLplotwindow 
constructor
by ::Connect() calls
to a static event table

This change 3) was not really needed, it was just to reflect the current way 
of handling events

http://docs.wxwidgets.org/3.1/overview_events.html

either by the static event table or by ::Bind()


feel free to change anything in the description.
I did not mention the new debug print option of wxWidgets in cmake,
because you implemented that feature, but that should be mentioned also.


-Pedro






----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "Phil Rosenberg" <p.d...@gm...>; "PLplot development list" 
<Plp...@li...>
Sent: Monday, December 26, 2016 5:09 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-24 20:24-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>>> Then collect those two files in a tarball using
>>> tar zcf wxwidgets_experimental_commits2.tar.gz 00*
>>
>> I did the git am as explained, and
>> wxwidgets_experimental_commits2.tar.gz
>> is attached
>>
>> examples/c/x01c -dev wxwidgets
>> and
>> test_wxPLplotDemo
>>
>> run with no problems on all my tests
>>
>
> Hi Pedro:
>
> Thanks very much for that compiler warning fix and big testing effort
> on a Windows platform and 4 Linux platforms for this latest iteration
> of your two-commit fix.
>
> I tested this latest version here in the same way I did the previous
> iteration, and all was well.
>
> Now that we have such a widely tested solution, would you be willing
> to write a short summary paragraph concerning the changes in the
> plplotwxwidgets library API?  I cannot write such a summary myself
> because I don't know the correct C++ terminology to use.
>
> That summary would likely help Phil make up his mind about whether we
> will adopt your latest iteration of the fix or try something else.
> However, please write that paragraph with a somewhat larger audience in 
> mind
> than just Phil.  Because if he decides to go with your fix, then I
> will want to include your summary paragraph in our release notes to
> aid those (like you and Greg Jung) who are developing their own
> applications and libraries that link with the plplotwxwidgets library
> and who will therefore have to change those applications and libraries
> to be compatible with our changes.  So the summary should answer the
> question what is the minimum that an outside developer need to know about 
> the
> the changes to the plplotwxwidgets library API?
>
> To help you figure out what to say, here is how to discover the
> changes since plplot-5.11.1 in the library API and our demo that links
> with that library:
>
> git diff --ignore-all-space plplot-5.11.1 bindings/wxwidgets/*.h
>
> git diff --ignore-all-space plplot-5.11.1 examples/c++/wxPLplotDemo.cpp
>
> Obviously, the extra include to allow for the possibility of debugging
> output in bindings/wxwidgets/wxPLplotstream.h is not an API change,
> but it looks like there have been substantial backwards-incompatible
> changes in the plplotwxwidgets library API as indicated by
> the changes in bindings/wxwidgets/wxPLplotwindow.h.
>
> Those API changes appear also to be confirmed by that second git diff
> result above (although some of those changes were an addition of a
> locate mode and nothing to do with API changes so your summary doesn't
> need to mention that locate mode addition).
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

Re: [Plplot-devel] Infinite Yielding issue

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

On 2016-12-26 21:30-0500 Pedro Vicente wrote:

> @Alan, Phil
>
>> Now that we have such a widely tested solution, would you be willing
>> to write a short summary paragraph concerning the changes in the
>> plplotwxwidgets library API?
>
> here it goes. The API really has no visible changes, but has a loss of 
> functionality
> (use of templates, i.e, ability to do plots other than in wxFrame windows)

@Phil and Pedro:

Isn't that loss of functionality by definition a backwards
incompatibility in the API for the plplotwxwidgets library?  If Phil
and you confirm that interpretation, I will need to warn about
that in the release notes.

Important questions below for Phil.

>
> "Fixed a bug that happened in test_wxPLplotDemo for  some Linux 
> configurations.
> The effect of the bug was a segmentation fault, due to the fact that an 
> invalid
> plot stream pointer was used. The cause of the stream pointer being invalid
> is that the frame window did not initialize in a timely manner. This 
> behaviour is a
> wxWidgets feature that can or cannot happen in GTK/X11 window systems.
> The solution for test_wxPLplotDemo was to initialize the stream in the 
> function
> Create(), which is done immediatley, instead of doing it on the function 
> OnCreate(),
> that is called later and executed at an indeterminated time. Note: the 
> possiblility and request of creating
> the stream in OnCreate() is still present, because this is a feature of the 
> driver needed elsewhere.
> A side effect of creating the new function Create() for the class 
> wxPLplotwindow,
> is that the class cannot be a template. At this time the class is descendant 
> from
> wxFrame, so only wxFrame windows can be created."
>
>
>> To help you figure out what to say, here is how to discover the
>> changes since plplot-5.11.1 in the library API and our demo that links
>> with that library:
>> 
>> git diff --ignore-all-space plplot-5.11.1 bindings/wxwidgets/*.h
>
>
> I did not got back in time this way, because all the other changes were made 
> by Phil.
>
> Basically what I did was start with the current master of wxPLplotwindow and
>
> 1) override a function Create()
> 2) do an auxilirary function CreateStream() that contains the code that was 
> previously in
> OnCreate(). This function is both called by Create() and OnCreate(). A 
> boolean
> flag assures that is only executed 1 time.
> 3) Moved the event trigering that was previously on the wxPLplotwindow 
> constructor
> by ::Connect() calls
> to a static event table
>
> This change 3) was not really needed, it was just to reflect the current way 
> of handling events
>
> http://docs.wxwidgets.org/3.1/overview_events.html
>
> either by the static event table or by ::Bind()
>
>
> feel free to change anything in the description.

@ Pedro:

Thanks for the above description of what you did.

@Phil:

I need your answers to the following questions.

1. Can you spot any release-critical issues with Pedro's present
    two-commit fix (i.e., any trouble you can forsee for our Unix
    and/or Windows users if we release with this)?

2. Are there any essential short-term changes you want to make to his
    approach for this release?  (Essential here means release-critical
    as used in question 1.)

3. Are there any long-term (post-release) changes you want to make to
    his approach?

Your answers to these questions are release critical so I would
appreciate your timely response to them.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

@Alan

> Isn't that loss of functionality by definition a backwards
> incompatibility in the API for the plplotwxwidgets library?

yes

but for the current (5.11.1) release compared to the new implemented 
examples,
the effect is the same

previously the way to start the demo was

wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();

and now is

wxPLplotwindow *frame = new wxPLplotwindow();

and because wxPLplotwindow is a child of a wxFrame,
the visible effect is exactly the same, a frame window that shows a 
plot.

-Pedro



On 2016-12-27 02:12, Alan W. Irwin wrote:
> On 2016-12-26 21:30-0500 Pedro Vicente wrote:
>
>> @Alan, Phil
>>
>>> Now that we have such a widely tested solution, would you be 
>>> willing
>>> to write a short summary paragraph concerning the changes in the
>>> plplotwxwidgets library API?
>>
>> here it goes. The API really has no visible changes, but has a loss 
>> of functionality
>> (use of templates, i.e, ability to do plots other than in wxFrame 
>> windows)
>
> @Phil and Pedro:
>
> Isn't that loss of functionality by definition a backwards
> incompatibility in the API for the plplotwxwidgets library?  If Phil
> and you confirm that interpretation, I will need to warn about
> that in the release notes.
>
> Important questions below for Phil.
>
>>
>> "Fixed a bug that happened in test_wxPLplotDemo for  some Linux 
>> configurations.
>> The effect of the bug was a segmentation fault, due to the fact that 
>> an invalid
>> plot stream pointer was used. The cause of the stream pointer being 
>> invalid
>> is that the frame window did not initialize in a timely manner. This 
>> behaviour is a
>> wxWidgets feature that can or cannot happen in GTK/X11 window 
>> systems.
>> The solution for test_wxPLplotDemo was to initialize the stream in 
>> the function
>> Create(), which is done immediatley, instead of doing it on the 
>> function OnCreate(),
>> that is called later and executed at an indeterminated time. Note: 
>> the possiblility and request of creating
>> the stream in OnCreate() is still present, because this is a feature 
>> of the driver needed elsewhere.
>> A side effect of creating the new function Create() for the class 
>> wxPLplotwindow,
>> is that the class cannot be a template. At this time the class is 
>> descendant from
>> wxFrame, so only wxFrame windows can be created."
>>
>>
>>> To help you figure out what to say, here is how to discover the
>>> changes since plplot-5.11.1 in the library API and our demo that 
>>> links
>>> with that library:
>>> git diff --ignore-all-space plplot-5.11.1 bindings/wxwidgets/*.h
>>
>>
>> I did not got back in time this way, because all the other changes 
>> were made by Phil.
>>
>> Basically what I did was start with the current master of 
>> wxPLplotwindow and
>>
>> 1) override a function Create()
>> 2) do an auxilirary function CreateStream() that contains the code 
>> that was previously in
>> OnCreate(). This function is both called by Create() and OnCreate(). 
>> A boolean
>> flag assures that is only executed 1 time.
>> 3) Moved the event trigering that was previously on the 
>> wxPLplotwindow constructor
>> by ::Connect() calls
>> to a static event table
>>
>> This change 3) was not really needed, it was just to reflect the 
>> current way of handling events
>>
>> http://docs.wxwidgets.org/3.1/overview_events.html
>>
>> either by the static event table or by ::Bind()
>>
>>
>> feel free to change anything in the description.
>
> @ Pedro:
>
> Thanks for the above description of what you did.
>
> @Phil:
>
> I need your answers to the following questions.
>
> 1. Can you spot any release-critical issues with Pedro's present
>    two-commit fix (i.e., any trouble you can forsee for our Unix
>    and/or Windows users if we release with this)?
>
> 2. Are there any essential short-term changes you want to make to his
>    approach for this release?  (Essential here means release-critical
>    as used in question 1.)
>
> 3. Are there any long-term (post-release) changes you want to make to
>    his approach?
>
> Your answers to these questions are release critical so I would
> appreciate your timely response to them.
>
> 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
> __________________________

-- 
Pedro Vicente
ped...@sp...
http://www.space-research.org/

Re: [Plplot-devel] Infinite Yielding issue

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

On 2016-12-27 10:09-0500 Pedro Vicente wrote:

> @Alan
>
>> Isn't that loss of functionality by definition a backwards
>> incompatibility in the API for the plplotwxwidgets library?
>
> yes
>
> but for the current (5.11.1) release compared to the new implemented 
> examples,
> the effect is the same
>
> previously the way to start the demo was
>
> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>
> and now is
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>
> and because wxPLplotwindow is a child of a wxFrame,
> the visible effect is exactly the same, a frame window that shows a plot.

@Pedro:

Thanks for that clarification.  So if users stick with the old way of
creating frame they will get a build error (which I assume is the
reason why Laurent is now getting build errors with his own code that
links to the plplotwxwidgets library).  I do not say that in a
critical way since if the choices are unreliability on some platforms
versus changing our API in a backwards-incompatible way, then we must
take the latter choice.

@Phil:

Do you agree with Pedro there is no obvious way out of this choice? If
so, then so be it, but we do have to warn users in the release notes
of this backwards-incompatible change.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

@Alan

> So if users stick with the old way of
> creating frame they will get a build error

yes

However, there is something we could try, which is,
keep the current way of wxPLplotwindow beging a template,
and at the same time overriding the Create() function (with template).

this could mean that the template would only work for wxFrame, like
now

wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();

but that would not break current applications

I'll try that later today

-Pedro


On 2016-12-27 12:58, Alan W. Irwin wrote:
> On 2016-12-27 10:09-0500 Pedro Vicente wrote:
>
>> @Alan
>>
>>> Isn't that loss of functionality by definition a backwards
>>> incompatibility in the API for the plplotwxwidgets library?
>>
>> yes
>>
>> but for the current (5.11.1) release compared to the new implemented 
>> examples,
>> the effect is the same
>>
>> previously the way to start the demo was
>>
>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>
>> and now is
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>
>> and because wxPLplotwindow is a child of a wxFrame,
>> the visible effect is exactly the same, a frame window that shows a 
>> plot.
>
> @Pedro:
>
> Thanks for that clarification.  So if users stick with the old way of
> creating frame they will get a build error (which I assume is the
> reason why Laurent is now getting build errors with his own code that
> links to the plplotwxwidgets library).  I do not say that in a
> critical way since if the choices are unreliability on some platforms
> versus changing our API in a backwards-incompatible way, then we must
> take the latter choice.
>
> @Phil:
>
> Do you agree with Pedro there is no obvious way out of this choice? 
> If
> so, then so be it, but we do have to warn users in the release notes
> of this backwards-incompatible change.
>
> 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
> __________________________

-- 
Pedro Vicente
ped...@sp...
http://www.space-research.org/

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

@Alan, Phil


>However, there is something we could try, which is,
>keep the current way of wxPLplotwindow beging a template,
>and at the same time overriding the Create() function (with template).

ok, I implemented this, attached

this

1) will not break current template use
2) will fix the bug

Limitation:
template can only be used with wxFrame (or a class that implements 
Create() with the same
signature)

test demo and example 01 run OK in CentOS, output is below



14:42:47: Debug: wxPLplotwindow::wxPLplotwindow
14:42:47: Debug: wxPLplotwindow::Create()
14:42:47: Debug: wxPLplotwindow::CreateStream()
14:42:47: Debug: plD_init_wxwidgets(): enter
14:42:47: Debug: wxPLDevice(): enter
14:42:47: Debug: wxPLDevice(): gc done
14:42:47: Debug: wxPLDevice(): m_interactiveTextGcdc done
14:42:47: Debug: wxPLDevice(): SetDC done
14:42:47: Debug: wxPLDevice(): leave
14:42:47: Debug: plD_init_wxwidgets(): leave
14:42:47: Debug: frame->Create
14:42:47: Debug: Plot()
14:42:48: Debug: wxPLplotwindow::OnCreate
14:42:48: Debug: wxPLplotwindow::CreateStream()



On 2016-12-27 12:58, Alan W. Irwin wrote:
> On 2016-12-27 10:09-0500 Pedro Vicente wrote:
>
>> @Alan
>>
>>> Isn't that loss of functionality by definition a backwards
>>> incompatibility in the API for the plplotwxwidgets library?
>>
>> yes
>>
>> but for the current (5.11.1) release compared to the new implemented 
>> examples,
>> the effect is the same
>>
>> previously the way to start the demo was
>>
>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>
>> and now is
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>
>> and because wxPLplotwindow is a child of a wxFrame,
>> the visible effect is exactly the same, a frame window that shows a 
>> plot.
>
> @Pedro:
>
> Thanks for that clarification.  So if users stick with the old way of
> creating frame they will get a build error (which I assume is the
> reason why Laurent is now getting build errors with his own code that
> links to the plplotwxwidgets library).  I do not say that in a
> critical way since if the choices are unreliability on some platforms
> versus changing our API in a backwards-incompatible way, then we must
> take the latter choice.
>
> @Phil:
>
> Do you agree with Pedro there is no obvious way out of this choice? 
> If
> so, then so be it, but we do have to warn users in the release notes
> of this backwards-incompatible change.
>
> 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
> __________________________

-- 
Pedro Vicente
ped...@sp...
http://www.space-research.org/

Re: [Plplot-devel] Infinite Yielding issue

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

This is really brief, I think we are all getting a little overexcited here very close to the release date.

This is a functionality reducing, backwards incompatible API change. I know for one that it will not only cause build errors in some of my code, but because I use wxPLplotwindow<wxPanel> classes in some of my code it will mean I have to revert to using wxPLstream and duplicate all the code from wxPLplotwindow to restore my functionality. This is why I made the class templated in the first place. It also future proofs us for future wxWindow derived classes and significantly eases linking problems. So there are very good design reasons for the current state.

That said, if we really can't solve the current problems with the existing model, then we should change. However we certainly should not do that in a rushed manner in the days leading up to release.

Note that up to now the bug Pedro reported exists on one remote x server. It does not appear to affect the Cygwin x server when used remotely, nor Xming. I would suggest that if we wish to release approximately on time, then we restore the previous API and release with a note saying that this remote X server has a compatibility issue and that users should check the git repo for updates.

Meanwhile I can still think of two or three ways we can quite likely sort this without losing functionality or generating backwards incompatible changes. But trying to do that over the Christmas break is just not doable for me. I can start looking at it properly in january.

Also would it be possible to make use of trac to keep up to date on this issue? There are now a number of threads all referring to this problem/change in different ways with cross posting that means chronology doesn't make sense and I'm finding it impossible in the time I have to make sense of it all.

So it turns out that this was not as brief as I hoped, but I hope you get my intention. In particular, I'm hugely grateful Pedro for your efforts on this. You've done a huge amount to push towards fixing this. It is easy for the tone of an email to be misinterpreted as grumpy, but please don’t think this is the case here – in fact the opposite, it's great to see interest in the device, but I think we all just need to take a breath, remember that some of us have young children and that this time of year means that PLplot is not everyone's top priority.

Does that make sense?

Sent from my Windows 10 phone

From: Pedro Vicente
Sent: 27 December 2016 19:46
To: Alan W. Irwin
Cc: Phil Rosenberg; PLplot development list
Subject: Re: [Plplot-devel] Infinite Yielding issue

@Alan, Phil


>However, there is something we could try, which is,
>keep the current way of wxPLplotwindow beging a template,
>and at the same time overriding the Create() function (with template).

ok, I implemented this, attached

this

1) will not break current template use
2) will fix the bug

Limitation:
template can only be used with wxFrame (or a class that implements 
Create() with the same
signature)

test demo and example 01 run OK in CentOS, output is below



14:42:47: Debug: wxPLplotwindow::wxPLplotwindow
14:42:47: Debug: wxPLplotwindow::Create()
14:42:47: Debug: wxPLplotwindow::CreateStream()
14:42:47: Debug: plD_init_wxwidgets(): enter
14:42:47: Debug: wxPLDevice(): enter
14:42:47: Debug: wxPLDevice(): gc done
14:42:47: Debug: wxPLDevice(): m_interactiveTextGcdc done
14:42:47: Debug: wxPLDevice(): SetDC done
14:42:47: Debug: wxPLDevice(): leave
14:42:47: Debug: plD_init_wxwidgets(): leave
14:42:47: Debug: frame->Create
14:42:47: Debug: Plot()
14:42:48: Debug: wxPLplotwindow::OnCreate
14:42:48: Debug: wxPLplotwindow::CreateStream()



On 2016-12-27 12:58, Alan W. Irwin wrote:
> On 2016-12-27 10:09-0500 Pedro Vicente wrote:
>
>> @Alan
>>
>>> Isn't that loss of functionality by definition a backwards
>>> incompatibility in the API for the plplotwxwidgets library?
>>
>> yes
>>
>> but for the current (5.11.1) release compared to the new implemented 
>> examples,
>> the effect is the same
>>
>> previously the way to start the demo was
>>
>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>
>> and now is
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>
>> and because wxPLplotwindow is a child of a wxFrame,
>> the visible effect is exactly the same, a frame window that shows a 
>> plot.
>
> @Pedro:
>
> Thanks for that clarification.  So if users stick with the old way of
> creating frame they will get a build error (which I assume is the
> reason why Laurent is now getting build errors with his own code that
> links to the plplotwxwidgets library).  I do not say that in a
> critical way since if the choices are unreliability on some platforms
> versus changing our API in a backwards-incompatible way, then we must
> take the latter choice.
>
> @Phil:
>
> Do you agree with Pedro there is no obvious way out of this choice? 
> If
> so, then so be it, but we do have to warn users in the release notes
> of this backwards-incompatible change.
>
> 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
> __________________________

-- 
Pedro Vicente
ped...@sp...
http://www.space-research.org/

Re: [Plplot-devel] Infinite Yielding issue

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

Hi Phil:

You have made many good points.  For example, I wholeheartedly second
your comment "In particular, I'm hugely grateful Pedro for your
efforts on this." Also, I completely agree with you it is bad to even
attempt to release anywhere near the Christmas holidays.  My
apologies for getting us into that situation which I propose to
rectify by putting the release on hold until you fix this issue.
See more on that below.

On 2016-12-27 23:21-0000 p.d...@gm... wrote:

> Note that up to now the bug Pedro reported exists on one remote x
server. It does not appear to affect the Cygwin x server when used
remotely, nor Xming. I would suggest that if we wish to release
approximately on time, then we restore the previous API and release
with a note saying that this remote X server has a compatibility issue
and that users should check the git repo for updates.

This summary of the limited nature of the issue may have been correct at
one point but unfortunately it is not correct now.

For example, the tip of the master branch bombs for me (Debian Jessie
with either remote X display with an X terminal or direct X display)
right now with the infinite Yielding loop generated whenever I build
the test_wxPLplotDemo target.  And I am virtually positive you would
run into the same situation if you made the same test on your Ubuntu
platform because I don't think there is anything particularly special
about Debian Jessie's version of the wxwidgets and gtk+ libraries.

All the latest wx-related commits for master tip are yours, e.g.,

995e75e Made some items clearer in the wxWigdets Demo
65e7b3c Fix bug with plotting in wxPLplotDemo
67ef7be Added a function to check if the window is ready to accept plot commands.
bf79603 Revert "wxwidgets binding: workaround fix for delayed OnCreate event"
c111bad Revert "wxwidgets binding: modification of workaround fix for delayed OnCreate event"
ca58e7c Use /dev/urandom in preference to /dev/random in wxWidgets driver.

And two of those reverted Pedro's commits so I don't think there is
anything of Pedro's in master tip right now.  So if I really did wish
to make a rushed release in the next few days, you would have to tell
me which of your commits above you think should be reverted.  And I
think we both prefer you take the time to make a solid fix instead
before we release!

> Meanwhile I can still think of two or three ways we can quite likely
sort this without losing functionality or generating backwards
incompatible changes. But trying to do that over the Christmas break
is just not doable for me. I can start looking at it properly in
january.

OK.  Please do that, and I will do what I should have done from the
start which is to delay the release until you have properly solved
this release-critical 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
__________________________

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

Hi Phil

The removal of the templates does not need to be done after all.
see my email from 
today 2.46 PM  "Infinite Yielding issue"
that has a git patch or my 
3.16PM email that has the actual source code files.

I'll send more details, once we get all in sync in communication.

-Pedro








  ----- Original Message ----- 
  From: p.d...@gm... 
  To: Pedro Vicente ; Alan W. Irwin 
  Cc: PLplot development list 
  Sent: Tuesday, December 27, 2016 6:21 PM
  Subject: RE: [Plplot-devel] Infinite Yielding issue


  This is really brief, I think we are all getting a little overexcited here very close to the release date.

   

  This is a functionality reducing, backwards incompatible API change. I know for one that it will not only cause build errors in some of my code, but because I use wxPLplotwindow<wxPanel> classes in some of my code it will mean I have to revert to using wxPLstream and duplicate all the code from wxPLplotwindow to restore my functionality. This is why I made the class templated in the first place. It also future proofs us for future wxWindow derived classes and significantly eases linking problems. So there are very good design reasons for the current state.

   

  That said, if we really can't solve the current problems with the existing model, then we should change. However we certainly should not do that in a rushed manner in the days leading up to release.

   

  Note that up to now the bug Pedro reported exists on one remote x server. It does not appear to affect the Cygwin x server when used remotely, nor Xming. I would suggest that if we wish to release approximately on time, then we restore the previous API and release with a note saying that this remote X server has a compatibility issue and that users should check the git repo for updates.

   

  Meanwhile I can still think of two or three ways we can quite likely sort this without losing functionality or generating backwards incompatible changes. But trying to do that over the Christmas break is just not doable for me. I can start looking at it properly in january.

   

  Also would it be possible to make use of trac to keep up to date on this issue? There are now a number of threads all referring to this problem/change in different ways with cross posting that means chronology doesn't make sense and I'm finding it impossible in the time I have to make sense of it all.

   

  So it turns out that this was not as brief as I hoped, but I hope you get my intention. In particular, I'm hugely grateful Pedro for your efforts on this. You've done a huge amount to push towards fixing this. It is easy for the tone of an email to be misinterpreted as grumpy, but please don’t think this is the case here – in fact the opposite, it's great to see interest in the device, but I think we all just need to take a breath, remember that some of us have young children and that this time of year means that PLplot is not everyone's top priority.

   

  Does that make sense?

   

  Sent from my Windows 10 phone

   

  From: Pedro Vicente
  Sent: 27 December 2016 19:46
  To: Alan W. Irwin
  Cc: Phil Rosenberg; PLplot development list
  Subject: Re: [Plplot-devel] Infinite Yielding issue

   

  @Alan, Phil

   

   

  >However, there is something we could try, which is,

  >keep the current way of wxPLplotwindow beging a template,

  >and at the same time overriding the Create() function (with template).

   

  ok, I implemented this, attached

   

  this

   

  1) will not break current template use

  2) will fix the bug

   

  Limitation:

  template can only be used with wxFrame (or a class that implements 

  Create() with the same

  signature)

   

  test demo and example 01 run OK in CentOS, output is below

   

   

   

  14:42:47: Debug: wxPLplotwindow::wxPLplotwindow

  14:42:47: Debug: wxPLplotwindow::Create()

  14:42:47: Debug: wxPLplotwindow::CreateStream()

  14:42:47: Debug: plD_init_wxwidgets(): enter

  14:42:47: Debug: wxPLDevice(): enter

  14:42:47: Debug: wxPLDevice(): gc done

  14:42:47: Debug: wxPLDevice(): m_interactiveTextGcdc done

  14:42:47: Debug: wxPLDevice(): SetDC done

  14:42:47: Debug: wxPLDevice(): leave

  14:42:47: Debug: plD_init_wxwidgets(): leave

  14:42:47: Debug: frame->Create

  14:42:47: Debug: Plot()

  14:42:48: Debug: wxPLplotwindow::OnCreate

  14:42:48: Debug: wxPLplotwindow::CreateStream()

   

   

   

  On 2016-12-27 12:58, Alan W. Irwin wrote:

  > On 2016-12-27 10:09-0500 Pedro Vicente wrote:

  > 

  >> @Alan

  >> 

  >>> Isn't that loss of functionality by definition a backwards

  >>> incompatibility in the API for the plplotwxwidgets library?

  >> 

  >> yes

  >> 

  >> but for the current (5.11.1) release compared to the new implemented 

  >> examples,

  >> the effect is the same

  >> 

  >> previously the way to start the demo was

  >> 

  >> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();

  >> 

  >> and now is

  >> 

  >> wxPLplotwindow *frame = new wxPLplotwindow();

  >> 

  >> and because wxPLplotwindow is a child of a wxFrame,

  >> the visible effect is exactly the same, a frame window that shows a 

  >> plot.

  > 

  > @Pedro:

  > 

  > Thanks for that clarification.  So if users stick with the old way of

  > creating frame they will get a build error (which I assume is the

  > reason why Laurent is now getting build errors with his own code that

  > links to the plplotwxwidgets library).  I do not say that in a

  > critical way since if the choices are unreliability on some platforms

  > versus changing our API in a backwards-incompatible way, then we must

  > take the latter choice.

  > 

  > @Phil:

  > 

  > Do you agree with Pedro there is no obvious way out of this choice? 

  > If

  > so, then so be it, but we do have to warn users in the release notes

  > of this backwards-incompatible change.

  > 

  > 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

  > __________________________

   

  -- 

  Pedro Vicente

  ped...@sp...

  http://www.space-research.org/

   

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

Hi Alan

I applied the patch on CentOS;
no errors on build
wxPLplotwindow demo does the plot
same error on the same example

I have a small suggestion:
instead of emailling patches and applyting them to multiple machines (I 
have 4)
what about doing a remote branch called "development"  and just commmit 
and push directly there,
even if you get errors like this?
that would make sharing more immediate

I'll take a llok at those errors later

results:

I got this warning

[pedro.vicente@rhw9121 plplot-plplot]$ git am < 
0001-wxwidgets-binding-fix-for-delayed-OnCreate-event.patch
Applying: wxwidgets binding: fix for delayed OnCreate event
.git/rebase-apply/patch:355: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

then

make VERBOSE=1 test_wxPLplotDemo

15:06:20: Debug: wxPLplotwindow::wxPLplotwindow
15:06:20: Debug: wxPLplotwindow::Create()
15:06:20: Debug: wxPLplotwindow::CreateFrame()
15:06:20: Debug: plD_init_wxwidgets(): enter
15:06:20: Debug: wxPLDevice(): enter
15:06:20: Debug: wxPLDevice(): gc done
15:06:20: Debug: wxPLDevice(): m_interactiveTextGcdc done
15:06:20: Debug: wxPLDevice(): SetDC done
15:06:20: Debug: wxPLDevice(): leave
15:06:20: Debug: plD_init_wxwidgets(): leave
15:06:20: Debug: frame->Create
15:06:20: Debug: Plot()

then

[pedro.vicente@rhw9121 build]$ examples/c/x01c -dev wxwidgets
PLplot library version: 5.11.1
15:11:37: Debug: plD_init_wxwidgets(): enter
15:11:37: Debug: wxPLDevice(): enter
15:11:37: Debug: wxPLDevice(): gc done
15:11:37: Debug: wxPLDevice(): m_interactiveTextGcdc done
15:11:37: Debug: SetupMemoryMap(): enter
15:11:37: Debug: SetupMemoryMap(): mapName start
15:11:37: Debug: SetupMemoryMap(): mapName done
15:11:37: Debug: SetupMemoryMap(): m_outputMemoryMap.create call
15:11:37: Debug: SetupMemoryMap(): m_outputMemoryMap.create done
15:11:38: Debug: wxPLplotwindow::wxPLplotwindow
15:11:38: Debug: SetupMemoryMap(): leave
15:11:38: Debug: wxPLDevice(): leave
15:11:38: Debug: plD_init_wxwidgets(): leave
../src/gtk/bitmap.cpp(941): assert ""IsOk()"" failed in GetWidth(): 
invalid bitmap






On 2016-12-23 14:50, Alan W. Irwin wrote:
> On 2016-12-23 01:40-0500 Pedro Vicente wrote:
>
>> Alan, Phil
>>
>> I went ahead and did a patch commit for option 3), attached,
>> that has this:
>>
>> (note: I wrote the code in Windows, then ftp to Linux, I got some 
>> warnings about line endings, just do
>> dos2unix if any thing shows up)
>
> Hi Pedro:
>
> Your change is extremly promising because for the first time I get 
> the
> same debug output here as you do on Ubunutu.  In other words we have
> a deterministic order for the first time!
>
> However, your commit needs some code revision.  I did some of that
> here, but there is more for you to do there to avoid the new bitmap
> errors I detected when running the wxwidgets device driver which
> launches wxPLViewer and communicates with it to get the plot 
> displayed.
> I suspect the revision you have done for the wxPLViewer code is
> somehow interfering with that use of the wxPLViewer application.
>
> Now for the details.
>
> Your formatted patch (which by the way has no Windows line endings in
> it) applied relatively cleanly here aside from minor whitespace 
> issues, but
> did not build.
>
> That build issue was caused by incorrect symbol visibility for your
> changes.  I found that issue on
> Linux by using the -fvisibility=hidden option, e.g.,
>
> software@raven> printenv |grep FL
> CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
> CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
> FFLAGS=-O3 -Wuninitialized -Wunused
>
> That produces for gcc a symbol visibility that is similar to
> visibility on Windows platforms. That is, I don't think your changes
> would have built on Windows.
>
> The visibility fix was to replace
>
> class wxPLplotwindow : public wxFrame
>
> by
>
> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
>
> in bindings/wxwidgets/wxPLplotwindow.h.
>
> I attach the revised version of your patch with this change and
> several line-ending and style changes applied.  However, to quote 
> from
> that revised commit message (in the new Tested by: section for me)
>
> I got "the same as the Ubuntu results above which is the first time 
> the
> two platforms have the same debugging output meaning we appear to 
> have
> a deterministic solution!"
>
> "HOWEVER. There are run-time problems (invalid bitmap) with these
> changes for wxPLViewer if you use that in conjunction with -dev
> wxwidgets so this should not be the final version of this commit."
>
> software@raven> examples/c/x01c -dev wxwidgets
> PLplot library version: 5.11.1
> 10:54:55: Debug: nanosecs since epoch = 2210969809300109:
> plD_init_wxwidgets(): enter
> 10:54:55: Debug: nanosecs since epoch = 2210969845142231: 
> wxPLDevice(): enter
> 10:54:55: Debug: nanosecs since epoch = 2210969845351899:
> wxPLDevice(): gc done
> 10:54:55: Debug: nanosecs since epoch = 2210969867143754:
> wxPLDevice(): m_interactiveTextGcdc done
> 10:54:55: Debug: nanosecs since epoch = 2210969867214649:
> SetupMemoryMap(): enter
> 10:54:55: Debug: nanosecs since epoch = 2210969868074842:
> SetupMemoryMap(): mapName start
> 10:54:55: Debug: nanosecs since epoch = 2210969868110859:
> SetupMemoryMap(): mapName done
> 10:54:55: Debug: nanosecs since epoch = 2210969868140426:
> SetupMemoryMap(): m_outputMemoryMap.create call
> 10:54:55: Debug: nanosecs since epoch = 2210969868201560:
> SetupMemoryMap(): m_outputMemoryMap.create done
> 10:54:55: Debug: nanosecs since epoch = 2210970015888076:
> wxPLplotwindow::wxPLplotwindow
> 10:54:55: Debug: nanosecs since epoch = 2210970031998161:
> SetupMemoryMap(): leave
> 10:54:55: Debug: nanosecs since epoch = 2210970032100417: 
> wxPLDevice(): leave
> 10:54:55: Debug: nanosecs since epoch = 2210970032134179:
> plD_init_wxwidgets(): leave
> software@raven> ../src/gtk/bitmap.cpp(923): assert "IsOk()" failed in
> GetWidth(): invalid bitmap
>
> So Pedro, my version of your patch should be applied there with
>
> git am < 
> /tmp/0001-wxwidgets-binding-fix-for-delayed-OnCreate-event.patch
>
> You should use that command on a fresh topic branch without your
> changes, i.e., latest master from SF.  And make sure it is my
> version of your patch you apply and not your own patch of the same 
> name.
>
> Please use my revision of your patch that way to preserve the style
> and line ending
> issues I fixed and the tested-by section I inserted in the commit 
> message
> rather than just cherry-picking the visibility fix.
>
> The next step after that is to build the wxwidgets, wxPLViewer, and
> x01c targets and try the experiment above.  Assuming you will see the 
> same
> bitmap error as above, then please revise your patch again to
> fix that.
>
> (Just use "git add" to stage additional changes you want to add to
> your commit, and "git commit --amend" to add those staged changes to
> your commit.  This very common git pattern avoids a series of
> non-working commits which are successive approximations to the final
> working commit.)
>
> Then follow up by testing the second revision of your patch on all
> systems accessible to you by building the test_wxPLplotDemo and
> test_c_wxwidgets targets on each of them.  (The latter does the above
> experiment on a small subset of the examples with all prerequisite
> targets built first automatically.)  Then send that second revised
> version of your patch to Phil and me for more testing/analysis.
>
> If it passes Phil's tests and mine, AND he likes your new approach,
> then I will revise my "Tested by:" section in the commit message


> appropriately and push your patch to finally put this 
> release-critical
> issue to rest.
>
> 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
> __________________________

-- 
Pedro Vicente
ped...@sp...
http://www.space-research.org/

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

Hi Alan

some more upbeat news about the example error , it's gone :-)

It's the first time I do this commit patch procedure , so I just did

git format-patch -1

with my new changes (after doing a new branch, from the master, then 
patching your changes, wrote my changes,
commited, merged into master, did a new patch, phew :-) )

I did not wrote much in the patch , but here it is, basically I reintroduced 
the wxPLplotwindow::OnCreate() event (keeping the wxPLplotwindow::Create() 
also)

I think what was happening is that the PLViewer needs the 
wxPLplotwindow::OnCreate()  to create the stream , since
wxPLplotwindow::Create() is not called for PLViewer.


I also removed this "PLDLLIMPEXP_WX"

class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame

I searched  in all the source code and could not find this symbol ?


> That produces for gcc a symbol visibility that is similar to
> visibility on Windows platforms. That is, I don't think your changes
> would have built on Windows.

It builds on Windows.
also, I think

class "something" wxPLplotwindow : public wxFrame

I believe is not a valid C++ construct

let me know if something on my patch is not clear


-Pedro


----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "Phil Rosenberg" <p.d...@gm...>; "PLplot development list" 
<Plp...@li...>
Sent: Friday, December 23, 2016 2:50 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-23 01:40-0500 Pedro Vicente wrote:
>
>> Alan, Phil
>>
>> I went ahead and did a patch commit for option 3), attached,
>> that has this:
>>
>> (note: I wrote the code in Windows, then ftp to Linux, I got some 
>> warnings
>> about line endings, just do
>> dos2unix if any thing shows up)
>
> Hi Pedro:
>
> Your change is extremly promising because for the first time I get the
> same debug output here as you do on Ubunutu.  In other words we have
> a deterministic order for the first time!
>
> However, your commit needs some code revision.  I did some of that
> here, but there is more for you to do there to avoid the new bitmap
> errors I detected when running the wxwidgets device driver which
> launches wxPLViewer and communicates with it to get the plot displayed.
> I suspect the revision you have done for the wxPLViewer code is
> somehow interfering with that use of the wxPLViewer application.
>
> Now for the details.
>
> Your formatted patch (which by the way has no Windows line endings in
> it) applied relatively cleanly here aside from minor whitespace issues, 
> but
> did not build.
>
> That build issue was caused by incorrect symbol visibility for your 
> changes.  I found that issue on
> Linux by using the -fvisibility=hidden option, e.g.,
>
> software@raven> printenv |grep FL
> CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
> CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
> FFLAGS=-O3 -Wuninitialized -Wunused
>
> That produces for gcc a symbol visibility that is similar to
> visibility on Windows platforms. That is, I don't think your changes
> would have built on Windows.
>
> The visibility fix was to replace
>
> class wxPLplotwindow : public wxFrame
>
> by
>
> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
>
> in bindings/wxwidgets/wxPLplotwindow.h.
>
> I attach the revised version of your patch with this change and
> several line-ending and style changes applied.  However, to quote from
> that revised commit message (in the new Tested by: section for me)
>
> I got "the same as the Ubuntu results above which is the first time the
> two platforms have the same debugging output meaning we appear to have
> a deterministic solution!"
>
> "HOWEVER. There are run-time problems (invalid bitmap) with these
> changes for wxPLViewer if you use that in conjunction with -dev
> wxwidgets so this should not be the final version of this commit."
>
> software@raven> examples/c/x01c -dev wxwidgets
> PLplot library version: 5.11.1
> 10:54:55: Debug: nanosecs since epoch = 2210969809300109: 
> plD_init_wxwidgets(): enter
> 10:54:55: Debug: nanosecs since epoch = 2210969845142231: wxPLDevice(): 
> enter
> 10:54:55: Debug: nanosecs since epoch = 2210969845351899: wxPLDevice(): gc 
> done
> 10:54:55: Debug: nanosecs since epoch = 2210969867143754: wxPLDevice(): 
> m_interactiveTextGcdc done
> 10:54:55: Debug: nanosecs since epoch = 2210969867214649: 
> SetupMemoryMap(): enter
> 10:54:55: Debug: nanosecs since epoch = 2210969868074842: 
> SetupMemoryMap(): mapName start
> 10:54:55: Debug: nanosecs since epoch = 2210969868110859: 
> SetupMemoryMap(): mapName done
> 10:54:55: Debug: nanosecs since epoch = 2210969868140426: 
> SetupMemoryMap(): m_outputMemoryMap.create call
> 10:54:55: Debug: nanosecs since epoch = 2210969868201560: 
> SetupMemoryMap(): m_outputMemoryMap.create done
> 10:54:55: Debug: nanosecs since epoch = 2210970015888076: 
> wxPLplotwindow::wxPLplotwindow
> 10:54:55: Debug: nanosecs since epoch = 2210970031998161: 
> SetupMemoryMap(): leave
> 10:54:55: Debug: nanosecs since epoch = 2210970032100417: wxPLDevice(): 
> leave
> 10:54:55: Debug: nanosecs since epoch = 2210970032134179: 
> plD_init_wxwidgets(): leave
> software@raven> ../src/gtk/bitmap.cpp(923): assert "IsOk()" failed in 
> GetWidth(): invalid bitmap
>
> So Pedro, my version of your patch should be applied there with
>
> git am < /tmp/0001-wxwidgets-binding-fix-for-delayed-OnCreate-event.patch
>
> You should use that command on a fresh topic branch without your
> changes, i.e., latest master from SF.  And make sure it is my
> version of your patch you apply and not your own patch of the same name.
>
> Please use my revision of your patch that way to preserve the style and 
> line ending
> issues I fixed and the tested-by section I inserted in the commit message
> rather than just cherry-picking the visibility fix.
>
> The next step after that is to build the wxwidgets, wxPLViewer, and
> x01c targets and try the experiment above.  Assuming you will see the same
> bitmap error as above, then please revise your patch again to
> fix that.
>
> (Just use "git add" to stage additional changes you want to add to
> your commit, and "git commit --amend" to add those staged changes to
> your commit.  This very common git pattern avoids a series of
> non-working commits which are successive approximations to the final
> working commit.)
>
> Then follow up by testing the second revision of your patch on all
> systems accessible to you by building the test_wxPLplotDemo and
> test_c_wxwidgets targets on each of them.  (The latter does the above
> experiment on a small subset of the examples with all prerequisite
> targets built first automatically.)  Then send that second revised
> version of your patch to Phil and me for more testing/analysis.
>
> If it passes Phil's tests and mine, AND he likes your new approach,
> then I will revise my "Tested by:" section in the commit message
> appropriately and push your patch to finally put this release-critical
> issue to rest.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________ 

Re: [Plplot-devel] Infinite Yielding issue

[Pedro V. <ped...@sp...>]

PS:


this is the ouput of the example


pvn@server:~/plplot-plplot/build$ examples/c/x01c -dev wxwidgets
PLplot library version: 5.11.1
00:36:21: Debug: plD_init_wxwidgets(): enter
00:36:21: Debug: wxPLDevice(): enter
00:36:21: Debug: wxPLDevice(): gc done
00:36:21: Debug: wxPLDevice(): m_interactiveTextGcdc done
00:36:21: Debug: SetupMemoryMap(): enter
00:36:21: Debug: SetupMemoryMap(): mapName start
00:36:21: Debug: SetupMemoryMap(): mapName done
00:36:21: Debug: SetupMemoryMap(): m_outputMemoryMap.create call
00:36:21: Debug: SetupMemoryMap(): m_outputMemoryMap.create done
00:36:21: Debug: wxPLplotwindow::wxPLplotwindow
00:36:21: Debug: SetupMemoryMap(): leave
00:36:21: Debug: wxPLDevice(): leave
00:36:21: Debug: plD_init_wxwidgets(): leave
00:36:21: Debug: wxPLplotwindow::OnCreate
00:36:21: Debug: plD_init_wxwidgets(): enter
00:36:21: Debug: wxPLDevice(): enter
00:36:21: Debug: wxPLDevice(): gc done
00:36:21: Debug: wxPLDevice(): m_interactiveTextGcdc done
00:36:21: Debug: wxPLDevice(): SetDC done
00:36:21: Debug: wxPLDevice(): leave
00:36:21: Debug: plD_init_wxwidgets(): leave
00:36:21: Debug: wxPLplotwindow::OnCreate

----- Original Message ----- 
From: "Pedro Vicente" <ped...@sp...>
To: "Alan W. Irwin" <ir...@be...>
Cc: "PLplot development list" <Plp...@li...>
Sent: Saturday, December 24, 2016 1:13 AM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> Hi Alan
>
> some more upbeat news about the example error , it's gone :-)
>
> It's the first time I do this commit patch procedure , so I just did
>
> git format-patch -1
>
> with my new changes (after doing a new branch, from the master, then
> patching your changes, wrote my changes,
> commited, merged into master, did a new patch, phew :-) )
>
> I did not wrote much in the patch , but here it is, basically I 
> reintroduced
> the wxPLplotwindow::OnCreate() event (keeping the wxPLplotwindow::Create()
> also)
>
> I think what was happening is that the PLViewer needs the
> wxPLplotwindow::OnCreate()  to create the stream , since
> wxPLplotwindow::Create() is not called for PLViewer.
>
>
> I also removed this "PLDLLIMPEXP_WX"
>
> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
>
> I searched  in all the source code and could not find this symbol ?
>
>
>> That produces for gcc a symbol visibility that is similar to
>> visibility on Windows platforms. That is, I don't think your changes
>> would have built on Windows.
>
> It builds on Windows.
> also, I think
>
> class "something" wxPLplotwindow : public wxFrame
>
> I believe is not a valid C++ construct
>
> let me know if something on my patch is not clear
>
>
> -Pedro
>
>
> ----- Original Message ----- 
> From: "Alan W. Irwin" <ir...@be...>
> To: "Pedro Vicente" <ped...@sp...>
> Cc: "Phil Rosenberg" <p.d...@gm...>; "PLplot development list"
> <Plp...@li...>
> Sent: Friday, December 23, 2016 2:50 PM
> Subject: Re: [Plplot-devel] Infinite Yielding issue
>
>
>> On 2016-12-23 01:40-0500 Pedro Vicente wrote:
>>
>>> Alan, Phil
>>>
>>> I went ahead and did a patch commit for option 3), attached,
>>> that has this:
>>>
>>> (note: I wrote the code in Windows, then ftp to Linux, I got some
>>> warnings
>>> about line endings, just do
>>> dos2unix if any thing shows up)
>>
>> Hi Pedro:
>>
>> Your change is extremly promising because for the first time I get the
>> same debug output here as you do on Ubunutu.  In other words we have
>> a deterministic order for the first time!
>>
>> However, your commit needs some code revision.  I did some of that
>> here, but there is more for you to do there to avoid the new bitmap
>> errors I detected when running the wxwidgets device driver which
>> launches wxPLViewer and communicates with it to get the plot displayed.
>> I suspect the revision you have done for the wxPLViewer code is
>> somehow interfering with that use of the wxPLViewer application.
>>
>> Now for the details.
>>
>> Your formatted patch (which by the way has no Windows line endings in
>> it) applied relatively cleanly here aside from minor whitespace issues,
>> but
>> did not build.
>>
>> That build issue was caused by incorrect symbol visibility for your
>> changes.  I found that issue on
>> Linux by using the -fvisibility=hidden option, e.g.,
>>
>> software@raven> printenv |grep FL
>> CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
>> CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
>> FFLAGS=-O3 -Wuninitialized -Wunused
>>
>> That produces for gcc a symbol visibility that is similar to
>> visibility on Windows platforms. That is, I don't think your changes
>> would have built on Windows.
>>
>> The visibility fix was to replace
>>
>> class wxPLplotwindow : public wxFrame
>>
>> by
>>
>> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
>>
>> in bindings/wxwidgets/wxPLplotwindow.h.
>>
>> I attach the revised version of your patch with this change and
>> several line-ending and style changes applied.  However, to quote from
>> that revised commit message (in the new Tested by: section for me)
>>
>> I got "the same as the Ubuntu results above which is the first time the
>> two platforms have the same debugging output meaning we appear to have
>> a deterministic solution!"
>>
>> "HOWEVER. There are run-time problems (invalid bitmap) with these
>> changes for wxPLViewer if you use that in conjunction with -dev
>> wxwidgets so this should not be the final version of this commit."
>>
>> software@raven> examples/c/x01c -dev wxwidgets
>> PLplot library version: 5.11.1
>> 10:54:55: Debug: nanosecs since epoch = 2210969809300109:
>> plD_init_wxwidgets(): enter
>> 10:54:55: Debug: nanosecs since epoch = 2210969845142231: wxPLDevice():
>> enter
>> 10:54:55: Debug: nanosecs since epoch = 2210969845351899: wxPLDevice(): 
>> gc
>> done
>> 10:54:55: Debug: nanosecs since epoch = 2210969867143754: wxPLDevice():
>> m_interactiveTextGcdc done
>> 10:54:55: Debug: nanosecs since epoch = 2210969867214649:
>> SetupMemoryMap(): enter
>> 10:54:55: Debug: nanosecs since epoch = 2210969868074842:
>> SetupMemoryMap(): mapName start
>> 10:54:55: Debug: nanosecs since epoch = 2210969868110859:
>> SetupMemoryMap(): mapName done
>> 10:54:55: Debug: nanosecs since epoch = 2210969868140426:
>> SetupMemoryMap(): m_outputMemoryMap.create call
>> 10:54:55: Debug: nanosecs since epoch = 2210969868201560:
>> SetupMemoryMap(): m_outputMemoryMap.create done
>> 10:54:55: Debug: nanosecs since epoch = 2210970015888076:
>> wxPLplotwindow::wxPLplotwindow
>> 10:54:55: Debug: nanosecs since epoch = 2210970031998161:
>> SetupMemoryMap(): leave
>> 10:54:55: Debug: nanosecs since epoch = 2210970032100417: wxPLDevice():
>> leave
>> 10:54:55: Debug: nanosecs since epoch = 2210970032134179:
>> plD_init_wxwidgets(): leave
>> software@raven> ../src/gtk/bitmap.cpp(923): assert "IsOk()" failed in
>> GetWidth(): invalid bitmap
>>
>> So Pedro, my version of your patch should be applied there with
>>
>> git am < /tmp/0001-wxwidgets-binding-fix-for-delayed-OnCreate-event.patch
>>
>> You should use that command on a fresh topic branch without your
>> changes, i.e., latest master from SF.  And make sure it is my
>> version of your patch you apply and not your own patch of the same name.
>>
>> Please use my revision of your patch that way to preserve the style and
>> line ending
>> issues I fixed and the tested-by section I inserted in the commit message
>> rather than just cherry-picking the visibility fix.
>>
>> The next step after that is to build the wxwidgets, wxPLViewer, and
>> x01c targets and try the experiment above.  Assuming you will see the 
>> same
>> bitmap error as above, then please revise your patch again to
>> fix that.
>>
>> (Just use "git add" to stage additional changes you want to add to
>> your commit, and "git commit --amend" to add those staged changes to
>> your commit.  This very common git pattern avoids a series of
>> non-working commits which are successive approximations to the final
>> working commit.)
>>
>> Then follow up by testing the second revision of your patch on all
>> systems accessible to you by building the test_wxPLplotDemo and
>> test_c_wxwidgets targets on each of them.  (The latter does the above
>> experiment on a small subset of the examples with all prerequisite
>> targets built first automatically.)  Then send that second revised
>> version of your patch to Phil and me for more testing/analysis.
>>
>> If it passes Phil's tests and mine, AND he likes your new approach,
>> then I will revise my "Tested by:" section in the commit message
>> appropriately and push your patch to finally put this release-critical
>> issue to rest.
>>
>> 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
>> __________________________
>


--------------------------------------------------------------------------------


> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/intel


--------------------------------------------------------------------------------


> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>