plplot-devel

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

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

// Copyright (C) 2005  Werner Smekal
//
// This file is part of PLplot.
//
// PLplot is free software; you can redistribute it and/or modify
// it under the terms of the GNU Library General Public License as published
// by the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// PLplot is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU Library General Public License for more details.
//
// You should have received a copy of the GNU Library General Public License
// along with PLplot; if not, write to the Free Software
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
//
//

// For compilers that support precompilation, includes "wx/wx.h".
#include "wx/wxprec.h"

#ifdef __BORLANDC__
    #pragma hdrstop
#endif

#ifndef WX_PRECOMP
    #include "wx/wx.h"
#endif

#ifdef __WXMAC__
        #include <Carbon/Carbon.h>
extern "C" { void CPSEnableForegroundOperation( ProcessSerialNumber* psn ); }
#endif

#include "wxPLplotwindow.h"
#include <cmath>

#define MAX( a, b )    ( ( a ) < ( b ) ? ( b ) : ( a ) )
#define MIN( a, b )    ( ( a ) < ( b ) ? ( a ) : ( b ) )

// Application icon as XPM
// This free icon was taken from http://2pt3.com/news/twotone-icons-for-free/
static const char            *graph[] = {
// columns rows colors chars-per-pixel
    "16 16 4 2",
    "   c black",
    ".  c #BA1825",
    "X  c gray100",
    "UX c None",
// pixels
    "UX. . . . . . . . . . . . . . UX",
    ". . . . . . . . . . . . . . . . ",
    ". . . . . . . . . . . . . . . . ",
    ". . . . . . . . . . . X X . . . ",
    ". . . . . . . . . . . X X . . . ",
    ". . . . . . . . . . . X X . . . ",
    ". . . . . X X . . . . X X . . . ",
    ". . . . . X X . . . . X X . . . ",
    ". . . . . X X . X X . X X . . . ",
    ". . . . . X X . X X . X X . . . ",
    ". . . . . X X . X X . X X . . . ",
    ". . . . . X X . X X . X X . . . ",
    ". . . X X X X X X X X X X . . . ",
    ". . . . . . . . . . . . . . . . ",
    ". . . . . . . . . . . . . . . . ",
    "UX. . . . . . . . . . . . . . UX"
};

class wxPlDemoFrame : public wxPLplotwindow<wxFrame>
{
private:
    virtual void OnLocate( const PLGraphicsIn &graphicsIn );
};

void wxPlDemoFrame::OnLocate( const PLGraphicsIn &graphicsIn )
{
    if ( graphicsIn.button == 0 )
        return;         //Do nothing for motion, only respond to clicks

    wxString message;

    if ( ( graphicsIn.state & PL_MASK_SHIFT ) != 0 )
        message << "Shift-";
    if ( ( graphicsIn.state & PL_MASK_CAPS ) != 0 )
        message << "Caps Lock-";
    if ( ( graphicsIn.state & PL_MASK_CONTROL ) != 0 )
        message << "Ctrl-";
    if ( ( graphicsIn.state & PL_MASK_ALT ) != 0 )
        message << "Alt-";
    if ( ( graphicsIn.state & PL_MASK_NUM ) != 0 )
        message << "Num Lock-";
    if ( ( graphicsIn.state & PL_MASK_ALTGR ) != 0 )
        message << "Alt Gr-";
    if ( ( graphicsIn.state & PL_MASK_WIN ) != 0 )
        message << "Win-";
    if ( ( graphicsIn.state & PL_MASK_SCROLL ) != 0 )
        message << "Scroll Lock-";

    if ( graphicsIn.button == 1 )
        message << "Left click.\n";
    else if ( graphicsIn.button == 2 )
        message << "Middle click.\n";
    else if ( graphicsIn.button == 3 )
        message << "Right click.\n";
    message << "Pixels: x = " << graphicsIn.pX << " y = " << graphicsIn.pY << ".\n";
    if ( graphicsIn.subwindow >= 0 )
    {
        message << "World: x = " << graphicsIn.wX << " y = " << graphicsIn.wY << ".\n";
        message << "Window = " << graphicsIn.subwindow << ".\n";
    }
    else
    {
        message << "Point is not in a Window.\n";
    }
    wxMessageBox( message, "Mouse capture demo" );
}

