Hi Phil
I agree, the Show() solution is a bad solution, the stream creation must be
done in OnCreate()
-Pedro
----- Original Message -----
From: p.d.rosenb...@gmail.com
To: Pedro Vicente ; Alan W. Irwin
Cc: PLplot development list
Sent: Tuesday, December 20, 2016 6:38 PM
Subject: RE: [Plplot-devel] Subscribing to our git feed
Hi Pedro
The fact that the solution is currently broken does not help my argument
here. However, here is the reasoning. With the show solution this works
MyFrame *frame = new Frame();
frame->Show();
Plot(frame);
But the user may not want to show the frame immediately or may want to show
and hide it at various times, in which case the following code fails
MyFrame *frame = new Frame();
Plot(frame);
// this could be one line later or in a whole
// different scope
frame->Show();
By having the create call this should put all construction in one place (
assuming it works!) and totally separates the construction and setting up of
the window from displaying it. Another way to think of it is that each function
must have a well defined contract – a set of things it does. If it doesn't do
those things, or if it has some side effects that aren't part of that contract
then this is bad. It violates the “principle of least surprise” and leads not
only to buggy code but to bugs that are very difficult to track down. In this
case the Show method already has a well defined contract and wxWidgets users
would expect that to be respected. Show displays or hides windows. Drawing on
windows is totally independent of Show. If we add a side effect to the Show
method then wxWidgets users don't expect that. The worst case scenario is that
by chance it works to start with, because they happen to have Show() before
Plot(), then they decide to move the Show() call, perhaps as part of some
bigger restructuring. Suddenly everything breaks and the user has no idea why.
They probably don't even suspect the innocuous Show() call, because they are
sure they know what it does – it has a well defined contract, but we broke
that. So they spend hours or days debugging and looking in the wrong place.
Well I may be over exaggerating. But I'm sure you get my point. In well
structured code every function has a well defined contract and no side effects.
If we mess with Show() then we are breaking that contract.
At least with Create(), there is a documented methodology already. We can
also encapsulate this in a constructor if needed (this is my plan for a few
cases, but it will have to wait until the next release).
Does that make sense?
I am however happy to hear other solutions, but I am pretty keen on trying to
enforce the principle of least surprise along with the contract concept as I
have been caught out badly in the past by (my own and other peoples’) code that
didn't confirm to these principles.
Phil
Sent from my Windows 10 phone
From: Pedro Vicente
Sent: 20 December 2016 18:07
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] Subscribing to our git feed
Hi Alan, Phil
> Also, it was
> really good to hear that your tests show we finally have the
> definitive fix for this Linux issue
You're welcome, glad I could help.
I was going to send an email questioning the reasoning of both
solutions assuming both were
working (Phil's and mine), but I just tried on my CentOS with the
latest git code, and what happens
is that the execution is always on
12:50:24: Debug: Plot() Yielding
About the solutions
1) Current solution
Right now, this has to be done in the client code
//We must wait for the Create event to be processed and the
//wxPLplotstream to be prepared
while (!frame->IsReady())
{
PLPLOT_wxLogDebug("Plot() Yielding");
wxGetApp().Yield();
}
So, the user has to do some extra step in order to wait for wxWidgets
to
process some event.
Ideally he should not have to do this but rather all should be done
inside wxWidgets.
This is error prone, because the usual way to use wxWidgets is
MyFrame *frame = new Frame()
frame->Show()
here we have
MyFrame *frame = new Frame()
frame->Create()
While ()
{
wait()
}
frame->Show()
Plot(
so a user might not even be aware of this wait extra step.
that is assuming it's working, but on my CentOS it gets stuck on the
Yield()
2) Solution of creating the fame in Show()
Client code is
MyFrame *frame = new Frame()
frame->Create()
frame->Show()
Plot()
there is no wait loop; there is also no need to create the stream in
OnCreate()
-Pedro
On 2016-12-20 04:01, Alan W. Irwin wrote:
> On 2016-12-19 23:32-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I subscribed to the feed, got the latest master, and all is working
>> now on wxWidgetsdemo.
>
> Hi Pedro:
>
> That is good that you are subscribed to the git feed. Also, it was
> really good to hear that your tests show we finally have the
> definitive fix for this Linux issue thanks to your original report of
> the issue, your implementation of an initial solution, your
> subsequent
> test efforts on various Linux platforms, and your discussions of the
> issue with Phil. And my thanks to Phil for ultimately finding the
> definitive fix. That was good collaborative development work on an
> open source project you can both be proud of.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
--
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
