plplot-devel — Technical discussion about PLplot development

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
__________________________

[Plplot-devel] Plans for IPC changes

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

On 2016-12-24 13:39-0000 p.d...@gm... wrote:

> Hi Alan
> It's great that these improvements have borne fruit.

> Regarding the two slower examples, I don't think it is cut and dry that it is the semaphores are the cause. It may be that for these cases where there are a large number of elements the ring buffer is filling up so the main application gets stuck waiting for the viewer to render.

To Phil and Pedro:

Just to clarify with my unnamed semaphores proof-of-concept project at
cmake/test_linux_ipc, I didn't use a ring buffer at all. Instead, it
was just a simple shared-memory buffer.  The receiving end would
sem_wait until the unnamed semaphore set by the sending end said it
was time to read. And the sending end would sem_wait to write to that
buffer depending on the initial semaphore condition to start and then
afterward by how the semaphore was set by the receiving end.  And one
of the nice advantages of the unnamed semaphores approach is the
memory area used by unnamed semaphores for interprocess communication
is just part of the shared memory buffer with no file semantics
involved.  I don't know how big an efficiency improvement that will
be, but the important point for me is it does make the code easier to
understand.

I haven't looked at the current code in this regard but if either end
is using a loop with a timed wait to check on conditions for a ring
buffer, then that may be an efficiency concern when relatively large
amounts of data have to be passed.  Anyhow, there are no timed waits
at all in the proof-of-concept code, and I think the efficiency of the
result (25MBytes of data passed between sender and receiver in 0.3
seconds for a small buffer and even shorter times for larger buffers)
speaks for itself.

However, instead of me speculating any more about what a great
efficiency improvement this _might_ be, this is obviously "show me the
code" time.  Therefore, after this release is out the door, I plan to
implement the proof-of-concept project's ideas in wxwidgets_comms.cpp.
And once that is working on a topic branch, I will document the time
required on both the -dev wxwidgets end AND the wxPLViewer end for
example 8 to complete for both that topic branch and master.  And if
the proof-of-concept approach turns out to be a net efficiency
benefit, push it, but otherwise abandon it.  You and Pedro are, of
course, welcome to join me in working on this proposed topic branch
even if you decide to limit your involvement to acting as a sounding
board if I run into trouble with this implementation.

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] 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] Significant improvement in our overall -dev wxwidgets speed on Linux

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

Hi Alan
It's great that these improvements have borne fruit.

Regarding the two slower examples, I don't think it is cut and dry that it is the semaphores are the cause. It may be that for these cases where there are a large number of elements the ring buffer is filling up so the main application gets stuck waiting for the viewer to render.


Anyway. As I said I’m glad to see the improvements so far 😊

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 23 December 2016 03:23
To: Phil Rosenberg; Pedro Vicente; PLplot development list
Subject: Significant improvement in our overall -dev wxwidgets speed on Linux

I was not particularly happy with the speed of our new wxwidgets
device driver as of the release of 5.11.1 on the Linux platform
because it was often significantly (factor of two to a factor of 20)
slower than any of our other interactive devices, and sometimes
(especially during tests) it would slow down by two orders of
magnitude!

So here some interesting measurements I have made of the speed of
wxwidgets as of master^ =

65e7b3c Fix bug with plotting in wxPLplotDemo

(e.g., the commit that is working for Pedro and me) which show a
substantial improvement over 5.11.1 thanks to Phil's work throughout
this release cycle on speed issues for wxwidgets.

Here are the two critical timing lines that before Phil's recent
"/dev/random ==> /dev/urandom" fix were often separated by a long
pause of 5 to 15 seconds due to the blocking nature of /dev/random on
Linux.

15:48:32: Debug: nanosecs since epoch = 2142186322453622: SetupMemoryMap(): enter
15:48:32: Debug: nanosecs since epoch = 2142186323455041: SetupMemoryMap(): mapName start

That "pause" is now reduced to 10^6 nanosec ~ 1 ms, an improvement of 4 orders of
magnitude!

To collect more time results I ran a bash "for" loop that compared
real times for all the examples from 0 to 30 (excluding 08, 17, 20,
and 25 because 17 and 20 are interactive in nature and I want to
discuss 08 and 25 separately below).  For each loop iteration I
displayed time results for our 3 highest quality (in terms of the
antialiased look of graphics and text, processing of unicode, etc.)
Linux interactive devices; qtwidget, xcairo, and wxwidgets.

To reduce the bash time result output from the normal 3 lines to just
one for each device, I changed the TIMEFORMAT environment variable that controls the
format of the time command (see the bash man page) from the default

export TIMEFORMAT=$'\nreal\t%3lR\nuser\t%3lU\nsys\t%3lS'

which gives the "real", "user", and "sys" 3 lines of output you
normally see from the "time" command to

export TIMEFORMAT=$'real\t%3R'

which expresses the real result on one line in pure seconds with 3
characters of precision past the decimal point, and drops the user and
system results.

So here are those real time comparison results (N.B. in groups of three
where the first is from -dev qtwidget, the second from xcairo, and the
3rd from wxwidgets) generated by the following bash for loop command:

software@raven> for N in $(seq --format='%02.0f' 0 30 |grep -vE '08|17|20|25'); do echo $N; (time examples/c/x${N}c -dev qtwidget -np >&/dev/null); (time examples/c/x${N}c -dev xcairo -np >&/dev/null); (time examples/c/x${N}c -dev wxwidgets -np >&/dev/null); sleep 5; done
00
real    0.184 *
real    0.292
real    0.344
01
real    0.207 *
real    0.376
real    0.307
02
real    0.279 *
real    0.386
real    0.288
03
real    0.191 *
real    0.385
real    0.275
04
real    0.293
real    0.400
real    0.279 *
05
real    0.188 *
real    0.395
real    0.275
06
real    0.598
real    0.458
real    0.393 *
07
real    1.331
real    0.846
real    0.619 *
09
real    0.570
real    0.450
real    0.370 *
10
real    0.178 *
real    0.351
real    0.296
11
real    0.882
real    0.750
real    0.407 *
12
real    0.504
real    0.498 *
real    0.807
13
real    0.184 *
real    0.334
real    0.301
14
real    0.813
real    0.712
real    0.669 *
15
real    0.310 *
real    0.417
real    0.376
16
real    0.578
real    0.998
real    0.402 *
18
real    1.281
real    0.813 *
real    1.161 
19
real    1.015
real    0.844
real    0.668 *
21
real    0.806 *
real    0.887
real    1.124
22
real    0.923 
real    0.824 *
real    0.925
23
real    2.860
real    1.463 *
real    1.685
24
real    0.630
real    0.533 *
real    0.845
26
real    0.628
real    0.524 *
real    0.854
27
real    1.396
real    1.077 *
real    1.232
28
real    0.834
real    0.567 *
real    0.883
29
real    0.781
real    0.643
real    0.466 *
30
real    0.238 *
real    0.365
real    0.288

Obviously, a caveat for these results is they are going to be
distorted in the -dev wxwidgets case because they only count the real
time spent by that device and completely ignore the real time spent by
wxPLViewer. However, a countervailing argument if you have multiple
CPU's (like my case where I have two of them) is wxPLViewer can be run
on a separate CPU because it is a separate application so in a sense
its real time does not count on multiple CPU machines).  Nevertheless,
in a few cases wxPLViewer took so much longer to finish then -dev
wxwidgets that it was distorting subsequent wxPLViewer instances which
were automatically created smaller to reduce (I presume) how much my
screen got filled up by wxPLViewer GUI's.  To counteract that crowding
effect I implemented a 5 second wait (not counted in the above real
time outputs) at the end of each loop iteration above, and the result
was most wxPLViewer GUI's finished during the loop and therefore the
next launch of the wxPLViewer GUI on the next loop ended up being full
sized.

Despite the above caveat these time results are still quite
interesting.  I have indicated with a trailing asterisk in the above
table which of the three times was the best, and if you count those
results above you obtain the following summary:

qtwidget  10
xcairo    08
wxwidgets 09

So it is clear that wxwidgets is now pretty much holding its own
(ignoring the caveat) with the others for our standard set of
examples, and since my previous evaluation done near the time when
5.11.1 was released was subject to the same caveat it is clear there
has been quite a substantial improvement, and we can generally (with a
few exceptions to be discussed) be proud of the efficiency of this
device now on Linux.

There are two known exceptions to the above remarks.  Whereas in all
the other examples above wxwidgets is at most two times slower than
the fastest result from either qt or xcairo, we have the following results
for examples 08 and 25 generated by a similar loop to the above
(starting with

for N in 08 25; ....

).

08
real    0.860 *
real    1.971
real    13.520
25
real    1.102
real    0.655 *
real    5.311

For these two cases, wxwidgets is slower (subject to the same caveat) than the best of the other
two devices by respective factors of 16 and 8!

After the release we should look at examples 08 and 25 to see what the
issue is, but both these examples have large numbers of graphical
elements (i.e., example 08 uses a large number of small triangles
to represent those varying 3D surfaces in a smooth way and 
example 25 uses a large number of thin rectangles to represent the number
of gradients in this plot in a smooth way). So my working hypothesis
to explain these large slowdowns compared to the rest of the examples
is there is some bottleneck transmitting positional data for graphical
elements between -dev wxwidgets and associated wxPLViewer application
via shared memory.  If this hypothesis is correct, the cure for this
issue would likely be to move to the efficient "unnamed semaphores"
algorithm which I demonstrated (using the proof-of-concept project at
cmake/test_linux_ipc) could move 25MB of data from one executable to
another in 0.3 seconds!

(I assume example 33 will show the same slowdown issue as 25 because
there are lots of plgradient invocations in example 33, but I did not
investigate 33 because it takes so long even when it is efficient.)

Also note whatever the cure is for this slowdown issue with examples
that have large numbers of graphical elements, it might be a noticable
benefit to some of the rest of the examples with moderate numbers of
graphical elements.  Thus, with any luck at all when this particular
inefficiency is solved we might see a big increase in the number of
examples where wxwidgets is faster than both the qtwidget and xcairo
results.

So from the above numbers there is still one obvious Linux efficiency
issue left for -dev wxwidgets that we need to work on after the
release, and we can look forward to a potential big payoff from that
work not only for examples 08 and 25, but possibly several other
examples as well.  However, for this release we can still be proud of
all the Linux wxwidgets efficiency progress made to this point.

So, good work, Phil, on getting us to this stage!

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

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] 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] 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
> __________________________
> 

[Plplot-devel] Trailing whitespace issues to be fixed post-release

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

For your information, I recently discovered we still have trailing
whitespace issues consisting of tabs (or possibly even mixtures of
blanks followed by tabs) because the current script to deal with that
issue only removed trailing blanks.  I have now updated that script to
remove all combinations of trailing tabs and blanks.  I also
changed its name from

scripts/remove_trailing_blanks.sh --> scripts/remove_trailing_whitespace.sh

