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" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg"
<p.d.rosenb...@gmail.com>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
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...@beluga.phys.uvic.ca>
> To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg"
> <p.d.rosenb...@gmail.com>
> Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
> 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
> Plplot-devel@lists.sourceforge.net
> 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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
