plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Infinite Yielding issue

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

Hi Pedro, Alan
Sorry. I guess I made a mistake in the new commit. It worked fine on my system but I never saw the same problem you did in the first place. I will check for obvious mistakes and if I can't see the cause then I'll revert the last commit. Although this will have to wait until the morning UK time.
Phil

Sent from my Windows 10 phone

From: Pedro Vicente
Sent: 20 December 2016 22:49
To: Alan W. Irwin; Phil Rosenberg; PLplot development list
Subject: Re: Infinite Yielding issue

@Alan, Phil


here are my results

for git master current

CentOS 6.8 wxWidgets 3.1
Linux 14.04 wxWidgets 3.0
Linux 16.04 wxWidgets 3.0
Debian 8.0 wxWidgets 3.0

all infinite loop

14:25:57: Debug: wxPLplotwindow::wxPLplotwindow
14:25:57: Debug: frame->Create
14:25:57: Debug: Plot() Yielding
14:25:57: Debug: Plot() Yielding

made with

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/plplot-install -DCMAKE_BUILD_TYPE=Debug 
 -DBUILD_SHARED_LIBS:BOOL=OFF  -DBUILD_TEST=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON

yesterday I sent this result for Ubuntu 14.04, but that was with yesterday's 
master.

Phil, today there was a new commit, so could that be it ?

23:26:43: Debug: wxPLplotwindow::wxPLplotwindow
23:26:44: Debug: frame->Create
23:26:44: Debug: Plot() Yielding
23:26:44: Debug: wxPLplotwindow::OnCreate
23:26:44: Debug: plD_init_wxwidgets(): enter
23:26:44: Debug: wxPLDevice(): enter
23:26:44: Debug: wxPLDevice(): gc done
23:26:44: Debug: wxPLDevice(): m_interactiveTextGcdc done
23:26:44: Debug: wxPLDevice(): SetDC done
23:26:44: Debug: wxPLDevice(): leave
23:26:44: Debug: plD_init_wxwidgets(): leave
23:26:44: Debug: Plot()






----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Phil Rosenberg" <p.d...@gm...>; "Pedro Vicente" 
<ped...@sp...>; "PLplot development list" 
<plp...@li...>
Sent: Tuesday, December 20, 2016 3:10 PM
Subject: Infinite Yielding issue


> On 2016-12-20 13:07-0500 Pedro Vicente wrote:
>
>> Hi Alan, Phil
> [...] I just tried on my CentOS with the latest git
>> code, and what happens
>> is that the execution is always on
>>
>> 12:50:24: Debug: Plot() Yielding
>
> To Pedro and Phil:
>
> @Pedro:
>
> It is good you have checked Phil's latest solution against some of the
> Linux platforms accessible to you, but while waiting for a response
> from him on this infinite Yielding issue you have found on your CentOS
> platform, you might want to check all your Linux platforms to see if
> the issue is confined just to CentOS or not to help give Phil some
> insight as to why his latest solution is not working universally on
> all Linux platforms. And of course when Phil comes up with a fix, it
> would help us a lot if you checked it against all Linux platforms
> accessible to you.
>
> @Phil:
>
> Part of my motivation for responding here is I noticed that Pedro had
> dropped you from the specific recipients list and used an old subject
> line that is no longer relevant.  So you might have missed his post.
> Therefore, I have put your e-mail address back in the recipients list
> and changed the subject line to something more relevant just to make
> sure this infinite Yielding issue gets your immediate attention.  It
> does sound to me like this is a release critical issue, i.e., if it is
> not fixed by our current estimate of the release date (December 27th),
> I should probably hold the release until you do figure out a solution.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

Re: [Plplot-devel] Infinite Yielding issue

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

@Alan, Phil


here are my results

for git master current

CentOS 6.8 wxWidgets 3.1
Linux 14.04 wxWidgets 3.0
Linux 16.04 wxWidgets 3.0
Debian 8.0 wxWidgets 3.0

all infinite loop

14:25:57: Debug: wxPLplotwindow::wxPLplotwindow
14:25:57: Debug: frame->Create
14:25:57: Debug: Plot() Yielding
14:25:57: Debug: Plot() Yielding

made with

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/plplot-install -DCMAKE_BUILD_TYPE=Debug 
 -DBUILD_SHARED_LIBS:BOOL=OFF  -DBUILD_TEST=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON

yesterday I sent this result for Ubuntu 14.04, but that was with yesterday's 
master.

Phil, today there was a new commit, so could that be it ?

