plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] I have now pinned down the long pause to a few lines of completely innocuous code.

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

Bingo!

I had totally forgotten about this. When creating the randomGenerator
class the constructor of Rand generates an initial seed using system
entropy.  This is the rand_s() function for windows or by reading from
/dev/random on Linux. If system entropy is low then the function must
wait  for enough entropy to be generated to get a new random number. I
have a feeling that the entropy is often generated from mouse movement
so if you are using the console mostly or especially if you are
running a script that does testing of the many examples then I presume
system entropy can be very low. Hence there is a long wait to grab
this seed.

I haven't tested this, but I suspect it is rather likely to be the
source of the slowdown.

Basically what we need here is some way to ensure that two instances
of plplot which may be run a short time apart get two different seeds
for creating the random name of the memory map. This is to stop name
clashes between multiple running instances.

Could we rely on all systems having a nanosecond resolution clock?
Would a microsecond resolution clock be sufficient to grab a time
which would be guaranteed to be different between two running
processes?

On 19 December 2016 at 12:44, Alan W. Irwin <ir...@be...> wrote:
> Hi Phil and Pedro:
>
> Please look at the commit message for af41765, and the corresponding
> part of the source code (lines 1537-1548 of
> drivers/wxwidgets_dev.cpp). I cannot spot anything between those two
> uses of the PLPLOT_wxLogDebug macro that would cause the 13-second
> pause that shows up on the timestamps (and also I could see that
> obvious pause myself when staring at those messages), so the
> conclusion I drew in the commit message was it had to be
> wxPLDevice::SetupMemoryMap() or wxLogDebug itself (that routine is
> called as a result of executing the PLPLOT_wxLogDebug macro) that was
> being suspended by something else going on with our wxwidgets code or
> the wxwidgets library that has nothing to do with the code in
> question.  Is that even possible?  Could this 13-second "suspension"
> be the result of some weird threading issue?
>
> After reading the above 12 lines of code, will both of you please take the
> few
> minutes to replicate this same test on some Linux box following the
> exact instructions in the above commit message?  I know one other
> wxwidgets user (Laurent?) has replicated the long pause on Linux, and
> I think Phil may have replicated it as well. But this time you will
> have detailed timestamped debug messages, and maybe given that
> evidence the light will dawn with one of you about what is really
> going on here. There sure isn't any such "dawn" here!
>
> Your totally confused fellow PLplot developer,
>
> 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

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

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

a new idea:

what about if we just override the Create() function of wxPLplotwindow 
?

eliminate the Show() override, and the trigger of the OnCreate 
function,
but just simply override the Create() function.

the client call would be

wxPLplotwindow<wxFrame> *frame = new wxPlDemoFrame();
frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
frame->Show();

and the stream would be created *inside*
frame->Create

not posted to a queue event


> PS - Pedro I just realised from your email address we are in the same
> line of work. I work at the Institute for Climate and Atmospheric
> Science at University of Leeds. Small world!

yes, good to know !

-Pedro


On 2016-12-19 09:03, Phil Rosenberg wrote:
> No worries :-)
>
> Attached is a patch which I hope should fix things. It is the 
> simplest
> possible fix as far as I can tell. It does have a while loop with no
> counter, but unless there is some rather fatal bug in wxWidgets it
> should never turn into an infinite loop. Alan if you prefer I will 
> add
> a counter to ensure things can't go crazy. I have also added some
> extra checks to wxPLplotwindow just in case the create event ends up
> arriving after the first paint event or something - I don't know if
> this can happen but the docs aren't clear so it does no harm to
> include the checks.
>
> I always have to check how to create patches with git. I followed the
> instructions at
> 
> https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/.
> The appropriate apply commands are listed there too.
>
> Pedro can you please check if this works on your systems?
>
> Phil
>
> PS - Pedro I just realised from your email address we are in the same
> line of work. I work at the Institute for Climate and Atmospheric
> Science at University of Leeds. Small world!
>
> On 19 December 2016 at 12:51, Alan W. Irwin
> <ir...@be...> wrote:
>> On 2016-12-19 11:31-0000 Phil Rosenberg wrote:
>>
>>> I'm  just generating a test fix. I will send a patch round once 
>>> it's
>>> done. If it works then I'll tidy it up. However you appear to have
>>> bumped up the minimum CMake version so I need to reinstall CMake -
>>> turns out the latest Windows version requires a manual uninstall
>>> first. I'm sure you're not deliberately making my life hard Alan 
>>> ;-)
>>> :-D :-D
>>
>>
>> Sorry about that.  I far prefer to make your life easy.  :-)
>>
>>
>> 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

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

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

No worries :-)

Attached is a patch which I hope should fix things. It is the simplest
possible fix as far as I can tell. It does have a while loop with no
counter, but unless there is some rather fatal bug in wxWidgets it
should never turn into an infinite loop. Alan if you prefer I will add
a counter to ensure things can't go crazy. I have also added some
extra checks to wxPLplotwindow just in case the create event ends up
arriving after the first paint event or something - I don't know if
this can happen but the docs aren't clear so it does no harm to
include the checks.

I always have to check how to create patches with git. I followed the
instructions at
https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/.
The appropriate apply commands are listed there too.

Pedro can you please check if this works on your systems?

Phil

PS - Pedro I just realised from your email address we are in the same
line of work. I work at the Institute for Climate and Atmospheric
Science at University of Leeds. Small world!

On 19 December 2016 at 12:51, Alan W. Irwin <ir...@be...> wrote:
> On 2016-12-19 11:31-0000 Phil Rosenberg wrote:
>
>> I'm  just generating a test fix. I will send a patch round once it's
>> done. If it works then I'll tidy it up. However you appear to have
>> bumped up the minimum CMake version so I need to reinstall CMake -
>> turns out the latest Windows version requires a manual uninstall
>> first. I'm sure you're not deliberately making my life hard Alan ;-)
>> :-D :-D
>
>
> Sorry about that.  I far prefer to make your life easy.  :-)
>
>
> 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

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

On 2016-12-19 11:31-0000 Phil Rosenberg wrote:

> I'm  just generating a test fix. I will send a patch round once it's
> done. If it works then I'll tidy it up. However you appear to have
> bumped up the minimum CMake version so I need to reinstall CMake -
> turns out the latest Windows version requires a manual uninstall
> first. I'm sure you're not deliberately making my life hard Alan ;-)
> :-D :-D

Sorry about that.  I far prefer to make your life easy.  :-)

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] I have now pinned down the long pause to a few lines of completely innocuous code.

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

Hi Phil and Pedro:

Please look at the commit message for af41765, and the corresponding
part of the source code (lines 1537-1548 of
drivers/wxwidgets_dev.cpp). I cannot spot anything between those two
uses of the PLPLOT_wxLogDebug macro that would cause the 13-second
pause that shows up on the timestamps (and also I could see that
obvious pause myself when staring at those messages), so the
conclusion I drew in the commit message was it had to be
wxPLDevice::SetupMemoryMap() or wxLogDebug itself (that routine is
called as a result of executing the PLPLOT_wxLogDebug macro) that was
being suspended by something else going on with our wxwidgets code or
the wxwidgets library that has nothing to do with the code in
question.  Is that even possible?  Could this 13-second "suspension"
be the result of some weird threading issue?