template< class WXWINDOW >
void Plot( wxPLplotwindow<WXWINDOW> *plotwindow );

class MyApp : public wxApp
{
public:
    virtual bool OnInit();
};

IMPLEMENT_APP( MyApp )

//! This method is called right at the beginning and opens a frame for us.
//
bool MyApp::OnInit()
{
#ifdef __WXMAC__
    // this hack enables to have a GUI on Mac OSX even if the
    // program was called from the command line (and isn't a bundle)
    ProcessSerialNumber psn;

    GetCurrentProcess( &psn );
    CPSEnableForegroundOperation( &psn );
    SetFrontProcess( &psn );
#endif

    //There is only a default constructor for the wxPLplotwindow<> class
    //so we do two stage creation - first use default constructor, then
    //call Create.
    wxPLplotwindow<wxFrame> *frame = new wxPlDemoFrame();
    frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ));
    PLPLOT_wxLogDebug("frame->Create");
    //Now we can set up our frame and do the plotting
    frame->SetIcon( wxIcon( graph ) );
    frame->Show();
    Plot( frame );

    //note that all the code above starting from the Create() call could
    //instead go in the wxPlDemoFrame constructor should we wish. It is
    //entirely the user's choice.

    return true;
}

template< class WXWINDOW >
void Plot( wxPLplotwindow<WXWINDOW> *plotwindow )
{
  if (!plotwindow->IsReady())
  {
    wxMessageBox(wxT("Somehow we attempted to plot before the wxPLplotwindow was ready. The plot will not be drawn."));
    return;
  }
  wxPLplotstream* pls = plotwindow->GetStream();
  PLPLOT_wxLogDebug("Plot()");
    assert(pls);

    const size_t  np = 500;
    PLFLT         x[np], y[np];
    PLFLT         xmin, xmax;
    PLFLT         ymin = 1e30, ymax = 1e-30;

    xmin = -2.0;
    xmax = 10.0;
    for ( size_t i = 0; i < np; i++ )
    {
        x[i] = ( xmax - xmin ) * i / np + xmin;
        y[i] = 1.0;
        if ( x[i] != 0.0 )
            y[i] = sin( x[i] ) / x[i];
        ymin = MIN( ymin, y[i] );
        ymax = MAX( ymax, y[i] );
    }

    pls->adv( 0 );
    pls->col0( 1 );
    pls->env( xmin, xmax, ymin, ymax, 0, 0 );
    pls->col0( 2 );
    pls->lab( "x", "y", "sin(x)/x" );

    pls->col0( 3 );
    pls->width( 2 );
    pls->line( np, x, y );

    plotwindow->RenewPlot();
}

