plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] build PLPlot with debug symbols in linux / cmake

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

Alan, Thanks
Phil (I am CC you here, because this is a wxdriver issue;
not saying that is a bug in the wxdriver, just a code error I have in my use 
of it )

The issue was not lack of -g, but just a code issue

I am following almost verbatim the demo wxPLplotDemo.cpp

what happens in my code is that

pls is NULL

here

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

so all pls-> calls seg fault


what happens is that this function is *not* called


void wxPLplotwindow<WXWINDOW>::OnCreate( wxWindowCreateEvent &event )
{
    if ( !m_created )


and it should have been in these calls


wxPLplotwindow<wxFrame> *frame = new wxPLplotwindow<wxFrame>();
  frame->Create(NULL, wxID_ANY, wxT("wxPLplotDemo"));
  frame->Show();
  Plot(frame);


This only happens in Linux, on Windows all is fine


so, I'll keep on debugging to see what is happening


by the way, since I am here, I have 2 small requests:

1) the wxdriver compilation has a couple of compiler warnings, would it be 
possible to eliminate them ?
2) would it be possible to keep in the upcoming version the old deprecated 
wxdriver code that is not templated ?
I find templated code difficult to follow and debug, and here there is no 
benefit in using it , because all my plots are in wxFrame

these are the warnings


M:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(181): warning C4100: 'event': 
unreferenced formal parameter (compiling source file wx_explorer_star.cpp)
  M:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(182): note: while compiling 
class template member function 'void 
wx_PLplotwindow<wxFramePlot>::OnCreate(wxWindowCreateEvent &)' (compiling 
source file wx_explorer_star.cpp)
  wx_explorer_star.cpp(860): note: see reference to class template 
instantiation 'wx_PLplotwindow<wxFramePlot>' being compiled
m:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(278): warning C4701: 
potentially uninitialized local variable 'drawDc' used
m:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(278): warning C4703: 
potentially uninitialized local pointer variable 'drawDc' used

for the first you can use the
WXUNUSED
 macro

like in
void wxFrameClient::OnQuit(wxCommandEvent& WXUNUSED(eve))

the others seem that you should see

m:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(278): warning C4701: 
potentially uninitialized local variable 'drawDc' used
m:\star_icvs\tools\wx_lib\wx_plplotwindow.hpp(278): warning C4703: 
potentially uninitialized local pointer variable 'drawDc' used


it says that the variables are not initialized and are potencially used


-Pedro

----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: <plp...@li...>
Sent: Thursday, December 08, 2016 1:59 PM
Subject: Re: [Plplot-devel] build PLPlot with debug symbols in linux / cmake


> On 2016-12-08 01:52-0500 Pedro Vicente wrote:
>
>>
>> Hi Alan
>>
>> I have a wxWidgets application that I developed for Windows and Linux 
>> that uses PLplot .
>>
>> I started having a segfault on the *Linux* only version.
>>
>> Debugging in Windows is a breeze with Visual Studio.
>>
>> For Linux I was able to make a QtCreator project to debug (yes, Qt 
>> debugging wxWidgets !)
>>
>> However when I try to step into the PLplot code, there is no step into, 
>> because probably debugging symbols were not built
>>
>> I used the following cmake call
>>
>> cmake ..  -G "Unix 
>> Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF 
>>  -DENABLE_tk:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/data/data127/pvicente/install/plplot-5.11.1 
>>  -DPL_HAVE_PTHREAD:BOOL=OFF -DPLD_xwin:BOOL=OFF -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0 
>>  -DwxWidgets_LIB_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0/lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF>>>>>> this is more probably a cmake question, but I am not that familiar withcmake, so the question is,>> how can I add debug symbols to PLPlot for  the above cmake call?>> Hi Pedro:>> I think there are some specific CMake options for making sure the -g> option is used on all compilations, but the one I always use is to set> the appropriate environment variables (which CMake recognizes as> well).  So before executing cmake in an initially empty build tree do> something like the following:>> export CXXFLAGS=-g> export CFLAGS=-g> export FFLAGS=-g>> I always just use the command line to build (with make) and debug> (with gdb) rather than some IDE like QtCreator, but I assume setting> the above environment variables will insure the QtCreator builds will> be done with the -g option so that you can debug (likely with gdb> doing the work in the background) with that IDE as well.>> Alan> __________________________> Alan W. Irwin>> Astronomical research affiliation with Department of Physics andAstronomy,> 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 with debug symbols in linux / cmake

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

On 2016-12-08 03:01-0500 Pedro Vicente wrote:

> I found out about the debug build cmake option, with
>
> cmake -DCMAKE_BUILD_TYPE=Debug ...

Yes, that was the name of the cmake option I was trying to remember in
my previous post.  But I have never tested that so there may be some
areas of our build system where that does not work correctly.

So I suggest you drop that option, and instead use the environment
variables I suggested (which always work for me with gdb).

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] plplot_pyqt4 shared object build issue

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

Hi Arjen:

On 2016-12-08 07:59-0000 Arjen Markus wrote:

> This visibility issue is one of obscurer aspects of today's
programming experience. It is akin to the import/export circus in
Windows DLLs. Always good for some puzzles.

Yes, and I have figured out this particular puzzle.  :-) The code generated by
automoc was not being compiled with -DUSINGDLL.  And that macro
is the essential trigger that allows us to specify visibility
support infrastructure in include/pldll.h.in and therefore visibility
of certain symbols throughout our code.

I have fixed that, but that involved a necessary style change (use
target properties rather than source code properties to set up
-DUSINGDLL) that I liked so much that I changed to that style
everywhere in our build system. Then I did a comprehensive test with
no constraints (i.e., of all interactive and noninteractive components
of PLplot) which revealed other issues.  I don't think those issues
are related to that style change, but nevertheless I want to get those
straightened out and completely tested before committing the style
change.  So hopefully I will be able to get this committed today, but
it might be tomorrow.

By the way, on the visibility issue, the Linux gcc developers are
firmly in Microsoft's corner on this (or at least the default no
exporting of symbols so developers have to specific about exactly
which symbols can be exported from a library).  The reason is extra
unused symbols that are exported for no reason make loading the
library more time consuming and increase the chances of nameclashes
between the same symbol name being used by two separate libraries.  So
this is a case where Microsoft got it right, and Linux has been
playing catch up with the gcc and g++ -fvisibility=hidden option.
Note, that is still just an option though, and if you don't specify
it, Linux libraries by default export all symbols which is a bad thing
so at some point (unless POSIX forbids it) I think -fvisibility=hidden
will become the default for gcc and g++.  Which would mean all Linux
developers (just like developers on Windows platforms) would have to
be aware of library symbol visibility issues from the start (which
would probably be a good thing).

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 with debug symbols in linux / cmake

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

On 2016-12-08 01:52-0500 Pedro Vicente wrote:

>
> Hi Alan
>
> I have a wxWidgets application that I developed for Windows and Linux that uses PLplot .
>
> I started having a segfault on the *Linux* only version.
>
> Debugging in Windows is a breeze with Visual Studio.
>
> For Linux I was able to make a QtCreator project to debug (yes, Qt debugging wxWidgets !)
>
> However when I try to step into the PLplot code, there is no step into, because probably debugging symbols were not built
>
> I used the following cmake call
>
> cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/data/data127/pvicente/install/plplot-5.11.1 -DPL_HAVE_PTHREAD:BOOL=OFF -DPLD_xwin:BOOL=OFF -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0 -DwxWidgets_LIB_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0/lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>
>
> this is more probably a cmake question, but I am not that familiar with cmake, so the question is,
> how can I add debug symbols to PLPlot for  the above cmake call?

Hi Pedro:

I think there are some specific CMake options for making sure the -g
option is used on all compilations, but the one I always use is to set
the appropriate environment variables (which CMake recognizes as
well).  So before executing cmake in an initially empty build tree do
something like the following:

export CXXFLAGS=-g
export CFLAGS=-g
export FFLAGS=-g

I always just use the command line to build (with make) and debug
(with gdb) rather than some IDE like QtCreator, but I assume setting
the above environment variables will insure the QtCreator builds will
be done with the -g option so that you can debug (likely with gdb
doing the work in the background) with that IDE as well.

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

[Laurent B. <lau...@un...>]

Hi,

I want to buil plplot in static using MSYS makefiles on windows 10.

In cmake GUI i have got an error that I cannot understand. wxWidgets is 
found but there is cmake_link_flags WARNING.

Any help would be appreciate.

CMake version = 3.7.0-rc2

CMAKE_SYSTEM_NAME = Windows

SH_EXECUTABLE = C:/Windows/System32/bash.exe....

Looking for gdi32 header and library

Looking for gdi32 header and library - found

wxWidgets_FOUND : TRUE

wxWidgets_INCLUDE_DIRS : 
F:/lib/wxWidgets-3.1.0/lib/wx/include/msw-unicode-static-3.1;F:/lib/wxWidgets-3.1.0/include

wxWidgets_LIBRARY_DIRS : /f/lib/wxWidgets-3.1.0/lib

wxWidgets_LIBRARIES : 
-L/f/lib/wxWidgets-3.1.0/lib;;;-Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;-lwxregexu-3.1;-lwxexpat-3.1;-lwxtiff-3.1;-lwxjpeg-3.1;-lwxpng-3.1;-lz;-lrpcrt4;-loleaut32;-lole32;-luuid;-lwinspool;-lwinmm;-lshell32;-lshlwapi;-lcomctl32;-lcomdlg32;-ladvapi32;-lversion;-lwsock32;-lgdi32

wxWidgets_CXX_FLAGS : -I/f/lib/wxWidgets-3.1.0/include

wxWidgets_USE_FILE : UsewxWidgets

cmake_link_flags WARNING: (original link flags) = 
-L/f/lib/wxWidgets-3.1.0/lib;;;-Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;-lwxregexu-3.1;-lwxexpat-3.1;-lwxtiff-3.1;-lwxjpeg-3.1;-lwxpng-3.1;-lz;-lrpcrt4;-loleaut32;-lole32;-luuid;-lwinspool;-lwinmm;-lshell32;-lshlwapi;-lcomctl32;-lcomdlg32;-ladvapi32;-lversion;-lwsock32;-lgdi32

