plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] The wxwidgets-related components of PLplot and the 5.12.0 release

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

Hi Alan
I should be able to look at the plclear buffer issue over the weekend. Then I'll start sorting the wxWidgets documentation.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 05 January 2017 21:51
To: Phil Rosenberg; Pedro Vicente; PLplot development list
Subject: The wxwidgets-related components of PLplot and the 5.12.0 release

On 2017-01-04 20:08-0500 Pedro Vicente wrote:

> I tried on my linux 16.04, same results as CentOS (I don'have the 14.04 and debian anymore)

To Phil and Pedro:

@Pedro:
It appears you are completely satisfied with this fix on the two Linux
platforms where you have tested it.  Those tests are much appreciated,
and based on good results now for 4 Linux platforms (two from you and
one each from Phil and I) the conclusion appears to be all is well
with this fix for the extremely tricky event-timing bug you discovered
on some Linux platforms/hardware.

@ Phil:
My understanding is you have made some text orientation changes that
continue to work now for you with older wxwidgets, and which you
anticipate (but have not tested) will work for the latest git version
of wxwidgets as well.  And you are still working on an additional
background colour fix (that we might or might not push for this
release depending on how intrusive that fix turns out to be).  Do you
have an ETA for when we will be able to make that decision, i.e., when
we can finalize the wxwidgets code changes for this release?

@ Both:
Once that finalization occurs, we (Phil, Pedro, and I) should
thoroughly test the wxwidgets components of PLplot again on all
accessible platforms, and after that I expect it will take several
days longer for me to finish my large documentation update (and I am
hoping Phil will contribute to that update as well for anything
related to wxwidgets).  So I think we are looking at a release date of
roughly one week after the wxwidgets code changes are finalized, e.g.,
late next week if that finalization happens soon.

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 wxwidgets-related components of PLplot and the 5.12.0 release

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

>> > It appears you are completely satisfied with this fix on the two Linux
> platforms where you have tested it.

yes


> Once that finalization occurs, we (Phil, Pedro, and I) should
> thoroughly test the wxwidgets components of PLplot again on all
> accessible platforms

ok, wil do

-Pedro

----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Phil Rosenberg" <p.d...@gm...>; "Pedro Vicente" 
<ped...@sp...>; "PLplot development list" 
<Plp...@li...>
Sent: Thursday, January 05, 2017 4:51 PM
Subject: The wxwidgets-related components of PLplot and the 5.12.0 release


> On 2017-01-04 20:08-0500 Pedro Vicente wrote:
>
>> I tried on my linux 16.04, same results as CentOS (I don'have the 14.04 
>> and debian anymore)
>
> To Phil and Pedro:
>
> @Pedro:
> It appears you are completely satisfied with this fix on the two Linux
> platforms where you have tested it.  Those tests are much appreciated,
> and based on good results now for 4 Linux platforms (two from you and
> one each from Phil and I) the conclusion appears to be all is well
> with this fix for the extremely tricky event-timing bug you discovered
> on some Linux platforms/hardware.
>
> @ Phil:
> My understanding is you have made some text orientation changes that
> continue to work now for you with older wxwidgets, and which you
> anticipate (but have not tested) will work for the latest git version
> of wxwidgets as well.  And you are still working on an additional
> background colour fix (that we might or might not push for this
> release depending on how intrusive that fix turns out to be).  Do you
> have an ETA for when we will be able to make that decision, i.e., when
> we can finalize the wxwidgets code changes for this release?
>
> @ Both:
> Once that finalization occurs, we (Phil, Pedro, and I) should
> thoroughly test the wxwidgets components of PLplot again on all
> accessible platforms, and after that I expect it will take several
> days longer for me to finish my large documentation update (and I am
> hoping Phil will contribute to that update as well for anything
> related to wxwidgets).  So I think we are looking at a release date of
> roughly one week after the wxwidgets code changes are finalized, e.g.,
> late next week if that finalization happens soon.
>
> 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] The wxwidgets-related components of PLplot and the 5.12.0 release

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

On 2017-01-04 20:08-0500 Pedro Vicente wrote:

> I tried on my linux 16.04, same results as CentOS (I don'have the 14.04 and debian anymore)

To Phil and Pedro:

@Pedro:
It appears you are completely satisfied with this fix on the two Linux
platforms where you have tested it.  Those tests are much appreciated,
and based on good results now for 4 Linux platforms (two from you and
one each from Phil and I) the conclusion appears to be all is well
with this fix for the extremely tricky event-timing bug you discovered
on some Linux platforms/hardware.

@ Phil:
My understanding is you have made some text orientation changes that
continue to work now for you with older wxwidgets, and which you
anticipate (but have not tested) will work for the latest git version
of wxwidgets as well.  And you are still working on an additional
background colour fix (that we might or might not push for this
release depending on how intrusive that fix turns out to be).  Do you
have an ETA for when we will be able to make that decision, i.e., when
we can finalize the wxwidgets code changes for this release?

@ Both:
Once that finalization occurs, we (Phil, Pedro, and I) should
thoroughly test the wxwidgets components of PLplot again on all
accessible platforms, and after that I expect it will take several
days longer for me to finish my large documentation update (and I am
hoping Phil will contribute to that update as well for anything
related to wxwidgets).  So I think we are looking at a release date of
roughly one week after the wxwidgets code changes are finalized, e.g.,
late next week if that finalization happens soon.

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] legend and label using wxWidgets

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

Hi Laurent
Although I haven't upgraded to wxWidgets 3.1. I think I have isolated
and fixed the issue. It turned out to affect all wxDCs that support
transformations so I was able to reproduce your bad results on a
wxMemoryDc. If you grab the latest version from the Git repo then you
should find everything is working correctly again. If not then please
let me know.

Phil