//
//class MyPlotwindow : public wxPLplotwindow
//{
//public:
//    MyPlotwindow( wxFrame* frame, wxWindow* parent, wxWindowID id = -1, const wxPoint& pos = wxDefaultPosition,
//                  const wxSize& size = wxDefaultSize, long style = 0,
//                  int pl_style = wxPLPLOT_NONE );
//
//    void OnChar( wxKeyEvent& event );
//
//private:
//    wxFrame* mframe;
//};
//
//
//// Define a new frame type: this is going to be our main frame
//class MyFrame : public wxFrame
//{
//public:
//    MyFrame( const wxString& title );
//    void Plot();
//
//private:
//    void OnQuit( wxCommandEvent& event );
//    void OnAbout( wxCommandEvent& event );
//    void OnBackgroundColor( wxCommandEvent& event );
//
//private:
//    MyPlotwindow* plotwindow;
//    bool        bgcolor;
//    int         m_backend;
//
//    DECLARE_EVENT_TABLE()
//};
//
//
//--------------------------------------------------------------------------
//// constants
//--------------------------------------------------------------------------
//enum { wxPLplotDemo_Quit    = wxID_EXIT, wxPLplotDemo_About = wxID_ABOUT,
//       wxPLplotDemo_BGColor = 10000 };
//
//--------------------------------------------------------------------------
//// event tables and other macros for wxWidgets
//--------------------------------------------------------------------------
//BEGIN_EVENT_TABLE( MyFrame, wxFrame )
//EVT_MENU( wxPLplotDemo_Quit, MyFrame::OnQuit )
//EVT_MENU( wxPLplotDemo_About, MyFrame::OnAbout )
//EVT_MENU( wxPLplotDemo_BGColor, MyFrame::OnBackgroundColor )
//END_EVENT_TABLE()
//
//
//--------------------------------------------------------------------------
//// implementation
//--------------------------------------------------------------------------
//
//
//
//MyPlotwindow::MyPlotwindow( wxFrame* frame, wxWindow* parent, wxWindowID id, const wxPoint& pos,
//                            const wxSize& size, long style, int pl_style ) :
//    wxPLplotwindow( parent, id, pos, size, style, pl_style )
//{
//    mframe = frame;
//}
//
//
//void MyPlotwindow::OnChar( wxKeyEvent& event )
//{
//    int keycode = event.GetKeyCode();
//
//    if ( keycode == WXK_RETURN ||
//         keycode == WXK_SPACE ||
//         keycode == WXK_RIGHT ||
//         keycode == WXK_ESCAPE )
//        mframe->Close( true );
//    else
//        event.Skip();
//}
//
//
////! Constructor of our custom frame, where the Menu is created and a
////  a wxPLplotwindow is inserted into the frame. We plot some easy functions
////  just to show how it works. wxPLplotwindow takes care of all the setup
////  for the use of PLplot library.
////
//MyFrame::MyFrame( const wxString& title ) : wxFrame( NULL, wxID_ANY, title )
//{
//    bgcolor = false;
//
//    // add menu
//    wxMenu *fileMenu = new wxMenu;
//    fileMenu->Append( wxPLplotDemo_BGColor, _T( "&Change background color...\tAlt-C" ), _T( "Change background color" ) );
//    fileMenu->Append( wxPLplotDemo_About, _T( "&About...\tF1" ), _T( "Show about dialog" ) );
//    fileMenu->Append( wxPLplotDemo_Quit, _T( "E&xit\tAlt-X" ), _T( "Quit this program" ) );
//
//    wxMenuBar *menuBar = new wxMenuBar();
//    menuBar->Append( fileMenu, _T( "&File" ) );
//    SetMenuBar( menuBar );
//    SetIcon( wxIcon( graph ) );
//
//    // add the wxPLplot
//    wxPanel   * panel = new wxPanel( this );
//    wxBoxSizer* box   = new wxBoxSizer( wxVERTICAL );
//    plotwindow = new MyPlotwindow( this, panel, -1, wxDefaultPosition, wxDefaultSize, wxWANTS_CHARS,
//#if wxUSE_GRAPHICS_CONTEXT
//        wxPLPLOT_BACKEND_GC | wxPLPLOT_DRAW_TEXT );
//#else
//        wxPLPLOT_BACKEND_AGG | wxPLPLOT_DRAW_TEXT );
//#endif
//    plotwindow->Connect( wxEVT_CHAR, wxKeyEventHandler( MyPlotwindow::OnChar ) );
//    box->Add( plotwindow, 1, wxALL | wxEXPAND, 0 );
//    panel->SetSizer( box );
//    SetSize( 640, 500 );      // set frame size
//    SetSizeHints( 220, 150 ); // set minimum frame size
//
//    wxString m_title = title;
//    switch ( plotwindow->getBackend() )
//    {
//    case wxPLPLOT_BACKEND_DC:
//        m_title += wxT( " (basic)" );
//        break;
//    case wxPLPLOT_BACKEND_GC:
//        m_title += wxT( " (wxGC)" );
//        break;
//    case wxPLPLOT_BACKEND_AGG:
//        m_title += wxT( " (AGG)" );
//        break;
//    default:
//        break;
//    }
//    SetTitle( m_title );
//
//    Plot();
//}
//
//void MyFrame::Plot()
//{
//    wxPLplotstream* pls = plotwindow->GetStream();
//
//    const size_t  np = 500;
//    PLFLT         x[np], y[np];
//    PLFLT         xmin, xmax;
//    PLFLT         ymin = 1e30, ymax = 1e-30;
//
//    xmin = -2.0;
//    xmax = 10.0;
//    for ( size_t i = 0; i < np; i++ )
//    {
//        x[i] = ( xmax - xmin ) * i / np + xmin;
//        y[i] = 1.0;
//        if ( x[i] != 0.0 )
//            y[i] = sin( x[i] ) / x[i];
//        ymin = MIN( ymin, y[i] );
//        ymax = MAX( ymax, y[i] );
//    }
//
//    pls->adv( 0 );
//    if ( bgcolor )
//    {
//        pls->scol0( 0, 255, 255, 255 );
//        pls->scol0( 15, 0, 0, 0 );
//    }
//    else
//    {
//        pls->scol0( 15, 255, 255, 255 );
//        pls->scol0( 0, 0, 0, 0 );
//    }
//    pls->col0( 1 );
//    pls->env( xmin, xmax, ymin, ymax, 0, 0 );
//    pls->col0( 2 );
//    pls->lab( "x", "y", "sin(x)/x" );
//
//    pls->col0( 3 );
//    pls->width( 2 );
//    pls->line( np, x, y );
//
//    plotwindow->RenewPlot();
//}
//
//
//void MyFrame::OnQuit( wxCommandEvent& WXUNUSED( event ) )
//{
//    Close( true );
//}
//
//
//void MyFrame::OnBackgroundColor( wxCommandEvent& WXUNUSED( event ) )
//{
//    bgcolor = !bgcolor;
//    Plot();
//}
//
//
////! Show information if Menu entry About was choosen.
////
//void MyFrame::OnAbout( wxCommandEvent& WXUNUSED( event ) )
//{
//    wxMessageBox( _T( "This is the About dialog of the wxPLplot demo.\n" ), _T( "About wxPLplot" ),
//        wxOK | wxICON_INFORMATION, this );
//}

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

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

