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

[p.d.rosenberg]

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- 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 *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  shows lots of
hits, in particular
.  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 

Re: [Plplot-devel] Comprehensive testing

[Arjen Markus]

Hi Alan,

> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> 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 
>
> 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.
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

On 2016-12-18 23:27- 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 *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  shows lots of
hits, in particular
.  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
__

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

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
__

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

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" 
To: "Pedro Vicente" 
Cc: "Alan W. Irwin" ; "PLplot development list" 

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 3a6a49a572e7aa518a5b8a6bbecd9ef1f812
> 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
>  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- 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
>> pedro.vice...@space-research.org
>> http://www.space-research.org/
> 


---

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

[Phil Rosenberg]

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 3a6a49a572e7aa518a5b8a6bbecd9ef1f812
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
 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- 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
> pedro.vice...@space-research.org
> http://www.space-research.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The pls NULL fix for some Linux platforms

[Alan W. Irwin]

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() will be replaced
by using the macro PLPLOT_wxLogDebug().

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
__

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The pls NULL fix for some Linux platforms

[Pedro Vicente]

Hi Alan


>> In fact I just did a google search for the terms > 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::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 *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" 
To: "Pedro Vicente" 
Cc: "PLplot development list" 
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 > event> and there did seem to be a lot of help given on that topic
>> right in the first reference found
>> . 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 v

Re: [Plplot-devel] Cmake generation with wxWidgets on Windows

[Pedro Vicente]

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" 
To: "Pedro Vicente" 
Cc: "PLplot development list" 
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'
>

Re: [Plplot-devel] The pls NULL fix for some Linux platforms

[Alan W. Irwin]

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  event> and there did seem to be a lot of help given on that topic
> right in the first reference found
> . 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  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
__