23:26:43: Debug: wxPLplotwindow::wxPLplotwindow
23:26:44: Debug: frame->Create
23:26:44: Debug: Plot() Yielding
23:26:44: Debug: wxPLplotwindow::OnCreate
23:26:44: Debug: plD_init_wxwidgets(): enter
23:26:44: Debug: wxPLDevice(): enter
23:26:44: Debug: wxPLDevice(): gc done
23:26:44: Debug: wxPLDevice(): m_interactiveTextGcdc done
23:26:44: Debug: wxPLDevice(): SetDC done
23:26:44: Debug: wxPLDevice(): leave
23:26:44: Debug: plD_init_wxwidgets(): leave
23:26:44: Debug: Plot()






----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Phil Rosenberg" <p.d...@gm...>; "Pedro Vicente" 
<ped...@sp...>; "PLplot development list" 
<plp...@li...>
Sent: Tuesday, December 20, 2016 3:10 PM
Subject: Infinite Yielding issue


> On 2016-12-20 13:07-0500 Pedro Vicente wrote:
>
>> Hi Alan, Phil
> [...] I just tried on my CentOS with the latest git
>> code, and what happens
>> is that the execution is always on
>>
>> 12:50:24: Debug: Plot() Yielding
>
> To Pedro and Phil:
>
> @Pedro:
>
> It is good you have checked Phil's latest solution against some of the
> Linux platforms accessible to you, but while waiting for a response
> from him on this infinite Yielding issue you have found on your CentOS
> platform, you might want to check all your Linux platforms to see if
> the issue is confined just to CentOS or not to help give Phil some
> insight as to why his latest solution is not working universally on
> all Linux platforms. And of course when Phil comes up with a fix, it
> would help us a lot if you checked it against all Linux platforms
> accessible to you.
>
> @Phil:
>
> Part of my motivation for responding here is I noticed that Pedro had
> dropped you from the specific recipients list and used an old subject
> line that is no longer relevant.  So you might have missed his post.
> Therefore, I have put your e-mail address back in the recipients list
> and changed the subject line to something more relevant just to make
> sure this infinite Yielding issue gets your immediate attention.  It
> does sound to me like this is a release critical issue, i.e., if it is
> not fixed by our current estimate of the release date (December 27th),
> I should probably hold the release until you do figure out a solution.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

[Plplot-devel] Infinite Yielding issue

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

On 2016-12-20 13:07-0500 Pedro Vicente wrote:

> Hi Alan, Phil
[...] I just tried on my CentOS with the latest git 
> code, and what happens
> is that the execution is always on
>
> 12:50:24: Debug: Plot() Yielding

To Pedro and Phil:

@Pedro:

It is good you have checked Phil's latest solution against some of the
Linux platforms accessible to you, but while waiting for a response
from him on this infinite Yielding issue you have found on your CentOS
platform, you might want to check all your Linux platforms to see if
the issue is confined just to CentOS or not to help give Phil some
insight as to why his latest solution is not working universally on
all Linux platforms. And of course when Phil comes up with a fix, it
would help us a lot if you checked it against all Linux platforms
accessible to you.

@Phil:

Part of my motivation for responding here is I noticed that Pedro had
dropped you from the specific recipients list and used an old subject
line that is no longer relevant.  So you might have missed his post.
Therefore, I have put your e-mail address back in the recipients list
and changed the subject line to something more relevant just to make
sure this infinite Yielding issue gets your immediate attention.  It
does sound to me like this is a release critical issue, i.e., if it is
not fixed by our current estimate of the release date (December 27th),
I should probably hold the release until you do figure out a solution.

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] Subscribing to our git feed

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

Hi Alan, Phil

> Also, it was
> really good to hear that your tests show we finally have the
> definitive fix for this Linux issue

You're welcome, glad I could help.

I was going to send an email questioning the reasoning of both 
solutions assuming both were
working (Phil's  and mine), but I just tried on my CentOS with the 
latest git code, and what happens
is that the execution is always on

12:50:24: Debug: Plot() Yielding

About the solutions

1) Current solution


Right now, this has to be done in the client code

//We must wait for the Create event to be processed and the
	//wxPLplotstream to be prepared
	while (!frame->IsReady())
	{
		PLPLOT_wxLogDebug("Plot() Yielding");
		wxGetApp().Yield();
	}

So, the user has to do some extra step in order to wait for wxWidgets 
to
process some event.
Ideally he should not have to do this but rather all should be done 
inside wxWidgets.
This is error prone, because the usual way to use wxWidgets is

MyFrame *frame = new Frame()
frame->Show()


here we have

MyFrame *frame = new Frame()
frame->Create()
While ()
  {
   wait()
  }
frame->Show()
Plot(


so a user might not even be aware of this wait extra step.

that is assuming it's working, but on my CentOS it gets stuck on the 
Yield()


2) Solution of creating the fame in Show()

Client code is

MyFrame *frame = new Frame()
frame->Create()
frame->Show()
Plot()