Hi All

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

So, here goes

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

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

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

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

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

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

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

Does that seem sensible?

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

Phil

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

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

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

Phil

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

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

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

Hi Phil

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


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

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


yes, sounds good, thanks
-Pedro



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

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

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

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

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

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

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

To Phil and Pedro:

@Phil:

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

@Both:

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

@Phil:

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

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

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

Every tested platform that you add gives us just that much further
confidence that Phil's solution is robust for this release, and I
thank you in advance for all this essential testing work for our
release.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

Hi Alan

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

yes

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

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

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

output is attached

-Pedro


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

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

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

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

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

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

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

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

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

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

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

That looks promising 😊

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

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



Sent from my Windows 10 phone

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

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

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

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

To Phil and Pedro:

@Phil:

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

@Both:

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

@Phil:

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

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

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

Every tested platform that you add gives us just that much further
confidence that Phil's solution is robust for this release, and I
thank you in advance for all this essential testing work for our
release.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

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

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

Good idea.  So, yes please!

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

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

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

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

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

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


  That looks promising 😊

   

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

   

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

   

   

  Sent from my Windows 10 phone

   

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

   

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

   

  > Hi Phil

  > 

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

  > I'll test other Linux later

   

  > 

  >> So what I

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

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

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

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

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

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

  >> 

  >> Does that seem sensible?

  > 

   

  To Phil and Pedro:

   

  @Phil:

   

  The test_c_wxwidgets and test_wxPLplotDemo targets worked without

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

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

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

  release-critical bug fixing.

   

  @Both:

   

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

  of you.

   

  @Phil:

   

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

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

  sense that test_wxPLplotDemo now produces two identical plots for me,

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

  effect.

   

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

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

  solution.

   

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

  building the test_wxPLplotDemo target?  Please extend that test to

  building the test_c_wxwidgets target as well. You were already

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

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

  and test_c_wxwidgets targets) for all Linux platforms.  And similarly

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

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

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

  please also test your own software projects that link with the

  plplotwxwidgets library on all platforms where you expect your own

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

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

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

   

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

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

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

  release.

   

  Alan

  __________________________

  Alan W. Irwin

   

  Astronomical research affiliation with Department of Physics and Astronomy,

  University of Victoria (astrowww.phys.uvic.ca).

   

  Programming affiliations with the FreeEOS equation-of-state

  implementation for stellar interiors (freeeos.sf.net); the Time

  Ephemerides project (timeephem.sf.net); PLplot scientific plotting

  software package (plplot.sf.net); the libLASi project

  (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);

  and the Linux Brochure Project (lbproject.sf.net).

  __________________________

   

  Linux-powered Science

  __________________________

   

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

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

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

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

Hi Pedro:

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

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________