That new version of the script appears to work fine (if sed is
available on your platform), but it turns out we have a fair number of
files that have trailing whitespace issues so this commit would be way
too intrusive to push before release.

So I have decided to keep this new version of the script on a private
topic branch for now.  After the release I plan to try it again, test
those many file changes with the comprehensive test script, and then
finally push the result.  N.B. until that occurs, you should expect
commands like "git am" to complain about whitespace issues.

Once we are free of such trailing whitespace issues, git has methods
of enforcing no trailing white space on certain files for commit, see
<http://stackoverflow.com/questions/591923/make-git-automatically-remove-trailing-whitespace-before-committing>
But the huge number of possibilities discussed there seem to be fairly
complex and have various drawbacks so I will likely just stick with
running this simple script from time to time.

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-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] Infinite Yielding issue

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

by the way, what are the commands to do 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 4:30 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-23 15:18-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I applied the patch on CentOS;
>> no errors on build
>> wxPLplotwindow demo does the plot
>> same error on the same example
>
> Thanks, Pedro, for verifying my revision of your commit applies
> cleanly there and for verifying the run-time error I discovered with
> your commit.  And good luck fixing whatever the trouble is that is
> causing that error.
>
> With regard to your suggestion for finding other ways to have
> collaborative git development, this is a really critical time for us
> trying to find a rock-solid fix for this release-critical issue so I
> would prefer we discuss your suggestion post-release when we are all
> more relaxed and have time to consider your suggestion carefully.
>
> 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

>With regard to your suggestion for finding other ways to have
>collaborative git development, this is a really critical time for us
>trying to find a rock-solid fix for this release-critical issue so I
>would prefer we discuss your suggestion post-release when we are all
>more relaxed and have time to consider your suggestion carefully.

on better thinking doing a "dev" branch where things have errors might not 
be a good idea,
the less entropy the better.

so, this patch exchange is better i.m.o

I''ll check the errors later

-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 4:30 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-23 15:18-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I applied the patch on CentOS;
>> no errors on build
>> wxPLplotwindow demo does the plot
>> same error on the same example
>
> Thanks, Pedro, for verifying my revision of your commit applies
> cleanly there and for verifying the run-time error I discovered with
> your commit.  And good luck fixing whatever the trouble is that is
> causing that error.
>
> With regard to your suggestion for finding other ways to have
> collaborative git development, this is a really critical time for us
> trying to find a rock-solid fix for this release-critical issue so I
> would prefer we discuss your suggestion post-release when we are all
> more relaxed and have time to consider your suggestion carefully.
>
> 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-23 15:18-0500 Pedro Vicente wrote:

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

Thanks, Pedro, for verifying my revision of your commit applies
cleanly there and for verifying the run-time error I discovered with
your commit.  And good luck fixing whatever the trouble is that is
causing that error.

With regard to your suggestion for finding other ways to have
collaborative git development, this is a really critical time for us
trying to find a rock-solid fix for this release-critical issue so I
would prefer we discuss your suggestion post-release when we are all
more relaxed and have time to consider your suggestion carefully.

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

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

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

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] An alternative idea for comprehensive testing of MSVC + ifort

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, December 22, 2016 7:31 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: An alternative idea for comprehensive testing of MSVC + ifort
>
> On 2016-12-22 09:32-0000 Arjen Markus wrote:
>
> [...]
> > I now use a Tcl script to compare the files (because of lack of a
> > suitable command under Windows - sigh)
> [...]
>
> Hi Arjen:
>
> I got curious about that, and a google search found
> <http://stackoverflow.com/questions/6877238/what-is-the-windows-equivalent-of-
> the-diff-command>
> where some of the suggested windows equivalents of the diff command seemed to
> meet with universal approval.
>
> The problem is that is a start of a long difficult path where you end up trying to
> mimic the logic of our current test system that depends on bash and several other
> Unix tools (such as cmp and/or diff).
>
Well, the script I have now simply skips the first fews lines (which contain the timestamp) and then compares the rest of the two files as two long strings. So the C equivalent would be fairly short as well. And nothing at all like cmp and diff. It simply tells the user whether the files have different lengths or whether the contents are different.

>
> I am pretty confident this approach would work because it is equivalent to the
> approach I used to take for testing the old MinGW (without old MSYS) build that
> used the "MinGW Makefiles" generator on the Wine version of Windows. All those
> tests were done from a CMD environment using the old MinGW make command
> (mingw32-make.exe) but with the old MSYS bin directory on the PATH to give
> access to the Unix tools needed for the tests (but avoiding using those tools for the
> build itself).  So I don't see why you cannot do the same with nmake.exe replacing
> mingw32-make.exe.
>
> In sum, I recommend you take another serious look at this general approach (with
> Unix tools used just for testing but expressly not used for the build) the next time
> (likely in 2017) that you have a chance to work on PLplot testing on the MSVC +
> ifort build platform.
>
I will do that - the drawback would be that the user needs to have MinGW installed in some form. Also it may not be all that evident where the MinGW tools are installed. Still, worth a try.

Regards,

Arjen

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

Re: [Plplot-devel] Infinite Yielding issue

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

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)

Subject: [PATCH] wxwidgets binding: fix for delayed OnCreate event

The delayed call of the create event (OnCreate()) on wxApp::OnInit() is a 
wxWidgets feature.
To avoid that, the fix is to remove the event creation completely,
and instead override Create().
For this to happen, the wxPLplotwindow class cannot be templated.
Other changes are that events are now handled by a static event table,
using wxDECLARE_EVENT_TABLE().
An auxiliary function CreateStream() creates the stream in Create().
The code of wxPLplotwindow was moved to a new source file wxPLplotwindow.cpp

