Re: [Plplot-devel] Comprehensive testing

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, December 22, 2016 1:15 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Comprehensive testing
>
> Hi Arjen:
>
> I have just described your recent MSVC + ifort platform tests as the first 
> item in the
> two tables at
> 
> and
>  ts>.
> Please take a careful look at the footnote (called "l" in that former table 
> and "d" in
> that latter table, but the wording is identical for those two different 
> footnotes).  I
> believe I have come up with a resonable designation for your MSVC compiler in
> those footnotes, but feel free to advise me if you think I can improve on 
> that.  Also,
> note the two ??? values that are in that footnote now corresponding to the Tcl
> version you use and general site where you obtained that version of Tcl.  
> Could you
> please let me know that information so I can replace those ??? values or else
> update those two separate footnotes yourself?
>
I have just added the version and origin information for Tcl in the Wiki page.

As for the designation of the C/C++ and Fortran compilers: as far as I am aware 
"everybody" uses the terms now in that Wiki page. The official designations you 
get with the options to report the version are confusing in my opinion - what 
is a composer other than someone writing a piece of music? (Those terms seem to 
originate with the marketing department of the various companies.)

The short message therefore is that with the concise and the detailed 
designations the software has been uniquely identified.

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.
--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Comprehensive testing

[Alan W. Irwin]

On 2016-12-22 08:27- Arjen Markus wrote:

> I have just added the version and origin information for Tcl in the Wiki page.

Thanks, Arjen.  I tweaked that footnote a bit more than propagated all
changes to the (duplicate) footnote for the other table.  While doing
that, it struck me that although the current description of your batch
file (taken from your e-mail) does not include C++, those examples are
built in any case by nmake. So the next time you use that batch file
you may want to add the C++ examples as well.

Also, would you be willing to copy your batch file to the scripts
directory and commit it?  It sounds like it would be useful to other
MSVC + ifort testers.

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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Comprehensive testing

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, December 22, 2016 10:25 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Comprehensive testing
>
> On 2016-12-22 08:27- Arjen Markus wrote:
>
> > I have just added the version and origin information for Tcl in the Wiki 
> > page.
>
> Thanks, Arjen.  I tweaked that footnote a bit more than propagated all 
> changes to
> the (duplicate) footnote for the other table.  While doing that, it struck me 
> that
> although the current description of your batch file (taken from your e-mail) 
> does not
> include C++, those examples are built in any case by nmake. So the next time 
> you
> use that batch file you may want to add the C++ examples as well.
>
> Also, would you be willing to copy your batch file to the scripts directory 
> and commit
> it?  It sounds like it would be useful to other MSVC + ifort testers.
>
Yes, that is an omission in the script. I now use a Tcl script to compare the 
files (because of lack of a suitable command under Windows - sigh) but a small 
C program to do the same may be more appropriate - we can be sure there is a C 
compiler on the machine, but not anything else. Also my current script simply 
takes for granted that the various languages are supported. I should make it a 
trifle more robust before releasing it to the outside world :). I will take 
care of both issues, not sure when, as the coming festivities will exact their 
toll on my time.

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.
--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[p.d.rosenberg]

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
Sent: 22 December 2016 05:39
To: Pedro Vicente; Phil Rosenberg; PLplot development list
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
__

--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

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.rosenb...@gmail.com 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...@beluga.phys.uvic.ca
> [2] mailto:pedro.vice...@space-research.org
> [3] mailto:p.d.rosenb...@gmail.com
> [4] mailto:plplot-devel@lists.sourceforge.net

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

On 2016-12-22 09:32- 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

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
__

--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Alan W. Irwin]

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
__

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

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@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" 
To: "Pedro Vicente" ; "Phil Rosenberg" 
; "PLplot development list" 

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 tr

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

[Alan W. Irwin]

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
real0.184 *
real0.292
real0.344
01
real0.207 *
real0.376
real0.307
02
real0.279 *
real0.386
real0.288
03
real0.191 *
real0.385
real0.275
04
real0.293
real0.400
real0.279 *
05
real0.188 *
real0.395
real0.275
06
real0.598
real0.458
real0.393 *
07
real1.331
real0.846
real0.619 *
09
real0.570
real0.450
real0.370 *
10
real0.178 *
real0.351
real0.296
11
real0.882
real0.750
real0.407 *
12
real0.504
real0.498 *
real0.807
13
real0.184 *
real0.334
real0.301
14
real0.813
real0.712
real0.669 *
15
real0.310 *
real0.417
real0.376
16
real0.578
real0.998
real0.402 *
18
real1.281
real0.813 *
real1.161 
19
real1.015
real0.844
real0.668 *
21
real0.806 *
real0.887
real1.124
22
real0.923 
real0.824 *
real0.925
23
real2.860
real1.463 *
real1.685
24
real0.630
real0.533 *
real0.845
26
real0.628
real0.524 *
real0.854
27
real1.396
real1.077 *
real1.232
28
real0.834
real0.567 *
real0.883
29
real0.781
real0.643
real0.466 *
30
real0.238 *
real0.365
real0.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 

Re: [Plplot-devel] Infinite Yielding issue

[Alan W. Irwin]

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

--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

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 
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" 
To: "Pedro Vicente" ; "Phil Rosenberg" 
; "PLplot development list" 


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

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> 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- 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
>  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.
--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel