plplot-devel — Technical discussion about PLplot development

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

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

Alan

All my linux failures were on 3 different "real" machines (CentOS with 
personal wxwidgets 3.1 build, 2 ubuntus 14.04 16.4 from packages)

the 4th linux failure was on a debian I installed on VirtualBox.
So, it's not a VirtualBox issue.
-Pedro


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


> On 2016-12-15 17:19-0500 Pedro Vicente wrote:
>
>> Hi Phil
>>
>>
>>>> I can't help feeling that there is something that we are missing here.
>>>> Given both I and Pedro have tested on Ubuntu 14.04 there must be
>>>> something different between the two systems.
>>
>> it seems so.
>> the only way to be sure is that on your side to install a completely new 
>> Ubuntu, or Debian on VirtualBox, and then do
>>
>> sudo apt-get install libwxgtk3.0-dev
>>
>> VirtualBox can be installed on Windows or Mac (this is called the host 
>> system).
>> I am running it on my Windows machine and I have three linux installed on 
>> it , ubuntu, centos, debian
>
> @ Phil and Pedro:
>
> I am beginning to wonder whether something that is being done
> differently but legitimately by VirtualBox is highlighting some subtle
> bug we have in the Linux wxwidgets code that doesn't happen to show any 
> symptoms for the non-VirtualBox'd case.
>
> @Phil:
>
> I am just going to go ahead and merge Pedro's patch (once he gets it
> to me in "git format-patch" form) to SF master since it apparently
> solves his "VirtualBox" issue (if we can call it that) without messing
> up the Linux success we have on non-VirtualBox'ed Linux.  But if you
> have any qualms about his changes, feel free to either contact me
> immediately (if you are not sleeping now) or ask me to revert my merge
> of his work tomorrow.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

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

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

Unfortunately I don't think I have enough space to install virtualbox.
I presume I need a few 10s of GB for an Ubuntu install?

I have also just tried on the Bash on Ubuntu on Windows (still trying
to decide if I like this or Cygwin best. Anyway...). Again everything
works fine on this (I'm using Xming for my X server).

Is there something different with the X server or something in a
VirtualBox install?

I suspect that you are correct Alan and this is a subtle VitualBox
thing. We should create a minimum working example of a wxFrame using
the two stage creation totally independent of plplot and see if this
works. If it doesn't then we know this is a VirtualBox/wxWidgets bug.
If it does then we can start adding complexity to find where it
breaks.

On 16 December 2016 at 00:05, Alan W. Irwin <ir...@be...> wrote:
> On 2016-12-15 17:19-0500 Pedro Vicente wrote:
>
>> Hi Phil
>>
>>
>>>> I can't help feeling that there is something that we are missing here.
>>>> Given both I and Pedro have tested on Ubuntu 14.04 there must be
>>>> something different between the two systems.
>>
>>
>> it seems so.
>> the only way to be sure is that on your side to install a completely new
>> Ubuntu, or Debian on VirtualBox, and then do
>>
>> sudo apt-get install libwxgtk3.0-dev
>>
>> VirtualBox can be installed on Windows or Mac (this is called the host
>> system).
>> I am running it on my Windows machine and I have three linux installed on
>> it , ubuntu, centos, debian
>
>
> @ Phil and Pedro:
>
> I am beginning to wonder whether something that is being done
> differently but legitimately by VirtualBox is highlighting some subtle
> bug we have in the Linux wxwidgets code that doesn't happen to show any
> symptoms for the non-VirtualBox'd case.
>
> @Phil:
>
> I am just going to go ahead and merge Pedro's patch (once he gets it
> to me in "git format-patch" form) to SF master since it apparently
> solves his "VirtualBox" issue (if we can call it that) without messing
> up the Linux success we have on non-VirtualBox'ed Linux.  But if you
> have any qualms about his changes, feel free to either contact me
> immediately (if you are not sleeping now) or ask me to revert my merge
> of his work tomorrow.
>
>
> 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] plbuffer bug

[Jim D. <ji...@di...>]

> On Dec 15, 2016, at 5:59 PM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2016-12-15 20:38-0000 Phil Rosenberg wrote:
>> 
>> The problem is that text is written and read in "device native"
>> encoding (i.e. Unicode or ascii) so if a buffer is copied from a
>> Unicode device to an ascii one then the plreplot call will hit a
>> problem with buffer reading and call plexit. The solution would be to
>> always write Unicode or to add a flag to indicate the encoding in the
>> buffer. If anyone has a preference then let me know.
> 
> Hi Phil:
> 
> Thanks for bringing this potentially nasty issue to our attention,
> and I agree with your judgement this is an issue that should be
> tackled after the release.
> 
> To answer your question for when you do work on this, if I recall
> correctly, user-specified strings which are assumed to be written in
> the UTF-8 encoding (which includes ascii) of unicode are uniformly
> translated to a modified UCS4 (32-bit) unicode encoding for internal
> PLplot use where the modifications include the possibility of
> embedding 32-bit FCI (font characterization integer) words (to change
> some font characteristic in mid string) in the middle of the modified
> UCS4 arrays.  I also recall (but haven't checked to be sure) that
> right now that if the device cannot handle
> unicode, then we store the text information in an entirely different
> array which is 4 times shorter.
> 
> But I would strongly prefer instead that we move to always using the
> modified UCS4 array for text with the ascii-only devices using a core
> function to convert that back to an ascii string (with appropriate
> filtering when the UCS4 array contains an FCI or a 32-bit
> representation of a non-ascii glyph) for their own text plotting.  The
> big advantage of this approach is our text handling then automatically
> becomes greatly simplified/much less confusing to understand.  The
> downside, of course, is UCS4 is 4 times larger than the equivalent
> ascii (for those cases when the pure ascii subset of UTF-8 is used by
> our users).  However, I think pure ascii use is becoming rarer and
> rarer (especially for scientific plotting where many Unicode math
> symbols are typically used in labels).  So instead of using our own
> (incredibly inefficient) "#[nnn]" unicode encoding that keeps users
> strings strictly in ascii, users now tend to just cut and paste the
> UTF-8 math symbol they need into their PLplot text string with
> some very nice results for our modern (unicode-aware) devices.
> 
> So assuming that is a correct summary of the present text situation,
> and we also decide to make the simplifying code modification I
> strongly suggest above, then obviously the modified UCS4 array that
> will then always contain the text information should be included in
> the buffer.
> 

Oops. I didn't think of that when I implemented the buffer awhile back. It probably would be best to have an encoding flag because if the library is compiled without unicode support, I think forcing Unicode could cause problems. 

My goof, so I can try my hand at a patch, but it will be after the freeze. 

> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

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

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

> Hi Phil
>
>
>>> I can't help feeling that there is something that we are missing here.
>>> Given both I and Pedro have tested on Ubuntu 14.04 there must be
>>> something different between the two systems.
>
> it seems so.
> the only way to be sure is that on your side to install a completely new 
> Ubuntu, or Debian on VirtualBox, and then do
>
> sudo apt-get install libwxgtk3.0-dev
>
> VirtualBox can be installed on Windows or Mac (this is called the host 
> system).
> I am running it on my Windows machine and I have three linux installed on it 
> , ubuntu, centos, debian

@ Phil and Pedro:

I am beginning to wonder whether something that is being done
differently but legitimately by VirtualBox is highlighting some subtle
bug we have in the Linux wxwidgets code that doesn't happen to show 
any symptoms for the non-VirtualBox'd case.

@Phil:

I am just going to go ahead and merge Pedro's patch (once he gets it
to me in "git format-patch" form) to SF master since it apparently
solves his "VirtualBox" issue (if we can call it that) without messing
up the Linux success we have on non-VirtualBox'ed Linux.  But if you
have any qualms about his changes, feel free to either contact me
immediately (if you are not sleeping now) or ask me to revert my merge
of his work tomorrow.

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] Recruiting members of the core development team

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

Hi Alan

> we frankly do like to
> recruit new and energetic core development help for our favourite
> software project) ask you to become a core PLplot developer with "git
> push" privileges.

yes , I would like to be a core PLplot developer .
I intend to use PLplot on a major project and there are some features that I 
would like to add probably (I'll elaborate another day).

I did what the README file said and here it is my first patch attached:-)

what it has it's *just* some print messages (not my fix yet) so that you and 
Phil could get a better idea of the bug

I have

17:57:49: Debug: wxPLplotwindow::wxPLplotwindow
17:57:49: Debug: frame->Create
17:57:49: Debug: pls NULL
17:57:49: Debug: wxPLplotwindow::RenewPlot
17:57:49: Debug: wxPLplotwindow::OnCreate
17:57:49: Debug: wxPLplotwindow::RenewPlot

so this clearly shows that the stream is NULL on my linux build

-Pedro


----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: "PLplot development list" <Plp...@li...>
Sent: Thursday, December 15, 2016 6:22 PM
Subject: Recruiting members of the core development team