there is no wait loop; there is also no need to create the stream in 
OnCreate()

-Pedro





On 2016-12-20 04:01, Alan W. Irwin wrote:
> On 2016-12-19 23:32-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I subscribed to the feed, got the latest master, and all is working 
>> now on wxWidgetsdemo.
>
> Hi Pedro:
>
> That is good that you are subscribed to the git feed.  Also, it was
> really good to hear that your tests show we finally have the
> definitive fix for this Linux issue thanks to your original report of
> the issue, your implementation of an initial solution, your 
> subsequent
> test efforts on various Linux platforms, and your discussions of the
> issue with Phil.  And my thanks to Phil for ultimately finding the
> definitive fix.  That was good collaborative development work on an
> open source project you can both be proud of.
>
> 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

[<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-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] Subscribing to our git feed

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

Just to concur with Alan to say thank you very much Pedro for your initial bug report and your help with debugging and suggested fixes. I couldn't have sorted it without your help.

And Alan the same to you. Thanks for all the help tracking down the delay issue.

I'm glad that between the three of us we got this sorted.

My intention today is to swap to the getrandom function as pedro suggested and to move the Create call and the waiting code to so they are adjacent which I think will make the example more obvious.

Thanks again
Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 20 December 2016 09:02
To: Pedro Vicente; PLplot development list
Subject: Re: [Plplot-devel] Subscribing to our git feed

On 2016-12-19 23:32-0500 Pedro Vicente wrote:

> Hi Alan
>
> I subscribed to the feed, got the latest master, and all is working now on 
> wxWidgetsdemo.

Hi Pedro:

That is good that you are subscribed to the git feed.  Also, it was
really good to hear that your tests show we finally have the
definitive fix for this Linux issue thanks to your original report of
the issue, your implementation of an initial solution, your subsequent
test efforts on various Linux platforms, and your discussions of the
issue with Phil.  And my thanks to Phil for ultimately finding the
definitive fix.  That was good collaborative development work on an
open source project you can both be proud of.

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] Subscribing to our git feed

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

On 2016-12-19 23:32-0500 Pedro Vicente wrote:

> Hi Alan
>
> I subscribed to the feed, got the latest master, and all is working now on 
> wxWidgetsdemo.

Hi Pedro:

That is good that you are subscribed to the git feed.  Also, it was
really good to hear that your tests show we finally have the
definitive fix for this Linux issue thanks to your original report of
the issue, your implementation of an initial solution, your subsequent
test efforts on various Linux platforms, and your discussions of the
issue with Phil.  And my thanks to Phil for ultimately finding the
definitive fix.  That was good collaborative development work on an
open source project you can both be proud of.

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

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] Subscribing to our git feed

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

Hi Alan

I subscribed to the feed, got the latest master, and all is working now on 
wxWidgetsdemo.
on my linux 14.04 it tries to go to Plot() one time, then OnCreate is 
called, then goes to Plot() again


23:26:43: Debug: wxPLplotwindow::wxPLplotwindow
23:26:44: Debug: frame->Create
23:26:44: Debug: Plot() Yielding
23:26:44: Debug: wxPLplotwindow::OnCreate
23:26:44: Debug: plD_init_wxwidgets(): enter
23:26:44: Debug: wxPLDevice(): enter
23:26:44: Debug: wxPLDevice(): gc done
23:26:44: Debug: wxPLDevice(): m_interactiveTextGcdc done
23:26:44: Debug: wxPLDevice(): SetDC done
23:26:44: Debug: wxPLDevice(): leave
23:26:44: Debug: plD_init_wxwidgets(): leave
23:26:44: Debug: Plot()



----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>; "PLplot development 
list" <plp...@li...>
Sent: Monday, December 19, 2016 10:29 PM
Subject: Subscribing to our git feed


> Hi Pedro:
>
> Phil found his own way of solving the two big Linux wxwidgets issues
> this evening with his latest series of commits.  But from your recent
> posts it appears you are not yet aware of those commits.
>
> To take care of that issue, I strongly recommend you subscribe to our git 
> feed.
>
> You do that as follows: visit
> <https://sourceforge.net/p/plplot/plplot/ci/master/tree/> and click on
> the "Feed" icon just to the right of the "Download History" and
> "Snapshot" icons.  That will take you to a page with our most recent
> git commits summarized and with some subscription choices at the top.
> Pick one of those choices, and if it acts like the git feed I am
> subscribed to (which I subscribed to years ago with a different method
> when we first moved to git), from then on you will get e-mail with the
> complete commit message every time a commit is pushed to our SF git
> server.  Which, of course, is highly useful when doing collaborative
> development or testing of PLplot.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

[Plplot-devel] Subscribing to our git feed

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

Hi Pedro:

Phil found his own way of solving the two big Linux wxwidgets issues
this evening with his latest series of commits.  But from your recent
posts it appears you are not yet aware of those commits.

To take care of that issue, I strongly recommend you subscribe to our git feed.

You do that as follows: visit
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/> and click on
the "Feed" icon just to the right of the "Download History" and
"Snapshot" icons.  That will take you to a page with our most recent
git commits summarized and with some subscription choices at the top.
Pick one of those choices, and if it acts like the git feed I am
subscribed to (which I subscribed to years ago with a different method
when we first moved to git), from then on you will get e-mail with the
complete commit message every time a commit is pushed to our SF git
server.  Which, of course, is highly useful when doing collaborative
development or testing of PLplot.

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

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

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

[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

[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


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

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

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

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

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] wxPLplotDemo.cpp -- linux build error - PATCH working

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

Hi Phil

It seems you got it working

I applied the patch, to 2 previous master commits that compile.
results are:


make VERBOSE=1 test_wxPLplotDemo
14:26:35: Debug: wxPLplotwindow::wxPLplotwindow
14:26:35: Debug: frame->Create
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: wxPLplotwindow::OnCreate
14:26:35: Debug: Plot()

So, we can just commit and push this patch

-Pedro


On 2016-12-19 13:59, Phil Rosenberg wrote:
> On 19 December 2016 at 17:47, Pedro Vicente
> <ped...@sp...> wrote:
>> Hi Phil
>>
>>> Pedro can you please check if this works on your systems?
>>
>>
>> ok, I'll try it when the patch is pushed to the master .
>>
>> Alan
>>
>> I assume you are going to push the patch?
>> I get some compiling errors on the current master, please see my 
>> last post
>
> It would be good for you to test the patch before it gets pushed to
> master so we don't contaminate master with useless changes that just
> get undone next commit. To do so create a new branch from master, 
> then
> apply the patch
> git checkout master
> git checkout -b myTestBranch
> git apply path/to/patch.patch
>
>
> If master is currently not working then try checking out a previous
> commit as follows
> git checkout master
> git log
> #select a working commit hash one or two back
> git checkout <hash of previous commit>
> git checkout -b myTestBranch
> git apply path/to/patch.patch
>
>>
>> a new idea:
>>
>> what about if we just override the Create() function of 
>> wxPLplotwindow ?
>
> Unfortunately we can't override the create function because we need 
> to
> call the base class create function. We can't call the base class
> create function inside our own create function because the parameters
> that need to be passed in will differ depending upon whether you use 
> a
> wxFrame, wxPanel or any other wxWindow as the template class that we
> inherit from. In fact this is why we are using the create event in 
> the
> first place, otherwise we would just sort everything in the
> constructor.
>
> I'm pretty confident that the patch I sent will fix things if the
> issue is just that the create event is delayed. If you are having
> trouble getting it to apply, then I'll commit it to master. But I
> guess we need to wait for Alan to fix the logging issues first.
>
> I'm about to leave work and head home. If he hasn't fixed them by the
> time I open my laptop this evening then I'll have a look at fixing 
> the
> issue myself.
>
> Phil

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

Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error

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

On 19 December 2016 at 17:47, Pedro Vicente
<ped...@sp...> wrote:
> Hi Phil
>
>> Pedro can you please check if this works on your systems?
>
>
> ok, I'll try it when the patch is pushed to the master .
>
> Alan
>
> I assume you are going to push the patch?
> I get some compiling errors on the current master, please see my last post

It would be good for you to test the patch before it gets pushed to
master so we don't contaminate master with useless changes that just
get undone next commit. To do so create a new branch from master, then
apply the patch
git checkout master
git checkout -b myTestBranch
git apply path/to/patch.patch


If master is currently not working then try checking out a previous
commit as follows
git checkout master
git log
#select a working commit hash one or two back
git checkout <hash of previous commit>
git checkout -b myTestBranch
git apply path/to/patch.patch

>
> a new idea:
>
> what about if we just override the Create() function of wxPLplotwindow ?

Unfortunately we can't override the create function because we need to
call the base class create function. We can't call the base class
create function inside our own create function because the parameters
that need to be passed in will differ depending upon whether you use a
wxFrame, wxPanel or any other wxWindow as the template class that we
inherit from. In fact this is why we are using the create event in the
first place, otherwise we would just sort everything in the
constructor.

I'm pretty confident that the patch I sent will fix things if the
issue is just that the create event is delayed. If you are having
trouble getting it to apply, then I'll commit it to master. But I
guess we need to wait for Alan to fix the logging issues first.

I'm about to leave work and head home. If he hasn't fixed them by the
time I open my laptop this evening then I'll have a look at fixing the
issue myself.

Phil