Tested by: Pedro Vicente <ped...@rh...>
on Ubuntu Linux 16.04 with wxwidgets3.0 package installed.
Results from building the test_wxPLplotDemo target:

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

NOTE:

previous to the creation of Create(), the same code was tested using
the event creation of OnCreate(): the error still happens in this case

00:48:12: Debug: wxPLplotwindow::wxPLplotwindow
00:48:12: Debug: frame->Create
00:48:12: Debug: Plot() FALSE IsReady()
00:48:12: Debug: wxPLplotwindow::OnCreate
00:48:12: Debug: plD_init_wxwidgets(): enter
00:48:12: Debug: wxPLDevice(): enter
00:48:12: Debug: wxPLDevice(): gc done
00:48:12: Debug: wxPLDevice(): m_interactiveTextGcdc done
00:48:12: Debug: wxPLDevice(): SetDC done
00:48:12: Debug: wxPLDevice(): leave
00:48:12: Debug: plD_init_wxwidgets(): leave





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


> Hi Pedro:
>
> On 2016-12-22 18:34-0500 Pedro Vicente wrote:
>
>> @Alan
> [...]
>> [The wxwidgets developer] says we cannot expect a timely response from 
>> the "create" event in wxApp::OnInit(),
>> which is the way wxPLplotDemo has.
>>
>> so, we have to change that, it just cannot be like it is now.
>
> Good point!
>
>>
>> @Phil
>>
>> [Three] options
>
> Your ideas for fixing this issue are rightly directed to Phil because I 
> don't have much
> expertise to help you in this area.  Therefore, I will confine what I say 
> in response to
> just one issue with case 3 that you brought up.
>
>> But [option 3] would probably break existing applications.
>> but at the moment this is the only solution that we know has no potencial 
>> issues.
>
> I don't think we should be too concerned with breaking applications since
> Phil's wxwidgets approach is still pretty new and experimental, and it
> was breaking them in any case as you have been demonstrating.  :-)
>
> I am not tuned in to wxwidgets very much, but I never heard of anyone
> using the old plplotwxwidgets library for anything.  And the only use
> of Phil's new plplotwxwidgets library I have heard of up to this point
> is your use and Greg Jung's use.  In his case he used that library as
> a means of getting the GDL (Gnu Data Language) project (see
> <https://en.wikipedia.org/wiki/GNU_Data_Language> to provide
> PLplot-generated plots on Windows. But I am pretty sure his approach
> was a private experiment and is not an official part of GDL. So I
> suspect that it is just you and Greg that we would be inconveniencing
> here, but I assume both of you would be happy to accept that
> inconvenience if the result was that from then on you were building
> your apps and libraries on top of a plplotwxwidgets library that was
> rock solid.
>
> It sounds like case 3 is the only rock-solid solution we have up to
> now so my naive vote would be for that solution unless Phil comes up
> with a different rock-solid solution that he prefers.  So please
> thrash it out between you, and I look forward to the decision you two
> make and the implementation that will quickly follow that decision
> about the best way to fix this issue in a fundamental way.
>
> 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...>]

Hi Pedro:

On 2016-12-22 18:34-0500 Pedro Vicente wrote:

> @Alan
[...]
> [The wxwidgets developer] says we cannot expect a timely response from the "create" event in 
> wxApp::OnInit(),
> which is the way wxPLplotDemo has.
>
> so, we have to change that, it just cannot be like it is now.

Good point!

>
> @Phil
>
> [Three] options

Your ideas for fixing this issue are rightly directed to Phil because I don't have much
expertise to help you in this area.  Therefore, I will confine what I say in response to
just one issue with case 3 that you brought up.

> But [option 3] would probably break existing applications.
> but at the moment this is the only solution that we know has no potencial 
> issues.

I don't think we should be too concerned with breaking applications since
Phil's wxwidgets approach is still pretty new and experimental, and it
was breaking them in any case as you have been demonstrating.  :-)

I am not tuned in to wxwidgets very much, but I never heard of anyone
using the old plplotwxwidgets library for anything.  And the only use
of Phil's new plplotwxwidgets library I have heard of up to this point
is your use and Greg Jung's use.  In his case he used that library as
a means of getting the GDL (Gnu Data Language) project (see
<https://en.wikipedia.org/wiki/GNU_Data_Language> to provide
PLplot-generated plots on Windows. But I am pretty sure his approach
was a private experiment and is not an official part of GDL. So I
suspect that it is just you and Greg that we would be inconveniencing
here, but I assume both of you would be happy to accept that
inconvenience if the result was that from then on you were building
your apps and libraries on top of a plplotwxwidgets library that was
rock solid.

It sounds like case 3 is the only rock-solid solution we have up to
now so my naive vote would be for that solution unless Phil comes up
with a different rock-solid solution that he prefers.  So please
thrash it out between you, and I look forward to the decision you two
make and the implementation that will quickly follow that decision
about the best way to fix this issue in a fundamental way.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] Significant improvement in our overall -dev wxwidgets speed on Linux

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

I was not particularly happy with the speed of our new wxwidgets
device driver as of the release of 5.11.1 on the Linux platform
because it was often significantly (factor of two to a factor of 20)
slower than any of our other interactive devices, and sometimes
(especially during tests) it would slow down by two orders of
magnitude!

So here some interesting measurements I have made of the speed of
wxwidgets as of master^ =

65e7b3c Fix bug with plotting in wxPLplotDemo

(e.g., the commit that is working for Pedro and me) which show a
substantial improvement over 5.11.1 thanks to Phil's work throughout
this release cycle on speed issues for wxwidgets.

Here are the two critical timing lines that before Phil's recent
"/dev/random ==> /dev/urandom" fix were often separated by a long
pause of 5 to 15 seconds due to the blocking nature of /dev/random on
Linux.

15:48:32: Debug: nanosecs since epoch = 2142186322453622: SetupMemoryMap(): enter
15:48:32: Debug: nanosecs since epoch = 2142186323455041: SetupMemoryMap(): mapName start

That "pause" is now reduced to 10^6 nanosec ~ 1 ms, an improvement of 4 orders of
magnitude!

To collect more time results I ran a bash "for" loop that compared
real times for all the examples from 0 to 30 (excluding 08, 17, 20,
and 25 because 17 and 20 are interactive in nature and I want to
discuss 08 and 25 separately below).  For each loop iteration I
displayed time results for our 3 highest quality (in terms of the
antialiased look of graphics and text, processing of unicode, etc.)
Linux interactive devices; qtwidget, xcairo, and wxwidgets.

To reduce the bash time result output from the normal 3 lines to just
one for each device, I changed the TIMEFORMAT environment variable that controls the
format of the time command (see the bash man page) from the default

export TIMEFORMAT=$'\nreal\t%3lR\nuser\t%3lU\nsys\t%3lS'

which gives the "real", "user", and "sys" 3 lines of output you
normally see from the "time" command to

export TIMEFORMAT=$'real\t%3R'

which expresses the real result on one line in pure seconds with 3
characters of precision past the decimal point, and drops the user and
system results.

So here are those real time comparison results (N.B. in groups of three
where the first is from -dev qtwidget, the second from xcairo, and the
3rd from wxwidgets) generated by the following bash for loop command:

software@raven> for N in $(seq --format='%02.0f' 0 30 |grep -vE '08|17|20|25'); do echo $N; (time examples/c/x${N}c -dev qtwidget -np >&/dev/null); (time examples/c/x${N}c -dev xcairo -np >&/dev/null); (time examples/c/x${N}c -dev wxwidgets -np >&/dev/null); sleep 5; done
00
real    0.184 *
real    0.292
real    0.344
01
real    0.207 *
real    0.376
real    0.307
02
real    0.279 *
real    0.386
real    0.288
03
real    0.191 *
real    0.385
real    0.275
04
real    0.293
real    0.400
real    0.279 *
05
real    0.188 *
real    0.395
real    0.275
06
real    0.598
real    0.458
real    0.393 *
07
real    1.331
real    0.846
real    0.619 *
09
real    0.570
real    0.450
real    0.370 *
10
real    0.178 *
real    0.351
real    0.296
11
real    0.882
real    0.750
real    0.407 *
12
real    0.504
real    0.498 *
real    0.807
13
real    0.184 *
real    0.334
real    0.301
14
real    0.813
real    0.712
real    0.669 *
15
real    0.310 *
real    0.417
real    0.376
16
real    0.578
real    0.998
real    0.402 *
18
real    1.281
real    0.813 *
real    1.161 
19
real    1.015
real    0.844
real    0.668 *
21
real    0.806 *
real    0.887
real    1.124
22
real    0.923 
real    0.824 *
real    0.925
23
real    2.860
real    1.463 *
real    1.685
24
real    0.630
real    0.533 *
real    0.845
26
real    0.628
real    0.524 *
real    0.854
27
real    1.396
real    1.077 *
real    1.232
28
real    0.834
real    0.567 *
real    0.883
29
real    0.781
real    0.643
real    0.466 *
30
real    0.238 *
real    0.365
real    0.288

Obviously, a caveat for these results is they are going to be
distorted in the -dev wxwidgets case because they only count the real
time spent by that device and completely ignore the real time spent by
wxPLViewer. However, a countervailing argument if you have multiple
CPU's (like my case where I have two of them) is wxPLViewer can be run
on a separate CPU because it is a separate application so in a sense
its real time does not count on multiple CPU machines).  Nevertheless,
in a few cases wxPLViewer took so much longer to finish then -dev
wxwidgets that it was distorting subsequent wxPLViewer instances which
were automatically created smaller to reduce (I presume) how much my
screen got filled up by wxPLViewer GUI's.  To counteract that crowding
effect I implemented a 5 second wait (not counted in the above real
time outputs) at the end of each loop iteration above, and the result
was most wxPLViewer GUI's finished during the loop and therefore the
next launch of the wxPLViewer GUI on the next loop ended up being full
sized.

Despite the above caveat these time results are still quite
interesting.  I have indicated with a trailing asterisk in the above
table which of the three times was the best, and if you count those
results above you obtain the following summary:

qtwidget  10
xcairo    08
wxwidgets 09

So it is clear that wxwidgets is now pretty much holding its own
(ignoring the caveat) with the others for our standard set of
examples, and since my previous evaluation done near the time when
5.11.1 was released was subject to the same caveat it is clear there
has been quite a substantial improvement, and we can generally (with a
few exceptions to be discussed) be proud of the efficiency of this
device now on Linux.

There are two known exceptions to the above remarks.  Whereas in all
the other examples above wxwidgets is at most two times slower than
the fastest result from either qt or xcairo, we have the following results
for examples 08 and 25 generated by a similar loop to the above
(starting with

for N in 08 25; ....

).

08
real    0.860 *
real    1.971
real    13.520
25
real    1.102
real    0.655 *
real    5.311

For these two cases, wxwidgets is slower (subject to the same caveat) than the best of the other
two devices by respective factors of 16 and 8!

After the release we should look at examples 08 and 25 to see what the
issue is, but both these examples have large numbers of graphical
elements (i.e., example 08 uses a large number of small triangles
to represent those varying 3D surfaces in a smooth way and 
example 25 uses a large number of thin rectangles to represent the number
of gradients in this plot in a smooth way). So my working hypothesis
to explain these large slowdowns compared to the rest of the examples
is there is some bottleneck transmitting positional data for graphical
elements between -dev wxwidgets and associated wxPLViewer application
via shared memory.  If this hypothesis is correct, the cure for this
issue would likely be to move to the efficient "unnamed semaphores"
algorithm which I demonstrated (using the proof-of-concept project at
cmake/test_linux_ipc) could move 25MB of data from one executable to
another in 0.3 seconds!

(I assume example 33 will show the same slowdown issue as 25 because
there are lots of plgradient invocations in example 33, but I did not
investigate 33 because it takes so long even when it is efficient.)

Also note whatever the cure is for this slowdown issue with examples
that have large numbers of graphical elements, it might be a noticable
benefit to some of the rest of the examples with moderate numbers of
graphical elements.  Thus, with any luck at all when this particular
inefficiency is solved we might see a big increase in the number of
examples where wxwidgets is faster than both the qtwidget and xcairo
results.

So from the above numbers there is still one obvious Linux efficiency
issue left for -dev wxwidgets that we need to work on after the
release, and we can look forward to a potential big payoff from that
work not only for examples 08 and 25, but possibly several other
examples as well.  However, for this release we can still be proud of
all the Linux wxwidgets efficiency progress made to this point.

So, good work, Phil, on getting us to this stage!

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


>Does that seem like a reasonable plan for dealing with the fairly
>large release uncertainties created by this issue?

yes

this is 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. But why should it matter? Just 
> run
> the event loop until the "create" event is received and do whatever
> initialization you need to do once it happens, you don't have to (and 
> won't
> be able to) do it directly in OnInit().

he says we cannot expect a timely response from the "create" event in 
wxApp::OnInit(),
which is the way wxPLplotDemo has.

so, we have to change that, it just cannot be like it is now.

@Phil

several options

1)

remove the frame creation from wxApp::OnInit(),

I don't know where to move it to (or even if it is possible) , but the wxApp 
methods could provide some insight.

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

2)

leave the frame creation in wxApp::OnInit(),

this requires that the  "create" event  must not be triggered, so we cannot 
call for OnCreate().

Since the frame creation must be done in the "create" functions (either in 
Create() or OnCreate())
that leaves only the Create()  function.

But , like Phil mentioned , the class that eventually creates the plot could 
not be a wxFrame,
so the Create()  function cannot be overriden.

But maybe we can do the template valid only for classes that have similar 
Create() functions to wxFrame, and where
it is possible to override Create() ?

I don't know wich classes are the intended targets of the plot, maybe also 
dialogs?

3) other option would be not to do the templated plot window, and do a 
version only for wxFrame,
and override the Create() function, and make the frame in wxApp::OnInit().

But this would probably break existing applications.
but at the moment this is the only solution that we know has no potencial 
issues.


> However, that might be the wrong thing to do since the issue is we
> don't really understand what is going on here. So I think we really need a 
> fundamental solution for this issue that
> you guys understand before we release PLplot.

yes, no point in switching to another commit version that could have or not 
the same problem.


> But finding
> a fundamental solution to this issue is important enough that I think
> we should put off that commit (if necessary) until 5 days from now
> (Tuesday,December 27th when I was planning to make the release).

ok


-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: Thursday, December 22, 2016 5:07 PM
Subject: RE: [Plplot-devel] Infinite Yielding issue


> On 2016-12-22 09:48-0500 Pedro Vicente wrote:
>
>> Hi Phil
>>
>> there is a response from a developer
>>
>> https://groups.google.com/forum/#!topic/wx-dev/wsk--AlQNzU
>
> To Pedro and Phil:
>
> I hope that developer is responsive to Pedro's supplementary question,
> but so far he hasn't been.  Therefore, Pedro, I suggest you follow
> Phil's advice to try other wxwidgets help avenues as well such as the
> "wxWidgets trac system" he mentioned for getting help.
>
> Meanwhile, I discovered just this morning that I now
> have the infinite Yielding loop when attempting to build the
> test_wxPLplotDemo target.  I believe that is the first time
> that anybody other than Pedro has encountered this issue.
>
> And if I use
>
> git checkout master^
>
> the test_wxPLplotDemo infinite Yielding loop goes away, i.e., I get
>
> 12:43:03: Debug: nanosecs since epoch = 2131058112372533: 
> wxPLplotwindow::wxPLplotwindow
> 12:43:03: Debug: nanosecs since epoch = 2131058122107520: frame->Create
> 12:43:03: Debug: nanosecs since epoch = 2131058129943746: 
> wxPLplotwindow::OnCreate
> 12:43:03: Debug: nanosecs since epoch = 2131058145174385: 
> plD_init_wxwidgets(): enter
> 12:43:03: Debug: nanosecs since epoch = 2131058145277524: wxPLDevice(): 
> enter
> 12:43:03: Debug: nanosecs since epoch = 2131058145349163: wxPLDevice(): gc 
> done
> 12:43:03: Debug: nanosecs since epoch = 2131058145447089: wxPLDevice(): 
> m_interactiveTextGcdc done
> 12:43:03: Debug: nanosecs since epoch = 2131058145489262: wxPLDevice(): 
> SetDC done
> 12:43:03: Debug: nanosecs since epoch = 2131058145596088: wxPLDevice(): 
> leave
> 12:43:03: Debug: nanosecs since epoch = 2131058145629197: 
> plD_init_wxwidgets(): leave
> 12:43:03: Debug: nanosecs since epoch = 2131058166078403: Plot()
>
> But the infinite loop comes back again if I use
>
> git checkout master
>
> where to be clear master =
>
> 995e75e Made some items clearer in the wxWigdets Demo
>
> I am pretty sure I tested 995e75e previously by building the
> test_wxPLplotDemo target without encountering the infinite loop.  So
> it is possible the infinite loop depends on delicate timing conditions
> that come and go....  However, I also tried Pedro's simple example
> again, and that does not have an infinite loop this morning.
>
> My instincts as release manager are to make another commit that
> reverses the effect of 995e75e which I believe was also Pedro's plan
> with a deadline of tomorrow (Friday) if he could not get advice
> on a definitive fix.
>
> However, that might be the wrong thing to do since the issue is we
> don't really understand what is going on here.  For example, making
> another commit that puts us back to the equivalent of
>
> 65e7b3c Fix bug with plotting in wxPLplotDemo
>
> may still leave some users out there that experience the infinite
> loop even when all of Pedro's tests of 65e7b3c and mine seem fine.
>
> So I think we really need a fundamental solution for this issue that
> you guys understand before we release PLplot.  So I appreciate you
> both spending some time on this issue by, e.g., exploring all avenues
> such as the "wxWidgets trac system" that Phil mentioned for getting
> help and also reading through wxwidgets documentation and tutorials
> to try and figure out for yourselves what is going on.
>
> In sum, I believe Pedro's plan was to suggest I make that commit to
> return us to the equivalent of 65e7b3c tomorrow (Friday) if he or Phil
> got no useful responses to their questions on wxwidgets forums
> concerning Pedro's simple example of the problem by then.  But finding
> a fundamental solution to this issue is important enough that I think
> we should put off that commit (if necessary) until 5 days from now
> (Tuesday,December 27th when I was planning to make the release).  And
> at that point we should decide whether to release using the equivalent
> of 65e7b3c or delay the release for several more days (and maybe into
> the first week in 2017) until we do get a fundamental fix that you
> guys understand.
>
> Does that seem like a reasonable plan for dealing with the fairly
> large release uncertainties created by this issue?
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

Re: [Plplot-devel] Infinite Yielding issue

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

On 2016-12-22 09:48-0500 Pedro Vicente wrote:

> Hi Phil
>
> there is a response from a developer
>
> https://groups.google.com/forum/#!topic/wx-dev/wsk--AlQNzU

To Pedro and Phil:

I hope that developer is responsive to Pedro's supplementary question,
but so far he hasn't been.  Therefore, Pedro, I suggest you follow
Phil's advice to try other wxwidgets help avenues as well such as the
"wxWidgets trac system" he mentioned for getting help.

Meanwhile, I discovered just this morning that I now
have the infinite Yielding loop when attempting to build the
test_wxPLplotDemo target.  I believe that is the first time
that anybody other than Pedro has encountered this issue.

And if I use

git checkout master^

the test_wxPLplotDemo infinite Yielding loop goes away, i.e., I get

12:43:03: Debug: nanosecs since epoch = 2131058112372533: wxPLplotwindow::wxPLplotwindow
12:43:03: Debug: nanosecs since epoch = 2131058122107520: frame->Create
12:43:03: Debug: nanosecs since epoch = 2131058129943746: wxPLplotwindow::OnCreate
12:43:03: Debug: nanosecs since epoch = 2131058145174385: plD_init_wxwidgets(): enter
12:43:03: Debug: nanosecs since epoch = 2131058145277524: wxPLDevice(): enter
12:43:03: Debug: nanosecs since epoch = 2131058145349163: wxPLDevice(): gc done
12:43:03: Debug: nanosecs since epoch = 2131058145447089: wxPLDevice(): m_interactiveTextGcdc done
12:43:03: Debug: nanosecs since epoch = 2131058145489262: wxPLDevice(): SetDC done
12:43:03: Debug: nanosecs since epoch = 2131058145596088: wxPLDevice(): leave
12:43:03: Debug: nanosecs since epoch = 2131058145629197: plD_init_wxwidgets(): leave
12:43:03: Debug: nanosecs since epoch = 2131058166078403: Plot()

But the infinite loop comes back again if I use

git checkout master

where to be clear master =

995e75e Made some items clearer in the wxWigdets Demo

I am pretty sure I tested 995e75e previously by building the
test_wxPLplotDemo target without encountering the infinite loop.  So
it is possible the infinite loop depends on delicate timing conditions
that come and go....  However, I also tried Pedro's simple example
again, and that does not have an infinite loop this morning.

My instincts as release manager are to make another commit that
reverses the effect of 995e75e which I believe was also Pedro's plan
with a deadline of tomorrow (Friday) if he could not get advice
on a definitive fix.

However, that might be the wrong thing to do since the issue is we
don't really understand what is going on here.  For example, making
another commit that puts us back to the equivalent of

65e7b3c Fix bug with plotting in wxPLplotDemo

may still leave some users out there that experience the infinite
loop even when all of Pedro's tests of 65e7b3c and mine seem fine.

So I think we really need a fundamental solution for this issue that
you guys understand before we release PLplot.  So I appreciate you
both spending some time on this issue by, e.g., exploring all avenues
such as the "wxWidgets trac system" that Phil mentioned for getting
help and also reading through wxwidgets documentation and tutorials
to try and figure out for yourselves what is going on.

In sum, I believe Pedro's plan was to suggest I make that commit to
return us to the equivalent of 65e7b3c tomorrow (Friday) if he or Phil
got no useful responses to their questions on wxwidgets forums
concerning Pedro's simple example of the problem by then.  But finding
a fundamental solution to this issue is important enough that I think
we should put off that commit (if necessary) until 5 days from now
(Tuesday,December 27th when I was planning to make the release).  And
at that point we should decide whether to release using the equivalent
of 65e7b3c or delay the release for several more days (and maybe into
the first week in 2017) until we do get a fundamental fix that you
guys understand.

Does that seem like a reasonable plan for dealing with the fairly
large release uncertainties created by this issue?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] An alternative idea for comprehensive testing of MSVC + ifort

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

On 2016-12-22 09:32-0000 Arjen Markus wrote:

[...]
> I now use a Tcl script to compare the files (because of lack of a suitable command under Windows - sigh)
[...]

Hi Arjen:

I got curious about that, and a google search found
<http://stackoverflow.com/questions/6877238/what-is-the-windows-equivalent-of-the-diff-command>
where some of the suggested windows equivalents of the diff command seemed to meet with universal
approval.

The problem is that is a start of a long difficult path where you end up
trying to mimic the logic of our current test system that depends
on bash and several other Unix tools (such as cmp and/or diff).

So I think instead you might want to consider simply putting the
relevant Unix tools from MinGW-w64/MSYS2 (or Cygwin) on your PATH and
proceeding from there to test your MSVC + ifort platform.  As I recall
you tried that approach before, and the Windows approach for setting
the PATH was not working for you. But I think it would work if you
simply executed the MinGW-w64/MSYS2 bash.exe by typing in its full
pathname from a CMD environment, set the environment variables such as
PATH that you need to set using bash facilities (e.g., running the
source command on a file containing all the export commands that you
need so you don't have to execute those export commands by hand), and
then ran the comprehensive test script from that environment with
nmake specified as the build command.

I am pretty confident this approach would work because it is
equivalent to the approach I used to take for testing the old MinGW
(without old MSYS) build that used the "MinGW Makefiles" generator on
the Wine version of Windows. All those tests were done from a CMD
environment using the old MinGW make command (mingw32-make.exe) but
with the old MSYS bin directory on the PATH to give access to the Unix
tools needed for the tests (but avoiding using those tools for the
build itself).  So I don't see why you cannot do the same with
nmake.exe replacing mingw32-make.exe.

In sum, I recommend you take another serious look at this general
approach (with Unix tools used just for testing but expressly not used
for the build) the next time (likely in 2017) that you have a chance
to work on PLplot testing on the MSVC + ifort build platform.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Infinite Yielding issue

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

Hi Phil

there is a response from a developer

https://groups.google.com/forum/#!topic/wx-dev/wsk--AlQNzU

-Pedro


On 2016-12-22 04:58, p.d...@gm... wrote:
> Hi Pedro
>
> It's great that you set that up. I would suggest that you post it to
> the wxWidgets trac system too. The forum is great for advice on how 
> we
> can change things, and doublemax really knows what he’s talking
> about, but the wxWidgets devs only use trac for dealing with bug
> reports. If it is left on the forum then it will get lost.
>
> Phil
>
> Sent from my Windows 10 phone
>
> FROM: Alan W. Irwin [1]
> SENT: 22 December 2016 05:39
> TO: Pedro Vicente [2]; Phil Rosenberg [3]; PLplot development list 
> [4]
> SUBJECT: Re: [Plplot-devel] Infinite Yielding issue
>
> Hi Pedro:
>
> More thoughts:
>
> I like your example because it follows the first rule of debugging
>
> which is to simplify the example that shows the strange behaviour.
>
> And I get success on my platform, and you don't on yours which
>
> confirms there is a problem (either there is a bug in wxwidgets/GTK+
>
> or your simple example uses that software incorrectly). But it is a
> huge
>
> simplification that PLplot is no longer involved, and I highly
>
> approve.
>
> And with regard to the actual problem demonstrated by this simple
>
> example, I am still left wondering if you might be exposing some
>
> wxwidgets or GTK+ bug on your fast hardware there that my slow
>
> hardware does not expose here?  So just for fun, can you get access
> to
>
> a Linux system on a moderately slow PC there to try this simple
>
> example?  It doesn't have to be superslow. But I do have a
>
> nine-year-old PC running at 2.4GHz with two cpus. So if you can find 
> a
>
> Linux PC that has roughly the same speed as that, you might find a
>
> platform where you obtain success with your simple example which 
> might
>
> be a clue about the cause of this issue.
>
> Alan
>
> __________________________
>
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and
> Astronomy,
>
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
>
> implementation for stellar interiors (freeeos.sf.net); the Time
>
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>
> software package (plplot.sf.net); the libLASi project
>
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>
> and the Linux Brochure Project (lbproject.sf.net).
>
> __________________________
>
> Linux-powered Science
>
> __________________________
>
>
>
> Links:
> ------
> [1] mailto:ir...@be...
> [2] mailto:ped...@sp...
> [3] mailto:p.d...@gm...
> [4] mailto:plp...@li...

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