> On 2016-12-15 16:39-0500 Pedro Vicente wrote:
>
>> do I have git permissions to do
>> git commit
>> git push
>> ?
>
> Hi Pedro:
>
> I am putting your good general question above on the list so others can
> share my answer.  Of course, you always have git commit privileges
> on your local cloned PLplot repository.  So the fundamental question
> is about "git push".
>
> First we would like to get some experience with you contributing to
> PLplot using the "git format-patch" (you) and "git am" (me or some
> other core team member) approach.  But if you continue to make
> contributions in that form that we like, then we will certainly
> (probably sooner rather than later because we frankly do like to
> recruit new and energetic core development help for our favourite
> software project) ask you to become a core PLplot developer with "git
> push" privileges.
>
> If you would like to see who is a core team member now, take a look at
> <https://sourceforge.net/p/plplot/_members/>.  From git log results
> you will find that some of them are no longer active and are only core
> team members to acknowledge their past contributions to PLplot.
>
> 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] build plplot using CMAKE using MSYS makefiles on windows 10

[Greg J. <gv...@gm...>]

So I found a reference to the discussion about the unicode patching in wx:
https://groups.google.com/forum/#!topic/wx-dev/MTYzgOqLdfU

And here is discussion on including the replacement file in MSYS2:

https://github.com/Alexpux/MINGW-packages/pull/727

On Thu, Dec 15, 2016 at 2:40 PM, Greg Jung <gv...@gm...> wrote:

>
>
> On Tue, Dec 13, 2016 at 2:13 AM, Laurent Berger <
> lau...@un...> wrote:
>
>> Thanks Greg,
>>
>> with your patch linking problem is solved. Can you post an answer in this
>> question https://forums.wxwidgets.org/viewtopic.php?f=19&t=42882&p=17
>> 4262#p174262
>>
>>
>> https://github.com/maynardGK/wxWidgets/commit/
> cb28fe5c5c49be4467a5d044f6fa4f7885972931
>
> I first submitted the patch in github around jul 30, 2015 and it went to a
> discussion somewhere in the bowels of the wxwidgets,  where after several
> back-and-forth about what the issue was, the wx guy decided it was
> "worthwhile"
> to consider a fix of somesort - or maybe he just wanted to leave that
> impression so I would stop replying.  I also suggested it be included in
> the MSYS2 repo mash-up but since it was no one else's problem, evidently
> not worthy.
> So providing me another example of the fuitility of propogating patches
> into a well-worn package.
>
>> Now there is still a problem in cmake process because I have to modify
>> file plplot\buildmingw64\examples\c++\CMakeFiles\wxPLplotDemo.dir\linklibs.rsp
>> to link wxPlplotDemo
>>
>> in this file I have changed all  /f/lib/wxWidgets-3.1.0 in
>> f:/lib/wxWidgets-3.1.0. May be it is not a bug in plot cmake but in cmake.
>>
>>
>> Yes the references in the .rsp file are in native format for me because I
> have edited the wxconfig file as follows:
>
>> # Determine the base directories we require.
>>
>> prefix=${input_option_prefix-${this_prefix:-/mingw32}}
>>
>> if [ "x${MSYSTEM}" = "xMINGW32" ] || [ "x${MSYSTEM}" = "xMINGW64" ]; then
>>
>>     prefix=$(cygpath -m ${prefix})
>>
>> fi
>>
>> exec_prefix=${input_option_exec_prefix-${input_option_
>>> prefix-${this_exec_prefix:-${prefix}}}}
>>
>> wxconfdir="${exec_prefix}/lib/wx/config"
>>
>>

[Plplot-devel] Recruiting members of the core development team

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

On 2016-12-15 16:39-0500 Pedro Vicente wrote:

> do I have git permissions to do
> git commit
> git push
> ?

Hi Pedro:

I am putting your good general question above on the list so others can
share my answer.  Of course, you always have git commit privileges
on your local cloned PLplot repository.  So the fundamental question
is about "git push".

First we would like to get some experience with you contributing to
PLplot using the "git format-patch" (you) and "git am" (me or some
other core team member) approach.  But if you continue to make
contributions in that form that we like, then we will certainly
(probably sooner rather than later because we frankly do like to
recruit new and energetic core development help for our favourite
software project) ask you to become a core PLplot developer with "git
push" privileges.

If you would like to see who is a core team member now, take a look at
<https://sourceforge.net/p/plplot/_members/>.  From git log results
you will find that some of them are no longer active and are only core
team members to acknowledge their past contributions to PLplot.

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] plbuffer bug

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

On 2016-12-15 20:38-0000 Phil Rosenberg wrote:

> Hi All
> I've just posted a bug to the bug tracker regarding  the buffer.
>
> I just wanted to send an email out to say that I don't particularly
> intend to fix it before the freeze as I don't think there is time. But
> I wanted to stick it on the tracker so it didn't get forgotten.
>
> The problem is that text is written and read in "device native"
> encoding (i.e. Unicode or ascii) so if a buffer is copied from a
> Unicode device to an ascii one then the plreplot call will hit a
> problem with buffer reading and call plexit. The solution would be to
> always write Unicode or to add a flag to indicate the encoding in the
> buffer. If anyone has a preference then let me know.

Hi Phil:

Thanks for bringing this potentially nasty issue to our attention,
and I agree with your judgement this is an issue that should be
tackled after the release.

To answer your question for when you do work on this, if I recall
correctly, user-specified strings which are assumed to be written in
the UTF-8 encoding (which includes ascii) of unicode are uniformly
translated to a modified UCS4 (32-bit) unicode encoding for internal
PLplot use where the modifications include the possibility of
embedding 32-bit FCI (font characterization integer) words (to change
some font characteristic in mid string) in the middle of the modified
UCS4 arrays.  I also recall (but haven't checked to be sure) that
right now that if the device cannot handle
unicode, then we store the text information in an entirely different
array which is 4 times shorter.

But I would strongly prefer instead that we move to always using the
modified UCS4 array for text with the ascii-only devices using a core
function to convert that back to an ascii string (with appropriate
filtering when the UCS4 array contains an FCI or a 32-bit
representation of a non-ascii glyph) for their own text plotting.  The
big advantage of this approach is our text handling then automatically
becomes greatly simplified/much less confusing to understand.  The
downside, of course, is UCS4 is 4 times larger than the equivalent
ascii (for those cases when the pure ascii subset of UTF-8 is used by
our users).  However, I think pure ascii use is becoming rarer and
rarer (especially for scientific plotting where many Unicode math
symbols are typically used in labels).  So instead of using our own
(incredibly inefficient) "#[nnn]" unicode encoding that keeps users
strings strictly in ascii, users now tend to just cut and paste the
UTF-8 math symbol they need into their PLplot text string with
some very nice results for our modern (unicode-aware) devices.

So assuming that is a correct summary of the present text situation,
and we also decide to make the simplifying code modification I
strongly suggest above, then obviously the modified UCS4 array that
will then always contain the text information should be included in
the buffer.

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] build plplot using CMAKE using MSYS makefiles on windows 10

[Greg J. <gv...@gm...>]

On Tue, Dec 13, 2016 at 2:13 AM, Laurent Berger <
lau...@un...> wrote:

> Thanks Greg,
>
> with your patch linking problem is solved. Can you post an answer in this
> question https://forums.wxwidgets.org/viewtopic.php?f=19&t=42882&p=
> 174262#p174262
>
>
>
https://github.com/maynardGK/wxWidgets/commit/cb28fe5c5c49be4467a5d044f6fa4f7885972931

I first submitted the patch in github around jul 30, 2015 and it went to a
discussion somewhere in the bowels of the wxwidgets,  where after several
back-and-forth about what the issue was, the wx guy decided it was
"worthwhile"
to consider a fix of somesort - or maybe he just wanted to leave that
impression so I would stop replying.  I also suggested it be included in
the MSYS2 repo mash-up but since it was no one else's problem, evidently
not worthy.
So providing me another example of the fuitility of propogating patches
into a well-worn package.

> Now there is still a problem in cmake process because I have to modify
> file plplot\buildmingw64\examples\c++\CMakeFiles\wxPLplotDemo.dir\linklibs.rsp
> to link wxPlplotDemo
>
> in this file I have changed all  /f/lib/wxWidgets-3.1.0 in
> f:/lib/wxWidgets-3.1.0. May be it is not a bug in plot cmake but in cmake.
>
>
> Yes the references in the .rsp file are in native format for me because I
have edited the wxconfig file as follows:

> # Determine the base directories we require.
>
> prefix=${input_option_prefix-${this_prefix:-/mingw32}}
>
> if [ "x${MSYSTEM}" = "xMINGW32" ] || [ "x${MSYSTEM}" = "xMINGW64" ]; then
>
>     prefix=$(cygpath -m ${prefix})
>
> fi
>
>
>> exec_prefix=${input_option_exec_prefix-${input_option_prefix-${this_exec_prefix:-${prefix}}}}
>
> wxconfdir="${exec_prefix}/lib/wx/config"
>
>

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

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

Hi Phil


>>I can't help feeling that there is something that we are missing here.
>>Given both I and Pedro have tested on Ubuntu 14.04 there must be
>>something different between the two systems.

it seems so.
the only way to be sure is that on your side to install a completely new 
Ubuntu, or Debian on VirtualBox, and then do

sudo apt-get install libwxgtk3.0-dev

VirtualBox can be installed on Windows or Mac (this is called the host 
system).
I am running it on my Windows machine and I have three linux installed on it 
, ubuntu, centos, debian

-Pedro




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


