plplot-devel

[Plplot-devel] New way to generate wxwidgets debug output

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

I have recently (commit 3c4e6be) implemented a new way for users to
optionally obtain wxwidgets debug output.

The principal change is you must use the CMake option
-DPLPLOT_WX_DEBUG_OUTPUT=ON to get any debug output at all.  There is
also now an experimental option -DPLPLOT_WX_NANOSEC=ON which you might
want to try if your like high-resolution time stamps (but it might
cause build errors on some Linux systems and virtually all other
systems, so you must experiment with it to see whether it will work on
any given system). If you want to insert more debugging output into
our wxwidgets-related code under the control of the above two CMake
options, please use the correct macro which is

PLPLOT_wxLogDebug("some string");

That boils down to

wxLogDebug("some string");

if -DPLPLOT_WX_DEBUG_OUTPUT=ON and PLPLOT_WX_NANOSEC is either not
specified or set to its default value using -DPLPLOT_WX_NANOSEC=OFF.
The above macro use further boils down to

;

if PLPLOT_WX_DEBUG_OUTPUT is either not specified or set to its
default value using -DPLPLOT_WX_DEBUG_OUTPUT=OFF.

For more details (especially what the nanosec time stamp looks like on
systems that support it), see the above commit message.

Note, that I plan after the release to implement a CMake test so it
can figure out PLPLOT_WX_NANOSEC automatically, i.e., only set that to
ON when relevant test code can be built.  However, for now I have
taken an extremely simplistic approach "try it and see using the
experimental option -DPLPLOT_WX_NANOSEC=ON" for generating the
nanonsec time step.

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] New way to generate wxwidgets debug output

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

Hi Alan

I just did a git pull of the master branch with these changes and I get 
compiling errors
if I don't add

-DPLPLOT_WX_NANOSEC=ON


I did

cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF 
-DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF 
-DBUILD_TEST:BOOL=ON
make VERBOSE=1 test_wxPLplotDemo

and result is


In file included from 
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets.h:28,
                  from 
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp:41:
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets_comms.h:35:30: 
error: wxPLplot_nanosec.h: No such file or directory
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp: In function 
‘void plD_init_wxwidgets(PLStream*)’:
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp:148: error: 
‘PLPLOT_wxLogDebug’ was not declared in this scope


and the same with

-DPLPLOT_WX_DEBUG_OUTPUT=ON

if I add

-DPLPLOT_WX_NANOSEC=ON

the build succeds and the output is


12:29:29: Debug: nanosecs since epoch = 21778268382005471: 
wxPLplotwindow::wxPLplotwindow
12:29:29: Debug: nanosecs since epoch = 21778268383178783: 
frame->Create
12:29:29: Debug: nanosecs since epoch = 21778268393882737: 
wxPLplotwindow::Show
12:29:29: Debug: nanosecs since epoch = 21778268393941866: 
wxPLplotwindow::CreateStream
12:29:29: Debug: nanosecs since epoch = 21778268401739575: 
plD_init_wxwidgets(): enter
12:29:29: Debug: nanosecs since epoch = 21778268401812999: 
wxPLDevice(): enter
12:29:29: Debug: nanosecs since epoch = 21778268401896369: 
wxPLDevice(): gc done
12:29:29: Debug: nanosecs since epoch = 21778268402036165: 
wxPLDevice(): m_interactiveTextGcdc done
12:29:29: Debug: nanosecs since epoch = 21778268402095492: 
wxPLDevice(): SetDC done
12:29:29: Debug: nanosecs since epoch = 21778268402127174: 
wxPLDevice(): leave
12:29:29: Debug: nanosecs since epoch = 21778268402165801: 
plD_init_wxwidgets(): leave
12:29:29: Debug: nanosecs since epoch = 21778268406212150: Plot()
12:29:29: Debug: nanosecs since epoch = 21778268498272214: 
wxPLplotwindow::OnCreate
12:29:29: Debug: nanosecs since epoch = 21778268498387763: 
wxPLplotwindow::CreateStream





On 2016-12-19 01:22, Alan W. Irwin wrote:
> I have recently (commit 3c4e6be) implemented a new way for users to
> optionally obtain wxwidgets debug output.
>
> The principal change is you must use the CMake option
> -DPLPLOT_WX_DEBUG_OUTPUT=ON to get any debug output at all.  There is
> also now an experimental option -DPLPLOT_WX_NANOSEC=ON which you 
> might
> want to try if your like high-resolution time stamps (but it might
> cause build errors on some Linux systems and virtually all other
> systems, so you must experiment with it to see whether it will work 
> on
> any given system). If you want to insert more debugging output into
> our wxwidgets-related code under the control of the above two CMake
> options, please use the correct macro which is
>
> PLPLOT_wxLogDebug("some string");
>
> That boils down to
>
> wxLogDebug("some string");
>
> if -DPLPLOT_WX_DEBUG_OUTPUT=ON and PLPLOT_WX_NANOSEC is either not
> specified or set to its default value using -DPLPLOT_WX_NANOSEC=OFF.
> The above macro use further boils down to
>
> ;
>
> if PLPLOT_WX_DEBUG_OUTPUT is either not specified or set to its
> default value using -DPLPLOT_WX_DEBUG_OUTPUT=OFF.
>
> For more details (especially what the nanosec time stamp looks like 
> on
> systems that support it), see the above commit message.
>
> Note, that I plan after the release to implement a CMake test so it
> can figure out PLPLOT_WX_NANOSEC automatically, i.e., only set that 
> to
> ON when relevant test code can be built.  However, for now I have
> taken an extremely simplistic approach "try it and see using the
> experimental option -DPLPLOT_WX_NANOSEC=ON" for generating the
> nanonsec time step.
>
> 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] New way to generate wxwidgets debug output

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

Hi Alan
Could you just confirm to me what command you are using to test the timings?

Phil

On 19 December 2016 at 17:33, Pedro Vicente
<ped...@sp...> wrote:
> Hi Alan
>
> I just did a git pull of the master branch with these changes and I get
> compiling errors
> if I don't add
>
> -DPLPLOT_WX_NANOSEC=ON
>
>
> I did
>
> cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF
> -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF
> -DBUILD_TEST:BOOL=ON
> make VERBOSE=1 test_wxPLplotDemo
>
> and result is
>
>
> In file included from
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets.h:28,
>                  from
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp:41:
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets_comms.h:35:30: error:
> wxPLplot_nanosec.h: No such file or directory
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp: In function
> ‘void plD_init_wxwidgets(PLStream*)’:
> /data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp:148: error:
> ‘PLPLOT_wxLogDebug’ was not declared in this scope
>
>
> and the same with
>
> -DPLPLOT_WX_DEBUG_OUTPUT=ON
>
> if I add
>
> -DPLPLOT_WX_NANOSEC=ON
>
> the build succeds and the output is
>
>
> 12:29:29: Debug: nanosecs since epoch = 21778268382005471:
> wxPLplotwindow::wxPLplotwindow
> 12:29:29: Debug: nanosecs since epoch = 21778268383178783: frame->Create
> 12:29:29: Debug: nanosecs since epoch = 21778268393882737:
> wxPLplotwindow::Show
> 12:29:29: Debug: nanosecs since epoch = 21778268393941866:
> wxPLplotwindow::CreateStream
> 12:29:29: Debug: nanosecs since epoch = 21778268401739575:
> plD_init_wxwidgets(): enter
> 12:29:29: Debug: nanosecs since epoch = 21778268401812999: wxPLDevice():
> enter
> 12:29:29: Debug: nanosecs since epoch = 21778268401896369: wxPLDevice(): gc
> done
> 12:29:29: Debug: nanosecs since epoch = 21778268402036165: wxPLDevice():
> m_interactiveTextGcdc done
> 12:29:29: Debug: nanosecs since epoch = 21778268402095492: wxPLDevice():
> SetDC done
> 12:29:29: Debug: nanosecs since epoch = 21778268402127174: wxPLDevice():
> leave
> 12:29:29: Debug: nanosecs since epoch = 21778268402165801:
> plD_init_wxwidgets(): leave
> 12:29:29: Debug: nanosecs since epoch = 21778268406212150: Plot()
> 12:29:29: Debug: nanosecs since epoch = 21778268498272214:
> wxPLplotwindow::OnCreate
> 12:29:29: Debug: nanosecs since epoch = 21778268498387763:
> wxPLplotwindow::CreateStream
>
>
>
>
>
>
> On 2016-12-19 01:22, Alan W. Irwin wrote:
>>
>> I have recently (commit 3c4e6be) implemented a new way for users to
>> optionally obtain wxwidgets debug output.
>>
>> The principal change is you must use the CMake option
>> -DPLPLOT_WX_DEBUG_OUTPUT=ON to get any debug output at all.  There is
>> also now an experimental option -DPLPLOT_WX_NANOSEC=ON which you might
>> want to try if your like high-resolution time stamps (but it might
>> cause build errors on some Linux systems and virtually all other
>> systems, so you must experiment with it to see whether it will work on
>> any given system). If you want to insert more debugging output into
>> our wxwidgets-related code under the control of the above two CMake
>> options, please use the correct macro which is
>>
>> PLPLOT_wxLogDebug("some string");
>>
>> That boils down to
>>
>> wxLogDebug("some string");
>>
>> if -DPLPLOT_WX_DEBUG_OUTPUT=ON and PLPLOT_WX_NANOSEC is either not
>> specified or set to its default value using -DPLPLOT_WX_NANOSEC=OFF.
>> The above macro use further boils down to
>>
>> ;
>>
>> if PLPLOT_WX_DEBUG_OUTPUT is either not specified or set to its
>> default value using -DPLPLOT_WX_DEBUG_OUTPUT=OFF.
>>
>> For more details (especially what the nanosec time stamp looks like on
>> systems that support it), see the above commit message.
>>
>> Note, that I plan after the release to implement a CMake test so it
>> can figure out PLPLOT_WX_NANOSEC automatically, i.e., only set that to
>> ON when relevant test code can be built.  However, for now I have
>> taken an extremely simplistic approach "try it and see using the
>> experimental option -DPLPLOT_WX_NANOSEC=ON" for generating the
>> nanonsec time step.
>>
>> 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] New way to generate wxwidgets debug output

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

To Phil and Pedro:

Just woke up, skimmed through your e-mails, and I promise to look at the
build issue that Pedro found starting just when I finish this e-mail.
Further thoughts below on what Phil said.

On 2016-12-19 17:42-0000 Phil Rosenberg wrote:

> Hi Alan
> Could you just confirm to me what command you are using to test the timings?


Exactly as stated in the commit message (after building the x01c, wxwidgets,
and wxPLViewer prerequisite targets).

time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c

It is the second of these commands where the pause occurs.

At one point I thought as you did that the random number generator
would have something to do with it, but is that actually used in the
interval where the pause is occurring?

The only reference to randomGenerator in the key interval of code is

static Rand  randomGenerator;         // make this static so that rapid repeat calls don't use the same seed

Last night I dismissed this possibility, but I guess what you are
saying now is this is not a simple declaration of Rand for later on,
but this also actually ends up running randomGenerator!

Regardless of such speculation on my part, I will try building up
some entropy before the above test to see if that affects the pause. I
will also try temporarily commenting out randomGenerator from all
aspects of the code to see if that totally solves the issue.  Then if
that step completely proves Phil's hypothesis, figure out a fix that
doesn't require a tonne of pure entropy.  But the first priority is the
above build fix.

Phil, later on today (hopefully just an hour or so) I will also start
testing your patch for the other issue of getting ready for Plot().

So yesterday we had two long-standing wxwidgets-related issues and
today there is a decent prospect of fixing both of them.  So I am
pretty hopeful right now!

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] New way to generate wxwidgets debug output

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

Hi Alan
I am on my commute home right now. But if you want to test if the random number generator is the cause then find the Rand constructor – Rand::Rand() and comment out everything, replacing it with a single line that sets the seed (probably m_seed or something) to a fixed value, like 0. That will show whether generating the seed is causing the slowdown.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 19 December 2016 19:38
To: Phil Rosenberg; Pedro Vicente; PLplot development list
Subject: Re: New way to generate wxwidgets debug output

To Phil and Pedro:

Just woke up, skimmed through your e-mails, and I promise to look at the
build issue that Pedro found starting just when I finish this e-mail.
Further thoughts below on what Phil said.

On 2016-12-19 17:42-0000 Phil Rosenberg wrote:

> Hi Alan
> Could you just confirm to me what command you are using to test the timings?


Exactly as stated in the commit message (after building the x01c, wxwidgets,
and wxPLViewer prerequisite targets).

time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c

It is the second of these commands where the pause occurs.

At one point I thought as you did that the random number generator
would have something to do with it, but is that actually used in the
interval where the pause is occurring?

The only reference to randomGenerator in the key interval of code is

static Rand  randomGenerator;         // make this static so that rapid repeat calls don't use the same seed

Last night I dismissed this possibility, but I guess what you are
saying now is this is not a simple declaration of Rand for later on,
but this also actually ends up running randomGenerator!

Regardless of such speculation on my part, I will try building up
some entropy before the above test to see if that affects the pause. I
will also try temporarily commenting out randomGenerator from all
aspects of the code to see if that totally solves the issue.  Then if
that step completely proves Phil's hypothesis, figure out a fix that
doesn't require a tonne of pure entropy.  But the first priority is the
above build fix.

Phil, later on today (hopefully just an hour or so) I will also start
testing your patch for the other issue of getting ready for Plot().

So yesterday we had two long-standing wxwidgets-related issues and
today there is a decent prospect of fixing both of them.  So I am
pretty hopeful right now!

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] New way to generate wxwidgets debug output

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

On 2016-12-19 19:47-0000 p.d...@gm... wrote:

> Hi Alan

> I am on my commute home right now. But if you want to test if the random number generator is the cause then find the Rand constructor – Rand::Rand() and comment out everything, replacing it with a single line that sets the seed (probably m_seed or something) to a fixed value, like 0. That will show whether generating the seed is causing the slowdown.

Hi Phil:

Thanks to your leap of insight that it was entropy and the random
number generator that was the source of the issue, I have now found
the fix!  My tests show all pauses are now gone after the following
local change, but I need C++ help to finalize this fix.

diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
index 1131e9b..e0f215f 100644
--- a/drivers/wxwidgets_dev.cpp
+++ b/drivers/wxwidgets_dev.cpp
@@ -603,7 +603,7 @@ public:
  #ifdef WIN32
          rand_s( &m_seed );
  #else
-        std::fstream fin( "/dev/random", std::ios::in );
+        std::fstream fin( "/dev/urandom", std::ios::in );
          fin.read( (char *) ( &m_seed ), sizeof ( m_seed ) );
          fin.close();
  #endif

The difference between /dev/random and /dev/urandom on Linux is the
former is blocking (and therefore only recommended if you need highest
security and are willing to wait for it) while the latter is not
blocking and gives adequate pseudo-randomness for most purposes (such
as ours). See <https://en.wikipedia.org/wiki//dev/random> for further
details.

The only trouble with the above fix is not every Unix platform has
/dev/urandom (although from the above URL most do).

So I would like to change the above fix to check for /dev/urandom
and use it if it exists, but otherwise fall back to using /dev/random.

How do I do that in C++?

Or, better yet show me by going ahead and making the commit to that
effect.

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] New way to generate wxwidgets debug output

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

Hi Alan


> The only trouble with the above fix is not every Unix platform has
> /dev/urandom (although from the above URL most do).
>
> So I would like to change the above fix to check for /dev/urandom
> and use it if it exists, but otherwise fall back to using 
> /dev/random.
>
> How do I do that in C++?


This is not a C++ (or C) issue.
This is ideal for cmake to check, the same way it detects for other 
possible system functions/features availability.
I never did this before, but I think the way it works it is on the 
cmake script
do a small C or C++ program embedded in the script that includes 
"/dev/urandom" in some way, for example

std::fstream fin( "/dev/urandom", std::ios::in );

and then check if it compiles and pass the result to cmake

> > /dev/urandom (although from the above URL most do).

yes, by reading the Wikipedia page,
they don't say of any system that does not have "/dev/urandom"

-Pedro


On 2016-12-19 16:14, Alan W. Irwin wrote:
> On 2016-12-19 19:47-0000 p.d...@gm... wrote:
>
>> Hi Alan
>
>> I am on my commute home right now. But if you want to test if the 
>> random number generator is the cause then find the Rand constructor – 
>> Rand::Rand() and comment out everything, replacing it with a single 
>> line that sets the seed (probably m_seed or something) to a fixed 
>> value, like 0. That will show whether generating the seed is causing 
>> the slowdown.
>
> Hi Phil:
>
> Thanks to your leap of insight that it was entropy and the random
> number generator that was the source of the issue, I have now found
> the fix!  My tests show all pauses are now gone after the following
> local change, but I need C++ help to finalize this fix.
>
> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> index 1131e9b..e0f215f 100644
> --- a/drivers/wxwidgets_dev.cpp
> +++ b/drivers/wxwidgets_dev.cpp
> @@ -603,7 +603,7 @@ public:
>  #ifdef WIN32
>          rand_s( &m_seed );
>  #else
> -        std::fstream fin( "/dev/random", std::ios::in );
> +        std::fstream fin( "/dev/urandom", std::ios::in );
>          fin.read( (char *) ( &m_seed ), sizeof ( m_seed ) );
>          fin.close();
>  #endif
>
> The difference between /dev/random and /dev/urandom on Linux is the
> former is blocking (and therefore only recommended if you need 
> highest
> security and are willing to wait for it) while the latter is not
> blocking and gives adequate pseudo-randomness for most purposes (such
> as ours). See <https://en.wikipedia.org/wiki//dev/random> for further
> details.
>
> The only trouble with the above fix is not every Unix platform has
> /dev/urandom (although from the above URL most do).
>
> So I would like to change the above fix to check for /dev/urandom
> and use it if it exists, but otherwise fall back to using 
> /dev/random.
>
> How do I do that in C++?
>
> Or, better yet show me by going ahead and making the commit to that
> effect.
>
> 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] New way to generate wxwidgets debug output

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

On 2016-12-19 16:33-0500 Pedro Vicente wrote:

> Hi Alan
>
>
>> The only trouble with the above fix is not every Unix platform has
>> /dev/urandom (although from the above URL most do).
>> 
>> So I would like to change the above fix to check for /dev/urandom
>> and use it if it exists, but otherwise fall back to using /dev/random.
>> 
>> How do I do that in C++?
>
>
> This is not a C++ (or C) issue.
> This is ideal for cmake to check, the same way it detects for other possible 
> system functions/features availability.
> I never did this before, but I think the way it works it is on the cmake 
> script
> do a small C or C++ program embedded in the script that includes 
> "/dev/urandom" in some way, for example
>
> std::fstream fin( "/dev/urandom", std::ios::in );
>
> and then check if it compiles and pass the result to cmake
>
>> > /dev/urandom (although from the above URL most do).

Hi Pedro:

I agree that is a possible approach, but that would mean
I would need to implement a build-system CMake test, propagate the relevant CMake variable from that test
to the C++ level as a macro, and introduce a preprocessor directive into our own C++
code based on whether that macro is defined or not.  And I think my
original proposal is simpler than that.

I never stated clearly what my proposed approach
would be, but it is no coincidence that it is C like.  :-)

That is check if

std::fstream fin( "/dev/urandom", std::ios::in );

works (probably by just checking the return code of that call, but I
could not find the documentation of what the return code would be
on failure),

and if that return code indicates a failure, then call

std::fstream fin( "/dev/random", std::ios::in );

instead.  But I assume Phil will do (or has done by now) the
equivalent using C++ exception handling.

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] New way to generate wxwidgets debug output

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

Hi Alan


ok, I see now.

> That is check if
>
> std::fstream fin( "/dev/urandom", std::ios::in );


this is the constructor, there is no return value, which is one of the 
criticisms made to C++.

In this case probably you need to do a small I/O operation after that call
and check for the result.

Not sure which , because I never use the C++ I/O, I always use the C API, 
even in C++ programs.

the reference is here

http://www.cplusplus.com/reference/fstream/fstream/fstream/


-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: Monday, December 19, 2016 7:51 PM
Subject: RE: New way to generate wxwidgets debug output


> On 2016-12-19 16:33-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>>
>>> The only trouble with the above fix is not every Unix platform has
>>> /dev/urandom (although from the above URL most do).
>>>
>>> So I would like to change the above fix to check for /dev/urandom
>>> and use it if it exists, but otherwise fall back to using /dev/random.
>>>
>>> How do I do that in C++?
>>
>>
>> This is not a C++ (or C) issue.
>> This is ideal for cmake to check, the same way it detects for other 
>> possible system functions/features availability.
>> I never did this before, but I think the way it works it is on the cmake 
>> script
>> do a small C or C++ program embedded in the script that includes 
>> "/dev/urandom" in some way, for example
>>
>> std::fstream fin( "/dev/urandom", std::ios::in );
>>
>> and then check if it compiles and pass the result to cmake
>>
>>> > /dev/urandom (although from the above URL most do).
>
> Hi Pedro:
>
> I agree that is a possible approach, but that would mean
> I would need to implement a build-system CMake test, propagate the 
> relevant CMake variable from that test
> to the C++ level as a macro, and introduce a preprocessor directive into 
> our own C++
> code based on whether that macro is defined or not.  And I think my
> original proposal is simpler than that.
>
> I never stated clearly what my proposed approach
> would be, but it is no coincidence that it is C like.  :-)
>
> That is check if
>
> std::fstream fin( "/dev/urandom", std::ios::in );
>
> works (probably by just checking the return code of that call, but I
> could not find the documentation of what the return code would be
> on failure),
>
> and if that return code indicates a failure, then call
>
> std::fstream fin( "/dev/random", std::ios::in );
>
> instead.  But I assume Phil will do (or has done by now) the
> equivalent using C++ exception handling.
>
> 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] New way to generate wxwidgets debug output

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

you could use "open" to try to open the stream as described here

http://www.cplusplus.com/reference/fstream/fstream/open/

I'll do a small test to see

-Pedro


----- Original Message ----- 
From: "Pedro Vicente" <ped...@sp...>
To: "Alan W. Irwin" <ir...@be...>; "Phil Rosenberg" 
<p.d...@gm...>; "PLplot development list" 
<plp...@li...>
Sent: Monday, December 19, 2016 8:30 PM
Subject: Re: [Plplot-devel] New way to generate wxwidgets debug output


> Hi Alan
>
>
> ok, I see now.
>
>> That is check if
>>
>> std::fstream fin( "/dev/urandom", std::ios::in );
>
>
> this is the constructor, there is no return value, which is one of the
> criticisms made to C++.
>
> In this case probably you need to do a small I/O operation after that call
> and check for the result.
>
> Not sure which , because I never use the C++ I/O, I always use the C API,
> even in C++ programs.
>
> the reference is here
>
> http://www.cplusplus.com/reference/fstream/fstream/fstream/
>
>
> -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: Monday, December 19, 2016 7:51 PM
> Subject: RE: New way to generate wxwidgets debug output
>
>
>> On 2016-12-19 16:33-0500 Pedro Vicente wrote:
>>
>>> Hi Alan
>>>
>>>
>>>> The only trouble with the above fix is not every Unix platform has
>>>> /dev/urandom (although from the above URL most do).
>>>>
>>>> So I would like to change the above fix to check for /dev/urandom
>>>> and use it if it exists, but otherwise fall back to using /dev/random.
>>>>
>>>> How do I do that in C++?
>>>
>>>
>>> This is not a C++ (or C) issue.
>>> This is ideal for cmake to check, the same way it detects for other
>>> possible system functions/features availability.
>>> I never did this before, but I think the way it works it is on the cmake
>>> script
>>> do a small C or C++ program embedded in the script that includes
>>> "/dev/urandom" in some way, for example
>>>
>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>>
>>> and then check if it compiles and pass the result to cmake
>>>
>>>> > /dev/urandom (although from the above URL most do).
>>
>> Hi Pedro:
>>
>> I agree that is a possible approach, but that would mean
>> I would need to implement a build-system CMake test, propagate the
>> relevant CMake variable from that test
>> to the C++ level as a macro, and introduce a preprocessor directive into
>> our own C++
>> code based on whether that macro is defined or not.  And I think my
>> original proposal is simpler than that.
>>
>> I never stated clearly what my proposed approach
>> would be, but it is no coincidence that it is C like.  :-)
>>
>> That is check if
>>
>> std::fstream fin( "/dev/urandom", std::ios::in );
>>
>> works (probably by just checking the return code of that call, but I
>> could not find the documentation of what the return code would be
>> on failure),
>>
>> and if that return code indicates a failure, then call
>>
>> std::fstream fin( "/dev/random", std::ios::in );
>>
>> instead.  But I assume Phil will do (or has done by now) the
>> equivalent using C++ exception handling.
>>
>> 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] New way to generate wxwidgets debug output

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

you can use the function "getrandom" as explained here


http://stackoverflow.com/questions/2572366/how-to-use-dev-random-or-urandom-in-c

http://man7.org/linux/man-pages/man2/getrandom.2.html

-Pedro

----- Original Message ----- 
From: "Pedro Vicente" <ped...@sp...>
To: "Alan W. Irwin" <ir...@be...>; "Phil Rosenberg" 
<p.d...@gm...>; "PLplot development list" 
<plp...@li...>
Sent: Monday, December 19, 2016 8:40 PM
Subject: Re: [Plplot-devel] New way to generate wxwidgets debug output


> you could use "open" to try to open the stream as described here
>
> http://www.cplusplus.com/reference/fstream/fstream/open/
>
> I'll do a small test to see
>
> -Pedro
>
>
> ----- Original Message ----- 
> From: "Pedro Vicente" <ped...@sp...>
> To: "Alan W. Irwin" <ir...@be...>; "Phil Rosenberg"
> <p.d...@gm...>; "PLplot development list"
> <plp...@li...>
> Sent: Monday, December 19, 2016 8:30 PM
> Subject: Re: [Plplot-devel] New way to generate wxwidgets debug output
>
>
>> Hi Alan
>>
>>
>> ok, I see now.
>>
>>> That is check if
>>>
>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>
>>
>> this is the constructor, there is no return value, which is one of the
>> criticisms made to C++.
>>
>> In this case probably you need to do a small I/O operation after that 
>> call
>> and check for the result.
>>
>> Not sure which , because I never use the C++ I/O, I always use the C API,
>> even in C++ programs.
>>
>> the reference is here
>>
>> http://www.cplusplus.com/reference/fstream/fstream/fstream/
>>
>>
>> -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: Monday, December 19, 2016 7:51 PM
>> Subject: RE: New way to generate wxwidgets debug output
>>
>>
>>> On 2016-12-19 16:33-0500 Pedro Vicente wrote:
>>>
>>>> Hi Alan
>>>>
>>>>
>>>>> The only trouble with the above fix is not every Unix platform has
>>>>> /dev/urandom (although from the above URL most do).
>>>>>
>>>>> So I would like to change the above fix to check for /dev/urandom
>>>>> and use it if it exists, but otherwise fall back to using /dev/random.
>>>>>
>>>>> How do I do that in C++?
>>>>
>>>>
>>>> This is not a C++ (or C) issue.
>>>> This is ideal for cmake to check, the same way it detects for other
>>>> possible system functions/features availability.
>>>> I never did this before, but I think the way it works it is on the 
>>>> cmake
>>>> script
>>>> do a small C or C++ program embedded in the script that includes
>>>> "/dev/urandom" in some way, for example
>>>>
>>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>>>
>>>> and then check if it compiles and pass the result to cmake
>>>>
>>>>> > /dev/urandom (although from the above URL most do).
>>>
>>> Hi Pedro:
>>>
>>> I agree that is a possible approach, but that would mean
>>> I would need to implement a build-system CMake test, propagate the
>>> relevant CMake variable from that test
>>> to the C++ level as a macro, and introduce a preprocessor directive into
>>> our own C++
>>> code based on whether that macro is defined or not.  And I think my
>>> original proposal is simpler than that.
>>>
>>> I never stated clearly what my proposed approach
>>> would be, but it is no coincidence that it is C like.  :-)
>>>
>>> That is check if
>>>
>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>>
>>> works (probably by just checking the return code of that call, but I
>>> could not find the documentation of what the return code would be
>>> on failure),
>>>
>>> and if that return code indicates a failure, then call
>>>
>>> std::fstream fin( "/dev/random", std::ios::in );
>>>
>>> instead.  But I assume Phil will do (or has done by now) the
>>> equivalent using C++ exception handling.
>>>
>>> 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
>>
>
>
> ------------------------------------------------------------------------------
> 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] New way to generate wxwidgets debug output

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

I made  and pushed the change last night to use urandom over random, but Pedro is probably correct, the getrandom() function may be the best solution. I can make that change later today.

Sent from my Windows 10 phone

From: Pedro Vicente
Sent: 20 December 2016 02:04
To: Alan W. Irwin; Phil Rosenberg; PLplot development list
Subject: Re: [Plplot-devel] New way to generate wxwidgets debug output

you can use the function "getrandom" as explained here


http://stackoverflow.com/questions/2572366/how-to-use-dev-random-or-urandom-in-c

http://man7.org/linux/man-pages/man2/getrandom.2.html

-Pedro

----- Original Message ----- 
From: "Pedro Vicente" <ped...@sp...>
To: "Alan W. Irwin" <ir...@be...>; "Phil Rosenberg" 
<p.d...@gm...>; "PLplot development list" 
<plp...@li...>
Sent: Monday, December 19, 2016 8:40 PM
Subject: Re: [Plplot-devel] New way to generate wxwidgets debug output


> you could use "open" to try to open the stream as described here
>
> http://www.cplusplus.com/reference/fstream/fstream/open/
>
> I'll do a small test to see
>
> -Pedro
>
>
> ----- Original Message ----- 
> From: "Pedro Vicente" <ped...@sp...>
> To: "Alan W. Irwin" <ir...@be...>; "Phil Rosenberg"
> <p.d...@gm...>; "PLplot development list"
> <plp...@li...>
> Sent: Monday, December 19, 2016 8:30 PM
> Subject: Re: [Plplot-devel] New way to generate wxwidgets debug output
>
>
>> Hi Alan
>>
>>
>> ok, I see now.
>>
>>> That is check if
>>>
>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>
>>
>> this is the constructor, there is no return value, which is one of the
>> criticisms made to C++.
>>
>> In this case probably you need to do a small I/O operation after that 
>> call
>> and check for the result.
>>
>> Not sure which , because I never use the C++ I/O, I always use the C API,
>> even in C++ programs.
>>
>> the reference is here
>>
>> http://www.cplusplus.com/reference/fstream/fstream/fstream/
>>
>>
>> -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: Monday, December 19, 2016 7:51 PM
>> Subject: RE: New way to generate wxwidgets debug output
>>
>>
>>> On 2016-12-19 16:33-0500 Pedro Vicente wrote:
>>>
>>>> Hi Alan
>>>>
>>>>
>>>>> The only trouble with the above fix is not every Unix platform has
>>>>> /dev/urandom (although from the above URL most do).
>>>>>
>>>>> So I would like to change the above fix to check for /dev/urandom
>>>>> and use it if it exists, but otherwise fall back to using /dev/random.
>>>>>
>>>>> How do I do that in C++?
>>>>
>>>>
>>>> This is not a C++ (or C) issue.
>>>> This is ideal for cmake to check, the same way it detects for other
>>>> possible system functions/features availability.
>>>> I never did this before, but I think the way it works it is on the 
>>>> cmake
>>>> script
>>>> do a small C or C++ program embedded in the script that includes
>>>> "/dev/urandom" in some way, for example
>>>>
>>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>>>
>>>> and then check if it compiles and pass the result to cmake
>>>>
>>>>> > /dev/urandom (although from the above URL most do).
>>>
>>> Hi Pedro:
>>>
>>> I agree that is a possible approach, but that would mean
>>> I would need to implement a build-system CMake test, propagate the
>>> relevant CMake variable from that test
>>> to the C++ level as a macro, and introduce a preprocessor directive into
>>> our own C++
>>> code based on whether that macro is defined or not.  And I think my
>>> original proposal is simpler than that.
>>>
>>> I never stated clearly what my proposed approach
>>> would be, but it is no coincidence that it is C like.  :-)
>>>
>>> That is check if
>>>
>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>>
>>> works (probably by just checking the return code of that call, but I
>>> could not find the documentation of what the return code would be
>>> on failure),
>>>
>>> and if that return code indicates a failure, then call
>>>
>>> std::fstream fin( "/dev/random", std::ios::in );
>>>
>>> instead.  But I assume Phil will do (or has done by now) the
>>> equivalent using C++ exception handling.
>>>
>>> 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
>>
>
>
> ------------------------------------------------------------------------------
> 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] New way to generate wxwidgets debug output

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

On 2016-12-20 08:55-0000 p.d...@gm... wrote:

> I made and pushed the change last night to use urandom over random,
but Pedro is probably correct, the getrandom() function may be the
best solution. I can make that change later today.

I agree that getrandom has a nice interface compared to what it wraps
(i.e., it also internally uses /dev/urandom with /dev/random as a fallback).
However, I am not convinced this is the way we should go now.

The problem is getrandom is Linux specific and only available for
newer Linux systems.  For example, I just did a complete search of all
packages I could install for getrandom, and it is not available on
Debian Jessie!

In contrast /dev/urandom seems to be available on virtually all Linux
systems and more important many Unix systems, and /dev/random is a posix standard I
believe, i.e., it should be available on all Unix systems as a
fallback if /dev/urandom is not available.  So I think we should stick
with the status quo here, and maybe revisit this a year or so from now
when likely getrandom will be a lot more common on at least Linux, and
maybe at the point it will have spread to other unices as well.  But
POSIX changes are slow...

Also, it is getting relatively close to release (still likely on
December 27th), and we finally have gotten one foot on dry land with
the long pause problem and Pedro's segfault issue so I would prefer we
not make further changes and instead test what we do have now with
appropriate comprehensive tests on systems with access to the needed
unix tools (bash, etc.), i.e., MinGW-w64/MSYS2 and Cygwin on Windows
and Linux, Mac OS X, and traditional Unix systems,

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] New way to generate wxwidgets debug output

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

That's fine. I will leave things alone for now

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 20 December 2016 10:19
To: Phil Rosenberg; Pedro Vicente; PLplot development list
Subject: RE: [Plplot-devel] New way to generate wxwidgets debug output

On 2016-12-20 08:55-0000 p.d...@gm... wrote:

> I made and pushed the change last night to use urandom over random,
but Pedro is probably correct, the getrandom() function may be the
best solution. I can make that change later today.

I agree that getrandom has a nice interface compared to what it wraps
(i.e., it also internally uses /dev/urandom with /dev/random as a fallback).
However, I am not convinced this is the way we should go now.

The problem is getrandom is Linux specific and only available for
newer Linux systems.  For example, I just did a complete search of all
packages I could install for getrandom, and it is not available on
Debian Jessie!

In contrast /dev/urandom seems to be available on virtually all Linux
systems and more important many Unix systems, and /dev/random is a posix standard I
believe, i.e., it should be available on all Unix systems as a
fallback if /dev/urandom is not available.  So I think we should stick
with the status quo here, and maybe revisit this a year or so from now
when likely getrandom will be a lot more common on at least Linux, and
maybe at the point it will have spread to other unices as well.  But
POSIX changes are slow...

Also, it is getting relatively close to release (still likely on
December 27th), and we finally have gotten one foot on dry land with
the long pause problem and Pedro's segfault issue so I would prefer we
not make further changes and instead test what we do have now with
appropriate comprehensive tests on systems with access to the needed
unix tools (bash, etc.), i.e., MinGW-w64/MSYS2 and Cygwin on Windows
and Linux, Mac OS X, and traditional Unix systems,

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] New way to generate wxwidgets debug output

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

On 2016-12-19 12:33-0500 Pedro Vicente wrote:

> Hi Alan
>
> I just did a git pull of the master branch with these changes and I get 
> compiling errors
> if I don't add
>
> -DPLPLOT_WX_NANOSEC=ON

To Pedro and Phil:

@Pedro:

Thanks for your above report.  I confirmed the issue and fixed it as of commit 946b17f.

I noticed for the case with -DPLPLOT_WX_NANOSEC=ON which did
build for you, you were not able to confirm the pause.  Was that
as a result of running (exactly)

time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c"

and showing the output for the _second_ run of the x01c example?

@Pedro and Phil:

The reason I am still keenly interested in your results and Phil's for
such tests, is I am having trouble here confirming Phil's hypothesis
(lack of entropy) for the pause.  Lots of mousing around to build up
entropy before or during the pause seemed to make absolutely no
difference.  The pause is never the same from one run to the next but
it is usually in the 5 to 15 second range.  But when I moused around
for a couple of tries of the test, the results were always near the
top-end of that range!

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] New way to generate wxwidgets debug output

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

On 2016-12-19 12:25-0800 Alan W. Irwin wrote:

> On 2016-12-19 12:33-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I just did a git pull of the master branch with these changes and I get
>> compiling errors
>> if I don't add
>>
>> -DPLPLOT_WX_NANOSEC=ON
>
> To Pedro and Phil:
>
> @Pedro:
>
> Thanks for your above report.  I confirmed the issue and fixed it as of commit 946b17f.

Well, I fixed that issue, but comprehensive testing of the wxwidgets
device driver and binding showed there were other build-system bugs
recently introduced by me that needed further fixes.  Sigh.  Those
fixes are all done now (commit 1ccbdcd) and passed the comprehensive
test (confined to just the interactive case for the wxwidgets device
driver and binding in the interest of speed) for the following three
cases:

(1) -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON
(2) -DPLPLOT_WX_DEBUG_OUTPUT=ON
(3) neither of the above options

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] New way to generate wxwidgets debug output

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

Hi Alan

>Was that as a result of running (exactly)

no, my previous output was just
make VERBOSE=1 test_wxPLplotDemo


this is the second output of

time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time 
examples/c/x01c -dev wxwidgets -np;echo "done x01c"


PLplot library version: 5.11.1
15:48:59: Debug: nanosecs since epoch = 21790238265641600: 
plD_init_wxwidgets(): enter
15:48:59: Debug: nanosecs since epoch = 21790238410215451: 
wxPLDevice(): enter
15:48:59: Debug: nanosecs since epoch = 21790238410393014: 
wxPLDevice(): gc done
15:48:59: Debug: nanosecs since epoch = 21790238418937794: 
wxPLDevice(): m_interactiveTextGcdc done
15:48:59: Debug: nanosecs since epoch = 21790238418999419: 
SetupMemoryMap(): enter
15:49:00: Debug: nanosecs since epoch = 21790239004602872: 
SetupMemoryMap(): mapName start
15:49:00: Debug: nanosecs since epoch = 21790239004716998: 
SetupMemoryMap(): mapName done
15:49:00: Debug: nanosecs since epoch = 21790239004770393: 
SetupMemoryMap(): m_outputMemoryMap.create call
15:49:00: Debug: nanosecs since epoch = 21790239005095987: 
SetupMemoryMap(): m_outputMemoryMap.create done
15:49:00: Debug: nanosecs since epoch = 21790239213638522: 
wxPLplotwindow::wxPLplotwindow
15:49:00: Debug: nanosecs since epoch = 21790239218784927: 
wxPLplotwindow::Show
15:49:00: Debug: nanosecs since epoch = 21790239218891790: 
wxPLplotwindow::CreateStream
15:49:00: Debug: nanosecs since epoch = 21790239220942648: 
SetupMemoryMap(): leave
15:49:00: Debug: nanosecs since epoch = 21790239221080760: 
wxPLDevice(): leave
15:49:00: Debug: nanosecs since epoch = 21790239221125073: 
plD_init_wxwidgets(): leave
15:49:00: Debug: nanosecs since epoch = 21790239248789077: 
plD_init_wxwidgets(): enter
15:49:00: Debug: nanosecs since epoch = 21790239248922765: 
wxPLDevice(): enter
15:49:00: Debug: nanosecs since epoch = 21790239249008840: 
wxPLDevice(): gc done
15:49:00: Debug: nanosecs since epoch = 21790239249148977: 
wxPLDevice(): m_interactiveTextGcdc done
15:49:00: Debug: nanosecs since epoch = 21790239249213837: 
wxPLDevice(): SetDC done
15:49:00: Debug: nanosecs since epoch = 21790239249246653: 
wxPLDevice(): leave
15:49:00: Debug: nanosecs since epoch = 21790239249273784: 
plD_init_wxwidgets(): leave
15:49:00: Debug: nanosecs since epoch = 21790239268439414: 
wxPLplotwindow::OnCreate
15:49:00: Debug: nanosecs since epoch = 21790239268543408: 
wxPLplotwindow::CreateStream
15:49:00: Debug: nanosecs since epoch = 21790239268995179: 
wxPLplotwindow::OnCreate
15:49:00: Debug: nanosecs since epoch = 21790239269051483: 
wxPLplotwindow::CreateStream

real	0m1.037s
user	0m0.047s
sys	0m0.032s
done x01c



On 2016-12-19 15:25, Alan W. Irwin wrote:
> On 2016-12-19 12:33-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I just did a git pull of the master branch with these changes and I 
>> get compiling errors
>> if I don't add
>>
>> -DPLPLOT_WX_NANOSEC=ON
>
> To Pedro and Phil:
>
> @Pedro:
>
> Thanks for your above report.  I confirmed the issue and fixed it as
> of commit 946b17f.
>
> I noticed for the case with -DPLPLOT_WX_NANOSEC=ON which did
> build for you, you were not able to confirm the pause.  Was that
> as a result of running (exactly)
>
> time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time
> examples/c/x01c -dev wxwidgets -np;echo "done x01c"
>
> and showing the output for the _second_ run of the x01c example?
>
> @Pedro and Phil:
>
> The reason I am still keenly interested in your results and Phil's 
> for
> such tests, is I am having trouble here confirming Phil's hypothesis
> (lack of entropy) for the pause.  Lots of mousing around to build up
> entropy before or during the pause seemed to make absolutely no
> difference.  The pause is never the same from one run to the next but
> it is usually in the 5 to 15 second range.  But when I moused around
> for a couple of tries of the test, the results were always near the
> top-end of that range!
>
> 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] New way to generate wxwidgets debug output

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

On 2016-12-19 15:52-0500 Pedro Vicente wrote:

> Hi Alan
>
>> Was that as a result of running (exactly)
>
> no, my previous output was just
> make VERBOSE=1 test_wxPLplotDemo
>
>
> this is the second output of
>
> time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time 
> examples/c/x01c -dev wxwidgets -np;echo "done x01c"
>

If you look at where the gross time stamp changes by a second and the
nanosec one changes by 0.6 seconds, you have confirmed the pause
on your platform although it is a pretty small pause compared
to the 5- to 15-second pauses I get here.

But the issue is now locally solved for me (as you can see from my
last post) by replacing /dev/random with /dev/urandom.)

But I do need C++ help from you or Phil to finalize that fix.

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
__________________________