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...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
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
> __________________________
>
------------------------------------------------------------------------------
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