> Hi Pedro, Alan
> I'm still unable to reproduce the problem on my Ubuntu 14.04 system
> with wxWidgets 3.0. Very strange. I have tried a totally fresh build
> directory and static and dynamic builds.
>
> I had forgotten to test on my work CentOS PC and although I know it is
> powered on I can't ssh into it. I'm not sure why. I will test it when
> I get in tomorrow.
>
> I can't help feeling that there is something that we are missing here.
> Given both I and Pedro have tested on Ubuntu 14.04 there must be
> something different between the two systems.
>
> Phil
>
> On 15 December 2016 at 15:22, Pedro Vicente
> <ped...@sp...> wrote:
>> Hi Alan
>>
>> I installed the latest from the debian site, here
>>
>> https://www.debian.org/distrib/
>>
>> it's not surprising that I got the same results in ubuntu because I used 
>> the
>> same package
>>
>> sudo apt-get install libwxgtk3.0-dev
>>
>>
>>
>>
>> On 2016-12-15 04:32, Alan W. Irwin wrote:
>>>
>>> On 2016-12-15 01:11-0500 Pedro Vicente wrote:
>>>
>>>> Hi Alan
>>>>
>>>> I just installed the latest debian on VirtualBox, and I get the same
>>>> errors.
>>>> the results are attached, same thing that I did for ubuntu.
>>>
>>>
>>> Hi Pedro:
>>>
>>> Just for the record, what version of Debian?
>>>
>>> Currently Jessie = stable (a largely frozen release from two years
>>> ago), Stretch = testing (a rolling release not as stable as stable),
>>> and Sid = unstable (another rolling release not as stable as testing).
>>> Stretch has turned or will turn soon into a frozen distribution
>>> similar to Jessie but two years more modern and be designated stable
>>> likely sometime in 2017.  Jessie will be redesignated as oldstable at
>>> that Debian release epoch, and Sid is always going to be unstable.
>>> :-)
>>>
>>> So if you installed Jessie, I would be officially amazed you cannot
>>> replicate my good results there.  But if Stretch or Sid, then those
>>> are quite different, and all bets are off.
>>>
>>>> it seems that something on your debian is preventing this error,
>>>> but you should be able to verify this by just installing a new debian 
>>>> (or
>>>> any linux , it seems) on VirtualBox.
>>>
>>>
>>> Half my computer memory fried itself a year or so ago so my computer
>>> (already 9 years old but with ASUS motherboard, Intel CPU's, new
>>> disks, and new power supply still doing pretty well) is a little short
>>> of memory. Thus, I don't plan to look at VirtualBox at the moment, but
>>> when (if?) one of my motherboard, CPU's, or remaining RAM die so that
>>> I really do have to replace all three, I intend to buy a huge amount
>>> of memory for the new system so I can play with VirtualBox with ease.
>>>
>>> Alan
>>> __________________________
>>> Alan W. Irwin
>>>
>>> Astronomical research affiliation with Department of Physics and
>>> Astronomy,
>>> University of Victoria (astrowww.phys.uvic.ca).
>>>
>>> Programming affiliations with the FreeEOS equation-of-state
>>> implementation for stellar interiors (freeeos.sf.net); the Time
>>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>>> software package (plplot.sf.net); the libLASi project
>>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>>> and the Linux Brochure Project (lbproject.sf.net).
>>> __________________________
>>>
>>> Linux-powered Science
>>> __________________________
>>
>>
>> --
>> Pedro Vicente
>> ped...@sp...
>> http://www.space-research.org/
> 

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

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

Hi Pedro, Alan
I'm still unable to reproduce the problem on my Ubuntu 14.04 system
with wxWidgets 3.0. Very strange. I have tried a totally fresh build
directory and static and dynamic builds.

I had forgotten to test on my work CentOS PC and although I know it is
powered on I can't ssh into it. I'm not sure why. I will test it when
I get in tomorrow.

I can't help feeling that there is something that we are missing here.
Given both I and Pedro have tested on Ubuntu 14.04 there must be
something different between the two systems.

Phil

On 15 December 2016 at 15:22, Pedro Vicente
<ped...@sp...> wrote:
> Hi Alan
>
> I installed the latest from the debian site, here
>
> https://www.debian.org/distrib/
>
> it's not surprising that I got the same results in ubuntu because I used the
> same package
>
> sudo apt-get install libwxgtk3.0-dev
>
>
>
>
> On 2016-12-15 04:32, Alan W. Irwin wrote:
>>
>> On 2016-12-15 01:11-0500 Pedro Vicente wrote:
>>
>>> Hi Alan
>>>
>>> I just installed the latest debian on VirtualBox, and I get the same
>>> errors.
>>> the results are attached, same thing that I did for ubuntu.
>>
>>
>> Hi Pedro:
>>
>> Just for the record, what version of Debian?
>>
>> Currently Jessie = stable (a largely frozen release from two years
>> ago), Stretch = testing (a rolling release not as stable as stable),
>> and Sid = unstable (another rolling release not as stable as testing).
>> Stretch has turned or will turn soon into a frozen distribution
>> similar to Jessie but two years more modern and be designated stable
>> likely sometime in 2017.  Jessie will be redesignated as oldstable at
>> that Debian release epoch, and Sid is always going to be unstable.
>> :-)
>>
>> So if you installed Jessie, I would be officially amazed you cannot
>> replicate my good results there.  But if Stretch or Sid, then those
>> are quite different, and all bets are off.
>>
>>> it seems that something on your debian is preventing this error,
>>> but you should be able to verify this by just installing a new debian (or
>>> any linux , it seems) on VirtualBox.
>>
>>
>> Half my computer memory fried itself a year or so ago so my computer
>> (already 9 years old but with ASUS motherboard, Intel CPU's, new
>> disks, and new power supply still doing pretty well) is a little short
>> of memory. Thus, I don't plan to look at VirtualBox at the moment, but
>> when (if?) one of my motherboard, CPU's, or remaining RAM die so that
>> I really do have to replace all three, I intend to buy a huge amount
>> of memory for the new system so I can play with VirtualBox with ease.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>
>
> --
> Pedro Vicente
> ped...@sp...
> http://www.space-research.org/

Re: [Plplot-devel] wxPLplotDemo.cpp -- FIXED

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

> I get something different here
>
> 12:45:37: Debug: wxPLplotwindow
> 12:45:37: Debug: frame->Create
> 12:45:37: Debug: wxPLplotwindow::Show


this is interesting.
It seems that the
frame->Create
call does *NOT* trigger the
wxPLplotwindow::OnCreate
event on your run

otherwise you would have this


12:45:37: Debug: wxPLplotwindow
12:45:37: Debug: frame->Create
11:13:52: Debug: wxPLplotwindow::OnCreate

but on the other hand, without my changes, you did get the plot, 
correct?

but probably this does not matter at this time, unless you're really 
curious about the sequence
of events in your code.
In that case , start from the original files as in the repo now and 
just add calls like these
wxLogDebug("wxPLplotwindow::OnCreate");

in all functions

> Important!  Also please follow the cookbook instructions in
> README.developers to format your change in "git format-patch" form. 
> (I
> just [commit ae4af16] updated those instructions with you in mind so 
> I
> hope you will find them easy to follow.)

ok

> But regardless of that system difference issue, your changes work
> here, and also work there.  So a big thanks for that fundamental
> fix for the problem!

your're welcome, glad I could help


> The alternative is I could just go ahead and commit your changed 
> files
> here, but then that would give me git credit for your work (as seen
> by, e.g., git log, git blame, etc.) so I far prefer you to use "git
> format-patch" following the cookbook instructions in
> README.developers.


I will commit, always good to get credit where credit is due :-)
do I have git permissions to do
git commit
git push
?


> I think the debugging output you have in your current changes should
> stay in for your commit.  Because that might help Phil understand
> your changes


ok

-Pedro

On 2016-12-15 16:12, Alan W. Irwin wrote:
> On 2016-12-15 11:24-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>>
>> Success
>>
>> The solution is to override the Show() function of the window, that 
>> is called in the demo.
>> So no need to modify the demo at all with a custom function call.
>>
>>
>> in wxPLplotwindow.h I just added this function
>>
>> template<class WXWINDOW>
>> bool wxPLplotwindow<WXWINDOW>::Show(bool show)
>> {
>>  wxLogDebug("wxPLplotwindow::Show");
>>  CreateStream();
>>  WXWINDOW::Show(show);
>>
>> }
>>
>> where
>> CreateStream();
>> is a new internal function of the class that contains the code that 
>> is now in OnCreate()
>>
>> the 2 files are attached
>> they contain a couple of debug messages
>>
>> this is the sequence I get
>>
>> 11:13:52: Debug: wxPLplotwindow
>> 11:13:52: Debug: frame->Create
>> 11:13:52: Debug: wxPLplotwindow::Show
>> 11:13:52: Debug: wxPLplotwindow::CreateStream
>> 11:13:52: Debug: wxPLplotwindow::RenewPlot
>> 11:13:52: Debug: Plot()
>> 11:13:52: Debug: wxPLplotwindow::RenewPlot
>> 11:13:52: Debug: wxPLplotwindow::RenewPlot
>> 11:13:52: Debug: wxPLplotwindow::OnCreate
>> 11:13:52: Debug: wxPLplotwindow::CreateStream
>> 11:13:52: Debug: wxPLplotwindow::OnErase
>>
>>
>> as you can see the stream is NOT NULL when we get at
>> 11:13:52: Debug: Plot()
>
> I get something different here
>
> 12:45:37: Debug: wxPLplotwindow
> 12:45:37: Debug: frame->Create
> 12:45:37: Debug: wxPLplotwindow::Show
> 12:45:37: Debug: wxPLplotwindow::CreateStream
> 12:45:37: Debug: wxPLplotwindow::RenewPlot
> 12:45:37: Debug: wxPLplotwindow::RenewPlot
> 12:45:37: Debug: wxPLplotwindow::RenewPlot
> 12:45:37: Debug: wxPLplotwindow::OnCreate
> 12:45:37: Debug: wxPLplotwindow::CreateStream
> 12:45:37: Debug: Plot()
> 12:45:37: Debug: wxPLplotwindow::RenewPlot
> 12:45:37: Debug: wxPLplotwindow::OnErase
> 12:45:43: Debug: wxPLplotwindow::OnErase
> 12:45:45: Debug: wxPLplotwindow::OnErase
> PLMemoryMap::close: just entering close
> [100%] Built target test_wxPLplotDemo
>
> Perhaps this different result is why the issue did not cause
> any problems on my system?
>
> But regardless of that system difference issue, your changes work
> here, and also work there.  So a big thanks for that fundamental
> fix for the problem!
>
> Important!  Also please follow the cookbook instructions in
> README.developers to format your change in "git format-patch" form. 
> (I
> just [commit ae4af16] updated those instructions with you in mind so 
> I
> hope you will find them easy to follow.)
>
> The alternative is I could just go ahead and commit your changed 
> files
> here, but then that would give me git credit for your work (as seen
> by, e.g., git log, git blame, etc.) so I far prefer you to use "git
> format-patch" following the cookbook instructions in
> README.developers.  Then I can follow up properly here with "git am"
> and then merge the commit that creates here (that is identified as
> yours) to master.
>
> I think the debugging output you have in your current changes should
> stay in for your commit.  Because that might help Phil understand
> your changes (if he gets back in contact before the release).
> Later on just before the release I plan to make an additional commit
> to drop the debugging output your commit creates (and also
> similarly for the debugging output I have put into -dev wxwidgets
> and wxPLViewere).
>
> 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/

[Plplot-devel] More on the -dev wxwidgets long pause issue

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

Hi Pedro:

I thought your fix and/or the additional debugging output it produces
might yield some insight into the long-pause issue that still remains.

So here is the most recent debugging output result for conditions
(a quick repeat of an example) that always cause the long pause issue
here.

Could you try the same experiment on one of your Linux systems that is
a lot more modern than Debian Jessie to confirm that the long pause
issue still occurs for those systems, i.e., it is not due to some
kernel, wxwidgets, or GTK+ issue that has been subsequently fixed?

Build the x01c, and wxwidgets targets (needed prerequisites).  Then run

software@raven> time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c"
PLplot library version: 5.11.1
PLMemoryMap::close: just entering close
PLMemoryMap::create: (mustNotExist) calling shm_open
PLMemoryMap::create: shm_open was a success for plplotMemoryMapYDIQRGQQHF
PLMemoryMap::create: (mustNotExist) calling ftruncate
PLMemoryMap::create: calling mmap
PLMemoryMap::create: finished with call of mmap
12:54:39: Debug: wxPLplotwindow
PLMemoryMap::close: just entering close
PLMemoryMap::create: (mustExist) calling shm_open
PLMemoryMap::create: shm_open was a success for plplotMemoryMapYDIQRGQQHF
PLMemoryMap::create: calling mmap
PLMemoryMap::create: finished with call of mmap
12:54:39: Debug: wxPLplotwindow::Show
12:54:39: Debug: wxPLplotwindow::CreateStream
12:54:39: Debug: wxPLplotwindow::RenewPlot
12:54:39: Debug: wxPLplotwindow::RenewPlot
12:54:39: Debug: wxPLplotwindow::RenewPlot
12:54:39: Debug: wxPLplotwindow::OnCreate
12:54:39: Debug: wxPLplotwindow::CreateStream
12:54:39: Debug: wxPLplotwindow::OnCreate
12:54:39: Debug: wxPLplotwindow::CreateStream
PLMemoryMap::close: just entering close
PLMemoryMap::close: calling munmap
PLMemoryMap::close: calling shm_unlink
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapYDIQRGQQHF
PLMemoryMap::close: start deleting m_name
PLMemoryMap::close: end deleting m_name
12:54:39: Debug: wxPLplotwindow::OnErase

real    0m0.256s
user    0m0.044s
sys     0m0.012s
done x01c
PLplot library version: 5.11.1
12:54:40: Debug: wxPLplotwindow::RenewPlot
12:54:40: Debug: wxPLplotwindow::OnErase
PLMemoryMap::close: just entering close
PLMemoryMap::close: calling munmap
PLMemoryMap::close: calling shm_unlink
PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory
PLMemoryMap::close: start deleting m_name
PLMemoryMap::close: end deleting m_name
PLMemoryMap::close: just entering close
**************[long ~5 second pause]*************
PLMemoryMap::close: just entering close
PLMemoryMap::create: (mustNotExist) calling shm_open
PLMemoryMap::create: shm_open was a success for plplotMemoryMapJVIGLNDRKZ
PLMemoryMap::create: (mustNotExist) calling ftruncate
PLMemoryMap::create: calling mmap
PLMemoryMap::create: finished with call of mmap
12:54:45: Debug: wxPLplotwindow
PLMemoryMap::close: just entering close
PLMemoryMap::create: (mustExist) calling shm_open
PLMemoryMap::create: shm_open was a success for plplotMemoryMapJVIGLNDRKZ
PLMemoryMap::create: calling mmap
PLMemoryMap::create: finished with call of mmap
12:54:45: Debug: wxPLplotwindow::Show
12:54:45: Debug: wxPLplotwindow::CreateStream
12:54:45: Debug: wxPLplotwindow::RenewPlot
12:54:45: Debug: wxPLplotwindow::RenewPlot
12:54:45: Debug: wxPLplotwindow::RenewPlot
12:54:45: Debug: wxPLplotwindow::OnCreate
12:54:45: Debug: wxPLplotwindow::CreateStream
12:54:45: Debug: wxPLplotwindow::OnCreate
12:54:45: Debug: wxPLplotwindow::CreateStream
12:54:45: Debug: wxPLplotwindow::OnErase
PLMemoryMap::close: just entering close
PLMemoryMap::close: calling munmap
PLMemoryMap::close: calling shm_unlink
PLMemoryMap::close: shm_unlink was a success for plplotMemoryMapJVIGLNDRKZ
PLMemoryMap::close: start deleting m_name
PLMemoryMap::close: end deleting m_name

real    0m5.754s
user    0m0.048s
sys     0m0.008s
done x01c
software@raven> 12:54:46: Debug: wxPLplotwindow::RenewPlot
12:54:46: Debug: wxPLplotwindow::OnErase
PLMemoryMap::close: just entering close
PLMemoryMap::close: calling munmap
PLMemoryMap::close: calling shm_unlink
PLMemoryMap::close: shm_unlink error
PLMemoryMap::close: No such file or directory
PLMemoryMap::close: start deleting m_name
PLMemoryMap::close: end deleting m_name
PLMemoryMap::close: just entering close

The time stamps on the debug output you inserted 
confirm the pause which previous analysis shows must
occur somewhere in -dev wxwidgets before the indicated call to

PLMemoryMap::close

after the long pause.  None of your own debug output occurs from the
second example before that call to PLMemoryMap::close so we are no
further forward (at present) in nailing down where the pause occurs
before that call to PLMemoryMap::close in the -dev wxwidgets code.
But it was worth a look with this more extensive debug output.

Unless something else comes up, I plan to work on nailing down
the exact commmand that causes the long pause issue for the
next little while.  So there should be more later today
about what I find out.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] wxPLplotDemo.cpp -- FIXED

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

On 2016-12-15 11:24-0500 Pedro Vicente wrote:

> Hi Alan
>
>
> Success
>
> The solution is to override the Show() function of the window, that is called 
> in the demo.
> So no need to modify the demo at all with a custom function call.
>
>
> in wxPLplotwindow.h I just added this function
>
> template<class WXWINDOW>
> bool wxPLplotwindow<WXWINDOW>::Show(bool show)
> {
>  wxLogDebug("wxPLplotwindow::Show");
>  CreateStream();
>  WXWINDOW::Show(show);
>
> }
>
> where
> CreateStream();
> is a new internal function of the class that contains the code that is now in 
> OnCreate()
>
> the 2 files are attached
> they contain a couple of debug messages
>
> this is the sequence I get
>
> 11:13:52: Debug: wxPLplotwindow
> 11:13:52: Debug: frame->Create
> 11:13:52: Debug: wxPLplotwindow::Show
> 11:13:52: Debug: wxPLplotwindow::CreateStream
> 11:13:52: Debug: wxPLplotwindow::RenewPlot
> 11:13:52: Debug: Plot()
> 11:13:52: Debug: wxPLplotwindow::RenewPlot
> 11:13:52: Debug: wxPLplotwindow::RenewPlot
> 11:13:52: Debug: wxPLplotwindow::OnCreate
> 11:13:52: Debug: wxPLplotwindow::CreateStream
> 11:13:52: Debug: wxPLplotwindow::OnErase
>
>
> as you can see the stream is NOT NULL when we get at
> 11:13:52: Debug: Plot()