On 5 January 2017 at 00:42,  <p.d...@gm...> wrote:
> Hi Alan
>
> I agree it would be good to look at this pre release. It's on my to do list
> for asap.
>
>
>
> Sent from my Windows 10 phone
>
>
>
> From: Alan W. Irwin
> Sent: 04 January 2017 20:37
> To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list
> Subject: Re: [Plplot-devel] legend and label using wxWidgets
>
>
>
> On 2016-12-28 23:19+0100 Laurent Berger wrote:
>
>
>
>> wxwidgets commit 0bf38e1 x04 y axis label is good
>
>>
>> (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be)
>
>>
>
>> wxwidgets commit 49000def x04 y axis label is false
>
>>
>> (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3)
>
>
>
> Hi Phil:
>
>
>
> Assuming (subject to Pedro's further extensive testing) that you have
>
> found a good fix for that bug he had discovered, then the only
>
> remaining potentially release critical issue for the wxwidgets-related
>
> components of PLplot is the issue discovered by Laurent above.
>
>
>
> So to learn more about what Laurent reported above,
>
> I described those two commits as follows:
>
>
>
> software@raven> git clone https://github.com/wxWidgets/wxWidgets.git
> wxwidgets.git
>
> software@raven> cd wxwidgets.git
>
> software@raven> git branch
>
> * master
>
> software@raven> git describe 0bf38e1
>
> v3.1.0-620-g0bf38e1
>
> software@raven> git describe 49000def
>
> v3.1.0-621-g49000de
>
>
>
> So it is clear from these results that Laurent already bisected this
>
> issue with the 621st commit beyond the last official release (3.1.0)
>
> of wxwidgets showing the issue for the first time.  And since this is
>
> an issue that will not affect any user of an official wxwidgets
>
> release at this time, that gives us a good excuse to do nothing at
>
> this time if the potential fix is going to be intrusive.
>
>
>
> Of course, this issue will affect our users as soon as the next
>
> wxwidgets official release is out so it would be nice at this time for
>
> you to (a) confirm the above results for 0bf38e1 and 49000def from
>
> Laurent and figure out what the issue is.  If it turns out to be a
>
> wxwidgets regression introduced for 49000def it would be good for you
>
> to draw this quickly to the attention of the wxwidgets developers so
>
> they can fix that regression before their next official release to
>
> avoid making life difficult for PLplot wxwidgets users.  But if it
>
> turns out to be our problem, then please prepare the fix and use your
>
> best judgement (depending on, e.g., whether the fix is more or less
>
> intrusive than the fix you just made) whether to push it now or wait
>
> until after 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
>
> __________________________
>
>

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

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

On 2017-01-04 20:08-0500 Pedro Vicente wrote:

>>> Yes that is the expected output, although the window titles should be different. But actually it may be nicer to at least use 2 different curves. An easy change. What do you think?
>
> I don't have an opinion on the plot itself, but regarding the test_c_wxwidgets test, it would be a good idea to put a simple
> sleep(1)
> betwwen each test so we can see that it's doing what it should do

Hi Pedro:

That workaround would work for both -dev wxwidgets (or more likely the
wxPLViewer application that that device communciates with) and -dev
wingcc.  But since a common script is used for all interactive device
tests, that workaround would put an unnecessary delay into the results
for -dev xwin, tk, xcairo, and qtwidget. Therefore in this case I
prefer the definitive fix for these -np issues for wxPLViewer and -dev
wingcc.

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] Linux OnCreate delay bug -- solution

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

On 2017-01-05 00:54-0000 p.d...@gm... wrote:

> 1. Yes [two plots are] expected output, although the window titles
should be different. But actually it may be nicer to at least use 2
different curves. An easy change. What do you think?

Good idea.  So, yes please!

> 2. Will do [README.release paragraph] plus this all really needs properly adding to the docs. I will try to do that asap.

Thanks.  README.release paragraph is release-essential.  DocBook update
concerning wxwidgets is a "would-be-wonderful".

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] A pre release buffer bug

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

On 2017-01-05 00:48-0000 p.d...@gm... wrote:

> Hi All, but mostly aimed at Alan I guess
>

> I found a bug today based on some of my code. I have some code that
uses wxWidgets then I was attempting to use plreplot to write to a
file. But I was getting just a black screen. After a first look I
think the problem is the plclear calls are not being logged to the
buffer so the clearing to a white background isn't happening so the
black lines I used aren't showing up. If possible I'd like to get this
fixed this release cycle if only because I will be sharing the code
I'm writing with others and it would be easier for me if I could
direct other users to the current release rather than the git version.

> Would that be okay?

Hi Phil:

That decision critically depends on what your fix touches.  So please
go ahead and make the definitive fix (i.e., touching everything that
is required for a definitive fix as opposed to, e.g., working around
some bug in the plbuf part of PLplot using a temporary wxwidgets fix)
in a private topic branch. Then share that fix on list, and we can
make the push decision based on that actual fix then.

By the way, please take a look at the first page of example 16 (whose
-dev wxwidgets background is currently an incorrect black rather than
the correct white) on Linux platforms at least.  This problem sounds
quite similar to your own so I am hoping when you have the definitive
fix for your issue, the example 16 issue will also be fixed.

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] Linux OnCreate delay bug -- solution

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

>> Yes that is the expected output, although the window titles should be different. But actually it may be nicer to at least use 2 different curves. An easy change. What do you think?

I don't have an opinion on the plot itself, but regarding the test_c_wxwidgets test, it would be a good idea to put a simple
sleep(1) 
betwwen each test so we can see that it's doing what it should do

I tried on my linux 16.04, same results as CentOS (I don'have the 14.04 and debian anymore)
-Pedro
  ----- Original Message ----- 
  From: p.d...@gm... 
  To: Alan W. Irwin ; Pedro Vicente ; PLplot development list 
  Sent: Wednesday, January 04, 2017 7:54 PM
  Subject: RE: Linux OnCreate delay bug -- solution


  That looks promising 😊

   

  To answer your questions Alan (sorry for top posting, but I'm on my phone)

   

    1.. Yes that is the expected output, although the window titles should be different. But actually it may be nicer to at least use 2 different curves. An easy change. What do you think?
    2.. Will do, plus this all really needs properly adding to the docs. I will try to do that asap.
   

   

   

  Sent from my Windows 10 phone

   

  From: Alan W. Irwin
  Sent: 04 January 2017 19:17
  To: Phil Rosenberg; Pedro Vicente; PLplot development list
  Subject: Re: Linux OnCreate delay bug -- solution

   

  On 2017-01-04 13:04-0500 Pedro Vicente wrote:

   

  > Hi Phil

  > 

  > I got a good plot on CentOS, below output.

  > I'll test other Linux later

   

  > 

  >> So what I

  >> would propose is that for this release we attempt to not add or remove

  >> anything from the API and just stick with an example that  works with

  >> what we've got. Then after this release we can add non-template

  >> classes for wxFrame, wxDialog and wxPanel which can be used really

  >> easily by our users and we have time to test them and make sure the

  >> API for their use is stable before the next release.

  >> 

  >> Does that seem sensible?

  > 

   

  To Phil and Pedro:

   

  @Phil:

   

  The test_c_wxwidgets and test_wxPLplotDemo targets worked without

  issues here.  So we now have three good tests on Linux and one good

  test on Windows.  So this indeed seems promising as a solution to

  this release critical bug, and I thank you for this timely

  release-critical bug fixing.

   

  @Both:

   

  To finish off this topic for the release I need some more from both

  of you.

   

  @Phil:

   

  1. It sounded from your description that you were changing the example

  to try two different methods of generating those plots so it makes

  sense that test_wxPLplotDemo now produces two identical plots for me,

  but please confirm that the two plots I observed are the intended

  effect.

   

  2. Please commit a change to README.release describing what you have

  done to deal with this bug equivalent to what Pedro wrote up for his

  solution.

   

  @Pedro: I think your current CentOS test is equivalent to just

  building the test_wxPLplotDemo target?  Please extend that test to

  building the test_c_wxwidgets target as well. You were already

  planning to test Phil's solution on all the Linux platforms accessible

  to you, but please do the full test (build both the test_wxPLplotDemo

  and test_c_wxwidgets targets) for all Linux platforms.  And similarly

  for your Windows platforms.  There, the convenient test_* targets

  won't work so you will have to do the equivalent by hand (run

  wxPLplotDemo and run several C examples with -dev wxwidgets). Finally,

  please also test your own software projects that link with the

  plplotwxwidgets library on all platforms where you expect your own

  software projects to currently work.  (I assume that is just Windows,

  but please test on at least one Linux platform as well if you

  expect your software to work on both Windows and Linux.)

   

  Every tested platform that you add gives us just that much further

  confidence that Phil's solution is robust for this release, and I

  thank you in advance for all this essential testing work for our

  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

  __________________________

   

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

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

That looks promising 😊

To answer your questions Alan (sorry for top posting, but I'm on my phone)

1. Yes that is the expected output, although the window titles should be different. But actually it may be nicer to at least use 2 different curves. An easy change. What do you think?
2. Will do, plus this all really needs properly adding to the docs. I will try to do that asap.



Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 04 January 2017 19:17
To: Phil Rosenberg; Pedro Vicente; PLplot development list
Subject: Re: Linux OnCreate delay bug -- solution

On 2017-01-04 13:04-0500 Pedro Vicente wrote:

> Hi Phil
>
> I got a good plot on CentOS, below output.
> I'll test other Linux later

>
>> So what I
>> would propose is that for this release we attempt to not add or remove
>> anything from the API and just stick with an example that  works with
>> what we've got. Then after this release we can add non-template
>> classes for wxFrame, wxDialog and wxPanel which can be used really
>> easily by our users and we have time to test them and make sure the
>> API for their use is stable before the next release.
>> 
>> Does that seem sensible?
>

To Phil and Pedro:

@Phil:

The test_c_wxwidgets and test_wxPLplotDemo targets worked without
issues here.  So we now have three good tests on Linux and one good
test on Windows.  So this indeed seems promising as a solution to
this release critical bug, and I thank you for this timely
release-critical bug fixing.

@Both:

To finish off this topic for the release I need some more from both
of you.

@Phil:

1. It sounded from your description that you were changing the example
to try two different methods of generating those plots so it makes
sense that test_wxPLplotDemo now produces two identical plots for me,
but please confirm that the two plots I observed are the intended
effect.

2. Please commit a change to README.release describing what you have
done to deal with this bug equivalent to what Pedro wrote up for his
solution.

@Pedro: I think your current CentOS test is equivalent to just
building the test_wxPLplotDemo target?  Please extend that test to
building the test_c_wxwidgets target as well. You were already
planning to test Phil's solution on all the Linux platforms accessible
to you, but please do the full test (build both the test_wxPLplotDemo
and test_c_wxwidgets targets) for all Linux platforms.  And similarly
for your Windows platforms.  There, the convenient test_* targets
won't work so you will have to do the equivalent by hand (run
wxPLplotDemo and run several C examples with -dev wxwidgets). Finally,
please also test your own software projects that link with the
plplotwxwidgets library on all platforms where you expect your own
software projects to currently work.  (I assume that is just Windows,
but please test on at least one Linux platform as well if you
expect your software to work on both Windows and Linux.)

Every tested platform that you add gives us just that much further
confidence that Phil's solution is robust for this release, and I
thank you in advance for all this essential testing work for our
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
__________________________

[Plplot-devel] A pre release buffer bug

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

Hi All, but mostly aimed at Alan I guess

I found a bug today based on some of my code. I have some code that uses wxWidgets then I was attempting to use plreplot to write to a file. But I was getting just a black screen. After a first look I think the problem is the plclear calls are not being logged to the buffer so the clearing to a white background isn't happening so the black lines I used aren't showing up. If possible I'd like to get this fixed this release cycle if only because I will be sharing the code I'm writing with others and it would be easier for me if I could direct other users to the current release rather than the git version.

Would that be okay?

Sent from my Windows 10 phone

Re: [Plplot-devel] legend and label using wxWidgets

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

Hi Alan
I agree it would be good to look at this pre release. It's on my to do list for asap.

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 04 January 2017 20:37
To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list
Subject: Re: [Plplot-devel] legend and label using wxWidgets

On 2016-12-28 23:19+0100 Laurent Berger wrote:

> wxwidgets commit 0bf38e1 x04 y axis label is good 
> (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be)
>
> wxwidgets commit 49000def x04 y axis label is false 
> (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3)

Hi Phil:

Assuming (subject to Pedro's further extensive testing) that you have
found a good fix for that bug he had discovered, then the only
remaining potentially release critical issue for the wxwidgets-related
components of PLplot is the issue discovered by Laurent above.

So to learn more about what Laurent reported above,
I described those two commits as follows:

software@raven> git clone https://github.com/wxWidgets/wxWidgets.git wxwidgets.git
software@raven> cd wxwidgets.git
software@raven> git branch
* master
software@raven> git describe 0bf38e1
v3.1.0-620-g0bf38e1
software@raven> git describe 49000def
v3.1.0-621-g49000de

So it is clear from these results that Laurent already bisected this
issue with the 621st commit beyond the last official release (3.1.0)
of wxwidgets showing the issue for the first time.  And since this is
an issue that will not affect any user of an official wxwidgets
release at this time, that gives us a good excuse to do nothing at
this time if the potential fix is going to be intrusive.

Of course, this issue will affect our users as soon as the next
wxwidgets official release is out so it would be nice at this time for
you to (a) confirm the above results for 0bf38e1 and 49000def from
Laurent and figure out what the issue is.  If it turns out to be a
wxwidgets regression introduced for 49000def it would be good for you
to draw this quickly to the attention of the wxwidgets developers so
they can fix that regression before their next official release to
avoid making life difficult for PLplot wxwidgets users.  But if it
turns out to be our problem, then please prepare the fix and use your
best judgement (depending on, e.g., whether the fix is more or less
intrusive than the fix you just made) whether to push it now or wait
until after 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
__________________________

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

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

On 2017-01-04 16:21-0500 Pedro Vicente wrote:

> I did [on CentOS]
> make VERBOSE=1 test_c_wxwidgets >& out.txt &
>
> there were no plots, just black and grey windows that quickly showed and 
> disappeared
>
> output is attached

As you can see for yourself there are no warnings or errors so that
looks promising.  However, you should skim those debug results (which
I did not do myself) to make sure there is nothing unexpected going
on for any of those examples that are run by that test.

Those "black and grey windows" are what I see here as well.  They are
apparently an artifact of the current wxPLViewer implementation where
nothing is displayed for that GUI until the buffer representing all
the plot activity for a particular page has been accumulated, then at
EOP that display is immediately removed again.  That is fine for
normal interactive use where you are clicking on the GUI to move
through the pages.  But the effect for the -np (no pause) option is
the page flashes on the screen for a microsec or so, and you end up
only seeing that weird effect.  If I recall correctly from when I was
testing on -dev wingcc on the Wine version of Windows there was a
similar weird effect with -np there (which was likely due to the same
cause).

As a low-priority item I have asked Phil to fix this -np issue for
-dev wxwidgets by following the buffer models used by -dev xwin, -dev
xcairo, and -dev qtwidget which display the buffer results as they
become available for the test_c_xwin, test_c_xcairo, and
test_c_qtwidget targets rather than waiting until the buffer has been
accumulated for the entire page. But since I plan to greatly improve
the efficiency of the IPC between -dev wxwidgets and wxPLViewer in any
case right after this release I may end up fixing the -np issue myself
at the same time since the two issues are likely closely related.  And
someone should similarly fix -dev wingcc.

But meanwhile even with these weird-looking results for the -np option
for -dev wxwidgets and -dev wingcc, that option is still extremely
useful for the interactive tests associated with building the
test_c_wxwidgets and test_c_wingcc targets because it means you test
several examples (rather than just one or two) for such obvious
run-time issues as segfaults, and you don't have to babysit the test
by constantly clicking on the GUI as the test goes through those
several examples.

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] Linux OnCreate delay bug -- solution

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

Hi Alan

>I think your current CentOS test is equivalent to just
> building the test_wxPLplotDemo target?

yes

>Please extend that test to
> building the test_c_wxwidgets target as well.

I did
make VERBOSE=1 test_c_wxwidgets >& out.txt &

there were no plots, just black and grey windows that quickly showed 
and disappeared

output is attached

-Pedro


On 2017-01-04 14:17, Alan W. Irwin wrote:
> On 2017-01-04 13:04-0500 Pedro Vicente wrote:
>
>> Hi Phil
>>
>> I got a good plot on CentOS, below output.
>> I'll test other Linux later
>
>>
>>> So what I
>>> would propose is that for this release we attempt to not add or 
>>> remove
>>> anything from the API and just stick with an example that  works 
>>> with
>>> what we've got. Then after this release we can add non-template
>>> classes for wxFrame, wxDialog and wxPanel which can be used really
>>> easily by our users and we have time to test them and make sure the
>>> API for their use is stable before the next release.
>>> Does that seem sensible?
>>
>
> To Phil and Pedro:
>
> @Phil:
>
> The test_c_wxwidgets and test_wxPLplotDemo targets worked without
> issues here.  So we now have three good tests on Linux and one good
> test on Windows.  So this indeed seems promising as a solution to
> this release critical bug, and I thank you for this timely
> release-critical bug fixing.
>
> @Both:
>
> To finish off this topic for the release I need some more from both
> of you.
>
> @Phil:
>
> 1. It sounded from your description that you were changing the 
> example
> to try two different methods of generating those plots so it makes
> sense that test_wxPLplotDemo now produces two identical plots for me,
> but please confirm that the two plots I observed are the intended
> effect.
>
> 2. Please commit a change to README.release describing what you have
> done to deal with this bug equivalent to what Pedro wrote up for his
> solution.
>
> @Pedro: I think your current CentOS test is equivalent to just
> building the test_wxPLplotDemo target?  Please extend that test to
> building the test_c_wxwidgets target as well. You were already
> planning to test Phil's solution on all the Linux platforms 
> accessible
> to you, but please do the full test (build both the test_wxPLplotDemo
> and test_c_wxwidgets targets) for all Linux platforms.  And similarly
> for your Windows platforms.  There, the convenient test_* targets
> won't work so you will have to do the equivalent by hand (run
> wxPLplotDemo and run several C examples with -dev wxwidgets). 
> Finally,
> please also test your own software projects that link with the
> plplotwxwidgets library on all platforms where you expect your own
> software projects to currently work.  (I assume that is just Windows,
> but please test on at least one Linux platform as well if you
> expect your software to work on both Windows and Linux.)
>
> Every tested platform that you add gives us just that much further
> confidence that Phil's solution is robust for this release, and I
> thank you in advance for all this essential testing work for our
> 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
> __________________________

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

Re: [Plplot-devel] legend and label using wxWidgets

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

On 2016-12-28 23:19+0100 Laurent Berger wrote:

> wxwidgets commit 0bf38e1 x04 y axis label is good 
> (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be)
>
> wxwidgets commit 49000def x04 y axis label is false 
> (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3)

Hi Phil:

Assuming (subject to Pedro's further extensive testing) that you have
found a good fix for that bug he had discovered, then the only
remaining potentially release critical issue for the wxwidgets-related
components of PLplot is the issue discovered by Laurent above.

So to learn more about what Laurent reported above,
I described those two commits as follows:

software@raven> git clone https://github.com/wxWidgets/wxWidgets.git wxwidgets.git
software@raven> cd wxwidgets.git
software@raven> git branch
* master
software@raven> git describe 0bf38e1
v3.1.0-620-g0bf38e1
software@raven> git describe 49000def
v3.1.0-621-g49000de

So it is clear from these results that Laurent already bisected this
issue with the 621st commit beyond the last official release (3.1.0)
of wxwidgets showing the issue for the first time.  And since this is
an issue that will not affect any user of an official wxwidgets
release at this time, that gives us a good excuse to do nothing at
this time if the potential fix is going to be intrusive.

Of course, this issue will affect our users as soon as the next
wxwidgets official release is out so it would be nice at this time for
you to (a) confirm the above results for 0bf38e1 and 49000def from
Laurent and figure out what the issue is.  If it turns out to be a
wxwidgets regression introduced for 49000def it would be good for you
to draw this quickly to the attention of the wxwidgets developers so
they can fix that regression before their next official release to
avoid making life difficult for PLplot wxwidgets users.  But if it
turns out to be our problem, then please prepare the fix and use your
best judgement (depending on, e.g., whether the fix is more or less
intrusive than the fix you just made) whether to push it now or wait
until after 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
__________________________

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

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

On 2017-01-04 13:04-0500 Pedro Vicente wrote:

> Hi Phil
>
> I got a good plot on CentOS, below output.
> I'll test other Linux later

>
>> So what I
>> would propose is that for this release we attempt to not add or remove
>> anything from the API and just stick with an example that  works with
>> what we've got. Then after this release we can add non-template
>> classes for wxFrame, wxDialog and wxPanel which can be used really
>> easily by our users and we have time to test them and make sure the
>> API for their use is stable before the next release.
>> 
>> Does that seem sensible?
>

To Phil and Pedro:

@Phil:

The test_c_wxwidgets and test_wxPLplotDemo targets worked without
issues here.  So we now have three good tests on Linux and one good
test on Windows.  So this indeed seems promising as a solution to
this release critical bug, and I thank you for this timely
release-critical bug fixing.

@Both:

To finish off this topic for the release I need some more from both
of you.

@Phil:

1. It sounded from your description that you were changing the example
to try two different methods of generating those plots so it makes
sense that test_wxPLplotDemo now produces two identical plots for me,
but please confirm that the two plots I observed are the intended
effect.

2. Please commit a change to README.release describing what you have
done to deal with this bug equivalent to what Pedro wrote up for his
solution.

@Pedro: I think your current CentOS test is equivalent to just
building the test_wxPLplotDemo target?  Please extend that test to
building the test_c_wxwidgets target as well. You were already
planning to test Phil's solution on all the Linux platforms accessible
to you, but please do the full test (build both the test_wxPLplotDemo
and test_c_wxwidgets targets) for all Linux platforms.  And similarly
for your Windows platforms.  There, the convenient test_* targets
won't work so you will have to do the equivalent by hand (run
wxPLplotDemo and run several C examples with -dev wxwidgets). Finally,
please also test your own software projects that link with the
plplotwxwidgets library on all platforms where you expect your own
software projects to currently work.  (I assume that is just Windows,
but please test on at least one Linux platform as well if you
expect your software to work on both Windows and Linux.)

Every tested platform that you add gives us just that much further
confidence that Phil's solution is robust for this release, and I
thank you in advance for all this essential testing work for our
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
__________________________

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

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

Hi Phil

I got a good plot on CentOS, below output.
I'll test other Linux later


12:40:53: Debug: wxPLplotwindow::wxPLplotwindow
12:40:53: Debug: wxPLplotwindow::wxPLplotwindow
12:40:53: Debug: frame->Create
12:40:53: Debug: Plot() Yielding
12:40:53: Debug: wxPLplotwindow::OnCreate
12:40:53: Debug: plD_init_wxwidgets(): enter
12:40:53: Debug: wxPLDevice(): enter
12:40:53: Debug: wxPLDevice(): gc done
12:40:53: Debug: wxPLDevice(): m_interactiveTextGcdc done
12:40:53: Debug: wxPLDevice(): SetDC done
12:40:53: Debug: wxPLDevice(): leave
12:40:53: Debug: plD_init_wxwidgets(): leave
12:40:53: Debug: wxPLplotwindow::OnCreate
12:40:53: Debug: plD_init_wxwidgets(): enter
12:40:53: Debug: wxPLDevice(): enter
12:40:53: Debug: wxPLDevice(): gc done
12:40:53: Debug: wxPLDevice(): m_interactiveTextGcdc done
12:40:53: Debug: wxPLDevice(): SetDC done
12:40:53: Debug: wxPLDevice(): leave
12:40:53: Debug: plD_init_wxwidgets(): leave
12:40:54: Debug: Plot()
12:40:54: Debug: Plot()

>So what I
> would propose is that for this release we attempt to not add or 
> remove
> anything from the API and just stick with an example that  works with
> what we've got. Then after this release we can add non-template
> classes for wxFrame, wxDialog and wxPanel which can be used really
> easily by our users and we have time to test them and make sure the
> API for their use is stable before the next release.
>
> Does that seem sensible?


yes, sounds good, thanks
-Pedro



On 2017-01-04 09:26, Phil Rosenberg wrote:
> Hi All
>
> Right I'm back with sensible access to all my systems and back into 
> my
> usual routine.
>
> So, here goes
>
> On 28 December 2016 at 05:00, Pedro Vicente
> <ped...@sp...> wrote:
>> One small caveat is that I think you can only instantiate the 
>> template with
>> a class that has this Create()
>> signature
>>
>> Create(wxWindow *parent, wxWindowID id, const wxString& title, const
>> wxPoint& pos, const wxSize& size, long style, const wxString& name)
>>
>> which is of course , wxFrames, the current use.
>> Probably dialogs too, but maybe not things like buttons and other 
>> GUI
>> elements.
>> But I assume that the vast majority of users, if not all, draws the 
>> plot in
>> "regular" windows?.
>
> You are indeed correct about this. The other very major category that
> I think doesn't have this signature is wxPanels and we absolutely 
> must
> maintain compatibility for this class. In fact it is more important
> for this class than any other, because you could create always create
> a wxPanel and put it as the only element of a wxFrame, wxDialog,
> wxPage etc
>
> So what I have done is modify the example so that we now generate two
> wxFrames with identical plots, but in slightly different ways.
>
> In one I have used the wxPlDemoFrame and moved most of the
> initialisation code into its constructor and then this frame is set 
> up
> to capture idle events. When it captures idle events it checks
> everything is ready and calls Plot() (setting a flag so this only
> happens once).
>
> In the other I show how a frame can be created without using
> inheritance, with the caveat that Show() must be called and we must
> then wait for the wxEVT_CREATE event to be processed before we do any
> plotting.
>
> If I have this right then these methods should be totally general and
> should allow any of the constructors for any of the different 
> wxWindow
> derived classes to be used. Which is good.
>
> However, you are very correct Pedro that mostly people are likely to
> want to derive from classes such as wxFrame, wxDialog and wxPanel. I
> think it makes sense to create those classes for our users so that
> they can use those in as few lines of code as possible. So what I
> would propose is that for this release we attempt to not add or 
> remove
> anything from the API and just stick with an example that  works with
> what we've got. Then after this release we can add non-template
> classes for wxFrame, wxDialog and wxPanel which can be used really
> easily by our users and we have time to test them and make sure the
> API for their use is stable before the next release.
>
> Does that seem sensible?
>
> So I have just committed the changes I mentioned above. Pedro and
> Alan, if you have time to test them on your Linux systems that would
> be good. I've tested on my Windows system and I'm about to do so on 
> my
> Linux system too.
>
> Phil

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

Re: [Plplot-devel] Using wxWidgets

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

Hello Laurent
If you grab the latest version of PLPlot from the git repo then you
should find that the API for wxWidgets is as it was and Pedro's
problems are now hopefully also fixed. There should be no need to
apply Pedro's patch.

If you find that your existing code does not work for any reason then
please let me know and I will ensure that this is fixed before the
next release.


All the best

Phil

On 27 December 2016 at 15:27, Laurent Berger
<lau...@un...> wrote:
> Problem is my compiler said
>
> 3>c:\users\laurent.pc-laurent-visi\documents\visual studio
> 2013\wxopencv\wxopencvmain\courbeplplot.h(55): error C2059: syntax error
>
> Now syntax error I need two days to change my code. It was like this in
> previous version of plplot. I don't remember 5.xx.xx. I don't wan't to go
> back in my code. I will use 5.11.1
>
> yes
>
> but for the current (5.11.1) release compared to the new implemented
> examples,
> the effect is the same
>
> previously the way to start the demo was
>
> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>
> and now is
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>
> and because wxPLplotwindow is a child of a wxFrame,
> the visible effect is exactly the same, a frame window that shows a
> plot.
>
> -Pedro
>
>
> Le 27/12/2016 à 16:11, Pedro Vicente a écrit :
>
> Laurent
>
> I have installed last version of plplot and last patch (from pedro).
> Can
> you confirm me that wxPLplotwindow is now a non template  class?
>
> yes, that is correct.
>
> -Pedro
>
>
> On 2016-12-27 10:04, Laurent Berger wrote:
>
> Hi,
>
> I have installed last version of plplot and last patch (from pedro).
> Can
> you confirm me that wxPLplotwindow is now a non template  class?
>
> thanks for yours answers
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

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

Just to add that I've just tested on my Ubuntu 16.04 system logging on
remotely using Cygwin ssh and X11 server and n my work CentOS system
logging on directly. Everything seems fine! Hopefully you will both
get the same results Pedro and Alan.

Phil

On 4 January 2017 at 14:26, Phil Rosenberg <p.d...@gm...> wrote:
> Hi All
>
> Right I'm back with sensible access to all my systems and back into my
> usual routine.
>
> So, here goes
>
> On 28 December 2016 at 05:00, Pedro Vicente
> <ped...@sp...> wrote:
>> One small caveat is that I think you can only instantiate the template with
>> a class that has this Create()
>> signature
>>
>> Create(wxWindow *parent, wxWindowID id, const wxString& title, const
>> wxPoint& pos, const wxSize& size, long style, const wxString& name)
>>
>> which is of course , wxFrames, the current use.
>> Probably dialogs too, but maybe not things like buttons and other GUI
>> elements.
>> But I assume that the vast majority of users, if not all, draws the plot in
>> "regular" windows?.
>
> You are indeed correct about this. The other very major category that
> I think doesn't have this signature is wxPanels and we absolutely must
> maintain compatibility for this class. In fact it is more important
> for this class than any other, because you could create always create
> a wxPanel and put it as the only element of a wxFrame, wxDialog,
> wxPage etc
>
> So what I have done is modify the example so that we now generate two
> wxFrames with identical plots, but in slightly different ways.
>
> In one I have used the wxPlDemoFrame and moved most of the
> initialisation code into its constructor and then this frame is set up
> to capture idle events. When it captures idle events it checks
> everything is ready and calls Plot() (setting a flag so this only
> happens once).
>
> In the other I show how a frame can be created without using
> inheritance, with the caveat that Show() must be called and we must
> then wait for the wxEVT_CREATE event to be processed before we do any
> plotting.
>
> If I have this right then these methods should be totally general and
> should allow any of the constructors for any of the different wxWindow
> derived classes to be used. Which is good.
>
> However, you are very correct Pedro that mostly people are likely to
> want to derive from classes such as wxFrame, wxDialog and wxPanel. I
> think it makes sense to create those classes for our users so that
> they can use those in as few lines of code as possible. So what I
> would propose is that for this release we attempt to not add or remove
> anything from the API and just stick with an example that  works with
> what we've got. Then after this release we can add non-template
> classes for wxFrame, wxDialog and wxPanel which can be used really
> easily by our users and we have time to test them and make sure the
> API for their use is stable before the next release.
>
> Does that seem sensible?
>
> So I have just committed the changes I mentioned above. Pedro and
> Alan, if you have time to test them on your Linux systems that would
> be good. I've tested on my Windows system and I'm about to do so on my
> Linux system too.
>
> Phil

Re: [Plplot-devel] Linux OnCreate delay bug -- solution

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

Hi All

Right I'm back with sensible access to all my systems and back into my
usual routine.

So, here goes

On 28 December 2016 at 05:00, Pedro Vicente
<ped...@sp...> wrote:
> One small caveat is that I think you can only instantiate the template with
> a class that has this Create()
> signature
>
> Create(wxWindow *parent, wxWindowID id, const wxString& title, const
> wxPoint& pos, const wxSize& size, long style, const wxString& name)
>
> which is of course , wxFrames, the current use.
> Probably dialogs too, but maybe not things like buttons and other GUI
> elements.
> But I assume that the vast majority of users, if not all, draws the plot in
> "regular" windows?.

You are indeed correct about this. The other very major category that
I think doesn't have this signature is wxPanels and we absolutely must
maintain compatibility for this class. In fact it is more important
for this class than any other, because you could create always create
a wxPanel and put it as the only element of a wxFrame, wxDialog,
wxPage etc

So what I have done is modify the example so that we now generate two
wxFrames with identical plots, but in slightly different ways.

In one I have used the wxPlDemoFrame and moved most of the
initialisation code into its constructor and then this frame is set up
to capture idle events. When it captures idle events it checks
everything is ready and calls Plot() (setting a flag so this only
happens once).

In the other I show how a frame can be created without using
inheritance, with the caveat that Show() must be called and we must
then wait for the wxEVT_CREATE event to be processed before we do any
plotting.

If I have this right then these methods should be totally general and
should allow any of the constructors for any of the different wxWindow
derived classes to be used. Which is good.

However, you are very correct Pedro that mostly people are likely to
want to derive from classes such as wxFrame, wxDialog and wxPanel. I
think it makes sense to create those classes for our users so that
they can use those in as few lines of code as possible. So what I
would propose is that for this release we attempt to not add or remove
anything from the API and just stick with an example that  works with
what we've got. Then after this release we can add non-template
classes for wxFrame, wxDialog and wxPanel which can be used really
easily by our users and we have time to test them and make sure the
API for their use is stable before the next release.

Does that seem sensible?

So I have just committed the changes I mentioned above. Pedro and
Alan, if you have time to test them on your Linux systems that would
be good. I've tested on my Windows system and I'm about to do so on my
Linux system too.

Phil

[Plplot-devel] git blog

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

I use this subject line for git topics I want to discuss, and I
encourage others to do the same as they continue (along with me) to
learn more about git.

As you are probably aware from my recent discussions with Pedro I
recommend using

git commit --amend

if your changes continue for exactly the same topic, i.e., your
commits would otherwise be a series of approximations to the final
commit version (e.g., for dealing with a particular bug).

Currently I am using the above git command a lot for my topic branch
for a large update to our DocBook documentation. However, I noticed
from "git log" results that the author date was stuck on November
30th, i.e., when I started making this series of amended commits, and
instead I want the author date to correspond to when I finish this
series of amended commits.  (Which should happen "real soon now".  :-) )

One google search later (using the search terms <git commit amend
author date>) I found
<http://stackoverflow.com/questions/9110310/update-git-commit-author-date-when-amending>
and tried one suggestion that looked promising there which was

git commit --amend --reset-author

Since the author is the same (me) nothing happens due to this command
other than the desired side effect that the author date becomes
current again.  Anyhow, this suggestion worked like a charm!

So I ended up resolving the issue in 5 minutes which is an
illustration of the fact that there are huge numbers of expert git
users out there willing to share their knowledge, and google is your
friend for quickly finding this expert knowledge on any git topic.

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] wxwidgets-related dependencies

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

Hi Alan
I don't know enough about cmake and how it creates visual studio projects/solutions to know what will work.

All I know is that cmake generates a visual studio solution, which when opened in visual studio contains multiple projects, one for each target (library and executable) and some others for executing other commands or bulk builds such as ALL and INSTALL. I can right click any of these and hit build, to build just that project. Or for the executable ones I can right click them and hit debug to run them in the debugger. If I right click a library project and hit debug then I just get an error. From memory there is a property like “debug target” that must be set and I think for executables it defaults to the build target, whereas for libraries it is blank.

Just setting a command to execute at the end of a build wouldn't do the job as it wouldn't run in the debugger, which is often the aim.

I'm not sure what is so bad about setting the viewer as a dependency of the examples?

Anyway, you know the issue and you know cmake way better than me so just go for it and we can see how it works.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 29 December 2016 18:30
To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list
Subject: RE: wxwidgets-related dependencies

On 2016-12-29 08:47-0000 p.d...@gm... wrote:

> Hi Alan

> I'm not sure if that [test_x00c_wxPLViewer, etc. targets] would
work. If I execute (I.e. Run or debug) that project, would it run the
example?

Hi Phil:

If the custom target has no associated COMMAND, what should happen is
instead of clicking on the all button to rebuild everything, you would
be clicking on the test_x00c_wxPLViewer, etc., buttons to rebuild just
the subset of the project that you need. In other words, that should
completely satisfy the limited rebuild need you expressed.

However, there is a bigger possibility here as well which is to use
COMMAND see
<https://cmake.org/cmake/help/latest/command/add_custom_target.html>
to actually execute the example appropriately after the rebuilds when
you click on test_x00c_wxPLViewer, etc.  I can guarantee this approach
(building all prerequisites then running the appropriate C standard
example using -dev wxwidgets) will work on the command line with Unix
shell and make when you build one of the test_x00c_wxPLViewer, etc.
targets, and I am virtually positive it will also work with Windows
CMD and nmake as well. But we don't really know whether that bigger
possibility would work with your particular IDE until we try it. So
after the release when we both will have more time for this, we should
do some joint experiments both with nmake and your IDE to figure out
what is most useful to you and other Windows developers/testers.

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] legend and label using wxWidgets

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

On 2016-12-29 08:50-0000 p.d...@gm... wrote:

> Hi Alan

> Theose are wxWidgets commits from the wxWidgets repo. WxWidgets have
made a change which I presume has exposed a bug in our code (or maybe
there is a bug in their code, but I think that's less likely).

@Laurent:
Oops!  Sorry for misreading your post.

@Phil and Laurent:

My comment about git bisect still stands, but in this case the idea
would be to find the first WxWidgets commit that generates bad results
for PLplot.  Of course, that means for each bisect iteration you would
be rebuilding both WxWidgets and PLplot, but bisection is terrifically
efficient so you would likely end up doing those builds less than 10
times.

Once you know that WxWidgets commit that generates the issue for the
first time, then you might be able to tell a lot more from the
associated commit message to help you figure out whether this is a
WxWidgets bug, a WxWidgets change that exposes a PLplot bug, or
deliberate or accidental WxWidgets API breakage (e.g., changing the
semantics of one or more WxWidgets function arguments).

Anyhow, good luck on this hunt for the cause of the issue.

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] wxwidgets-related dependencies

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

On 2016-12-29 08:47-0000 p.d...@gm... wrote:

> Hi Alan

> I'm not sure if that [test_x00c_wxPLViewer, etc. targets] would
work. If I execute (I.e. Run or debug) that project, would it run the
example?

Hi Phil:

If the custom target has no associated COMMAND, what should happen is
instead of clicking on the all button to rebuild everything, you would
be clicking on the test_x00c_wxPLViewer, etc., buttons to rebuild just
the subset of the project that you need. In other words, that should
completely satisfy the limited rebuild need you expressed.

However, there is a bigger possibility here as well which is to use
COMMAND see
<https://cmake.org/cmake/help/latest/command/add_custom_target.html>
to actually execute the example appropriately after the rebuilds when
you click on test_x00c_wxPLViewer, etc.  I can guarantee this approach
(building all prerequisites then running the appropriate C standard
example using -dev wxwidgets) will work on the command line with Unix
shell and make when you build one of the test_x00c_wxPLViewer, etc.
targets, and I am virtually positive it will also work with Windows
CMD and nmake as well. But we don't really know whether that bigger
possibility would work with your particular IDE until we try it. So
after the release when we both will have more time for this, we should
do some joint experiments both with nmake and your IDE to figure out
what is most useful to you and other Windows developers/testers.

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] An alternative idea for comprehensive testing of MSVC + ifort

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, December 22, 2016 7:31 PM
>
>
> I am pretty confident this approach would work because it is equivalent to the
> approach I used to take for testing the old MinGW (without old MSYS) build that
> used the "MinGW Makefiles" generator on the Wine version of Windows. All those
> tests were done from a CMD environment using the old MinGW make command
> (mingw32-make.exe) but with the old MSYS bin directory on the PATH to give
> access to the Unix tools needed for the tests (but avoiding using those tools for the
> build itself).  So I don't see why you cannot do the same with nmake.exe replacing
> mingw32-make.exe.
>
> In sum, I recommend you take another serious look at this general approach (with
> Unix tools used just for testing but expressly not used for the build) the next time
> (likely in 2017) that you have a chance to work on PLplot testing on the MSVC +
> ifort build platform.
>


I just finished cleaning up my batch file for running the examples under Windows and writing a dedicated comparison program (see my commit). The reason for writing this little program - which does no more than check if the contents of the files are identical, not much else, no indication of where things differ - was that my console froze when I tried to run the diff command (and several others) outside the MinGW-w64/MSYS2 shell.

I am not sure it is completely impossible, but it was simpler to write this little program than to hunt for the right magic incantation.

The script can easily be extended with any of the other programming languages - I have now included C++, Fortran and Tcl only. For these the results are as identical with the C ones as we want ;).

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] legend and label using wxWidgets

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

Hi Alan
Theose are wxWidgets commits from the wxWidgets repo. WxWidgets have made a change which I presume has exposed a bug in our code (or maybe there is a bug in their code, but I think that's less likely).

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 29 December 2016 00:48
To: Laurent Berger; Phil Rosenberg; Pedro Vicente; PLplot development list
Subject: Re: [Plplot-devel] legend and label using wxWidgets

On 2016-12-28 23:19+0100 Laurent Berger wrote:

> wxwidgets commit 0bf38e1 x04 y axis label is good 
> (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be)
>
> wxwidgets commit 49000def x04 y axis label is false 
> (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3)

Hi Laurent:

The github repositories for PLplot are experimental.  Therefore,
please use official PLplot resources (your local git repository that has been
cloned from our official SF repository) to do tests and describe the
resulting commits. For example those two commits do not even exist on
our SF repository so something different has occurred on the
experimental github version you have been testing with, and that adds
an element of uncertainty to your results.

If you get to a similar result for the official version (one commit
good, the other not) that, of course, would be an extremely useful
result to us for figuring out what is going wrong here for you.  But
if you haven't done so already, I would follow up with git bisect to
find the first commit that generates the bad result.  And if you
haven't run "git bisect" before, it is actually a lot of fun, and "git
help bisect" gives you all the information you need to run it.

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
__________________________