cmake_link_flags WARNING: wxwidgets_LINK_FLAGS = 
-Wl,--subsystem,windows;-mwindows;/f/lib/wxWidgets-3.1.0/lib/libwx_mswu_core-3.1.a;/f/lib/wxWidgets-3.1.0/lib/libwx_baseu-3.1.a;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;F:/mingw-w64/Strawberry/c/lib/libz.a;C:/Windows/System32/rpcrt4.dll;C:/Windows/System32/oleaut32.dll;C:/Windows/System32/ole32.dll;_library_pathname-NOTFOUND;_library_pathname-NOTFOUND;C:/Windows/System32/winmm.dll;C:/Windows/System32/shell32.dll;C:/Windows/System32/shlwapi.dll;C:/Windows/System32/comctl32.dll;C:/Windows/System32/comdlg32.dll;C:/Windows/System32/advapi32.dll;C:/Windows/System32/version.dll;C:/Windows/System32/wsock32.dll;C:/Windows/System32/gdi32.dll

cmake_link_flags WARNING: wxwidgets_LINK_FLAGS is invalid so it is set 
to nothing to signal the failure of cmake_link_flags for the original 
link flags printed out above.

WARNING: wxWidgets or its libraries not found so setting all wxwidgets 
devices to OFF.

WARNING: ENABLE_wxwidgets is OFF so setting all wxwidgets devices to OFF.

Re: [Plplot-devel] build PLPlot with debug symbols in linux / cmake

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

I found out about the debug build cmake option, with