I get something different here

12:45:37: Debug: wxPLplotwindow
12:45:37: Debug: frame->Create
12:45:37: Debug: wxPLplotwindow::Show
12:45:37: Debug: wxPLplotwindow::CreateStream
12:45:37: Debug: wxPLplotwindow::RenewPlot
12:45:37: Debug: wxPLplotwindow::RenewPlot
12:45:37: Debug: wxPLplotwindow::RenewPlot
12:45:37: Debug: wxPLplotwindow::OnCreate
12:45:37: Debug: wxPLplotwindow::CreateStream
12:45:37: Debug: Plot()
12:45:37: Debug: wxPLplotwindow::RenewPlot
12:45:37: Debug: wxPLplotwindow::OnErase
12:45:43: Debug: wxPLplotwindow::OnErase
12:45:45: Debug: wxPLplotwindow::OnErase
PLMemoryMap::close: just entering close
[100%] Built target test_wxPLplotDemo

Perhaps this different result is why the issue did not cause
any problems on my system?

But regardless of that system difference issue, your changes work
here, and also work there.  So a big thanks for that fundamental
fix for the problem!

Important!  Also please follow the cookbook instructions in
README.developers to format your change in "git format-patch" form. (I
just [commit ae4af16] updated those instructions with you in mind so I
hope you will find them easy to follow.)

The alternative is I could just go ahead and commit your changed files
here, but then that would give me git credit for your work (as seen
by, e.g., git log, git blame, etc.) so I far prefer you to use "git
format-patch" following the cookbook instructions in
README.developers.  Then I can follow up properly here with "git am"
and then merge the commit that creates here (that is identified as
yours) to master.

I think the debugging output you have in your current changes should
stay in for your commit.  Because that might help Phil understand
your changes (if he gets back in contact before the release).
Later on just before the release I plan to make an additional commit
to drop the debugging output your commit creates (and also
similarly for the debugging output I have put into -dev wxwidgets
and wxPLViewere).

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] plbuffer bug

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

Hi All
I've just posted a bug to the bug tracker regarding  the buffer.

I just wanted to send an email out to say that I don't particularly
intend to fix it before the freeze as I don't think there is time. But
I wanted to stick it on the tracker so it didn't get forgotten.

The problem is that text is written and read in "device native"
encoding (i.e. Unicode or ascii) so if a buffer is copied from a
Unicode device to an ascii one then the plreplot call will hit a
problem with buffer reading and call plexit. The solution would be to
always write Unicode or to add a flag to indicate the encoding in the
buffer. If anyone has a preference then let me know.

Phil

Re: [Plplot-devel] wxPLplotDemo.cpp -- FIXED

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

Hi Alan


Success

The solution is to override the Show() function of the window, that is 
called in the demo.
So no need to modify the demo at all with a custom function call.


in wxPLplotwindow.h I just added this function

template<class WXWINDOW>
bool wxPLplotwindow<WXWINDOW>::Show(bool show)
{
   wxLogDebug("wxPLplotwindow::Show");
   CreateStream();
   WXWINDOW::Show(show);

}

where
CreateStream();
is a new internal function of the class that contains the code that is 
now in OnCreate()

the 2 files are attached
they contain a couple of debug messages

this is the sequence I get

11:13:52: Debug: wxPLplotwindow
11:13:52: Debug: frame->Create
11:13:52: Debug: wxPLplotwindow::Show
11:13:52: Debug: wxPLplotwindow::CreateStream
11:13:52: Debug: wxPLplotwindow::RenewPlot
11:13:52: Debug: Plot()
11:13:52: Debug: wxPLplotwindow::RenewPlot
11:13:52: Debug: wxPLplotwindow::RenewPlot
11:13:52: Debug: wxPLplotwindow::OnCreate
11:13:52: Debug: wxPLplotwindow::CreateStream
11:13:52: Debug: wxPLplotwindow::OnErase


as you can see the stream is NOT NULL when we get at
11:13:52: Debug: Plot()

-Pedro



On 2016-12-15 10:22, Pedro Vicente wrote:
> Hi Alan
>
> I installed the latest from the debian site, here
>
> https://www.debian.org/distrib/
>
> it's not surprising that I got the same results in ubuntu because I
> used the same package
>
> sudo apt-get install libwxgtk3.0-dev
>
>
>
> On 2016-12-15 04:32, Alan W. Irwin wrote:
>> On 2016-12-15 01:11-0500 Pedro Vicente wrote:
>>
>>> Hi Alan
>>>
>>> I just installed the latest debian on VirtualBox, and I get the 
>>> same
>>> errors.
>>> the results are attached, same thing that I did for ubuntu.
>>
>> Hi Pedro:
>>
>> Just for the record, what version of Debian?
>>
>> Currently Jessie = stable (a largely frozen release from two years
>> ago), Stretch = testing (a rolling release not as stable as stable),
>> and Sid = unstable (another rolling release not as stable as
>> testing).
>> Stretch has turned or will turn soon into a frozen distribution
>> similar to Jessie but two years more modern and be designated stable
>> likely sometime in 2017.  Jessie will be redesignated as oldstable 
>> at
>> that Debian release epoch, and Sid is always going to be unstable.
>> :-)
>>
>> So if you installed Jessie, I would be officially amazed you cannot
>> replicate my good results there.  But if Stretch or Sid, then those
>> are quite different, and all bets are off.
>>
>>> it seems that something on your debian is preventing this error,
>>> but you should be able to verify this by just installing a new
>>> debian (or any linux , it seems) on VirtualBox.
>>
>> Half my computer memory fried itself a year or so ago so my computer
>> (already 9 years old but with ASUS motherboard, Intel CPU's, new
>> disks, and new power supply still doing pretty well) is a little
>> short
>> of memory. Thus, I don't plan to look at VirtualBox at the moment,
>> but
>> when (if?) one of my motherboard, CPU's, or remaining RAM die so 
>> that
>> I really do have to replace all three, I intend to buy a huge amount
>> of memory for the new system so I can play with VirtualBox with 
>> ease.
>>
>> 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/
>
> 
> ------------------------------------------------------------------------------
> 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

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

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

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

Hi Alan

I installed the latest from the debian site, here

https://www.debian.org/distrib/

it's not surprising that I got the same results in ubuntu because I 
used the same package

sudo apt-get install libwxgtk3.0-dev



On 2016-12-15 04:32, Alan W. Irwin wrote:
> On 2016-12-15 01:11-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I just installed the latest debian on VirtualBox, and I get the same 
>> errors.
>> the results are attached, same thing that I did for ubuntu.
>
> Hi Pedro:
>
> Just for the record, what version of Debian?
>
> Currently Jessie = stable (a largely frozen release from two years
> ago), Stretch = testing (a rolling release not as stable as stable),
> and Sid = unstable (another rolling release not as stable as 
> testing).
> Stretch has turned or will turn soon into a frozen distribution
> similar to Jessie but two years more modern and be designated stable
> likely sometime in 2017.  Jessie will be redesignated as oldstable at
> that Debian release epoch, and Sid is always going to be unstable.
> :-)
>
> So if you installed Jessie, I would be officially amazed you cannot
> replicate my good results there.  But if Stretch or Sid, then those
> are quite different, and all bets are off.
>
>> it seems that something on your debian is preventing this error,
>> but you should be able to verify this by just installing a new 
>> debian (or any linux , it seems) on VirtualBox.
>
> Half my computer memory fried itself a year or so ago so my computer
> (already 9 years old but with ASUS motherboard, Intel CPU's, new
> disks, and new power supply still doing pretty well) is a little 
> short
> of memory. Thus, I don't plan to look at VirtualBox at the moment, 
> but
> when (if?) one of my motherboard, CPU's, or remaining RAM die so that
> I really do have to replace all three, I intend to buy a huge amount
> of memory for the new system so I can play with VirtualBox with ease.
>
> 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] Comprehensive testing

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]


> Hi Arjen:
>
> That's a really nice piece of news to hear from you.  I will take a look at the details
> in that report tomorrow and post it and your prior report for MinGW-w64/MSYS2 on
> our wiki.
>
Glad to hear that - my renewed installation of MinGW-w64/MSYS2 is misbehaving so I cannot produce any report for that platform at the moment.

Regards,

Arjen

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

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

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

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

> Hi Alan
>
>> I think you will agree with me that smells like a workaround rather
>> than a fundamental fix.
>
> yes, I agree.
>
>>> Eventually, we had to change our
>>> minimum acceptable wxwidgets version from 2.8 to 3.0 because of one
>>> commit which only worked for 3.0.
>
> hhm, ok
> I have to double check this but the comments in your code say ::Bind() is 
> only available
> for 3.0, and ::Bind()  is not used
>
> so probably the code as of now is compatible with 2.8 (meaning it only has 
> 2.8 calls, not 3.0 calls)

Not exactly.  If you read Phil's commit messages carefuly they imply
the code was developed for 3.0 and the minimum changes made as
an afterthought when it did not work on his CentOS box at that time
so it would work on 2.8.  So, for example, there is a
commit that _replaced_ Bind by the current connect method.

>
>
>>> I would appreciate
>>> your thoughts on this matter of moving to pure 3.0.
>
> we could try the ::Bind()   route, yes, to see what happens

Good.  And thanks for your willingness to give us some help with wxwidgets to
get these current Linux build errors straightened out.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive testing

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

On 2016-12-15 07:49-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Thursday, December 15, 2016 2:31 AM
>>
>> Well, if I recall correctly, the last time we discussed the
>> MinGW-w64/MSYS2 version of cmake, the conclusion then was your install of that
>> platform had problems just like every other MinGW-w64/MSYS2 user at that time
>> so a complete reinstall was recommended, but I suspect you did not do that.  But
>> now is your chance to do that in the next several weeks.
>>
> I will have to, the thing is completely unuseable ;).
>
>>
>> Likely the best advice I can give you for this Linux-like (except for the core parts
>> which are native Windows, of course) free software distribution, is to keep careful
>> file records of everything you install and update.  (I have found that habit to be
>> invaluable for
>> Debian.) Typically, I capture such output with the "tee" command, e.g.,
>>
>> apt-get install python-pil |tee -a 20161202
>>
> I usually redirect all output to a file and then examine that afterwards. Cygwin is easier in this respect: the setup program shows the installed packages itself.
>
>>
>> BTW, I see the expected three good dashboards from your recent Cygwin
>> comprehensive test so I am looking forward to seeing the corresponding report
>> tarball which should finish your comprehensive testing for this release with any luck
>> at all.
>>
> See the attached tarball. It took a long time to run through all the tests and all the build configurations, but it finished without any complaints indeed.

Hi Arjen:

That's a really nice piece of news to hear from you.  I will take a
look at the details in that report tomorrow and post it and your prior
report for MinGW-w64/MSYS2 on our wiki.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

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

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

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

> Hi Alan
>
> I just installed the latest debian on VirtualBox, and I get the same errors.
> the results are attached, same thing that I did for ubuntu.

Hi Pedro:

Just for the record, what version of Debian?

Currently Jessie = stable (a largely frozen release from two years
ago), Stretch = testing (a rolling release not as stable as stable),
and Sid = unstable (another rolling release not as stable as testing).
Stretch has turned or will turn soon into a frozen distribution
similar to Jessie but two years more modern and be designated stable
likely sometime in 2017.  Jessie will be redesignated as oldstable at
that Debian release epoch, and Sid is always going to be unstable.
:-)

So if you installed Jessie, I would be officially amazed you cannot
replicate my good results there.  But if Stretch or Sid, then those
are quite different, and all bets are off.

> it seems that something on your debian is preventing this error,
> but you should be able to verify this by just installing a new debian (or any 
> linux , it seems) on VirtualBox.

Half my computer memory fried itself a year or so ago so my computer
(already 9 years old but with ASUS motherboard, Intel CPU's, new
disks, and new power supply still doing pretty well) is a little short
of memory. Thus, I don't plan to look at VirtualBox at the moment, but
when (if?) one of my motherboard, CPU's, or remaining RAM die so that
I really do have to replace all three, I intend to buy a huge amount
of memory for the new system so I can play with VirtualBox with ease.

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] git blog

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

On 2016-12-14 21:35-0800 Alan W. Irwin wrote:

> One issue you should be aware of is git blame results are obfuscated
> by our code styling events (often triggered by me) which amount to
> putting random blanks in the code to make it conform to our style.
>
> So
>
> software@raven> git blame bindings/wxwidgets/wxPLplotwindow.h |grep '2\.8'
> 39a6c01b (Alan W. Irwin  2015-02-14 19:32:12 -0800  90)     //We use connect instead of Bind for compatiblity with wxWidgets 2.8
> 39a6c01b (Alan W. Irwin  2015-02-14 19:32:12 -0800 123)     //on at least one system (CentOS with intel compiler and wxWidgets 2.8.12).
>
> "shows" I was the author of the above comment in commit 39a6c01b, but
> that was a styling commit so you have to back off one commit to 39a6c01b^ to find the true
> author/commit which then shows the following:
>
> software@raven> git blame 39a6c01b^ bindings/wxwidgets/wxPLplotwindow.h |grep '2\.8'
> cf59c54a (Phil Rosenberg 2015-01-15 14:18:42 +0000  75)         //We use connect instead of Bind for compatiblity with wxWidgets 2.8
> fa121bd5 (Phil Rosenberg 2015-01-20 15:56:53 +0000 102)         //on at least one system (CentOS with intel compiler and wxWidgets 2.8.12).

Never mind.  I learn something new about git every week it seems.
Which is why this subject line is "git blog" again.

I just now discovered the -w option ignores whitespace for git blame.  So we have the
following result (note there is no specification required of the commit prior
to a style event)

software@raven> git blame -w bindings/wxwidgets/wxPLplotwindow.h |grep '2\.8'
cf59c54a (Phil Rosenberg 2015-01-15 14:18:42 +0000  90)     //We use connect instead of Bind for compatiblity with wxWidgets 2.8
fa121bd5 (Phil Rosenberg 2015-01-20 15:56:53 +0000 123)     //on at least one system (CentOS with intel compiler and wxWidgets 2.8.12).

So that -w option is extraordinarily useful for us (because of all our
whitespace style changes).

Of course, this also illustrates one of my principal gripes with git
which is the inconsistent option names.  So to ignore whitespace for
diffs, use either -w or --ignore-all-space, but to do that same thing
for git blame use -w only.  git blame does accept --ignore-all-space,
but it ignores it silently which is a bug that should be fixed.  (Either
accept the option and use it, or reject the option, but do not silently
ignore it.)

So to be really provactive here, because of such option
inconsistencies and bugs, it is possible git might be the CVS of
_distributed_ version control systems. Eventually CVS, the premier
centralized version control system was replaced in just a few years by
something much slicker and consistent (svn).  Does that slicker and
consistent git already exist, and is the git demise therefore just
around the corner?

Of course, to return to reality the two cases are obviously not
parallel.  CVS probably would have continued to be virtually the only
centralized version control system if there had been a development
team to support it, but its original developer(s) abandoned it and
which left a vacuum for the svn development team to populate.  My
understanding is git continues to have an active development team.  So
it is likely going to be around for a very long time.  But I sure wish
those git developers made a point of systematically cleaning up the
many inconsistent option names that are used (to return to my
principal git gripe).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive testing

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, December 15, 2016 2:31 AM
>
> Well, if I recall correctly, the last time we discussed the
> MinGW-w64/MSYS2 version of cmake, the conclusion then was your install of that
> platform had problems just like every other MinGW-w64/MSYS2 user at that time
> so a complete reinstall was recommended, but I suspect you did not do that.  But
> now is your chance to do that in the next several weeks.
>
I will have to, the thing is completely unuseable ;).

>
> Likely the best advice I can give you for this Linux-like (except for the core parts
> which are native Windows, of course) free software distribution, is to keep careful
> file records of everything you install and update.  (I have found that habit to be
> invaluable for
> Debian.) Typically, I capture such output with the "tee" command, e.g.,
>
> apt-get install python-pil |tee -a 20161202
>
I usually redirect all output to a file and then examine that afterwards. Cygwin is easier in this respect: the setup program shows the installed packages itself.

>
> BTW, I see the expected three good dashboards from your recent Cygwin
> comprehensive test so I am looking forward to seeing the corresponding report
> tarball which should finish your comprehensive testing for this release with any luck
> at all.
>
See the attached tarball. It took a long time to run through all the tests and all the build configurations, but it finished without any complaints indeed.

Regards,

Arjen



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

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

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

hmm, ok, I forgot Plot() is called right after the Create() call
so, this makes the assertion happen before there is a Paint event

xPLplotwindow<wxFrame> *frame = new wxPlDemoFrame();
    frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
    frame->SetIcon( wxIcon( graph ) );
    Plot( frame );

returning on PLot() avoids the assertion