After reading the above 12 lines of code, will both of you please take the few
minutes to replicate this same test on some Linux box following the
exact instructions in the above commit message?  I know one other
wxwidgets user (Laurent?) has replicated the long pause on Linux, and
I think Phil may have replicated it as well. But this time you will
have detailed timestamped debug messages, and maybe given that
evidence the light will dawn with one of you about what is really
going on here. There sure isn't any such "dawn" here!

Your totally confused fellow PLplot developer,

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

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

I'm  just generating a test fix. I will send a patch round once it's
done. If it works then I'll tidy it up. However you appear to have
bumped up the minimum CMake version so I need to reinstall CMake -
turns out the latest Windows version requires a manual uninstall
first. I'm sure you're not deliberately making my life hard Alan ;-)
:-D :-D

Phil

On 19 December 2016 at 09:31, Alan W. Irwin <ir...@be...> wrote:
> On 2016-12-19 00:30-0800 Alan W. Irwin wrote:
>
>> Anyhow, good luck with implementing this readiness check anyway you
>> like, and I look forward to your commit to that effect which can go
>> right on top of master tip (which should simplify your life). Then we can
>> ask
>> Pedro to drop his (now hopefully redundant) fix to test your solution
>> really works for all the platforms he has access to.
>
>
> Or better yet to take the load off of you some more (say if you don't
> have a Linux machine readily available to test your change) you could
> send me your tentative patch for your readiness check, and I could try
> it here.
>
>
> 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] Comprehensive testing

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

On 2016-12-19 09:39-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> The 5 new reports there are based on the Fortran subset of 4 recent
>> comprehensive test reports (Cygwin and MinGW-w64/MSYS2 from you, and
>> Debian Jessie with CMake-3.0.2 and CMake-3.7.0 from me) as well as a special
>> Ubuntu NAGFOR comprehensive test you did in July which showed no warning or
>> error messages at all from that high-quality, standards-checking, Fortran compiler.
>> From the e-mail you wrote back then, I have identified that platform as Ubuntu (I
>> believe it was on some virtual box you had available to you at work) with NAGFOR
>> compiler.  Can you retrieve any more details at this late date about which version
>> (i.e., codename) of Ubuntu, and which numerical version of NAGFOR?  If so,
>> please update that table item in the wiki or send me that data so I can do that
>> myself.
>>
> I have checked the Ubuntu version - not a codename but only: Ubuntu 16.04 LTS

> NAG Fortran was version 6.1

Hi Arjen:

Thanks very much for those two pieces of information.

>From <https://en.wikipedia.org/wiki/Ubuntu_version_history> 16.04 LTS
corresponds to codename "Xenial Xerus".  I will use both designations
in the report.

Wikipedia knows all.  :-)

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

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> The 5 new reports there are based on the Fortran subset of 4 recent
> comprehensive test reports (Cygwin and MinGW-w64/MSYS2 from you, and
> Debian Jessie with CMake-3.0.2 and CMake-3.7.0 from me) as well as a special
> Ubuntu NAGFOR comprehensive test you did in July which showed no warning or
> error messages at all from that high-quality, standards-checking, Fortran compiler.
> From the e-mail you wrote back then, I have identified that platform as Ubuntu (I
> believe it was on some virtual box you had available to you at work) with NAGFOR
> compiler.  Can you retrieve any more details at this late date about which version
> (i.e., codename) of Ubuntu, and which numerical version of NAGFOR?  If so,
> please update that table item in the wiki or send me that data so I can do that
> myself.
>
I have checked the Ubuntu version - not a codename but only: Ubuntu 16.04 LTS

NAG Fortran was version 6.1

Regards,

Arjen

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

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

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

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

> Anyhow, good luck with implementing this readiness check anyway you
> like, and I look forward to your commit to that effect which can go
> right on top of master tip (which should simplify your life). Then we can ask
> Pedro to drop his (now hopefully redundant) fix to test your solution
> really works for all the platforms he has access to.

Or better yet to take the load off of you some more (say if you don't
have a Linux machine readily available to test your change) you could
send me your tentative patch for your readiness check, and I could try
it here.

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

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

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

> Hi Alan, Pedro
> Yes Alan, that is what I intended. Sorry, that doesn't compile. I was on my way to bed when I sent the email and was doing it from memory.
>
> I will try to find a moment today to fix this.
>
> I'm not sure what your one line fix is. Feel free to elaborate. wxYield() basically exits the flow, allows events to be processed then returns. In theory the while shouldn't be needed I think.
>

> Another option would be to catch idle events and check if we are ready then call Plot().

Is that check for readiness the same as waiting for a particular
wxwidgets event that we launched to complete? If so, then I think we
are on exactly the same page, but it doesn't matter if your idea
differs from mine, because you are the expert here so please just implement
whatever readiness check feels right to you.

Note I was probably over-influenced by the (way too) rich wxwidgets
documentation and web advice on waiting for wxwidgets events, if you
prefer other methods of checking for readiness.

Also, I don't care if that check for readiness occurs outside the call
to Plot() or as the first executable line of it (before pls is
assigned a value).  But just for the record, my idea was to do the
latter.

Anyhow, good luck with implementing this readiness check anyway you
like, and I look forward to your commit to that effect which can go
right on top of master tip (which should simplify your life). Then we can ask
Pedro to drop his (now hopefully redundant) fix to test your solution
really works for all the platforms he has access to.

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

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

Hi Alan, Pedro
Yes Alan, that is what I intended. Sorry, that doesn't compile. I was on my way to bed when I sent the email and was doing it from memory.

I will try to find a moment today to fix this.

I'm not sure what your one line fix is. Feel free to elaborate. wxYield() basically exits the flow, allows events to be processed then returns. In theory the while shouldn't be needed I think.

Another option would be to catch idle events and check if we are ready then call Plot().

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 19 December 2016 07:35
To: Phil Rosenberg; Pedro Vicente; PLplot development list
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error

On 2016-12-18 23:27-0000 Phil Rosenberg wrote:

> The error is in the wxplplotdemo code, not in the wxplplotwindow. In
> the demo we must simply wait for the OnCreate message to arrive and be
> processed before we grab the stream in Plot(). We may be able to do
> that with
> while(!m_created)
>   wxYield();

To Phil and Pedro:

I tried the following patch (to master tip, note the use of the
latest PLPLOT_wxLogDebug macro in the context for the diff)

diff --git a/examples/c++/wxPLplotDemo.cpp b/examples/c++/wxPLplotDemo.cpp
index afbf260..17b1259 100644
--- a/examples/c++/wxPLplotDemo.cpp
+++ b/examples/c++/wxPLplotDemo.cpp
@@ -155,7 +155,11 @@ bool MyApp::OnInit()
  template< class WXWINDOW >
  void Plot( wxPLplotwindow<WXWINDOW> *plotwindow )
  {
-    wxPLplotstream* pls = plotwindow->GetStream();
+    wxPLplotstream* pls;
+    while(!m_created)
+      wxYield();
+
+    pls = plotwindow->GetStream();
      if (pls == NULL)
      {
       PLPLOT_wxLogDebug("pls NULL");

@Phil:

I am pretty sure this is what you meant by your suggestion, but it won't build because
m_created is not in scope.


/home/software/plplot/HEAD/plplot.git/examples/c++/wxPLplotDemo.cpp:159:12: error: ‘m_created’ was not declared in this scope
      while(!m_created)
             ^
examples/c++/CMakeFiles/wxPLplotDemo.dir/build.make:62: recipe for target 'examples/c++/CMakeFiles/wxPLplotDemo.dir/wxPLplotDemo.cpp.o' failed
make[3]: *** [examples/c++/CMakeFiles/wxPLplotDemo.dir/wxPLplotDemo.cpp.o] Error 1
CMakeFiles/Makefile2:13143: recipe for target 'examples/c++/CMakeFiles/wxPLplotDemo.dir/all' failed
make[2]: *** [examples/c++/CMakeFiles/wxPLplotDemo.dir/all] Error 2
CMakeFiles/Makefile2:5326: recipe for target 'examples/CMakeFiles/test_wxPLplotDemo.dir/rule' failed
make[1]: *** [examples/CMakeFiles/test_wxPLplotDemo.dir/rule] Error 2
Makefile:1807: recipe for target 'test_wxPLplotDemo' failed
make: *** [test_wxPLplotDemo] Error 2

Can you suggest a way to address this build issue so I can give this
solution a try?  Or did you mean something else?

That said, wxYield was already deprecated in wxwidgets 2.8, and even
more strongly deprecated for wxwidgets 3.1.  Also, from reading
the wxYield documentation, I am not sure it will be the answer to
our problem.  And I am not particularly happy with a loop (which
alays has the potential to burn a lot of cpu or even spin indefinitely).

Isn't the real issue, that the code should wait in the above spot for
a particular event that our other code has launched to fire?  If you
agree with that characterization of the problem, shouldn't the above
two-line loop be replaced with a one-line solution which is to make
the proper wxwidgets call to wait for the correct event to fire?

I realize you are extremely pressed for time so if you think waiting
for the event is not the way to go say so here, and forget the rest
of this.  But if you think the above approach is ultimately the
correct one, please let us know in which case the rest of this
is mostly for Pedro.

@Pedro:

Assuming Phil recommends this approach, would you be willing to
implement it?

A google search for the terms <wxwidgets wait event> shows lots of
hits, in particular
<https://forums.wxwidgets.org/viewtopic.php?t=22893>.  That reference
is dated but quite encouraging about this general idea.  However, I
soon get lost in C++ and wxwidgets details so I need an expert in
those areas to move further with this idea. However, if I am reading
the above reference properly all you have to do is make the correct
wxwidgets wait call to replace the two lines above, and you need to
set up our code that launches the event so that event can be uniquely
identified for the wait call.  So it looks really easy to do "when you
know how", i.e., if you are already pretty experienced with C++ and
wxwidgets.

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

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Saturday, December 17, 2016 4:00 AM
> To: Arjen Markus; PLplot development list
> Subject: RE: [Plplot-devel] Comprehensive testing
>
> Thanks for this additional test on MinGW-w64/MSYS2 with your new installation of
> that platform.
>
> I have summarized this good test result (and also your prior good test for Cygwin)
> at <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
>
> For your new installation of MinGW-w64/MSYS2 there is still a lot of package
> installation incompleteness, see footnotes j1, C1, D1, D2, F1, G2, H2, I1, and J1.
> But it is a good start that is suitable for this release, and I will remark more to you
> off list concerning how to rectify that package incompleteness issue for the next
> time (presumably post-release) when you repeat this comprehensive test.
> (And for this test, if I got any of those footnotes wrong, please let me know, and I
> will change them.)
>
I will have to look at this carefully ;). As well as your summarty of the MinGW-w64/MSYS2 package management in general. What I wrote was the result of empirical research. Your digging into the documentation should be quite valuable - the MinGW-w64/MSYS2 environment is useful, but confusing.

> I believe you mentioned previously that you planned to test the combination of
> MSVC + ifort for this release?  If you have done that I would appreciate you letting
> me know the results for our release notes (concerning the part of those release
> notes detailing what new Fortran binding tests were done.  Also, please let me
> know the version of MSVC and ifort you used so I can record that in the release
> notes.

I have not gotten around to that yet - ought to be simple enough, but currently I compare the files manually (there is a compare command under Windows, but it is downright useless - you cannot skip lines, nor will it compare lines, but only bytes). I have been thinking of a small script to the job, but I have not written it yet.

>
> By the way, you might find as a result of those tests that you have to upgrade
> bindings/f95/plplotf95_ifort.def since that was last updated in February 2016 (!) and
> there have been some Fortran changes since.
>
Hm, they have not popped up since then ...

> Also, I have a feeling you have a Windows batch file you run to automate your run-
> time testing of MSVC + ifort. Would you be willing to distribute that file with PLplot
> [in the scripts subdirectory?] for the benefit of other testers of the MSVC + ifort
> combination?
>
Yes, I can do that - it is very simple and straightforward, but it might be useful :).

Regards,

Arjen



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

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

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

On 2016-12-18 23:27-0000 Phil Rosenberg wrote:

> The error is in the wxplplotdemo code, not in the wxplplotwindow. In
> the demo we must simply wait for the OnCreate message to arrive and be
> processed before we grab the stream in Plot(). We may be able to do
> that with
> while(!m_created)
>   wxYield();

To Phil and Pedro:

I tried the following patch (to master tip, note the use of the
latest PLPLOT_wxLogDebug macro in the context for the diff)

diff --git a/examples/c++/wxPLplotDemo.cpp b/examples/c++/wxPLplotDemo.cpp
index afbf260..17b1259 100644
--- a/examples/c++/wxPLplotDemo.cpp
+++ b/examples/c++/wxPLplotDemo.cpp
@@ -155,7 +155,11 @@ bool MyApp::OnInit()
  template< class WXWINDOW >
  void Plot( wxPLplotwindow<WXWINDOW> *plotwindow )
  {
-    wxPLplotstream* pls = plotwindow->GetStream();
+    wxPLplotstream* pls;
+    while(!m_created)
+      wxYield();
+
+    pls = plotwindow->GetStream();
      if (pls == NULL)
      {
       PLPLOT_wxLogDebug("pls NULL");

@Phil:

I am pretty sure this is what you meant by your suggestion, but it won't build because
m_created is not in scope.


/home/software/plplot/HEAD/plplot.git/examples/c++/wxPLplotDemo.cpp:159:12: error: ‘m_created’ was not declared in this scope
      while(!m_created)
             ^
examples/c++/CMakeFiles/wxPLplotDemo.dir/build.make:62: recipe for target 'examples/c++/CMakeFiles/wxPLplotDemo.dir/wxPLplotDemo.cpp.o' failed
make[3]: *** [examples/c++/CMakeFiles/wxPLplotDemo.dir/wxPLplotDemo.cpp.o] Error 1
CMakeFiles/Makefile2:13143: recipe for target 'examples/c++/CMakeFiles/wxPLplotDemo.dir/all' failed
make[2]: *** [examples/c++/CMakeFiles/wxPLplotDemo.dir/all] Error 2
CMakeFiles/Makefile2:5326: recipe for target 'examples/CMakeFiles/test_wxPLplotDemo.dir/rule' failed
make[1]: *** [examples/CMakeFiles/test_wxPLplotDemo.dir/rule] Error 2
Makefile:1807: recipe for target 'test_wxPLplotDemo' failed
make: *** [test_wxPLplotDemo] Error 2

Can you suggest a way to address this build issue so I can give this
solution a try?  Or did you mean something else?

That said, wxYield was already deprecated in wxwidgets 2.8, and even
more strongly deprecated for wxwidgets 3.1.  Also, from reading
the wxYield documentation, I am not sure it will be the answer to
our problem.  And I am not particularly happy with a loop (which
alays has the potential to burn a lot of cpu or even spin indefinitely).

Isn't the real issue, that the code should wait in the above spot for
a particular event that our other code has launched to fire?  If you
agree with that characterization of the problem, shouldn't the above
two-line loop be replaced with a one-line solution which is to make
the proper wxwidgets call to wait for the correct event to fire?

I realize you are extremely pressed for time so if you think waiting
for the event is not the way to go say so here, and forget the rest
of this.  But if you think the above approach is ultimately the
correct one, please let us know in which case the rest of this
is mostly for Pedro.

@Pedro:

Assuming Phil recommends this approach, would you be willing to
implement it?

A google search for the terms <wxwidgets wait event> shows lots of
hits, in particular
<https://forums.wxwidgets.org/viewtopic.php?t=22893>.  That reference
is dated but quite encouraging about this general idea.  However, I
soon get lost in C++ and wxwidgets details so I need an expert in
those areas to move further with this idea. However, if I am reading
the above reference properly all you have to do is make the correct
wxwidgets wait call to replace the two lines above, and you need to
set up our code that launches the event so that event can be uniquely
identified for the wait call.  So it looks really easy to do "when you
know how", i.e., if you are already pretty experienced with C++ and
wxwidgets.

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

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

Hi Phil

>This is because there is no
> requirement to call Show() immediately after window creation.

that's true.
but if a user wants to see the plot, he *has* to create Show() at some time, 
because Show()
displays the window on screen.

when he does, then that is the time to create the stream.
if it does not call  Show() , then there is no window and no stream 
(assuming we remove the OnCreate() creation)


> while(!m_created)
>   wxYield();

where is the place to put this code?
in the demo client or in wxplplotwindow?

-Pedro

----- Original Message ----- 
From: "Phil Rosenberg" <p.d...@gm...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "Alan W. Irwin" <ir...@be...>; "PLplot development list" 
<plp...@li...>
Sent: Sunday, December 18, 2016 6:27 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


> Hi Pedro
> Ah, I had assumed that the OnCreate event was not being triggered at
> all. I now understand what is happening. Or at least I think I do ;-)
> Actually now you have pointed out the issue I am surprised the code
> works on any platform.
>
> The error is in the wxplplotdemo code, not in the wxplplotwindow. In
> the demo we must simply wait for the OnCreate message to arrive and be
> processed before we grab the stream in Plot(). We may be able to do
> that with
> while(!m_created)
>   wxYield();
>
> Could you try the above instead of your overloaded Show() fix please?
> You can check out an older version of Plplot by using
> git checkout 3cccca6a49a572e7aa518a5b8a6bbecd9ef1f812
> which will have your debug code in, but not your Show() fix.
>
> Unfortunately, although your fix does work for the example as it is
> written, it will not work in general. This is because there is no
> requirement to call Show() immediately after window creation.
>
> I am sorry that I have not been able to go through this in huge detail
> with you as fast as I would have liked. I have rather a lot on at work
> and I'm sure you understand I have to give that priority.
>
> Phil
>
>
> On 16 December 2016 at 18:01, Pedro Vicente
> <ped...@sp...> wrote:
>> Hi Phil, Alan
>>
>> I tried evtCreateExample.cpp and I get the good expected result.
>> This just means that for this simple example the OnCreate event is
>> triggered.
>>
>> To note that on my bad results of the PLplot demo, the OnCreate event is
>> *also* triggered.
>> the problem is that is triggered after the plot was made
>>
>>
>> 11:09:13: Debug: wxPLplotwindow::wxPLplotwindow
>> 11:09:13: Debug: frame->Create
>> 11:09:13: Debug: pls NULL
>> 11:09:13: Debug: wxPLplotwindow::OnCreate
>>
>> I am not that familiar with the wxWidgets internals but it seems events 
>> are
>> put in a queue.
>>
>> http://docs.wxwidgets.org/3.1/overview_events.html
>>
>> it could be that the event is not processed in the expected order or 
>> delayed
>> for some reason.
>> this could be a good question for the wxWidgets support list.
>>
>> -Pedro
>>
>>
>>
>> On 2016-12-15 21:11, Alan W. Irwin wrote:
>>>
>>> On 2016-12-16 01:05-0000 Phil Rosenberg wrote:
>>>
>>>> Hmm - well another theory down in smoke.
>>>>
>>>> Attached is an absolute minimum example of the use of wxEVT_CREATE. On
>>>> Windows I get the expected behaviour of a popup dialog appearing
>>>> before the frame saying "OnCreate called."
>>>>
>>>> Could you try it on one of your Linux machines? I'm afraid it's way
>>>> past my bedtime here in the UK, so I'll have to continue tomorrow.
>>>
>>>
>>> @Pedro: You should do this test as well since your Linux platforms
>>> are the ones where
>>> (so far at least) issues are showing up.  But for what it is worth, I
>>> did the following
>>>
>>> irwin@raven> g++ $(wx-config --cppflags --libs) evtCreateExample.cpp
>>>
>>> to successfully (no errors/warnings) build Phil's test application.
>>>
>>> Then I ran it with
>>>
>>> irwin@raven> ./a.out
>>>
>>> and a popup window came up (apparently as a subGUI of a grey GUI blank
>>> called "My Frame") with the "OnCreate Called" message displayed (which
>>> I understand was the expected result when everything is working
>>> properly).
>>>
>>> I hope that experiment helps you guys to gain some insight in what the
>>> heck is going on for wxwidgets-gtk+ on Linux.
>>>
>>> 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] wxPLplotDemo.cpp -- linux build error

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

Hi Pedro
Ah, I had assumed that the OnCreate event was not being triggered at
all. I now understand what is happening. Or at least I think I do ;-)
Actually now you have pointed out the issue I am surprised the code
works on any platform.

The error is in the wxplplotdemo code, not in the wxplplotwindow. In
the demo we must simply wait for the OnCreate message to arrive and be
processed before we grab the stream in Plot(). We may be able to do
that with
while(!m_created)
   wxYield();

Could you try the above instead of your overloaded Show() fix please?
You can check out an older version of Plplot by using
git checkout 3cccca6a49a572e7aa518a5b8a6bbecd9ef1f812
which will have your debug code in, but not your Show() fix.

Unfortunately, although your fix does work for the example as it is
written, it will not work in general. This is because there is no
requirement to call Show() immediately after window creation.

I am sorry that I have not been able to go through this in huge detail
with you as fast as I would have liked. I have rather a lot on at work
and I'm sure you understand I have to give that priority.

Phil


On 16 December 2016 at 18:01, Pedro Vicente
<ped...@sp...> wrote:
> Hi Phil, Alan
>
> I tried evtCreateExample.cpp and I get the good expected result.
> This just means that for this simple example the OnCreate event is
> triggered.
>
> To note that on my bad results of the PLplot demo, the OnCreate event is
> *also* triggered.
> the problem is that is triggered after the plot was made
>
>
> 11:09:13: Debug: wxPLplotwindow::wxPLplotwindow
> 11:09:13: Debug: frame->Create
> 11:09:13: Debug: pls NULL
> 11:09:13: Debug: wxPLplotwindow::OnCreate
>
> I am not that familiar with the wxWidgets internals but it seems events are
> put in a queue.
>
> http://docs.wxwidgets.org/3.1/overview_events.html
>
> it could be that the event is not processed in the expected order or delayed
> for some reason.
> this could be a good question for the wxWidgets support list.
>
> -Pedro
>
>
>
> On 2016-12-15 21:11, Alan W. Irwin wrote:
>>
>> On 2016-12-16 01:05-0000 Phil Rosenberg wrote:
>>
>>> Hmm - well another theory down in smoke.
>>>
>>> Attached is an absolute minimum example of the use of wxEVT_CREATE. On
>>> Windows I get the expected behaviour of a popup dialog appearing
>>> before the frame saying "OnCreate called."
>>>
>>> Could you try it on one of your Linux machines? I'm afraid it's way
>>> past my bedtime here in the UK, so I'll have to continue tomorrow.
>>
>>
>> @Pedro: You should do this test as well since your Linux platforms
>> are the ones where
>> (so far at least) issues are showing up.  But for what it is worth, I
>> did the following
>>
>> irwin@raven> g++ $(wx-config --cppflags --libs) evtCreateExample.cpp
>>
>> to successfully (no errors/warnings) build Phil's test application.
>>
>> Then I ran it with
>>
>> irwin@raven> ./a.out
>>
>> and a popup window came up (apparently as a subGUI of a grey GUI blank
>> called "My Frame") with the "OnCreate Called" message displayed (which
>> I understand was the expected result when everything is working
>> properly).
>>
>> I hope that experiment helps you guys to gain some insight in what the
>> heck is going on for wxwidgets-gtk+ on Linux.
>>
>> 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] The pls NULL fix for some Linux platforms

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

On 2016-12-18 15:01-0500 Pedro Vicente wrote:

> to summarize, there are 3 options
>
> 1) Make the stream creation call happen *only* in
> frame->Show();
> delete the function
> wxPLplotwindow::OnCreate
>
> this makes the stream creation to always happen in Show(); only
>
> 2) Leave the code like it is
> like it is the stream creation is always created in Show(); actually,
> as you can see from both (yours, mine)  print sequences
>
> so the
> wxPLplotwindow::OnCreate
> does not actually have any effect now, but it's there for debugging reasons

Got it.  Thanks for the explanation that clarified that and put my
concerns to rest.

[...]
> 3) Leave the code like it is but add further debugging features like
> the millisecond resolution

I am not qualified to make a choice.  Therefore, it your choice, i.e.,
go ahead and implement (1) if you think it is better than (2) or stick
with the status quo (2).

Time is one of my big interests (see the timeephem project below) so
with regard to (3) I have changed my mind and plan to implement the
nanosec solution myself using a particular POSIX timers call to
clock_gettime() with appropriate checks that this optional POSIX
extension actually exists on the platform.  Since this is so near
release I will also add a Linux-only check just in case there is some
loophole in my preprocessor logic for detecting this extension on
non-Linux platforms.  This will be implemented such that your
present calls to wxLogDebug(<some string>) will be replaced
by using the macro PLPLOT_wxLogDebug(<some string>).

I also plan to use PLPLOT_wxLogDebug in the -dev wxwidgets code
to attempt to track down the cause of the big pause later today.

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] The pls NULL fix for some Linux platforms

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

Hi Alan


>> In fact I just did a google search for the terms <wxwidgets wait
>> event> and there did seem to be a lot of help given on that topic

I am still looking at this.


> What bothers me about these results is there seems to be two
> CreateStream calls in both cases where I suspect (although I don't
> know since I am not that familiar with wxwidgets) one is essentially
> ignored.

> 22:45:01: Debug: wxPLplotwindow::wxPLplotwindow
> 22:45:01: Debug: frame->Create
> 22:45:01: Debug: wxPLplotwindow::Show
> 22:45:01: Debug: wxPLplotwindow::CreateStream
> 22:45:01: Debug: wxPLplotwindow::OnCreate
> 22:45:01: Debug: wxPLplotwindow::CreateStream
> 22:45:01: Debug: Plot()


The two CreateStream calls are made but the second is ignored .
The 2 calls are made because both
Show()
OnCreate()

call
CreateStream()

But the boolean flag "m_created" below makes that the actual creation of the 
stream
is only made once

void wxPLplotwindow<WXWINDOW>::CreateStream( void )
{
    wxLogDebug("wxPLplotwindow::CreateStream");
    if ( !m_created )
   {
    ...
    m_created = true;
  }

 also the print statement is made right at the start,
so it's always printed.


>So is Pedro's current fix simply one method of inserting a
> small timing wait before you get to Plot()?

No, my changes are just to make
Show()
create the stream, there are no events and timing in any way modified.


This is the client code sequence in wxPLplotDemo.cpp

wxPLplotwindow<wxFrame> *frame = new wxPlDemoFrame();
frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
frame->Show();

Since the Show(); function is *always* called in a deterministic way,
creating the stream there makes sure that it is always called at that time.

making the stream to be *eventually* created later in
frame->Create
puts a lag in the actual creation time and sequence , because it goes
to an event queue


One way to solve this matter completely is just to make the stream
creation in
frame->Show();
and not in
frame->Create

I just left it now also in
frame->Create

so that we have an understanding of what is actually happening.


> Do you know how to trivially override FormatTime to give us at least
> millisecond resolution here?  If that is not a trivial change, another
> alternative I am thinking of is (strictly for the Linux case) is to
> call clock_gettime which will help give us a nanosecond time stamp.


ok, I'll try to change the time format.

to summarize, there are 3 options

1) Make the stream creation call happen *only* in
frame->Show();
delete the function
wxPLplotwindow::OnCreate

this makes the stream creation to always happen in Show(); only

2) Leave the code like it is
like it is the stream creation is always created in Show(); actually,
as you can see from both (yours, mine)  print sequences

so the
wxPLplotwindow::OnCreate
does not actually have any effect now, but it's there for debugging reasons


the differences in sequences in your linux and mine is that in your case
both Show() and OnCreate() are called *before* Plot()
the OnCreate() call has no effect, it is ignored

22:45:01: Debug: wxPLplotwindow::Show
22:45:01: Debug: wxPLplotwindow::OnCreate
22:45:01: Debug: Plot()

in my case

22:45:01: Debug: wxPLplotwindow::Show
22:45:01: Debug: Plot()
22:45:01: Debug: wxPLplotwindow::OnCreate

Plot() is called before OnCreate()
and this was what was causing the bug (no stream created when Plot() is 
called)



3) Leave the code like it is but add further debugging features like
the millisecond resolution


let me know which option you prefer

-Pedro



----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "PLplot development list" <plp...@li...>
Sent: Sunday, December 18, 2016 3:12 AM
Subject: Re: [Plplot-devel] The pls NULL fix for some Linux platforms


> On 2016-12-17 00:38-0800 Alan W. Irwin wrote:
>
> [...]
>> So if that is a good summary of the problem (the timing for when the
>> OnCreate event fires is not deterministic which your debug output
>> seems to have proved again and again) doesn't wxwidgets have a decent
>> way to wait for that event to fire in the Plot routine before
>> proceeding with defining pls? That would be the definitive fix for
>> this nondeterministic event timing issue (assuming that is the issue).
>>
>> In fact I just did a google search for the terms <wxwidgets wait
>> event> and there did seem to be a lot of help given on that topic
>> right in the first reference found
>> <https://forums.wxwidgets.org/viewtopic.php?t=22893>. Could you adapt
>> one of those ideas?  Or if that reference is too old (2009) so not
>> wxwidgets-3.x relevant, perhaps one of the other hits you get with the
>> above search terms might give you the one-liner you need to
>> efficiently wait for the onCreate event before proceeding with
>> defining pls in Plot().  And that one-liner would allow you to remove
>> the changes you made in the present workaround bug fix.  Anyhow, if
>> you can come up with that one-liner + dropping the changes in commit
>> e5b7485 (your workaround fix) I would be very happy to push that
>> commit.
>
> To Pedro and Phil:
>
> I am still not convinced we have the definitive fix for this issue (as
> I indicated in my other post about freeze date and release status).
> The present Linux debug output results (from the recent git log) from
> building the test_wxPLplotDemo target are the following:
>
> Pedro:
>
> 15:33:46: Debug: wxPLplotwindow::wxPLplotwindow
> 15:33:46: Debug: frame->Create
> 15:33:46: Debug: wxPLplotwindow::Show
> 15:33:46: Debug: wxPLplotwindow::CreateStream
> 15:33:46: Debug: Plot()
> 15:33:46: Debug: wxPLplotwindow::OnCreate
> 15:33:46: Debug: wxPLplotwindow::CreateStream
>
> Me:
>
> 22:45:01: Debug: wxPLplotwindow::wxPLplotwindow
> 22:45:01: Debug: frame->Create
> 22:45:01: Debug: wxPLplotwindow::Show
> 22:45:01: Debug: wxPLplotwindow::CreateStream
> 22:45:01: Debug: wxPLplotwindow::OnCreate
> 22:45:01: Debug: wxPLplotwindow::CreateStream
> 22:45:01: Debug: Plot()
>
> What bothers me about these results is there seems to be two
> CreateStream calls in both cases where I suspect (although I don't
> know since I am not that familiar with wxwidgets) one is essentially
> ignored.  So is Pedro's current fix simply one method of inserting a
> small timing wait before you get to Plot()?  If so, that is pretty ad
> hoc. So wouldn't it be better to do a proper wait in Plot() instead
> for the needed event to occur before you define pls?
>
> @Pedro:
>
> One thing I dislike about the present debug output is the time stamp
> resolution of 1 second is so coarse when Linux is typically capable of
> nanosec resolution for times and the wxWidgets library is generally
> capable of millisec resolution.  Furthermore, the documentation
> at <http://docs.wxwidgets.org/3.0/overview_log.html> says:
>
> "Additionally, you can customize the way full log messages are
> constructed from the components (such as time stamp, source file
> information, logging thread ID and so on). This task is performed by
> wxLogFormatter class so you need to derive a custom class from it and
> override its Format() method to build the log messages in desired way.
> Notice that if you just need to modify (or suppress) the time stamp
> display, overriding FormatTime() is enough."
>
> Do you know how to trivially override FormatTime to give us at least
> millisecond resolution here?  If that is not a trivial change, another
> alternative I am thinking of is (strictly for the Linux case) is to
> call clock_gettime which will help give us a nanosecond time stamp.
>
> The reason I am concerned about this topic of time resolution is I
> think knowing the intervals between the various events with much
> higher accuracy is going to give us some added insight as to what is
> going on here with the above event order that is clearly not
> deterministic on Linux from these two examples (and many others).  For
> example, if the two CreateStream calls and the Plot() call are all
> within a few nanoseconds of each other, that tells you one thing, but
> if they are separated by a much larger time interval or at some exact
> multiple of some fairly large interval (such as 50 ms) that tells you
> a very different story.
>
> Anyhow, if you don't want to fiddle with time resolution, let me
> know, and I will play with the clock_gettime 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] Cmake generation with wxWidgets on Windows

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

Hi Alan

>My point is CMake find commands only look for a certain tiny subset of a 
>given
>installation, and if you haven't clobbered anything in that subset it won't 
>detect
>anything wrong.  But of course when you try and build and run with
>Visual Studio, the missing .lib files were detected.

yes that was what happened.
In the end the missing files are detected, but I was under the impression 
that the cmake
step would detect the missing files when I assumed they were there, 
therefore my original report
(where I was thinking the files existed, it was only after sending the first 
report that I noticed they did not exist).

all good then

-Pedro

----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "PLplot development list" <plp...@li...>
Sent: Sunday, December 18, 2016 2:28 AM
Subject: Re: [Plplot-devel] Cmake generation with wxWidgets on Windows


> On 2016-12-17 19:25-0500 Pedro Vicente wrote:
>
>>
>> Hi Alan
>>
>>> (3) Static PLplot libraries + device driver code embedded in our core
>>> static library (identified by its "plplot" basename).
>>
>> I always use (3).
>>
>> I repeated what I had done before:
>>
>> My wxwidgets libraries are located at
>>
>> M:\wx\wxwidgets-3.1.0\lib\vc_lib
>>
>> here there are several .lib files like this one
>>
>> wxmsw31ud_core.lib
>>
>> 1) I deleted all .lib files from that location
>> 2) did a PLplot cmake run with
>>
>> cmake ".." -G "Visual Studio 
>> 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
>>  -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON 
>>  -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib 
>>  -DwxWidgets_CONFIGURATION=mswud -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>>> cmake.out.txt 2>&1
>>
>> where
>> %WXWIN%
>> is
>> M:\wx\wxwidgets-3.1.0
>>
>> cmake.out.txt  is attached and it detected wxwidgets
>>
>> 2) Built the Visual Studio generated solution and got the wxwidgets 
>> linking errors
>>
>> 4) rebuilt wxwidgets libraries at M:\wx\wxwidgets-3.1.0\lib\vc_lib
>>
>> 5) did the same  PLplot cmake run
>>
>> 6) Built the Visual Studio generated solution , no errors
>
> Hi Pedro:
>
> Am I understanding your test properly?  You clobbered your wxwidgets
> installation (by removing the .lib files), our build system did not
> detect those removed .lib files, but Visual Studio did in step 2.  You
> fixed that wxwidgets installation issue, ran cmake again, and this
> time Visual Studio worked.  Isn't this exactly how you would like
> our build system to work in conjunction with Visual Studio?
>
> My point is CMake find commands only look for a certain tiny subset of a 
> given
> installation, and if you haven't clobbered anything in that subset it 
> won't detect
> anything wrong.  But of course when you try and build and run with
> Visual Studio, the missing .lib files were detected.
>
> Anyhow, I don't see anything wrong here.  Am I missing something?
>
>>
>> I took a look at the PLplot
>> FindwxWidgets.cmake
>> module and it seems that there is an attempt to find the wxwidgets 
>> libraries (the actual file names), here
>>
>> find_library(WX_${LIB}${_DBG}
>>       NAMES
>>       wxbase31${_UCD}${_DBG}_${LIB}
>>
>>
>> so, not sure exactly what happened, and probably we could leave this 
>> possible non-critical bug for after the release (if it's a bug).
>
> As far as I can tell from the above argument it is not a bug.  But if it
> turns out to be a bug, I will likely wait to fix it until post-release
> because it doesn't seem to be release critical (if a bug at all).
>
>>
>> I started using cmake in my projects some months ago, and what I do to 
>> detect libraries is like this,
>> an example for the JSON jansson library:
>>
>>
>> find_library(JANSSON_LIBRARY NAMES jansson HINTS 
>> "/data/data127/pvicente/install/jansson-2.9/lib/")
>> if(NOT JANSSON_LIBRARY)
>> message(FATAL_ERROR "jansson library not found")
>> else()
>> message("-- Found jansson library at: " ${JANSSON_LIBRARY})
>> endif()
>
> Good.
>
> [....]
>> Here's my Windows call (the path like /C/ is because this is in Git Bash)
>>
>> cmake 
>> .. -DSTATIC_CRT:BOOL=ON -DJANSSON_INCLUDE:PATH=/C/include -DJANSSON_LIBRARY=/C/lib/jansson.lib
>>
>>
>> my library file is actually called (extra _d)
>> /C/lib/jansson_d.lib
>>
>> and cmake said
>>
>> -- Found jansson.h header file at: C:/include
>> -- Found jansson library at: C:/lib/jansson.lib
>
> find_library (in fact, all the CMake find technology) is a no-op if
> you specify the answer it is trying to determine (JANSSON_LIBRARY).
> So if your specification (-DJANSSON_LIBRARY=/C/lib/jansson.lib) points to 
> a file that doesn't exist, CMake will happily accept that
> and move on.  However, if you don't specify, CMake find technology
> will only find existing files.
>
>>
>> then when I build Visual Studio I get
>>
>> LINK : fatal error LNK1104: cannot open file 'C:\lib\jansson.lib'
>>
>> my understanding is that
>> find_library
>>
>> does not actually detect if the argument is an existent file
>
> That depends, see above.
>
>>
>> Or could be that it does not because I am using the same variable name 
>> JANSSON_LIBRARY
>> for both the argument of
>> cmake .. -DJANSSON_LIBRARY
>> and
>> find_library(JANSSON_LIBRARY
>>
>> so , this print
>> -- Found jansson library at: C:/lib/jansson.lib
>>
>> is not actually true for this example.
>
> Exactly.  You have specified what find_library was trying to
> determine, and the CMake find technology is designed following the
> philosophy that the customer must always be right.  :-)
>
> So it is better if you tell CMake as little as possible with
> command-line options in case you make some mistake with those as
> in the above example.  Also, try
>
> cmake --help-full |less
>
> to look at complete documentation of cmake.  So within
> that less command you can look for the regexp "find_library$", and
> there you will find (heh) everything you need to know
> about that command and how to influence its results (e.g.,
> by specifying CMAKE_LIBRARY_PATH) without telling it
> something that turns out to be incorrect such as in your
> example above.
>
> The above is what I routinely do on the command line on Linux to
> access CMake documentation.  Let's face it, "less" is a simple but
> wonderful app that does a limited job well.  A perfect example, of the
> Unix philosopy.  So this method should work on any Unix system or
> Unix-like Windows system (e.g., Cygwin or MinGW-w64/MSYS2).  But if
> you don't have Unix tools like "less" at hand, you can also instantly
> get complete documentation for find_library from a google search, and
> by playing with the URL in an obvious way you can get any version of
> the find_library documentation from 3.0.x to 3.7.x in case there were
> any changes during that range of releases.
>
> 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] The pls NULL fix for some Linux platforms

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

On 2016-12-17 00:38-0800 Alan W. Irwin wrote:

[...]
> So if that is a good summary of the problem (the timing for when the
> OnCreate event fires is not deterministic which your debug output
> seems to have proved again and again) doesn't wxwidgets have a decent
> way to wait for that event to fire in the Plot routine before
> proceeding with defining pls? That would be the definitive fix for
> this nondeterministic event timing issue (assuming that is the issue).
>
> In fact I just did a google search for the terms <wxwidgets wait
> event> and there did seem to be a lot of help given on that topic
> right in the first reference found
> <https://forums.wxwidgets.org/viewtopic.php?t=22893>. Could you adapt
> one of those ideas?  Or if that reference is too old (2009) so not
> wxwidgets-3.x relevant, perhaps one of the other hits you get with the
> above search terms might give you the one-liner you need to
> efficiently wait for the onCreate event before proceeding with
> defining pls in Plot().  And that one-liner would allow you to remove
> the changes you made in the present workaround bug fix.  Anyhow, if
> you can come up with that one-liner + dropping the changes in commit
> e5b7485 (your workaround fix) I would be very happy to push that
> commit.

To Pedro and Phil:

I am still not convinced we have the definitive fix for this issue (as
I indicated in my other post about freeze date and release status).
The present Linux debug output results (from the recent git log) from
building the test_wxPLplotDemo target are the following:

Pedro:

15:33:46: Debug: wxPLplotwindow::wxPLplotwindow
15:33:46: Debug: frame->Create
15:33:46: Debug: wxPLplotwindow::Show
15:33:46: Debug: wxPLplotwindow::CreateStream
15:33:46: Debug: Plot()
15:33:46: Debug: wxPLplotwindow::OnCreate
15:33:46: Debug: wxPLplotwindow::CreateStream

Me:

22:45:01: Debug: wxPLplotwindow::wxPLplotwindow
22:45:01: Debug: frame->Create
22:45:01: Debug: wxPLplotwindow::Show
22:45:01: Debug: wxPLplotwindow::CreateStream
22:45:01: Debug: wxPLplotwindow::OnCreate
22:45:01: Debug: wxPLplotwindow::CreateStream
22:45:01: Debug: Plot()

What bothers me about these results is there seems to be two
CreateStream calls in both cases where I suspect (although I don't
know since I am not that familiar with wxwidgets) one is essentially
ignored.  So is Pedro's current fix simply one method of inserting a
small timing wait before you get to Plot()?  If so, that is pretty ad
hoc. So wouldn't it be better to do a proper wait in Plot() instead
for the needed event to occur before you define pls?

@Pedro:

One thing I dislike about the present debug output is the time stamp
resolution of 1 second is so coarse when Linux is typically capable of
nanosec resolution for times and the wxWidgets library is generally
capable of millisec resolution.  Furthermore, the documentation
at <http://docs.wxwidgets.org/3.0/overview_log.html> says:

"Additionally, you can customize the way full log messages are
constructed from the components (such as time stamp, source file
information, logging thread ID and so on). This task is performed by
wxLogFormatter class so you need to derive a custom class from it and
override its Format() method to build the log messages in desired way.
Notice that if you just need to modify (or suppress) the time stamp
display, overriding FormatTime() is enough."

Do you know how to trivially override FormatTime to give us at least
millisecond resolution here?  If that is not a trivial change, another
alternative I am thinking of is (strictly for the Linux case) is to
call clock_gettime which will help give us a nanosecond time stamp.

The reason I am concerned about this topic of time resolution is I
think knowing the intervals between the various events with much
higher accuracy is going to give us some added insight as to what is
going on here with the above event order that is clearly not
deterministic on Linux from these two examples (and many others).  For
example, if the two CreateStream calls and the Plot() call are all
within a few nanoseconds of each other, that tells you one thing, but
if they are separated by a much larger time interval or at some exact
multiple of some fairly large interval (such as 50 ms) that tells you
a very different story.

Anyhow, if you don't want to fiddle with time resolution, let me
know, and I will play with the clock_gettime 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] Cmake generation with wxWidgets on Windows

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

On 2016-12-17 19:25-0500 Pedro Vicente wrote:

>
> Hi Alan
>
>> (3) Static PLplot libraries + device driver code embedded in our core
>> static library (identified by its "plplot" basename).
>
> I always use (3).
>
> I repeated what I had done before:
>
> My wxwidgets libraries are located at
>
> M:\wx\wxwidgets-3.1.0\lib\vc_lib
>
> here there are several .lib files like this one
>
> wxmsw31ud_core.lib
>
> 1) I deleted all .lib files from that location
> 2) did a PLplot cmake run with
>
> cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON 
> -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMAKE_BUILD_TYPE:STRING="Debug" 
> -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON 
> -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib 
> -DwxWidgets_CONFIGURATION=mswud -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF 
>> cmake.out.txt 2>&1
>
> where
> %WXWIN%
> is
> M:\wx\wxwidgets-3.1.0
>
> cmake.out.txt  is attached and it detected wxwidgets
>
> 2) Built the Visual Studio generated solution and got the wxwidgets linking 
> errors
>
> 4) rebuilt wxwidgets libraries at M:\wx\wxwidgets-3.1.0\lib\vc_lib
>
> 5) did the same  PLplot cmake run
>
> 6) Built the Visual Studio generated solution , no errors

Hi Pedro:

Am I understanding your test properly?  You clobbered your wxwidgets
installation (by removing the .lib files), our build system did not
detect those removed .lib files, but Visual Studio did in step 2.  You
fixed that wxwidgets installation issue, ran cmake again, and this
time Visual Studio worked.  Isn't this exactly how you would like
our build system to work in conjunction with Visual Studio?

My point is CMake find commands only look for a certain tiny subset of a given
installation, and if you haven't clobbered anything in that subset it won't detect
anything wrong.  But of course when you try and build and run with
Visual Studio, the missing .lib files were detected.

Anyhow, I don't see anything wrong here.  Am I missing something?

>
> I took a look at the PLplot
> FindwxWidgets.cmake
> module and it seems that there is an attempt to find the wxwidgets libraries 
> (the actual file names), here
>
> find_library(WX_${LIB}${_DBG}
>       NAMES
>       wxbase31${_UCD}${_DBG}_${LIB}
>
>
> so, not sure exactly what happened, and probably we could leave this possible 
> non-critical bug for after the release (if it's a bug).

As far as I can tell from the above argument it is not a bug.  But if it
turns out to be a bug, I will likely wait to fix it until post-release
because it doesn't seem to be release critical (if a bug at all).

>
> I started using cmake in my projects some months ago, and what I do to detect 
> libraries is like this,
> an example for the JSON jansson library:
>
>
> find_library(JANSSON_LIBRARY NAMES jansson HINTS 
> "/data/data127/pvicente/install/jansson-2.9/lib/")
> if(NOT JANSSON_LIBRARY)
> message(FATAL_ERROR "jansson library not found")
> else()
> message("-- Found jansson library at: " ${JANSSON_LIBRARY})
> endif()

Good.

[....]
> Here's my Windows call (the path like /C/ is because this is in Git Bash)
>
> cmake .. -DSTATIC_CRT:BOOL=ON -DJANSSON_INCLUDE:PATH=/C/include 
> -DJANSSON_LIBRARY=/C/lib/jansson.lib
>
>
> my library file is actually called (extra _d)
> /C/lib/jansson_d.lib
>
> and cmake said
>
> -- Found jansson.h header file at: C:/include
> -- Found jansson library at: C:/lib/jansson.lib

find_library (in fact, all the CMake find technology) is a no-op if
you specify the answer it is trying to determine (JANSSON_LIBRARY).
So if your specification (-DJANSSON_LIBRARY=/C/lib/jansson.lib) 
points to a file that doesn't exist, CMake will happily accept that
and move on.  However, if you don't specify, CMake find technology
will only find existing files.

>
> then when I build Visual Studio I get
>
> LINK : fatal error LNK1104: cannot open file 'C:\lib\jansson.lib'
>
> my understanding is that
> find_library
>
> does not actually detect if the argument is an existent file

That depends, see above.

>
> Or could be that it does not because I am using the same variable name 
> JANSSON_LIBRARY
> for both the argument of
> cmake .. -DJANSSON_LIBRARY
> and
> find_library(JANSSON_LIBRARY
>
> so , this print
> -- Found jansson library at: C:/lib/jansson.lib
>
> is not actually true for this example.

Exactly.  You have specified what find_library was trying to
determine, and the CMake find technology is designed following the
philosophy that the customer must always be right.  :-)

So it is better if you tell CMake as little as possible with
command-line options in case you make some mistake with those as
in the above example.  Also, try

cmake --help-full |less

to look at complete documentation of cmake.  So within
that less command you can look for the regexp "find_library$", and
there you will find (heh) everything you need to know
about that command and how to influence its results (e.g.,
by specifying CMAKE_LIBRARY_PATH) without telling it
something that turns out to be incorrect such as in your
example above.

The above is what I routinely do on the command line on Linux to
access CMake documentation.  Let's face it, "less" is a simple but
wonderful app that does a limited job well.  A perfect example, of the
Unix philosopy.  So this method should work on any Unix system or
Unix-like Windows system (e.g., Cygwin or MinGW-w64/MSYS2).  But if
you don't have Unix tools like "less" at hand, you can also instantly
get complete documentation for find_library from a google search, and
by playing with the URL in an obvious way you can get any version of
the find_library documentation from 3.0.x to 3.7.x in case there were
any changes during that range of releases.

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] The pls NULL fix for some Linux platforms

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

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

> Hi Alan
> Patch is attached, it's a good idea to have the "git format-patch" format.

Hi Pedro:

Commit message amended with a slightly different first line + my test

Commit pushed (commit 786ff04) with thanks.

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] Freeze is now official

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

This is the official notice from your release manager that the soft
freeze is in effect from now until the release.  What this means in
practical terms is during this test period starting now and ending
with the actual release (likely ~10 days from now) you are strongly
discouraged from pushing intrusive/large topic branches into the SF
master branch other than documentation upgrades.

At the same time you are strongly encouraged during this test period
to fix all bugs that don't require an intrusive change.  For example,
any bug fixes for the wxwidgets device are strongly encouraged at this
time, because almost by definition those fixes will not be intrusive
since they will only affect two components of PLplot (both of which
can be classified as interactive), the wxwidgets device, and the
wxwidgets binding. (And the Linux run-time trouble with a wxwidgets
event that Pedro has been encountering with the wxwidgets binding, and
and the Linux run-time trouble with large pauses I and others have
been encountering for the wxwidgets device mean the wxwidgets
components of our software is not in a very good state at the moment
on Linux so again almost by definition any fix for those issues is not
disruptive. Thus, I plan to strongly encourage pushes of such fixes
right up to the day of the release.  Assuming, of course, that the
fixes have been sufficiently tested on all platforms that we are
confident no disruptive build issues have been introduced by such
fixes.

In contrast to the Linux wxwidgets case, anything that significantly
affects the core library is almost by definition disruptive. A good
example of such a disruptive change is the large change I made
recently to include/plplot.h.  Which is why I made sure that change
was completely tested on Linux before I pushed it substantially before
this freeze date.  This means we have been actually free of disruptive
changes since that commit date, 6 days ago, and, of course thanks to
Arjen's recent comprehensive test work, that change has also been
tested pretty thoroughly on both the Cygwin and MinGW-w64/MSYS2
platforms.

My plans for these next ~10 days (aside from a day or so off for
Christmas) until the release are to encourage as best I can (within
the limitations of my limited C++ skills) getting Pedro and Phil to
deal with the two egregious bug issues for the wxwidgets device driver
and binding on Linux (to the point I would be willing to delay the
release by a few extra days if one of them felt they were on the edge
of a breakthrough), respond to any more comprehensive test reports
that people send me (by posting those results in our wiki if the
comprehensive script completes or advising the tester what constraints
on the comprehensive test they should make to allow the script to
complete), deal with any PLplot regressions that might show up, and
especially to mature my work on the large DocBook documentation update
that I have had in progress for the last several months so that the
DocBook changes can be pushed to master and DocBook results pushed to
our website before the release.

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
__________________________