cmake -DCMAKE_BUILD_TYPE=Debug ...and I was able to get into the PLlot code, at least someI replaced the code with the code from the PLplot wxwidgets demo, just to make sure the error is not on my code.and the stack call isvoid Plot(wxPLplotwindow<WXWINDOW> *plotwindow){wxPLplotstream* pls = plotwindow->GetStream();...pls->adv( 0 );then inside adv()plstream::adv( PLINT page ){set_stream();the segmentation fault happens herehowever in the linux build I *cannot* step into set_stream();I wonder why, I was able to step into here but not further , it makes no senseCould it be because of the use of templates in the PLPlot wxWidgets code?----- Original Message ----- 
  From: Pedro Vicente 
  To: plp...@li... 
  Sent: Thursday, December 08, 2016 1:52 AM
  Subject: [Plplot-devel] build PLPlot with debug symbols in linux / cmake



  Hi Alan

  I have a wxWidgets application that I developed for Windows and Linux that uses PLplot .

  I started having a segfault on the *Linux* only version.

  Debugging in Windows is a breeze with Visual Studio.

  For Linux I was able to make a QtCreator project to debug (yes, Qt debugging wxWidgets !)

  However when I try to step into the PLplot code, there is no step into, because probably debugging symbols were not built

  I used the following cmake call

  cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/data/data127/pvicente/install/plplot-5.11.1 -DPL_HAVE_PTHREAD:BOOL=OFF -DPLD_xwin:BOOL=OFF -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0 -DwxWidgets_LIB_DIR:PATH=/data/data127/pvicente/install/wxwidgets-3.1.0/lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF


  this is more probably a cmake question, but I am not that familiar with cmake, so the question is, 
  how can I add debug symbols to PLPlot for  the above cmake call?

  The code is attached 

  The segfault happens when I try to get into the init() call here

  wx_PLplotstream* pls = frame->GetStream();
  pls->init();

  The weird thing is that I have nearly identical code for other application that works fine

  when I was learning the PLplot code , and the app was just exiting for unknow reasons I found out that the init() call is dependent on at least 2 pallete and 2 font

  files to read from several "standard" locations.

  Since I develop cross platforms and in many machines I ended up doing a svn repository with those 4 files at the same location as the program, like that they are always found.

  but that is not the cause here, because those file are found (by the way, is there a way to eliminate the need to read those files?)

  The Qt project is also attached in case anyone needs a Qt project to debug wxWidgets and PLPlot

  thanks

  -Pedro







------------------------------------------------------------------------------


  ------------------------------------------------------------------------------
  Developer Access Program for Intel Xeon Phi Processors
  Access to Intel Xeon Phi processor-based developer platforms.
  With one year of Intel Parallel Studio XE.
  Training and support from Colfax.
  Order your platform today.http://sdm.link/xeonphi


------------------------------------------------------------------------------


  _______________________________________________
  Plplot-devel mailing list
  Plp...@li...
  https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plplot_pyqt4 shared object build issue

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, December 07, 2016 10:10 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: plplot_pyqt4 shared object build issue
>
> Hi Arjen:
>
> Never mind about my request for you to do some nm experiments.  (Although you
> might want to do those experiments in any case just to familiarize yourself with this
> very helpful tool for figuring out such undefined reference issues.)
>
I am familiar with the basic usage of nm, but mostly to inspect if a particular symbol is or is not present in the library - and my experience with C++ in combination with nm is really minimal (the name mangling is daunting! Glad to see nm can undo that).

This visibility issue is one of obscurer aspects of today's programming experience. It is akin to the import/export circus in Windows DLLs. Always good for some puzzles.

Anyway, I will wait for your further results in this.

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.

[Plplot-devel] build PLPlot with debug symbols in linux / cmake

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

#include <assert.h>
#include <jansson.h>
#include "wx/wxprec.h"
#include "wx/wx.h"
//icons
#include "icons/sample.xpm"
#include "icons/back.xpm"
#include "icons/forward.xpm"
#include "icons/doc_blue.xpm"
#ifdef HAVE_VLD
#include "vld.h"
#endif
//local
#include "wx_thread.hh"
#include "wx_client.hh"
#include "socket.hh"
#include "rdr_read.hh"
//plot
#ifdef HAVE_PLPLOT_WX
#include "wx_plplotwindow.hpp"
template< class WXWINDOW >
void plot_points(wx_PLplotwindow<WXWINDOW> *plotwindow);
template< class WXWINDOW >
void plot_bars(wx_PLplotwindow<WXWINDOW> *plotwindow);
#endif

const unsigned short port = 2000;

/////////////////////////////////////////////////////////////////////////////////////////////////////
//get_app_name
/////////////////////////////////////////////////////////////////////////////////////////////////////

wxString get_app_name()
{
  wxString str(wxT("STAR Reader"));
  return str;
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxAppClient
/////////////////////////////////////////////////////////////////////////////////////////////////////

wxIMPLEMENT_APP(wxAppClient);

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxAppClient::OnInit()
/////////////////////////////////////////////////////////////////////////////////////////////////////

bool wxAppClient::OnInit()
{
  if (!wxApp::OnInit())
  {
    return false;
  }
  wxFrameClient *frame = new wxFrameClient();
  frame->Show(true);
  frame->Maximize();
  return true;
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::wxFrameClient
//Note: set size to 1000 to avoid Gtk-CRITICAL IA__gtk_widget_set_size_request
/////////////////////////////////////////////////////////////////////////////////////////////////////

wxBEGIN_EVENT_TABLE(wxFrameClient, wxMDIParentFrame)
EVT_CLOSE(wxFrameClient::OnClose)
EVT_MENU(wxID_EXIT, wxFrameClient::OnQuit)
EVT_MENU(wxID_ABOUT, wxFrameClient::OnAbout)
EVT_MENU(ID_WINDOW_FRAME_GRID, wxFrameClient::event_grid)
EVT_MENU(ID_WINDOW_FRAME_PLOT_POINT, wxFrameClient::event_plot_point)
EVT_SIZE(wxFrameClient::OnSize)
EVT_CALENDAR_SEL_CHANGED(ID_CALENDAR_START, wxFrameClient::event_calendar_start_change)
EVT_CALENDAR_SEL_CHANGED(ID_CALENDAR_END, wxFrameClient::event_calendar_end_change)
EVT_TEXT_ENTER(ID_WINDOW_TOOLBAR_TEXTCTRL_SERVER, wxFrameClient::event_textctrl_server)
EVT_COMMAND(wxID_ANY, EVENT_STATUS_BAR, wxFrameClient::update_status_bar)
EVT_COMMAND(wxID_ANY, EVENT_GAUGE_VALUE, wxFrameClient::update_gauge_value)
EVT_COMMAND(wxID_ANY, EVENT_GAUGE_RANGE, wxFrameClient::update_gauge_range)
EVT_COMMAND(wxID_ANY, EVENT_SET_DATA, wxFrameClient::update_set_data)
wxEND_EVENT_TABLE()

wxFrameClient::wxFrameClient() :
  wxMDIParentFrame(NULL, wxID_ANY, get_app_name(), wxPoint(0, 0), wxSize(1000, 840)),
  m_thread(NULL)
{
  int w, h;
  GetClientSize(&w, &h);
  wxSashLayoutWindow* win;

  SetIcon(wxICON(sample));

  /////////////////////////////////////////////////////////////////////////////////////////////////////
  //menu
  /////////////////////////////////////////////////////////////////////////////////////////////////////

  wxMenu *menu_file = new wxMenu;
  menu_file->Append(wxID_EXIT, "E&xit\tAlt-X", "Quit this program");
  wxMenu *menu_data = new wxMenu;
  menu_data->Append(ID_WINDOW_FRAME_GRID, "Show &Grid", "Show grid");
  menu_data->Append(ID_WINDOW_FRAME_PLOT_POINT, "Show &Point plot", "Show point plot");
  wxMenu *menu_help = new wxMenu;
  menu_help->Append(wxID_ABOUT, "&About\tF1", "Show about dialog");

  wxMenuBar *menu_bar = new wxMenuBar();
  menu_bar->Append(menu_file, "&File");
  menu_bar->Append(menu_data, "&Data");
  menu_bar->Append(menu_help, "&Help");
  SetMenuBar(menu_bar);
  CreateStatusBar(2);
  SetStatusText("Ready");

  /////////////////////////////////////////////////////////////////////////////////////////////////////
  //calendar pane
  /////////////////////////////////////////////////////////////////////////////////////////////////////

  win = new wxSashLayoutWindow(this, ID_WINDOW_SASH_CALENDAR, wxDefaultPosition, wxDefaultSize, wxNO_BORDER | wxSW_3D | wxCLIP_CHILDREN);
  win->SetDefaultSize(wxSize(300, h));
  win->SetOrientation(wxLAYOUT_VERTICAL);
  win->SetAlignment(wxLAYOUT_RIGHT);
  win->SetSashVisible(wxSASH_RIGHT, true);
  win->SetExtraBorderSize(10);
  win->SetMinimumSizeX(100);
  win->SetBackgroundColour(*wxWHITE);

  m_sash_calendar = win;

  m_date_start.Set(30, wxDateTime::May, 2016, 0, 0, 0, 0);
  m_date_end.Set(1, wxDateTime::Jun, 2016, 0, 0, 0, 0);
  m_panel = new PanelCalendar(m_sash_calendar, m_date_start, m_date_end);

  /////////////////////////////////////////////////////////////////////////////////////////////////////
  //toolbar
  /////////////////////////////////////////////////////////////////////////////////////////////////////

  wxToolBar* toolbar = CreateToolBar();

  wxArrayString strings;
  strings.Add(wxT("173.66.46.228"));
  strings.Add(wxT("127.0.0.1"));
  strings.Add(wxT("rhw9121.star1.nesdis.noaa.gov"));
  m_textctrl_server = new wxTextCtrl(toolbar, ID_WINDOW_TOOLBAR_TEXTCTRL_SERVER, strings[1], wxDefaultPosition, wxSize(500, -1), wxTE_PROCESS_ENTER);
  toolbar->AddControl(m_textctrl_server);
  toolbar->AddSeparator();

  m_gauge = new wxGauge();
  wxSize size = m_textctrl_server->GetSize();
  size.SetWidth(size.GetWidth());
  m_gauge->Create(toolbar, ID_WINDOW_TOOLBAR_GAUGE, 0, wxDefaultPosition, wxSize(size), wxGA_HORIZONTAL | wxGA_SMOOTH);
  toolbar->AddControl(m_gauge);
  toolbar->Realize();
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::~wxFrameClient
/////////////////////////////////////////////////////////////////////////////////////////////////////

wxFrameClient::~wxFrameClient()
{
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::OnClose
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::OnClose(wxCloseEvent&)
{
  {
    wxCriticalSectionLocker enter(m_critical_section);
    if (m_thread)
    {
      m_thread->Delete();
    }
  }
  // exit from the critical section to give the thread
  // the possibility to enter its destructor
  while (1)
  {
    {
      wxCriticalSectionLocker enter(m_critical_section);
      if (!m_thread) break;
    }
    // wait for thread completion
    wxThread::This()->Sleep(1);
  }
  Destroy();
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::OnSize
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::OnSize(wxSizeEvent& WXUNUSED(eve))
{
  wxLayoutAlgorithm layout;
  layout.LayoutMDIFrame(this);
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::OnQuit
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::OnQuit(wxCommandEvent& WXUNUSED(eve))
{
  Close(true);
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::OnAbout
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::OnAbout(wxCommandEvent& WXUNUSED(eve))
{
  wxMessageBox("NOAA ICVS\n\n", get_app_name(), wxOK, this);
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::event_calendar_start_change
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::event_calendar_start_change(wxCalendarEvent& event)
{
  wxString str;
  m_date_start = event.GetDate();
  str.Printf(wxT("Start date: %s"), m_date_start.FormatISODate().c_str());
  m_panel->m_text_start->SetLabel(str);
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::event_calendar_end_change
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::event_calendar_end_change(wxCalendarEvent& event)
{
  wxString str;
  m_date_end = event.GetDate();
  str.Printf(wxT("End date: %s"), m_date_end.FormatISODate().c_str());
  m_panel->m_text_end->SetLabel(str);
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::event_textctrl_server
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::event_textctrl_server(wxCommandEvent& WXUNUSED(eve))
{
  m_gauge->SetRange(1);
  m_gauge->Pulse();
  m_thread = new wxThreadReceive(this, m_textctrl_server->GetValue());
  wxThreadError err = m_thread->Create();
  err = m_thread->Run();
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::update_status_bar
//called when the event from the thread is received
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::update_status_bar(wxCommandEvent& evt)
{
  GetStatusBar()->SetStatusText(evt.GetString());
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::update_gauge_value
//called when the event from the thread is received
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::update_gauge_value(wxCommandEvent& evt)
{
  m_gauge->SetValue(evt.GetInt());
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::update_gauge_range
//called when the event from the thread is received
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::update_gauge_range(wxCommandEvent& evt)
{
  m_gauge->SetRange(evt.GetInt());
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::update_set_data
//called when the event from the thread is received
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::update_set_data(wxCommandEvent& evt)
{
  //delete data from previous request, if any
  m_vec_current_anomaly.clear();
  json_t *response_orbit = (json_t *)evt.GetClientData();

  //parse JSON
  json_t *json_object = json_object_get(response_orbit, "current_anomaly");
  assert(json_is_object(json_object));
  const char *json_key;
  json_t *json_value;
  json_object_foreach(json_object, json_key, json_value)
  {
    size_t size_arr = json_array_size(json_value);
    assert(size_arr == 7);
    orbit_current_anomaly_t oc(
      static_cast<int>(json_integer_value(json_array_get(json_value, 0))), //orbit_number
      static_cast<int>(json_integer_value(json_array_get(json_value, 1))), //year
      static_cast<int>(json_integer_value(json_array_get(json_value, 2))), //month
      static_cast<int>(json_integer_value(json_array_get(json_value, 3))), //day
      json_real_value(json_array_get(json_value, 4)), //mean
      json_real_value(json_array_get(json_value, 5)), //max
      json_real_value(json_array_get(json_value, 6))); //min
    m_vec_current_anomaly.push_back(oc);
  }

  json_decref(response_orbit);
  wxFrameGrid *subframe = new wxFrameGrid(this, "Grid");
  subframe->Show(true);
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::event_grid
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::event_grid(wxCommandEvent& WXUNUSED(eve))
{
  if (m_vec_current_anomaly.size())
  {
    wxFrameGrid *subframe = new wxFrameGrid(this, "Grid");
    subframe->Show(true);
  }
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxGridOrbit::wxGridOrbit
/////////////////////////////////////////////////////////////////////////////////////////////////////

wxBEGIN_EVENT_TABLE(wxGridOrbit, wxGrid)
wxEND_EVENT_TABLE()

wxGridOrbit::wxGridOrbit(wxWindow *parent, const wxSize& size) :
  wxGrid(parent, wxID_ANY, wxPoint(0, 0), size, wxNO_BORDER)
{
  wxFrameGrid *frame = (wxFrameGrid*)GetParent();
  wxFrameClient *main = (wxFrameClient*)frame->GetParent();
  std::vector<orbit_current_anomaly_t> &orbit = main->m_vec_current_anomaly;

  /////////////////////////////////////////////////////////////////////////////////////////////////////
  //define grid
  /////////////////////////////////////////////////////////////////////////////////////////////////////

  m_nbr_rows = orbit.size();
  m_nbr_cols = 5;
  this->CreateGrid(m_nbr_rows, m_nbr_cols);
  this->MakeGrid(orbit);
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxGridOrbit::~wxGridOrbit
/////////////////////////////////////////////////////////////////////////////////////////////////////

wxGridOrbit::~wxGridOrbit()
{
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxGridOrbit::MakeGrid
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxGridOrbit::MakeGrid(const std::vector<orbit_current_anomaly_t> &orbit)
{
  this->SetColSize(0, 200);
  this->SetColSize(1, 150);
  this->SetColSize(2, 150);
  this->SetColSize(3, 150);
  this->SetColSize(4, 150);
  this->SetColLabelValue(0, wxT("Orbit number"));
  this->SetColLabelValue(1, wxT("Date"));
  this->SetColLabelValue(2, wxT("Mean"));
  this->SetColLabelValue(3, wxT("Maximum"));
  this->SetColLabelValue(4, wxT("Minimum"));

  for (int idx_row = 0; idx_row < m_nbr_rows; idx_row++)
  {
    orbit_current_anomaly_t ob = orbit.at(idx_row);
    this->SetCellValue(idx_row, 0, wxString::Format(wxT("%i"), ob.orbit_number));
    wxDateTime dt;
    dt.Set(ob.day, (wxDateTime::Month)(ob.month - 1), ob.year, 0, 0, 0, 0);
    this->SetCellValue(idx_row, 1, dt.FormatISODate());
    this->SetCellValue(idx_row, 2, wxString::Format(wxT("%f"), ob.mean));
    this->SetCellValue(idx_row, 3, wxString::Format(wxT("%f"), ob.maximum));
    this->SetCellValue(idx_row, 4, wxString::Format(wxT("%f"), ob.minimum));
  }
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameGrid::wxFrameGrid
/////////////////////////////////////////////////////////////////////////////////////////////////////

wxBEGIN_EVENT_TABLE(wxFrameGrid, wxFrame)
EVT_MENU(ID_WINDOW_GRID_QUIT, wxFrameGrid::OnQuit)
wxEND_EVENT_TABLE()

wxFrameGrid::wxFrameGrid(wxMDIParentFrame *parent, const wxString& title) :
  wxFrame(parent, wxID_ANY, title, wxDefaultPosition, wxDefaultSize, wxDEFAULT_FRAME_STYLE | wxNO_FULL_REPAINT_ON_RESIZE | wxFRAME_FLOAT_ON_PARENT)
{
  SetIcon(wxICON(sample));
  m_grid = new wxGridOrbit(this, GetClientSize());
  Raise();
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameGrid::OnActivate
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameGrid::OnActivate(wxActivateEvent& event)
{
  if (event.GetActive() && m_grid)
    m_grid->SetFocus();
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameGrid::OnQuit
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameGrid::OnQuit(wxCommandEvent& WXUNUSED(eve))
{
  Close(true);
}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//wxFrameClient::event_plot_point
/////////////////////////////////////////////////////////////////////////////////////////////////////

void wxFrameClient::event_plot_point(wxCommandEvent& WXUNUSED(eve))
{
  wx_PLplotwindow<wxFrame> *frame = new wx_PLplotwindow<wxFrame>();

  frame->Create(this,
    wxID_ANY,
    "Plot",
    wxDefaultPosition,
    wxSize(900, 700),
    wxDEFAULT_FRAME_STYLE | wxNO_FULL_REPAINT_ON_RESIZE | wxFRAME_FLOAT_ON_PARENT);
  frame->Show(true);

  wx_PLplotstream* pls = frame->GetStream();
  pls->init();

  pls->adv(0);
  pls->scol0(0, 255, 255, 255);
  pls->clear();
  pls->scol0(1, 0, 0, 0);

  plot_points(frame);

}

/////////////////////////////////////////////////////////////////////////////////////////////////////
//plot_points
/////////////////////////////////////////////////////////////////////////////////////////////////////

#ifdef HAVE_PLPLOT_WX
template< class WXWINDOW >
void plot_points(wx_PLplotwindow<WXWINDOW> *plotwindow)
{
  wxFrameClient* frame = (wxFrameClient*)plotwindow->GetParent();
  std::vector<orbit_current_anomaly_t> &ob = frame->m_vec_current_anomaly;

  wx_PLplotstream* pls = plotwindow->GetStream();
  const int NSIZE = ob.size();
  PLFLT xmin, xmax, ymin, ymax;
  PLFLT *x, *y;
  xmin = 0;
  xmax = NSIZE;
  ymin = -0.5;
  ymax = 5.0;
  x = new PLFLT[NSIZE];
  y = new PLFLT[NSIZE];

  pls->schr(0, 1.2);
  pls->col0(1);
  pls->env(xmin, xmax, ymin, ymax, 0, 0);
  pls->lab("", "Current (Amps)", "Scan Drive Main Motor Current");

  //time axis
  for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
  {
    x[idx_orb] = idx_orb;
  }

  //mean
  pls->col0(1); //black
  for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
  {
    y[idx_orb] = ob[idx_orb].mean;
  }
  pls->poin(NSIZE, x, y, 46);

  //max
  for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
  {
    y[idx_orb] = ob[idx_orb].maximum;
  }
  pls->col0(9); //blue
  pls->poin(NSIZE, x, y, 46);

  //min
  for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
  {
    y[idx_orb] = ob[idx_orb].minimum;
  }
  pls->col0(9);
  pls->poin(NSIZE, x, y, 46);

  delete[] x;
  delete[] y;
  plotwindow->RenewPlot();
}
#endif

Re: [Plplot-devel] plplot_pyqt4 shared object build issue

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

Hi Arjen:

Never mind about my request for you to do some nm experiments.  (Although you
might want to do those experiments in any case just to familiarize yourself with
this very helpful tool for figuring out such undefined reference issues.)

>From my recent experiments here, I am virtually positive the issue
concerns my workaround (in the plplot_pyqt4 shared object build) for a
symbol visibility issue that was showing up on Linux.  That shared
object links to the plplotqt library which does define the appropriate
moc-generated symbols.  But those symbols were not visible (for the
g++ -fvisibility=hidden option which more or less mimics the Windows
visibility case) for my new automoc approach for running moc. So
linking failed on Linux for plplot_pyqt4, and to work around that issue, I
regenerated the moc results again specifically for plplot_pyqt4.  That
workaround worked here on Linux but obviously does not work on Cygwin
for some reason that lots of nm investigation may eventually discover.

But I don't care anymore (except for my curiosity which I don't have
time to indulge right now) because the real issue is the
visibility one for the plplotqt library, and it turns out my old
method of moc generation did not have that visibility issue (and
your old reports confirm in that case your build of the plplot_pyqt4
shared object went smoothly with that method, and I had similar
success here on Linux).

Furthermore, I have git bisected the visibility issue for the plplotqt
library on a particular moc-generated symbol for that library, and
indeed the first commit where the problem occurs corresponds exactly
with when I switched from the old moc-generation method to the automoc
approach.

So my choices are to go back to the old method (which I don't
particularly want to do because it is much clumsier than automoc) or
figure out how to make the automoc-generated results for
the plplotqt library visible on Linux.  (By the way, the automoc generated
result for the plplotqt library results in a build of that library
with no issues on Cygwin.  So there is nothing wrong there with
automoc-generated results for that library other than their visibility to
other software, e.g., the plplot_pyqt4 shared object.)

Note also that plplot_pyqt5 has exactly the same issue (for
the case where our qt device driver and plplotqt library are
linked with Qt5).

Anyhow, I hope to resolve this moc-generated symbol visibility issue
for the plplotqt library today with one of the two methods above, and
once that is done the build of the plplot_pyqt[45] shared objects
should go well on both Linux and Cygwin without any build workarounds
for plplot_pyqt[45].

More later....

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] plplot_pyqt4 shared object build issue

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

On 2016-12-07 08:43-0000 Arjen Markus wrote:

> Here is the report from the comprehensive test script. A link error
on PyQt4 made it stop prematurely. I will take the other steps on
Friday.

Hi Arjen:

Thanks for that quick response.  As you could tell it is the same
undefined reference result for a symbol that should be defined within
the library itself!  That is, this result is exactly as before
(without the jumbling). I was afraid dropping the -j4 would not solve
the issue, but thanks for at least trying that experiment even though
it did not solve the undefined reference problem.

So analysis of what is causing that undefined reference should be your
next step, and my experience is the "nm" command is ideal for that
task. So I hope you can use that to figure this all out on Friday
following what I did here, but by all means if there is another tool
you like to use to analyze these undefined reference issues, use that
as well to confirm the nm results (just in case nm is not reliable on
Cygwin).

I am looking forward to hearing back from you on Friday with lots of
results from your investigation of this issue.

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] plplot_pyqt4 shared object build issue

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

Hi Alan,



Here is the report from the comprehensive test script. A link error on PyQt4 made it stop prematurely. I will take the other steps on Friday.



Regards,

Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, December 07, 2016 8:28 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: plplot_pyqt4 shared object build issue
>
> On 2016-12-01 08:31-0000 Arjen Markus wrote:
>
> [...]
>
> > I am not sure about the PyQt4 component. But
> when I tried to do it via the comprehensive test script, I got compilation errors - see
> the attached tarball.
>
> Hi Arjen:
>
> Now that I have finally had a chance to look at your report, it appears to me you
> have found something release critical so suddenly time is of the essence.  Sorry
> about that....  These things always seem to happen whenever you think you can
> relax near a release date.
> :-)
>
> The first issue is you used the default -j4 for make (and likely ctest as well if you
> had gotten that far).  I believe you have found in the past those intermittently failed
> for Cygwin so from now on please automate your invocation script for
> scripts/comprehensive_test.sh to always drop the -j4 arguments (by specifying the
> script options --build_command make --ctest_command ctest) so this issue never
> crops up again.
>
> I doubt the -j4 option on the make command (which after all normally only causes
> intermittent issues) was the cause of the present issue, but you never know so
> please try the same comprehensive test run again with the above issue fixed.  If
> that shows good results we are done.
>
> But if not, and the "undefined reference" remains, please read on and send me
> back the latest report tarball (which will be a lot more understandable without -j4 in
> any case) and the requested other results below which I summarize at the end.
>
> Your current report is giving me some results I don't understand, but the issue is
> occurring exactly where I recently changed our build system so with the release
> coming up I hope you can quickly reply to this post.
>
> The overview is that I can build the plplot_pyqt4 shared object here (called
> dll/plplot_pyqt4.pyd there and bindings/qt_gui/pyqt4/plplot_pyqt4.so here), and what
> I believe is the equivalent symbol that is undefined for your shared object is defined
> in my shared object according to "nm". Furthermore, the reason for this good result
> here is the symbol is actually defined in the object
> bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o
> (named that both here and there) which is included by the linker here into the
> plplot_pyqt4 shared object here and also the same there.
> (This is exactly the way the new AUTOMOC procedure that generates
> plplot_pyqt4_automoc.cpp.o is supposed to work.)
>
> Note the actual command that failed (from the make.out file that was jumbled by
> the above -j4 option, but I have excised some things to reduce the source of that
> confusion) was
>
> Linking CXX shared module ../../../dll/plplot_pyqt4.pyd [...] Entering directory
> '/cygdrive/d/plplot-
> svn/comprehensive_test_disposeable/shared/noninteractive/build_tree'
> /usr/bin/c++.exe     -shared -Wl,--enable-auto-import -o ../../../dll/plplot_pyqt4.pyd -
> Wl,--major-image-version,0,--minor-image-version,0
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4cmodule.cpp.o
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtPLDriver.cpp.o
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtPLWidget.cpp.o
> CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o ../../../dll/libplplotqt.dll.a ../.
> ./../dll/libplplot.dll.a -lpython2.7 -lQtSvg -lQtGui -lQtCore -lltdl -Wl,-Bstatic -ldl -lshp -
> Wl,-Bdynamic -lfreetype ../../../dll/libcsirocsa.dll.a ../../../dll/libcsironn.dll.a -
> lqhull ../../../dll/libqsastime.dll.a
> [...]
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o:sipplplot_pyqt4QtExt
> Widget.cpp:(.text+0x1ed): undefined reference to
> `__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv'
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o:sipplplot_pyqt4QtExt
> Widget.cpp:(.text+0x1ed): relocation truncated to fit: R_X86_64_PC32 against
> undefined symbol
> `__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv'
> [...] + other undefined references
>
> Here are the nm results for that first undefined reference
> (__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv) in a
> similar build I did here.  The mangled and demangled results here are
>
> software@raven> nm --defined-only bindings/qt_gui/pyqt4/plplot_pyqt4.so |grep
> 11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
> 000000000001b640 t
> _ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
> software@raven> nm --defined-only --demangle
> bindings/qt_gui/pyqt4/plplot_pyqt4.so |grep 'QtExtWidget.*qt_meta.*QMetaObject'
> 000000000001b640 t QtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
> 00000000000089f0 t sipQtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
>
> software@raven> nm --defined-only
> bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o
> |grep 11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
> 0000000000000490 T
> _ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
>
> software@raven> nm --defined-only --demangle
> bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o |
> grep 'QtExtWidget.*qt_metacall.*QMetaObject'
> 0000000000000490 T QtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
>
> The common locations 1b640 in the first set and 490 in the second set tell you
> which demangled symbol corresponds to the mangled one.
>
> I looked for "QMetaObject::Call" in the moc-generated code that is compiled here
> (and there?) to create the object file plplot_pyqt4_automoc.cpp.o with the following
> results:
>
> software@raven> grep QMetaObject::Call
> bindings/qt_gui/pyqt4/plplot_pyqt4_automoc.dir/include/moc_qt.cpp
> void MasterHandler::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id,
> void **_a) int MasterHandler::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
> void QtPLWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id,
> void **_a) int QtPLWidget::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
> void QtExtWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id,
> void **_a) int QtExtWidget::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
>
> My C++ skills are not so hot, but I believe from the name coincidences that that last
> line of source code is instrumental in creating the demangled symbol,
> QtExtWidget::qt_metacall(QMetaObject::Call, int, void**) that is defined in the
> library here, but apparently somehow not defined there.  So please try the above
> nm experiments on the relevant files there and also with the --define-only option
> replaced by --undefined-only to find whether the above specific symbols are defined
> or not there.  Then follow up with similar analysis of moc_qt.cpp.
>
> When you attempt to replicate the above nm results and send them to me, please
> make sure the demangled symbol is exactly the same as mine so that we know that
> our mangled symbols refer to the same thing despite their different prefixes on my
> platform versus yours (your platform appears to have a prefix of "__imp__" while
> mine has no prefix at all).  And if you can prove those demangled symbols are
> effectively defined by the moc-generated source code there like appears to be the
> case here, then we have a real puzzle unless all of this mess was generated by the
> -j4 make option on Cygwin.
>
> In sum, I am looking for a new report tarball without -j4 (in case that fix happens to
> affect the above undefined reference issue) from you, but if that doesn't appear to
> make a difference, then I am also asking for at least 8 "nm" results from you (the 4
> above and 4 more with the --undefined-only flag replaced in --defined-only flag) for
> the build without -j4 to investigate why the above symbol which is defined here both
> in the shared object and object is not defined there. And further analysis of the
> relevant moc-generated source code would be appreciated as well.  Note I have
> attached a compressed version of
> bindings/qt_gui/pyqt4/plplot_pyqt4_automoc.dir/include/moc_qt.cpp
> so you can compare your moc-generated source-code results with mine.
>
> 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
> __________________________

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] plplot_pyqt4 shared object build issue

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

Hi Alan,



I probably have time today to run the test script without -j4. The other things I do not know. The problem with the -j option occurs in MinGW-w64/MSYS, not in Cygwin, unless I am mistaken. But I will do this anyway, just to make sure.



(Getting the results from nm will take more of my brain power than I can spare right now. Friday ought to be a good time though)

Regards,

Arjen


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, December 07, 2016 8:28 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: plplot_pyqt4 shared object build issue
>
> On 2016-12-01 08:31-0000 Arjen Markus wrote:
>
> [...]
>
> > I am not sure about the PyQt4 component. But
> when I tried to do it via the comprehensive test script, I got compilation errors - see
> the attached tarball.
>
> Hi Arjen:
>
> Now that I have finally had a chance to look at your report, it appears to me you
> have found something release critical so suddenly time is of the essence.  Sorry
> about that....  These things always seem to happen whenever you think you can
> relax near a release date.
> :-)
>
> The first issue is you used the default -j4 for make (and likely ctest as well if you
> had gotten that far).  I believe you have found in the past those intermittently failed
> for Cygwin so from now on please automate your invocation script for
> scripts/comprehensive_test.sh to always drop the -j4 arguments (by specifying the
> script options --build_command make --ctest_command ctest) so this issue never
> crops up again.
>
> I doubt the -j4 option on the make command (which after all normally only causes
> intermittent issues) was the cause of the present issue, but you never know so
> please try the same comprehensive test run again with the above issue fixed.  If
> that shows good results we are done.
>
> But if not, and the "undefined reference" remains, please read on and send me
> back the latest report tarball (which will be a lot more understandable without -j4 in
> any case) and the requested other results below which I summarize at the end.
>
> Your current report is giving me some results I don't understand, but the issue is
> occurring exactly where I recently changed our build system so with the release
> coming up I hope you can quickly reply to this post.
>
> The overview is that I can build the plplot_pyqt4 shared object here (called
> dll/plplot_pyqt4.pyd there and bindings/qt_gui/pyqt4/plplot_pyqt4.so here), and what
> I believe is the equivalent symbol that is undefined for your shared object is defined
> in my shared object according to "nm". Furthermore, the reason for this good result
> here is the symbol is actually defined in the object
> bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o
> (named that both here and there) which is included by the linker here into the
> plplot_pyqt4 shared object here and also the same there.
> (This is exactly the way the new AUTOMOC procedure that generates
> plplot_pyqt4_automoc.cpp.o is supposed to work.)
>
> Note the actual command that failed (from the make.out file that was jumbled by
> the above -j4 option, but I have excised some things to reduce the source of that
> confusion) was
>
> Linking CXX shared module ../../../dll/plplot_pyqt4.pyd [...] Entering directory
> '/cygdrive/d/plplot-
> svn/comprehensive_test_disposeable/shared/noninteractive/build_tree'
> /usr/bin/c++.exe     -shared -Wl,--enable-auto-import -o ../../../dll/plplot_pyqt4.pyd -
> Wl,--major-image-version,0,--minor-image-version,0
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4cmodule.cpp.o
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtPLDriver.cpp.o
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtPLWidget.cpp.o
> CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o ../../../dll/libplplotqt.dll.a ../.
> ./../dll/libplplot.dll.a -lpython2.7 -lQtSvg -lQtGui -lQtCore -lltdl -Wl,-Bstatic -ldl -lshp -
> Wl,-Bdynamic -lfreetype ../../../dll/libcsirocsa.dll.a ../../../dll/libcsironn.dll.a -
> lqhull ../../../dll/libqsastime.dll.a
> [...]
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o:sipplplot_pyqt4QtExt
> Widget.cpp:(.text+0x1ed): undefined reference to
> `__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv'
> CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o:sipplplot_pyqt4QtExt
> Widget.cpp:(.text+0x1ed): relocation truncated to fit: R_X86_64_PC32 against
> undefined symbol
> `__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv'
> [...] + other undefined references
>
> Here are the nm results for that first undefined reference
> (__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv) in a
> similar build I did here.  The mangled and demangled results here are
>
> software@raven> nm --defined-only bindings/qt_gui/pyqt4/plplot_pyqt4.so |grep
> 11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
> 000000000001b640 t
> _ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
> software@raven> nm --defined-only --demangle
> bindings/qt_gui/pyqt4/plplot_pyqt4.so |grep 'QtExtWidget.*qt_meta.*QMetaObject'
> 000000000001b640 t QtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
> 00000000000089f0 t sipQtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
>
> software@raven> nm --defined-only
> bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o
> |grep 11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
> 0000000000000490 T
> _ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
>
> software@raven> nm --defined-only --demangle
> bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o |
> grep 'QtExtWidget.*qt_metacall.*QMetaObject'
> 0000000000000490 T QtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
>
> The common locations 1b640 in the first set and 490 in the second set tell you
> which demangled symbol corresponds to the mangled one.
>
> I looked for "QMetaObject::Call" in the moc-generated code that is compiled here
> (and there?) to create the object file plplot_pyqt4_automoc.cpp.o with the following
> results:
>
> software@raven> grep QMetaObject::Call
> bindings/qt_gui/pyqt4/plplot_pyqt4_automoc.dir/include/moc_qt.cpp
> void MasterHandler::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id,
> void **_a) int MasterHandler::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
> void QtPLWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id,
> void **_a) int QtPLWidget::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
> void QtExtWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id,
> void **_a) int QtExtWidget::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
>
> My C++ skills are not so hot, but I believe from the name coincidences that that last
> line of source code is instrumental in creating the demangled symbol,
> QtExtWidget::qt_metacall(QMetaObject::Call, int, void**) that is defined in the
> library here, but apparently somehow not defined there.  So please try the above
> nm experiments on the relevant files there and also with the --define-only option
> replaced by --undefined-only to find whether the above specific symbols are defined
> or not there.  Then follow up with similar analysis of moc_qt.cpp.
>
> When you attempt to replicate the above nm results and send them to me, please
> make sure the demangled symbol is exactly the same as mine so that we know that
> our mangled symbols refer to the same thing despite their different prefixes on my
> platform versus yours (your platform appears to have a prefix of "__imp__" while
> mine has no prefix at all).  And if you can prove those demangled symbols are
> effectively defined by the moc-generated source code there like appears to be the
> case here, then we have a real puzzle unless all of this mess was generated by the
> -j4 make option on Cygwin.
>
> In sum, I am looking for a new report tarball without -j4 (in case that fix happens to
> affect the above undefined reference issue) from you, but if that doesn't appear to
> make a difference, then I am also asking for at least 8 "nm" results from you (the 4
> above and 4 more with the --undefined-only flag replaced in --defined-only flag) for
> the build without -j4 to investigate why the above symbol which is defined here both
> in the shared object and object is not defined there. And further analysis of the
> relevant moc-generated source code would be appreciated as well.  Note I have
> attached a compressed version of
> bindings/qt_gui/pyqt4/plplot_pyqt4_automoc.dir/include/moc_qt.cpp
> so you can compare your moc-generated source-code results with mine.
>
> 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
> __________________________

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.

[Plplot-devel] plplot_pyqt4 shared object build issue

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

On 2016-12-01 08:31-0000 Arjen Markus wrote:

[...]

> I am not sure about the PyQt4 component. But
when I tried to do it via the comprehensive test script, I got
compilation errors - see the attached tarball.

Hi Arjen:

Now that I have finally had a chance to look at your report, it
appears to me you have found something release critical so suddenly
time is of the essence.  Sorry about that....  These things always
seem to happen whenever you think you can relax near a release date.
:-)

The first issue is you used the default -j4 for make (and likely ctest
as well if you had gotten that far).  I believe you have found in the
past those intermittently failed for Cygwin so from now on please
automate your invocation script for scripts/comprehensive_test.sh to
always drop the -j4 arguments (by specifying the script options
--build_command make --ctest_command ctest) so this issue never crops
up again.

I doubt the -j4 option on the make command (which after all
normally only causes intermittent issues) was the cause of the present
issue, but you never know so please try the same comprehensive test run again with the
above issue fixed.  If that shows good results we are done.

But if not, and the "undefined reference" remains, please read on
and send me back the latest report tarball (which will be a lot
more understandable without -j4 in any case) and the requested
other results below which I summarize at the end.

Your current report is giving me some results I don't understand, but
the issue is occurring exactly where I recently changed our build
system so with the release coming up I hope you can quickly reply to
this post.

The overview is that I can build the plplot_pyqt4 shared object here
(called dll/plplot_pyqt4.pyd there and
bindings/qt_gui/pyqt4/plplot_pyqt4.so here), and what I believe is the
equivalent symbol that is undefined for your shared object is defined
in my shared object according to "nm". Furthermore, the reason for
this good result here is the symbol is actually defined in the object
bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o
(named that both here and there) which is included by the linker here
into the plplot_pyqt4 shared object here and also the same there.
(This is exactly the way the new AUTOMOC procedure that generates
plplot_pyqt4_automoc.cpp.o is supposed to work.)

Note the actual command that failed (from the make.out file that was
jumbled by the above -j4 option, but I have excised some things to
reduce the source of that confusion) was

Linking CXX shared module ../../../dll/plplot_pyqt4.pyd
[...]
Entering directory '/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree'
/usr/bin/c++.exe     -shared -Wl,--enable-auto-import -o ../../../dll/plplot_pyqt4.pyd -Wl,--major-image-version,0,--minor-image-version,0 CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4cmodule.cpp.o CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtPLDriver.cpp.o CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtPLWidget.cpp.o CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o ../../../dll/libplplotqt.dll.a ../../../dll/libplplot.dll.a -lpython2.7 -lQtSvg -lQtGui -lQtCore -lltdl -Wl,-Bstatic -ldl -lshp -Wl,-Bdynamic -lfreetype ../../../dll/libcsirocsa.dll.a ../../../dll/libcsironn.dll.a -lqhull ../../../dll/libqsastime.dll.a 
[...]
CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o:sipplplot_pyqt4QtExtWidget.cpp:(.text+0x1ed): undefined reference to `__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv'
CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4QtExtWidget.cpp.o:sipplplot_pyqt4QtExtWidget.cpp:(.text+0x1ed): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv'
[...] + other undefined references

Here are the nm results for that first undefined reference
(__imp__ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv) in a similar build
I did here.  The mangled and demangled results here are

software@raven> nm --defined-only bindings/qt_gui/pyqt4/plplot_pyqt4.so |grep 11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
000000000001b640 t _ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
software@raven> nm --defined-only --demangle bindings/qt_gui/pyqt4/plplot_pyqt4.so |grep 'QtExtWidget.*qt_meta.*QMetaObject'
000000000001b640 t QtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
00000000000089f0 t sipQtExtWidget::qt_metacall(QMetaObject::Call, int, void**)

software@raven> nm --defined-only bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o |grep 11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv
0000000000000490 T _ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv

software@raven> nm --defined-only --demangle bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/plplot_pyqt4_automoc.cpp.o | grep 'QtExtWidget.*qt_metacall.*QMetaObject'
0000000000000490 T QtExtWidget::qt_metacall(QMetaObject::Call, int, void**)

The common locations 1b640 in the first set and 490 in the second set
tell you which demangled symbol corresponds to the mangled one.

I looked for "QMetaObject::Call" in the moc-generated code that is
compiled here (and there?) to create the object file
plplot_pyqt4_automoc.cpp.o with the following results:

software@raven> grep QMetaObject::Call bindings/qt_gui/pyqt4/plplot_pyqt4_automoc.dir/include/moc_qt.cpp
void MasterHandler::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id, void **_a)
int MasterHandler::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
void QtPLWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id, void **_a)
int QtPLWidget::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
void QtExtWidget::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id, void **_a)
int QtExtWidget::qt_metacall(QMetaObject::Call _c, int _id, void **_a)

My C++ skills are not so hot, but I believe from the name coincidences
that that last line of source code is instrumental in creating the
demangled symbol, QtExtWidget::qt_metacall(QMetaObject::Call, int, void**)
that is defined in the library here, but apparently somehow not defined
there.  So please try the above nm experiments on the relevant files
there and also with the --define-only option replaced by
--undefined-only to find whether the above specific symbols are defined
or not there.  Then follow up with similar analysis of moc_qt.cpp.

When you attempt to replicate the above nm results and send them to
me, please make sure the demangled symbol is exactly the same as mine
so that we know that our mangled symbols refer to the same thing
despite their different prefixes on my platform versus yours (your
platform appears to have a prefix of "__imp__" while mine has no
prefix at all).  And if you can prove those demangled symbols are
effectively defined by the moc-generated source code there like
appears to be the case here, then we have a real puzzle unless all of
this mess was generated by the -j4 make option on Cygwin.

In sum, I am looking for a new report tarball without -j4 (in case
that fix happens to affect the above undefined reference issue) from
you, but if that doesn't appear to make a difference, then I am also
asking for at least 8 "nm" results from you (the 4 above and 4 more
with the --undefined-only flag replaced in --defined-only flag) for
the build without -j4 to investigate why the above symbol which is
defined here both in the shared object and object is not defined
there. And further analysis of the relevant moc-generated source code
would be appreciated as well.  Note I have attached a compressed
version of
bindings/qt_gui/pyqt4/plplot_pyqt4_automoc.dir/include/moc_qt.cpp
so you can compare your moc-generated source-code results with mine.

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] Updating xwNN.py set, removing xNN.py set and moving xwNN.py to xNN.py

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

On 2016-12-03 00:53-0800 Alan W. Irwin wrote:

> [...] This
> topic (getting pytkdemo to work perfectly on a slightly expanded subset
> of its original examples but now in xw??.py form [which is already
> done], moving to namespaced versions of all xw??.py examples (60 per
> cent done), deleting the xNN.py versions, and moving the xwNN.py
> versions to the xNN.py form) will be a very welcome improvement for
> this release.

Hi again, Hazen:

As of commit 8b19e88, I have all but the last (move) part of this
project done, tested, and merged to master.  But that move part is a
little tricky because a number of files have to be changed internally
to be consistent with this extensive name change.  So I will tackle
that final issue of this topic after I get some sleep.

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] Python3

[Hazen B. <hba...@ma...>]

On 12/01/2016 04:13 AM, Alan W. Irwin wrote:
>> Spoke too soon I guess. It appears that swig detects which version of
>> Python you are using and creates a binding that only works with that
>> version. So if you create the bindings in a Python3 environment they
>> will not work with Python2 and vice versa.
>
> I suggest the proper thing for me to do here (post-release since you
> are not quite ready yet to merge your Python 3 work, and I am pretty
> busy myself) is to have the build system look preferentially for
> support for Python 3 + consistent numpy for that Python version, and
> if that is not found fall back to looking for Python 2 + consistent
> numpy for that version.  But the user has the option to skip the look
> for that first preference if they so desire. So the approach would be
> similar to the way the build system looks first for Qt4, then Qt5
> with the user option to skip the look for Qt4
> except in the Python case the first preference order should likely be the
> newer Python (which I assume is completely stable), then the older (as
> opposed to the Qt case where the preference order is old, then new for
> the reasons I have discussed).

I'm not clear on how cmake detects which version(s) of Python are 
available, but I would suggest the use of which ever version is 
currently active, i.e. the one that runs when the user types "python" at 
the command prompt. If this is Python2 and Python3 is used instead then 
I think this violates the principle of least surprise. I think we should 
assume that the user had their reasons for choosing one or the other 
versions of Python to be active and not over-riding that. Otherwise I 
predict a lot of questions about why Python fails with:

"ImportError: dynamic module does not define init function (init_plplotc)"

Which is what will happen when you built with 3 and tried to run with 2.

It may also be more difficult to implement because I don't think swig 
has a flag that allows you to specify which version of Python to use. So 
to force swig to use the desired Python you'd need to change the users 
environment so that the desired Python was the active Python.

Somewhere in the build process though we should at least report which 
version of Python (if any) the bindings will be compatible with.

>> (3) Based on the make output I think plplot_widgetmodule.c will not
>> work with Python3. Is this important? Is there a test for this?
>
> Yes and yes.  The pytkdemo Python script discussed above and for which
> I have just implemented the test_pytkdemo target contains the following
> import statement:
>
> from plplot_widget import *
>
> and is a test of that module (as well as the xNN.py set now, but
> hopefully that will be changed to the xwNN.py set soon, see above).

Great, thanks! Once you have finished all of your Python changes (and 
the release) I will rebase my changes and get them working with the 
changes to the examples and the additional tests you have been working on.

-Hazen

[Plplot-devel] Updating xwNN.py set, removing xNN.py set and moving xwNN.py to xNN.py

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

On 2016-12-01 01:13-0800 Alan W. Irwin wrote:

> On 2016-11-30 20:59-0500 Hazen Babcock wrote:
[...]
>> (2) There appear to be at least two versions of each Python example. Maybe we
>> could get rid of one set? i.e. the xNN.py set and not the xwNN.py set that
>> are actually tested?
>

Hi again, Hazen:

It turned out the required changes are straightforward, but the
editing required has been pretty massive.  So instead of just one day,
I have been at this pretty hard for the last two days, and it will
likely take me another day to finish.  That is, I am currently on course
to get this topic merged into master within 24 hours from now.  This
topic (getting pytkdemo to work perfectly on a slightly expanded subset
of its original examples but now in xw??.py form [which is already
done], moving to namespaced versions of all xw??.py examples (60 per
cent done), deleting the xNN.py versions, and moving the xwNN.py
versions to the xNN.py form) will be a very welcome improvement for
this release.

There is at least one more fairly large topic I would like to merge 
(and there might be other last-minute large changes others here would
like to do).  Therefore, I have decided to push the freeze date from
December 3rd to at least December 8th, and there might be another
adjustment of that date up to as late as December 10th if I or anybody
else has some last-minute needs, but that would be the latest allowed
freeze date because we do need at least a week of testing, and I
really do want to stick with a release date of December 17th.

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] Python3

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

On 2016-11-30 20:59-0500 Hazen Babcock wrote:

>
>
> On 11/27/2016 01:40 PM, Alan W. Irwin wrote:
>> It is good to hear it is likely going to be even easier than I thought.  I
>> guess that -py3 flag is needed for more complex Python bindings than ours.
>
> Spoke too soon I guess. It appears that swig detects which version of Python 
> you are using and creates a binding that only works with that version. So if 
> you create the bindings in a Python3 environment they will not work with 
> Python2 and vice versa.

Hi Hazen:

I suggest the proper thing for me to do here (post-release since you
are not quite ready yet to merge your Python 3 work, and I am pretty
busy myself) is to have the build system look preferentially for
support for Python 3 + consistent numpy for that Python version, and
if that is not found fall back to looking for Python 2 + consistent
numpy for that version.  But the user has the option to skip the look
for that first preference if they so desire. So the approach would be
similar to the way the build system looks first for Qt4, then Qt5
with the user option to skip the look for Qt4
except in the Python case the first preference order should likely be the
newer Python (which I assume is completely stable), then the older (as
opposed to the Qt case where the preference order is old, then new for
the reasons I have discussed).

>
>> I have looked at the naming conventions used in practice for
>> python-2.6 and python-2.7 on Debian, and even there the old-fashioned idea
>> of inserting a "module" suffix on the basename of the shared object
>> has mostly (but not completely) fallen out of favour.  So it is fine
>> with me if you drop the module part of the shared object name as well.
>
> I just changed the output target from _plplotcmodule to _plplotc. Maybe this 
> will have some downstream consequences?

I don't believe this is a concern. That doubly raw C module should be
effectively private, i.e., it should only be imported by the swig-generated
plplotc.py module (which we already designate as the raw module).  That in turn is
imported by the hand-crafted module plplot.py which is the one
that users would prefer to import. So I don't think there will be any
downstream consequences other than in the lists of filenames that are
part of creating a software package (i.e. an rpm or deb) for PLplot,
but packagers typically have access to packaging tools to automatically
deal with changed filenames that are installed so I don't think even
that is going to be a downstream issue.

>> make test_python_psc
>
> ..
>
>> Then, you can run that example individually
>> (_in the build tree_) as follows:
>> 
>> examples/python/x00 -dev psc -o test.psc
>
> Thank you, this was very helpful.

You are welcome.

>
> The Python bindings are now compatible with Python3 as well as Python2, as 
> judged by running the (basic?) tests, i.e.
>
> $ make
> $ ctest

Good news, indeed!

>
> New questions:
> (1) How does one run the tests that compare the example output files to each 
> other so that I can verify that the output is still the same?

ctest does that already with its examples_compare test (which depends
on the various tests named examples_<binding> which run our standard
set of <binding> examples using -dev psc).  I think you need the
--extra-verbose option to see the results of that test on stdout, but
I also believe even without that option you can see the results of that
test in the Testing hierarchy of directories.

> (2) There appear to be at least two versions of each Python example. Maybe we 
> could get rid of one set? i.e. the xNN.py set and not the xwNN.py set that 
> are actually tested?

You ask interesting questions!  The situation concerning the largely
unmaintained xNN.py set and the well-maintained 
and xwNN.py set is summarized in examples/python/README.pythondemos.
At the time when I wrote that, I was hoping that Geoffrey Furnish (who
was the author of the plplot_widgets module and the pytkdemo example
that used that module + Tkinter + our own Tcl/Tk plframe GUI) would
consolidate the two sets of examples, i.e., by teaching the
well-maintained xwNN.py set how to be run from pytkdemo.

Well, Geoffrey dropped out of PLplot development soon after and there
it rested until you asked your question above.  :-)

To start to answer your question I have just implemented a test of
pytkdemo (see commit cb2a2c6) which is the test_pytkdemo target, and
that target build and resulting GUI appear to work fine subject to
some bugs in the xNN.py set of examples (see lack of maintenance
comment above).  Also, to look further at the consolidation question I
looked carefully at x10 + xw10.py (the combination used to run that
example for the pure python case versus x10.py, and it turns out the
only real difference is the namespace one which is straightforward to
deal with.

So I tried the appropriate namespace changes for x10 and xw10.py, and
the result is xw10.py can be called directly from pytkdemo, and the
combination of x10 and xw10.py still works perfectly for the pure
python case! With this proof-of-concept under my belt, I plan to
continue this work for all 33 of the xw??.py (replacing as needed in
pytkdemo or adding there when the corresponding x??.py does not
exist).  Which after a lot of editing and careful testing should allow
me to throw out the xNN.py set and rename the xwNN.py set as xNN.py.
(The "w" in the xwNN.py historically stood for "widgetless", but I
have long realized that choice of mine was a poor one which I would
like to get rid of in the way suggested.)

That change would be a most welcome addition for this release, but all
that editing required for the namespace change will likely be quite
time consuming.  But I will see how far I get with this tomorrow
(Thursday) to help decide whether I will be able to get this complete
topic merged into master before the freeze date this weekend.

> (3) Based on the make output I think plplot_widgetmodule.c will not work with 
> Python3. Is this important? Is there a test for this?

Yes and yes.  The pytkdemo Python script discussed above and for which
I have just implemented the test_pytkdemo target contains the following
import statement:

from plplot_widget import *

and is a test of that module (as well as the xNN.py set now, but
hopefully that will be changed to the xwNN.py set soon, see above).

More later.

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] Convenient submission of dashboards has now been enabled

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, December 01, 2016 2:15 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Convenient submission of dashboards has now been
> enabled
>
> On 2016-11-30 13:57-0000 Arjen Markus wrote:
>
> > By the looks of the first part of the output it has done the trick
> indeed :). No compiler errors or warnings according to ctest.
>
> Hi Arjen:
>
> I was very happy to see your clean dashboard (aside from some spurious warning
> counts for the configuration stage) at
> <http://my.cdash.org/index.php?project=PLplot_git>.
>
> I did take a quick look at the cmake output that is published there.
> In particular, these notices are all OFF for your Cygwin platform while mine are ON
> on Linux:
>
> ENABLE_ada:OFF
> ENABLE_d:OFF
> ENABLE_java:OFF
> ENABLE_ocaml:OFF
> ENABLE_octave:OFF
> _______________________
> ENABLE_pyqt4:OFF
> ENABLE_tk:OFF
> ENABLE_itk:OFF
>
> The ones above the line we have discussed before. You have been forced to set
> ENABLE_ada:OFF due to our own problem with Ada language support on Windows.
> The D, Java, and OCaml issues are due to missing software on Cygwin, i.e., the
> gdc.exe D compiler, some Java environment (e.g., gcj.exe, gij,exe, and other java
> friends), camlidl.exe (the rest of ocaml support is available), and octave.exe.  I
> suggest you make appropriate packaging requests on the Cygwin mailing list to see
> if anybody is willing to do thatrequired packaging work.
>
> I am pretty sure you have dealt with the ones below the line before, i.e., those are
> regressions from your previous results from running scripts/comprehensive_test.sh.
>
The tk and itk components were not enabled by CMake because there was no X server running. I am not sure about the PyQt4 component. But when I tried to do it via the comprehensive test script, I got compilation errors - see the attached tarball.

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] Python3

[Hazen B. <hba...@ma...>]

On 11/27/2016 01:40 PM, Alan W. Irwin wrote:
> It is good to hear it is likely going to be even easier than I thought.  I
> guess that -py3 flag is needed for more complex Python bindings than ours.

Spoke too soon I guess. It appears that swig detects which version of 
Python you are using and creates a binding that only works with that 
version. So if you create the bindings in a Python3 environment they 
will not work with Python2 and vice versa.

> I have looked at the naming conventions used in practice for
> python-2.6 and python-2.7 on Debian, and even there the old-fashioned idea
> of inserting a "module" suffix on the basename of the shared object
> has mostly (but not completely) fallen out of favour.  So it is fine
> with me if you drop the module part of the shared object name as well.

I just changed the output target from _plplotcmodule to _plplotc. Maybe 
this will have some downstream consequences?

> Try,
>
> make test_python_psc

..

> Then, you can run that example individually
> (_in the build tree_) as follows:
>
> examples/python/x00 -dev psc -o test.psc

Thank you, this was very helpful.

The Python bindings are now compatible with Python3 as well as Python2, 
as judged by running the (basic?) tests, i.e.

$ make
$ ctest

New questions:
(1) How does one run the tests that compare the example output files to 
each other so that I can verify that the output is still the same?

(2) There appear to be at least two versions of each Python example. 
Maybe we could get rid of one set? i.e. the xNN.py set and not the 
xwNN.py set that are actually tested?

(3) Based on the make output I think plplot_widgetmodule.c will not work 
with Python3. Is this important? Is there a test for this?

If anyone is interested, my python3 branch is available here:
https://github.com/HazenBabcock/PLplot/tree/python3

Just for testing though, don't do any work off of it :).

I'm going to wait until after the release to push this into master as 
the changes were somewhat intrusive and are likely to have broken something.

-Hazen

Re: [Plplot-devel] Convenient submission of dashboards has now been enabled

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

On 2016-11-30 13:57-0000 Arjen Markus wrote:

> By the looks of the first part of the output it has done the trick
indeed :). No compiler errors or warnings according to ctest.

Hi Arjen:

I was very happy to see your clean dashboard (aside from some spurious
warning counts for the configuration stage) at
<http://my.cdash.org/index.php?project=PLplot_git>.

I did take a quick look at the cmake output that is published there.
In particular, these notices are all OFF for your Cygwin platform while
mine are ON on Linux:

ENABLE_ada:OFF
ENABLE_d:OFF
ENABLE_java:OFF
ENABLE_ocaml:OFF
ENABLE_octave:OFF
_______________________
ENABLE_pyqt4:OFF
ENABLE_tk:OFF
ENABLE_itk:OFF

The ones above the line we have discussed before. You have been forced
to set ENABLE_ada:OFF due to our own problem with Ada language support
on Windows.  The D, Java, and OCaml issues are due to missing software
on Cygwin, i.e., the gdc.exe D compiler, some Java environment (e.g.,
gcj.exe, gij,exe, and other java friends), camlidl.exe (the rest of
ocaml support is available), and octave.exe.  I suggest you make
appropriate packaging requests on the Cygwin mailing list to see if
anybody is willing to do thatrequired packaging work.

I am pretty sure you have dealt with the ones below the line before,
i.e., those are regressions from your previous results from
running scripts/comprehensive_test.sh.

So to help figure those regressions out, please use the
comprehensive test way of submitting a dashboard that I gave
an example of in a recent commit message,
i.e.,

scripts/comprehensive_test.sh --do_submit_dashboard yes --do_test_interactive no --do_test_noninteractive no --do_test_install_tree no --do_test_traditional_install_tree no --do_nondynamic no --do_static no

This will submit one dashboard by running ctest with dashboard submission enabled in the
build tree for just the shared libraries/dynamic devices choice of our
three principal build configurations.

That script run should pretty much follow what you have just done by
hand, but the added value is you can send me the tarball report to
give me a good chance of helping you figure out the above regressions
compared to your previous comprehensive test results.

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] Convenient submission of dashboards has now been enabled

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

Hi Alan,



By the looks of the first part of the output it has done the trick indeed :). No compiler errors or warnings according to ctest.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> This is a most interesting result that puzzled me for a long while until I believe I
> have now found the solution.
>


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] Convenient submission of dashboards has now been enabled

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

Hi Alan,



I will try this new approach rightaway. This is an obscure bug indeed.



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> This is a most interesting result that puzzled me for a long while until I believe I
> have now found the solution.
>
> I agree with your conclusion that HAS_LIBQHULL_INCLUDE was not being set
> correctly.  After a lot of staring at the CMake logic in our build system I finally
> spotted a bug that would occur any time HAS_LIBQHULL_INCLUDE was true (your
> case) and you were running cmake a second time (which happens as a result of
> ctest -D Experimental, see below).  I believe I have now fixed this bug (see commit
> 8dfff8a) so please try submitting a dashboard again.
>
> Note from my further reading of the documentation
>
> ctest -D Experimental
>
> should be equivalent to
>
> Make Experimental
>
> which builds the following targets in this exact order (again from the documentation).
>
> ExperimentalStart
> ExperimentalConfigure
> ExperimentalBuild
> ExperimentalCoverage
> ExperimentalTest
> ExperimentalSubmit
>
> (The coverage part is ignored because we don't have any support for coverage in
> our build system.) Anyhow, building the above subtargets (so long as you
> remember to do them in the above order because apparently there are no
> dependencies between them to enforce the correct order) can be used to do
> everything required to prepare a dashboard and optionally submit it.  This allows
> you to watch results being accumulated in the Testing subdirectory for each of
> those subtargets if you are trying to diagnose an issue.
>
> I did that here, and ExperimentalConfigure does what its name implies and reruns
> cmake.  For your particular platform where HAS_LIBQHULL_INCLUDE is ON on
> the first cmake run, this subsequent run would set it (incorrectly) to OFF until I fixed
> the CMake logic bug as above.  So your dashboard submission has already been
> quite a success since it uncovered a build-system bug that has been with us for a
> while.  I am actually surprised you have never run into this issue on Cygwin before.
> Because all you would have to do to generate a subsequent CMake run and the
> resulting broken build is to edit any of our build-system code and continue on with
> another build with a dirty cache.  But as I recall you did not have libqhull installed for
> a long time on your Cygwin platform so that may explain why you have never seen
> this issue before.
>
> Come to think of it, perhaps we have been plagued with a lot of these stale cached
> variable bugs in the past which has lead me to the possibly incorrect conclusion we
> should always start fresh with an empty build tree.  So from now on I am going to
> continue with a stale cache for a while as I continue to develop PLplot to see how
> far I get (and to see if any other stale cached variable errors like you just
> discovered turn up).  And, of course, my previously successful dashboard
> submissions did involve a stale cache so perhaps such bugs are quite rare now in
> our build-system logic.  For example, I only had the qhull form of the header here
> so this bug did not affect me at all.
>


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] Convenient submission of dashboards has now been enabled

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

On 2016-11-30 07:54-0000 Arjen Markus wrote:

> Yes, [dashboard submission] turned out to be easier than I thought.
My first run failed because I had forgotten to adjust the path before
running ctest -D Experimental. (I was misled by the term "dashboard"
which seems to have several different meanings in modern
computespeak.)

> I am a bit puzzled though about the compiler errors -
qhull/qhull_a.h not found. I had not seen that before. Checking the
code and my installation:

> The include directory for Qhull is libqhull - in previous/ordinary
builds this was selected via the macro HAS_LIBQHULL_INCLUDE.

Hi Arjen:

This is a most interesting result that puzzled me for a long while until
I believe I have now found the solution.

I agree with your conclusion that HAS_LIBQHULL_INCLUDE was not being
set correctly.  After a lot of staring at the CMake logic in our build
system I finally spotted a bug that would occur any time
HAS_LIBQHULL_INCLUDE was true (your case) and you were running cmake a
second time (which happens as a result of ctest -D Experimental, see
below).  I believe I have now fixed this bug (see commit 8dfff8a) so
please try submitting a dashboard again.

Note from my further reading of the documentation

ctest -D Experimental

should be equivalent to

Make Experimental

which builds the following targets in this exact order (again
from the documentation).

ExperimentalStart
ExperimentalConfigure
ExperimentalBuild
ExperimentalCoverage
ExperimentalTest
ExperimentalSubmit

(The coverage part is ignored because we don't have any support for
coverage in our build system.) Anyhow, building the above subtargets
(so long as you remember to do them in the above order because
apparently there are no dependencies between them to enforce the
correct order) can be used to do everything required to prepare a
dashboard and optionally submit it.  This allows you to watch results
being accumulated in the Testing subdirectory for each of those
subtargets if you are trying to diagnose an issue.

I did that here, and ExperimentalConfigure does what its name implies
and reruns cmake.  For your particular platform where
HAS_LIBQHULL_INCLUDE is ON on the first cmake run, this subsequent run
would set it (incorrectly) to OFF until I fixed the CMake logic bug as
above.  So your dashboard submission has already been quite a success
since it uncovered a build-system bug that has been with us for a
while.  I am actually surprised you have never run into this issue on
Cygwin before.  Because all you would have to do to generate a
subsequent CMake run and the resulting broken build is to edit any of
our build-system code and continue on with another build with a dirty
cache.  But as I recall you did not have libqhull installed for a long
time on your Cygwin platform so that may explain why you have never
seen this issue before.

Come to think of it, perhaps we have been plagued with a lot of these
stale cached variable bugs in the past which has lead me to the
possibly incorrect conclusion we should always start fresh with an
empty build tree.  So from now on I am going to continue with a stale
cache for a while as I continue to develop PLplot to see how far I get
(and to see if any other stale cached variable errors like you just
discovered turn up).  And, of course, my previously successful
dashboard submissions did involve a stale cache so perhaps such
bugs are quite rare now in our build-system logic.  For example, I
only had the qhull form of the header here so this bug did not
affect me at all.

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] Convenient submission of dashboards has now been enabled

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> To be precise you are actually using ctest as a dashboard client to send
> dashboards to our dashboard server (the PLplot_git "project" at my.cdash.org).
> The place where today's submitted dashboard information is publicly displayed is
> <http://my.cdash.org/index.php?project=PLplot_git>) with calendar links to
> submissions on other days.  So you don't actually need to know anything about the
> cdash software that runs that site other than it provides a nice dashboard server.
>
Yes, that turned out to be easier than I thought. My first run failed because I had forgotten to adjust the path before running ctest -D Experimental. (I was misled by the term "dashboard" which seems to have several  different meanings in modern computespeak.)

I am a bit puzzled though about the compiler errors - qhull/qhull_a.h not found. I had not seen that before. Checking the code and my installation:

The include directory for Qhull is libqhull - in previous/ordinary builds this was selected via the macro HAS_LIBQHULL_INCLUDE. Could it be that this is not covered via ctest?

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.

[Plplot-devel] git blog

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

For my (Debian Jessie) version of git, the default color for
displaying the commit hash in the "git log" output is yellow.  That is a
bad choice on normal terminals like mine with a white background because
it makes the commit hash (extremely important and useful information)
virtually unreadable.  So I found myself using

git log |less

quite a bit which suppresses the colours, but I finally got tired of
such workarounds today, and started googling for the answer which
turned out to be extremely difficult to find because there are other
aspects of the git log information (especially decoration and pretty
formats) where users are fascinated with setting the color, but all
that information doesn't help for setting the color for the key
information in the log, the commit hash.  Eventually, though I did find
the solution which is to run the following command:

git config --global color.diff.commit "yellow black"

which improved visibility tremendously because that yellow
foreground is now seen against a black background.  Another alternative
with good visibility (at least for my terminal) is

git config --global color.diff.commit red

i.e., red on the terminal background (white for me).

But other foreground and background colors are possible as well. For
my version of git (2.1.4), the only color choices appear to be normal,
black, red, green, yellow, blue, magenta, cyan and white.  However, if
you have git-2.3.0 or later it appears from web commentary that 24-bit
hex colors will be recognized, e.g., '#FF0000' instead of red if you
have a terminal that supports those.

By the way, to those here wondering why the configuration item
color.diff.commit has anything to do with the color of the commit hash
displayed in the git log command, "git help config" does mention the
git log command for the color.diff configuration item so I guess you
can infer that color.diff.commit controls the commit hash color for
git log, but that inference is not completely obvious so that is why I
didn't come up with this solution myself and had to use a long
detailed google search to find it.

I hope this solution helps those here who are currently having trouble
with the visibility of the default yellow color on terminal background
for displays of commit hashes.

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
__________________________