void Plot( wxPLplotwindow<WXWINDOW> *plotwindow )
{
    wxPLplotstream* pls = plotwindow->GetStream();
    if (pls == NULL) return;
    assert(pls);

and this makes all the events to be callled (*even* the  OnCreate one)
and I was wrong, ::OnPaint is only called when I move the window (that now 
has no plot primitives, but still
with the stream created, which is progress)

02:28:23: Debug: wxPLplotwindow constructor
02:28:23: Debug: wxPLplotwindow::OnSize stream creation
02:28:23: Debug: wxPLplotwindow<WXWINDOW>::OnCreate
02:28:23: Debug: wxPLplotwindow::OnPaint
02:28:23: Debug: wxPLplotwindow::OnPaint


so playing a bit with this it should be possible to have a non intrusive 
workaround

as it happens wxWidgets is an excellent built framework, so this page

http://docs.wxwidgets.org/trunk/classwx_evt_handler.html

http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a0f30c8fa5583b4a5f661897d63de3b62

should have some solutions

-Pedro


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


> Hi Alan, Phil
>
> I forgot about a very simple fix that does need a custom function call
> (therefore a "real" fix, or better a non intrusive fix for users)
>
> that is, right now, the code is responding to these 2 events
>
> WXWINDOW::Connect( wxEVT_SIZE, wxSizeEventHandler(
> wxPLplotwindow<WXWINDOW>::OnSize ) );
> WXWINDOW::Connect( wxEVT_PAINT, wxPaintEventHandler(
> wxPLplotwindow<WXWINDOW>::OnPaint ) );
>
> so, it's just a matter of calling the OnCreate() stream on one
>
> wxEVT_SIZE is a bad idea, because it's only called when the user moves the
> window
> but I think wxEVT_PAINT is *continuously* called in a event loop (meaning
> always)
>
> right now it even has some calls that are called there as a workaround
>
>
> template<class WXWINDOW>
> void wxPLplotwindow<WXWINDOW>::OnPaint( wxPaintEvent &WXUNUSED( event ) )
> {
>    //Really this should be in the constructor, but it caused a segfault
>    //on at least one system (CentOS with intel compiler and wxWidgets
> 2.8.12).
>    //Moving it here after WXWINDOW::Create has been called stops this and
>    //the call does nothing if the style is the same as previous calls so
>    //should be safe to call here.
>
>
> the boolean flag
>
> if ( !m_created )
>    {
>        //create the stream
>
>
> makes it that it's only called 1 time
>
> I'll try this tomorrow
>
> -Pedro
>
>
>
> ----- Original Message ----- 
> From: "Pedro Vicente" <ped...@sp...>
> To: "Alan W. Irwin" <ir...@be...>; "Phil Rosenberg"
> <p.d...@gm...>
> Cc: "PLplot development list" <plp...@li...>
> Sent: Thursday, December 15, 2016 1:31 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error
>
>
>> Hi Alan
>>
>>> I think you will agree with me that smells like a workaround rather
>>> than a fundamental fix.
>>
>> yes, I agree.
>>
>>>> Eventually, we had to change our
>>>> minimum acceptable wxwidgets version from 2.8 to 3.0 because of one
>>>> commit which only worked for 3.0.
>>
>> hhm, ok
>> I have to double check this but the comments in your code say ::Bind() is
>> only available
>> for 3.0, and ::Bind()  is not used
>>
>> so probably the code as of now is compatible with 2.8 (meaning it only 
>> has
>> 2.8 calls, not 3.0 calls)
>>
>>
>>>>I would appreciate
>>>> your thoughts on this matter of moving to pure 3.0.
>>
>> we could try the ::Bind()   route, yes, to see what happens
>>
>> another thing
>> wxPLplotwindow.h is a header file
>> we can try to move the implementation to a .ccp file (with templates 
>> there
>> are some idiosyncrasies about the use of headers versus .cpp,
>> that's why I never use templates)
>>
>>
>>>>I would be willing to hold the release for you for a few
>>>> extra days beyond December 27th
>>
>> that would be great, that should be enough to have a better idea.
>> I have more time to work on this on the weekends only.
>>
>> -Pedro
>>
>>
>> ----- Original Message ----- 
>> From: "Alan W. Irwin" <ir...@be...>
>> To: "Pedro Vicente" <ped...@sp...>; "Phil Rosenberg"
>> <p.d...@gm...>
>> Cc: "PLplot development list" <plp...@li...>
>> Sent: Thursday, December 15, 2016 12:35 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error
>>
>>
>>> On 2016-12-14 22:30-0500 Pedro Vicente wrote:
>>>
>>>> Hi Alan
>>>>
>>>> see my replies between your questions
>>>>
>>>>> This certainly qualifies as a release-critical wxwidgets bug.  And you
>>>>> have certainly supplied enough information that Phil should find this
>>>>> to be straightforward to reproduce.
>>>>
>>>> easy to reproduce on the PLplot code, but not immediatley obvious to
>>>> find
>>>> the root cause.
>>>
>>> Amen!
>>>
>>>>
>>>> My speculation is that it happens because this function located in
>>>> \bindings\wxwidgets\wxPLplotwindow.h
>>>>
>>>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event )
>>>> {
>>>>   if ( !m_created )
>>>>
>>>> is not automatically called in an wxwidgets event triggered by this 
>>>> code
>>>> in wxPLplotDemo.cpp, the Create() call
>>>>
>>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>>
>>>> this can be easily confirmed if you put a print statement here
>>>>
>>>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event )
>>>> {
>>>> wxLogDebug("wxPLplotwindow<WXWINDOW>::OnCreate");
>>>>   if ( !m_created )
>>>>
>>>> so, my solution is simple, it's just to specifically call the code that
>>>> is inside
>>>> void wxPLplotwindow<WXWINDOW>::OnCreate
>>>>
>>>>
>>>> I did this by doing a function that I called CreatePLplotstream(), that
>>>> contains the stream initialization code
>>>> that is in
>>>> wxPLplotwindow<WXWINDOW>::OnCreate
>>>>
>>>>
>>>> so, in the demo code the call is now
>>>>
>>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>> frame->CreatePLplotstream();
>>>
>>> I think you will agree with me that smells like a workaround rather
>>> than a fundamental fix.  Nevertheless, if you turn that change into a
>>> PLplot patch AND that solves the present build issue for all the Linux
>>> distros you have tried, and if it works here on Debian Jessie, then I
>>> will apply that patch as a temporary fix for the release which we can
>>> undo afterwards (or even before the release if we are lucky) with a
>>> more fundamental fix.
>>>
>>>>
>>>>> Do you see any use of (presumably deprecated) wxwidgets-2.x calls
>>>>> in our wxwidgets binding or device driver?  If so, that might be
>>>>> a good place to start to work on this issue.
>>>>
>>>>
>>>> not sure, I'll check
>>>>
>>>> events are explained here
>>>>
>>>> http://docs.wxwidgets.org/3.1/overview_events.html
>>>>
>>>> I always do a static event table in my code.
>>>> it's also possible to do a dynamic event (with ::Bind())
>>>> actually in the PLplot code this is done another way, that I am not 
>>>> sure
>>>> about
>>>>
>>>> //We use connect instead of Bind for compatiblity with wxWidgets 2.8
>>>> //but should move to bind in the future.
>>>> WXWINDOW::Connect( wxEVT_CREATE, wxWindowCreateEventHandler(
>>>> wxPLplotwindow<WXWINDOW>::OnCreate ) );
>>>
>>> Implementing a fundamental fix for the current build issue is already
>>> way beyond my meager C++ and wxwidgets expertise, but I do have some
>>> sense of the overview that may help you.
>>>
>>> One issue you should be aware of is git blame results are obfuscated
>>> by our code styling events (often triggered by me) which amount to
>>> putting random blanks in the code to make it conform to our style.
>>>
>>> So
>>>
>>> software@raven> git blame bindings/wxwidgets/wxPLplotwindow.h |grep
>>> '2\.8'
>>> 39a6c01b (Alan W. Irwin  2015-02-14 19:32:12 -0800  90)     //We use
>>> connect instead of Bind for compatiblity with wxWidgets 2.8
>>> 39a6c01b (Alan W. Irwin  2015-02-14 19:32:12 -0800 123)     //on at 
>>> least
>>> one system (CentOS with intel compiler and wxWidgets 2.8.12).
>>>
>>> "shows" I was the author of the above comment in commit 39a6c01b, but
>>> that was a styling commit so you have to back off one commit to 
>>> 39a6c01b^
>>> to find the true
>>> author/commit which then shows the following:
>>>
>>> software@raven> git blame 39a6c01b^ bindings/wxwidgets/wxPLplotwindow.h
>>> |grep '2\.8'
>>> cf59c54a (Phil Rosenberg 2015-01-15 14:18:42 +0000  75)         //We use
>>> connect instead of Bind for compatiblity with wxWidgets 2.8
>>> fa121bd5 (Phil Rosenberg 2015-01-20 15:56:53 +0000 102)         //on at
>>> least one system (CentOS with intel compiler and wxWidgets 2.8.12).
>>>
>>> Also, if you look at the git log for references to wxwidgets 2.8 and
>>> 3.0, it appears we tried to keep backwards compatibility with 2.8 for
>>> quite a while (the commit messages for cf59c54a, and fa121bd5 but also
>>> other commits mention maintaining compatibility with 2.8) even though
>>> principal development was on 3.0.  Eventually, we had to change our
>>> minimum acceptable wxwidgets version from 2.8 to 3.0 because of one
>>> commit which only worked for 3.0.  So it does appear our code is a
>>> mixture of wxwidgets-2.8 (supported typically by an extra commit after
>>> some development on 3.0) and 3.0, and it might be a bit of an effort
>>> to remove all that wxwidgets-2.8 support.
>>>
>>> @Phil:
>>>
>>> If you are in e-mail contact, i.e., reading this, I would appreciate
>>> your thoughts on this matter of moving to pure 3.0. If it is
>>> straightforward to do, and you have time to work on that before
>>> Christmas, I would be willing to hold the release for you for a few
>>> extra days beyond December 27th until you are done and the result
>>> thoroughly checked on Debian Jessie, Windows, and all the different
>>> Linux distros available to Pedro.  I advise this change eventually in
>>> any case because the mixture of 2.8 and 3.0 we have now appears not to
>>> be well supported on most Linux distros unless Pedro's workaround
>>> turns out to (temporarily) save the day for us.
>>>
>>> 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
>> 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] wxPLplotDemo.cpp -- linux build error

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

>>> I forgot about a very simple fix that does need a custom function call

I meant does NOT need a custom function call

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


> Hi Alan, Phil
>
> I forgot about a very simple fix that does need a custom function call
> (therefore a "real" fix, or better a non intrusive fix for users)
>
> that is, right now, the code is responding to these 2 events
>
> WXWINDOW::Connect( wxEVT_SIZE, wxSizeEventHandler(
> wxPLplotwindow<WXWINDOW>::OnSize ) );
> WXWINDOW::Connect( wxEVT_PAINT, wxPaintEventHandler(
> wxPLplotwindow<WXWINDOW>::OnPaint ) );
>
> so, it's just a matter of calling the OnCreate() stream on one
>
> wxEVT_SIZE is a bad idea, because it's only called when the user moves the
> window
> but I think wxEVT_PAINT is *continuously* called in a event loop (meaning
> always)
>
> right now it even has some calls that are called there as a workaround
>
>
> template<class WXWINDOW>
> void wxPLplotwindow<WXWINDOW>::OnPaint( wxPaintEvent &WXUNUSED( event ) )
> {
>    //Really this should be in the constructor, but it caused a segfault
>    //on at least one system (CentOS with intel compiler and wxWidgets
> 2.8.12).
>    //Moving it here after WXWINDOW::Create has been called stops this and
>    //the call does nothing if the style is the same as previous calls so
>    //should be safe to call here.
>
>
> the boolean flag
>
> if ( !m_created )
>    {
>        //create the stream
>
>
> makes it that it's only called 1 time
>
> I'll try this tomorrow
>
> -Pedro
>
>
>
> ----- Original Message ----- 
> From: "Pedro Vicente" <ped...@sp...>
> To: "Alan W. Irwin" <ir...@be...>; "Phil Rosenberg"
> <p.d...@gm...>
> Cc: "PLplot development list" <plp...@li...>
> Sent: Thursday, December 15, 2016 1:31 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error
>
>
>> Hi Alan
>>
>>> I think you will agree with me that smells like a workaround rather
>>> than a fundamental fix.
>>
>> yes, I agree.
>>
>>>> Eventually, we had to change our
>>>> minimum acceptable wxwidgets version from 2.8 to 3.0 because of one
>>>> commit which only worked for 3.0.
>>
>> hhm, ok
>> I have to double check this but the comments in your code say ::Bind() is
>> only available
>> for 3.0, and ::Bind()  is not used
>>
>> so probably the code as of now is compatible with 2.8 (meaning it only 
>> has
>> 2.8 calls, not 3.0 calls)
>>
>>
>>>>I would appreciate
>>>> your thoughts on this matter of moving to pure 3.0.
>>
>> we could try the ::Bind()   route, yes, to see what happens
>>
>> another thing
>> wxPLplotwindow.h is a header file
>> we can try to move the implementation to a .ccp file (with templates 
>> there
>> are some idiosyncrasies about the use of headers versus .cpp,
>> that's why I never use templates)
>>
>>
>>>>I would be willing to hold the release for you for a few
>>>> extra days beyond December 27th
>>
>> that would be great, that should be enough to have a better idea.
>> I have more time to work on this on the weekends only.
>>
>> -Pedro
>>
>>
>> ----- Original Message ----- 
>> From: "Alan W. Irwin" <ir...@be...>
>> To: "Pedro Vicente" <ped...@sp...>; "Phil Rosenberg"
>> <p.d...@gm...>
>> Cc: "PLplot development list" <plp...@li...>
>> Sent: Thursday, December 15, 2016 12:35 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error
>>
>>
>>> On 2016-12-14 22:30-0500 Pedro Vicente wrote:
>>>
>>>> Hi Alan
>>>>
>>>> see my replies between your questions
>>>>
>>>>> This certainly qualifies as a release-critical wxwidgets bug.  And you
>>>>> have certainly supplied enough information that Phil should find this
>>>>> to be straightforward to reproduce.
>>>>
>>>> easy to reproduce on the PLplot code, but not immediatley obvious to
>>>> find
>>>> the root cause.
>>>
>>> Amen!
>>>
>>>>
>>>> My speculation is that it happens because this function located in
>>>> \bindings\wxwidgets\wxPLplotwindow.h
>>>>
>>>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event )
>>>> {
>>>>   if ( !m_created )
>>>>
>>>> is not automatically called in an wxwidgets event triggered by this 
>>>> code
>>>> in wxPLplotDemo.cpp, the Create() call
>>>>
>>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>>
>>>> this can be easily confirmed if you put a print statement here
>>>>
>>>> void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event )
>>>> {
>>>> wxLogDebug("wxPLplotwindow<WXWINDOW>::OnCreate");
>>>>   if ( !m_created )
>>>>
>>>> so, my solution is simple, it's just to specifically call the code that
>>>> is inside
>>>> void wxPLplotwindow<WXWINDOW>::OnCreate
>>>>
>>>>
>>>> I did this by doing a function that I called CreatePLplotstream(), that
>>>> contains the stream initialization code
>>>> that is in
>>>> wxPLplotwindow<WXWINDOW>::OnCreate
>>>>
>>>>
>>>> so, in the demo code the call is now
>>>>
>>>> wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
>>>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>> frame->CreatePLplotstream();
>>>
>>> I think you will agree with me that smells like a workaround rather
>>> than a fundamental fix.  Nevertheless, if you turn that change into a
>>> PLplot patch AND that solves the present build issue for all the Linux
>>> distros you have tried, and if it works here on Debian Jessie, then I
>>> will apply that patch as a temporary fix for the release which we can
>>> undo afterwards (or even before the release if we are lucky) with a
>>> more fundamental fix.
>>>
>>>>
>>>>> Do you see any use of (presumably deprecated) wxwidgets-2.x calls
>>>>> in our wxwidgets binding or device driver?  If so, that might be
>>>>> a good place to start to work on this issue.
>>>>
>>>>
>>>> not sure, I'll check
>>>>
>>>> events are explained here
>>>>
>>>> http://docs.wxwidgets.org/3.1/overview_events.html
>>>>
>>>> I always do a static event table in my code.
>>>> it's also possible to do a dynamic event (with ::Bind())
>>>> actually in the PLplot code this is done another way, that I am not 
>>>> sure
>>>> about
>>>>
>>>> //We use connect instead of Bind for compatiblity with wxWidgets 2.8
>>>> //but should move to bind in the future.
>>>> WXWINDOW::Connect( wxEVT_CREATE, wxWindowCreateEventHandler(
>>>> wxPLplotwindow<WXWINDOW>::OnCreate ) );
>>>
>>> Implementing a fundamental fix for the current build issue is already
>>> way beyond my meager C++ and wxwidgets expertise, but I do have some
>>> sense of the overview that may help you.
>>>
>>> One issue you should be aware of is git blame results are obfuscated
>>> by our code styling events (often triggered by me) which amount to
>>> putting random blanks in the code to make it conform to our style.
>>>
>>> So
>>>
>>> software@raven> git blame bindings/wxwidgets/wxPLplotwindow.h |grep
>>> '2\.8'
>>> 39a6c01b (Alan W. Irwin  2015-02-14 19:32:12 -0800  90)     //We use
>>> connect instead of Bind for compatiblity with wxWidgets 2.8
>>> 39a6c01b (Alan W. Irwin  2015-02-14 19:32:12 -0800 123)     //on at 
>>> least
>>> one system (CentOS with intel compiler and wxWidgets 2.8.12).
>>>
>>> "shows" I was the author of the above comment in commit 39a6c01b, but
>>> that was a styling commit so you have to back off one commit to 
>>> 39a6c01b^
>>> to find the true
>>> author/commit which then shows the following:
>>>
>>> software@raven> git blame 39a6c01b^ bindings/wxwidgets/wxPLplotwindow.h
>>> |grep '2\.8'
>>> cf59c54a (Phil Rosenberg 2015-01-15 14:18:42 +0000  75)         //We use
>>> connect instead of Bind for compatiblity with wxWidgets 2.8
>>> fa121bd5 (Phil Rosenberg 2015-01-20 15:56:53 +0000 102)         //on at
>>> least one system (CentOS with intel compiler and wxWidgets 2.8.12).
>>>
>>> Also, if you look at the git log for references to wxwidgets 2.8 and
>>> 3.0, it appears we tried to keep backwards compatibility with 2.8 for
>>> quite a while (the commit messages for cf59c54a, and fa121bd5 but also
>>> other commits mention maintaining compatibility with 2.8) even though
>>> principal development was on 3.0.  Eventually, we had to change our
>>> minimum acceptable wxwidgets version from 2.8 to 3.0 because of one
>>> commit which only worked for 3.0.  So it does appear our code is a
>>> mixture of wxwidgets-2.8 (supported typically by an extra commit after
>>> some development on 3.0) and 3.0, and it might be a bit of an effort
>>> to remove all that wxwidgets-2.8 support.
>>>
>>> @Phil:
>>>
>>> If you are in e-mail contact, i.e., reading this, I would appreciate
>>> your thoughts on this matter of moving to pure 3.0. If it is
>>> straightforward to do, and you have time to work on that before
>>> Christmas, I would be willing to hold the release for you for a few
>>> extra days beyond December 27th until you are done and the result
>>> thoroughly checked on Debian Jessie, Windows, and all the different
>>> Linux distros available to Pedro.  I advise this change eventually in
>>> any case because the mixture of 2.8 and 3.0 we have now appears not to
>>> be well supported on most Linux distros unless Pedro's workaround
>>> turns out to (temporarily) save the day for us.
>>>
>>> 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
>> 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
>