Re: [Plplot-devel] Your development plans for this release cycle

[Pedro Vicente]

Hi Alan
Congratulations on the release.

> For this release cycle I encourage both of you to continue your
> efforts to deal with obvious wxwidgets bugs

ok, will do, as my time permits
Regards

-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Pedro Vicente" 
<pedro.vice...@space-research.org>; "PLplot development list" 
<Plplot-devel@lists.sourceforge.net>
Sent: Monday, January 30, 2017 12:36 AM
Subject: Your development plans for this release cycle


> To Phil and Pedro:
>
> Now that 5.12.0 has been released, I am writing a series of posts to
> our active developers with this subject line.
>
> If either of you has any additional wxwidgets development in mind beyond 
> what I
> discuss below, please let me know.
>
> For this release cycle I encourage both of you to continue your
> efforts to deal with obvious wxwidgets bugs (such as the unexpected
> black rather than expected white background color for the first page
> of example 16) to complement the work I plan to do deal with the last
> of the wxwidgets device driver efficiency issues on Linux. Your goal
> should be that each of our C examples with -dev wxwidgets should
> produce exactly the same results (except possibly for text size) as
> given at <http://plplot.sourceforge.net>/examples.php>.
>
> It would be great if one of you got the currently retired wxpng file
> device going again as an aid for such comparisons with other
> file-based plot results.  But even better would be if you implemented
> a wxwidgets-based SVG device (see
> <https://wiki.wxwidgets.org/WxSVGFileDC>).  The reason I particularly
> mention SVG as a file format is the generated results are written in
> XML and therefore are straightforward to interpret and debug by visual
> comparison of that XML result with other SVG (from -dev svg, -dev
> svgcairo, or -dev svgqt) results for the same standard example.
>
> @Phil: We were all agreed (see the February 2016 thread with the
> subject line "Error report system plus thread safety" that our current
> use of calls to exit() or the equivalent plexit whenever an error
> condition was encountered was an important issue for our
> users using interactive environments, i.e., one PLplot error ==> takes
> down entire interactive work without giving the user a chance to save
> anything ==> one less user interested in using PLplot!
>
> During that thread you were strongly recommending using a
> setjmp()/longjmp() C-based exception model because you are very
> comfortable with using exception handling in C++ and the amount of
> editing required to implement it would be much smaller than the return
> code method.  Although Hazen had a substantially more cautious
> attitude, I was happy to go along with that C exception approach
> rather than the alternative return code method because of my knowledge
> of the extreme length of many of our call/caller graphs and the large
> amount of the work it would be for us to check _all_ calls of _all_
> PLplot functions within our C library code for invalid return codes.
>
>A google search for the search terms 
>   gives lots of hits.  Phil, I would appreciate you looking at the top
>   several and letting me know which you think is the best for learning
>   about exception handling in C.
> 
>
> The final upshot of that thread was you planned to make a proof of
> concept for us to look at (and help you propagate it to everywhere
> else in our C code during this release cycle if we liked that proof of
> concept). Anyhow, could you please implement that proof of concept
> now?
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

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

yes


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

ok, wil do

-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Pedro Vicente" 
<pedro.vice...@space-research.org>; "PLplot development list" 
<Plplot-devel@lists.sourceforge.net>
Sent: Thursday, January 05, 2017 4:51 PM
Subject: The wxwidgets-related components of PLplot and the 5.12.0 release


> On 2017-01-04 20:08-0500 Pedro Vicente wrote:
>
>> I tried on my linux 16.04, same results as CentOS (I don'have the 14.04 
>> and debian anymore)
>
> To Phil and Pedro:
>
> @Pedro:
> It appears you are completely satisfied with this fix on the two Linux
> platforms where you have tested it.  Those tests are much appreciated,
> and based on good results now for 4 Linux platforms (two from you and
> one each from Phil and I) the conclusion appears to be all is well
> with this fix for the extremely tricky event-timing bug you discovered
> on some Linux platforms/hardware.
>
> @ Phil:
> My understanding is you have made some text orientation changes that
> continue to work now for you with older wxwidgets, and which you
> anticipate (but have not tested) will work for the latest git version
> of wxwidgets as well.  And you are still working on an additional
> background colour fix (that we might or might not push for this
> release depending on how intrusive that fix turns out to be).  Do you
> have an ETA for when we will be able to make that decision, i.e., when
> we can finalize the wxwidgets code changes for this release?
>
> @ Both:
> Once that finalization occurs, we (Phil, Pedro, and I) should
> thoroughly test the wxwidgets components of PLplot again on all
> accessible platforms, and after that I expect it will take several
> days longer for me to finish my large documentation update (and I am
> hoping Phil will contribute to that update as well for anything
> related to wxwidgets).  So I think we are looking at a release date of
> roughly one week after the wxwidgets code changes are finalized, e.g.,
> late next week if that finalization happens soon.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
> 


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

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

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

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


  That looks promising 

   

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

   

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

   

   

  Sent from my Windows 10 phone

   

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

   

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

   

  > Hi Phil

  > 

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

  > I'll test other Linux later

   

  > 

  >> So what I

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

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

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

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

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

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

  >> 

  >> Does that seem sensible?

  > 

   

  To Phil and Pedro:

   

  @Phil:

   

  The test_c_wxwidgets and test_wxPLplotDemo targets worked without

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

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

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

  release-critical bug fixing.

   

  @Both:

   

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

  of you.

   

  @Phil:

   

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

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

  sense that test_wxPLplotDemo now produces two identical plots for me,

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

  effect.

   

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

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

  solution.

   

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

  building the test_wxPLplotDemo target?  Please extend that test to

  building the test_c_wxwidgets target as well. You were already

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

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

  and test_c_wxwidgets targets) for all Linux platforms.  And similarly

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

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

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

  please also test your own software projects that link with the

  plplotwxwidgets library on all platforms where you expect your own

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

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

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

   

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

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

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

  release.

   

  Alan

  __

  Alan W. Irwin

   

  Astronomical research affiliation with Department of Physics and Astronomy,

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

   

  Programming affiliations with the FreeEOS equation-of-state

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

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

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

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

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

  __

   

  Linux-powered Science

  __

   
--
Check out the 

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

[Pedro Vicente]

Hi Alan


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


yes


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


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

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


output is attached

-Pedro


On 2017-01-04 14:17, Alan W. Irwin wrote:

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


Hi Phil

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





So what I
would propose is that for this release we attempt to not add or 
remove
anything from the API and just stick with an example that  works 
with

what we've got. Then after this release we can add non-template
classes for wxFrame, wxDialog and wxPanel which can be used really
easily by our users and we have time to test them and make sure the
API for their use is stable before the next release.
Does that seem sensible?




To Phil and Pedro:

@Phil:

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

@Both:

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

@Phil:

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

to try two different methods of generating those plots so it makes
sense that test_wxPLplotDemo now produces two identical plots for me,
but please confirm that the two plots I observed are the intended
effect.

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

@Pedro: I think your current CentOS test is equivalent to just
building the test_wxPLplotDemo target?  Please extend that test to
building the test_c_wxwidgets target as well. You were already
planning to test Phil's solution on all the Linux platforms 
accessible

to you, but please do the full test (build both the test_wxPLplotDemo
and test_c_wxwidgets targets) for all Linux platforms.  And similarly
for your Windows platforms.  There, the convenient test_* targets
won't work so you will have to do the equivalent by hand (run
wxPLplotDemo and run several C examples with -dev wxwidgets). 
Finally,

please also test your own software projects that link with the
plplotwxwidgets library on all platforms where you expect your own
software projects to currently work.  (I assume that is just Windows,
but please test on at least one Linux platform as well if you
expect your software to work on both Windows and Linux.)

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

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and 
Astronomy,

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

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

Linux-powered Science
__


--
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org//data/home002/pvicente/programs/cmake-3.6.2-Linux-x86_64/bin/cmake 
-H/data/home002/pvicente/dev/plplot-plplot 
-B/data/home002/pvicente/dev/plplot-plplot/build --check-build-system 
CMakeFiles/Makefile.cmake 0
make -f CMakeFiles/Makefile2 test_c_wxwidgets
make[1]: Entering directory `/data/home002/pvicente/dev/plplot-plplot/build'
/data/home002/pvicente/programs/cmake-3.6.2-Linux-x86_64/bin/cmake 
-H/data/home002/pvicente/dev/plplot-plplot 
-B/data/home002/pvicente/dev/plplot-plplot/build --check-build-system 
CMakeFiles/Makefile.cmake 0
/data/home002/pvicente/programs/cmake-3.6.2-Linux-x86_64/bin/cmake -E 
cmake_progress_start /data/home002/pvicente/dev/plplot-plplot/build/CMakeFiles 
49
make -f CMakeFiles/Makefile2 examples/CMakeFiles/test_c_wxwidgets.dir/all
make[2]: Entering directory `/data/home002/pvicente/dev/plplot-plplot/build'
make -f include/CMakeFiles/plhershey-unicode-gen.dir/build.make 
include/CMakeFiles/plhershey-unicode-gen.dir/depend
make[3]: Entering directory `/data/home002/pvicente/dev/plplot-plplot/build'
cd /data/home002/pvicente/dev/plplot-plplot/build && 
/data/home002/pvicente/programs/cmake-3.6.2-Linux-x86_64/bin/cmake -E 
cmake_depends "Unix Makefiles" /data/home002/pvicente/dev/plplot-plplot 
/data/home002/pvicente/dev/plplot-plplot/include 
/data/home002/pvicente/dev/plplo

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

[Pedro Vicente]

Hi Phil

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


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

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


yes, sounds good, thanks
-Pedro



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

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

Hi Phil, Alan

I started a new thread, that summarizes all the learnings we have so far on 
this and proposes a simple solution that keeps the current API (templates).

1) remotely or in place

First the issue of accessing the machine remotely or in place.
One of my machines that I previously accessed remotely is a server on my living 
room (not very remote in this case).
So I did a test "in place" (that is, directly on the laptop) on this machine.

It was a good idea that I committed a version that only shows the bug, with 
debug messages.
To get that version I did:

git log --pretty=oneline  -n 20
git log - n 20

and that commit it's this one

commit 3a6a49a572e7aa518a5b8a6bbecd9ef1f812
Author: Pedro Vicente <pedro.vice...@rhw9121.star1.nesdis.noaa.gov>
Date:   Fri Dec 16 11:24:23 2016 -0500

wxwidgets binding: insert debug messages

Add debug messages that show sequence of events for a bug that happens
on some but not all Linux distributions with wxwidgets3.0/3.1.  The
cause is that frame->Create does not always trigger an OnCreate()
event on time before the Plot() call.

so I did 

git checkout  3a6a49a572e7aa518a5b8a6bbecd9ef1f812
cmake .. -DBUILD_TEST=ON 
make VERBOSE=1 test_wxPLplotDemo

and the output shows the NULL stream

22:35:26: Debug: wxPLplotwindow::wxPLplotwindow
22:35:26: Debug: frame->Create
22:35:26: Debug: pls NULL
22:35:26: Debug: wxPLplotwindow::OnCreate

So, this clearly shows that the bug happens "in place" and we can forget about 
remote X server tests.

2) the infinite Yielding loop 

The introduction of the Yield() call was an unsuccessful attempt to wait for 
the delay
in the OnCreate() event.
But it does not work, and does not fix the bug, and furthermore happens in 
cases where
the bug did not show up (i.e Alan's cases).
So, the Yield() call should be completely removed.

3) The solution for the bug

The solution for the bug is simple and minimal.
It is to override the Create() function of wxPLplotwindow, 
which I did with the following function

template
bool wxPLplotwindow::Create(wxWindow *parent, wxWindowID id, const 
wxString& title, const wxPoint& pos, const wxSize& size, long style, const 
wxString& name)
{
  PLPLOT_wxLogDebug("wxPLplotwindow::Create()");
  if (!WXWINDOW::Create(parent, id, title, pos, size, style, name))
return false;
  CreateStream();
  return true;
}

where
CreateStream();
is just a new function that has the code previously in OnCreate()

NOTE:  OnCreate() *ALSO* calls
CreateStream();
because this is used by the PLviewer.
 

Attached to this email is a git patch that can be applied to the current git 
master.
( I did not write a full description)
Also I attached the 2 source files that fix the issue.

NOTE: The change in wxPLplotDemo.cpp was just to remove the Yield() call.
besides that, its use was like it was on 5.11.1, which is

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

The thing here is that now this call
frame->Create

*creates* the frame immediately, instead of waiting for the OnCreate() event

So, problem solved :-)

@Alan

With this in mind here's a new description for the fix,
similar to the previous, except that it removes the mention of template removal:


"Fixed a bug that happened in test_wxPLplotDemo for  some Linux 
configurations.
 The effect of the bug was a segmentation fault, due to the fact that an 
invalid
plot stream pointer was used. The cause of the stream pointer being invalid
is that the frame window did not initialize in a timely manner. This 
behaviour is a
wxWidgets feature that can or cannot happen in GTK/X11 window systems.
The solution for test_wxPLplotDemo was to initialize the stream in the 
function
Create(), which is done immediately, instead of doing it on the function 
OnCreate(),
that is called later and executed at an indeterminate time. Note: the 
request of creating
the stream in OnCreate() is still present, because this is a feature of the 
driver needed elsewhere."


@Phil, 
do you agree with this solution?

It keeps the current use of templates.
One small caveat is that I think you can only instantiate the template with a 
class that has this Create()
signature 

Create(wxWindow *parent, wxWindowID id, const wxString& title, const wxPoint& 
pos, const wxSize& size, long style, const wxString& name)

which is of course , wxFrames, the current use.
Probably dialogs too, but maybe not things like buttons and other GUI elements.
But I assume that the vast majority of users, if not all, draws the plot in 
"regular" windows?.

-Pedro




0001-Add-function-Create.patch.tar.gz
Description: GNU Zip compressed data
// Copyright (C) 2005  Werner Smekal
//
// This file is part of PLplot.
//
// PLplot is free software; you can redistribute it and/or modify
// it under the 

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

Hi Phil

The removal of the templates does not need to be done after all.
see my email from 
today 2.46 PM  "Infinite Yielding issue"
that has a git patch or my 
3.16PM email that has the actual source code files.

I'll send more details, once we get all in sync in communication.

-Pedro








  - Original Message - 
  From: p.d.rosenb...@gmail.com 
  To: Pedro Vicente ; Alan W. Irwin 
  Cc: PLplot development list 
  Sent: Tuesday, December 27, 2016 6:21 PM
  Subject: RE: [Plplot-devel] Infinite Yielding issue


  This is really brief, I think we are all getting a little overexcited here 
very close to the release date.

   

  This is a functionality reducing, backwards incompatible API change. I know 
for one that it will not only cause build errors in some of my code, but 
because I use wxPLplotwindow classes in some of my code it will mean I 
have to revert to using wxPLstream and duplicate all the code from 
wxPLplotwindow to restore my functionality. This is why I made the class 
templated in the first place. It also future proofs us for future wxWindow 
derived classes and significantly eases linking problems. So there are very 
good design reasons for the current state.

   

  That said, if we really can't solve the current problems with the existing 
model, then we should change. However we certainly should not do that in a 
rushed manner in the days leading up to release.

   

  Note that up to now the bug Pedro reported exists on one remote x server. It 
does not appear to affect the Cygwin x server when used remotely, nor Xming. I 
would suggest that if we wish to release approximately on time, then we restore 
the previous API and release with a note saying that this remote X server has a 
compatibility issue and that users should check the git repo for updates.

   

  Meanwhile I can still think of two or three ways we can quite likely sort 
this without losing functionality or generating backwards incompatible changes. 
But trying to do that over the Christmas break is just not doable for me. I can 
start looking at it properly in january.

   

  Also would it be possible to make use of trac to keep up to date on this 
issue? There are now a number of threads all referring to this problem/change 
in different ways with cross posting that means chronology doesn't make sense 
and I'm finding it impossible in the time I have to make sense of it all.

   

  So it turns out that this was not as brief as I hoped, but I hope you get my 
intention. In particular, I'm hugely grateful Pedro for your efforts on this. 
You've done a huge amount to push towards fixing this. It is easy for the tone 
of an email to be misinterpreted as grumpy, but please don’t think this is the 
case here – in fact the opposite, it's great to see interest in the device, but 
I think we all just need to take a breath, remember that some of us have young 
children and that this time of year means that PLplot is not everyone's top 
priority.

   

  Does that make sense?

   

  Sent from my Windows 10 phone

   

  From: Pedro Vicente
  Sent: 27 December 2016 19:46
  To: Alan W. Irwin
  Cc: Phil Rosenberg; PLplot development list
  Subject: Re: [Plplot-devel] Infinite Yielding issue

   

  @Alan, Phil

   

   

  >However, there is something we could try, which is,

  >keep the current way of wxPLplotwindow beging a template,

  >and at the same time overriding the Create() function (with template).

   

  ok, I implemented this, attached

   

  this

   

  1) will not break current template use

  2) will fix the bug

   

  Limitation:

  template can only be used with wxFrame (or a class that implements 

  Create() with the same

  signature)

   

  test demo and example 01 run OK in CentOS, output is below

   

   

   

  14:42:47: Debug: wxPLplotwindow::wxPLplotwindow

  14:42:47: Debug: wxPLplotwindow::Create()

  14:42:47: Debug: wxPLplotwindow::CreateStream()

  14:42:47: Debug: plD_init_wxwidgets(): enter

  14:42:47: Debug: wxPLDevice(): enter

  14:42:47: Debug: wxPLDevice(): gc done

  14:42:47: Debug: wxPLDevice(): m_interactiveTextGcdc done

  14:42:47: Debug: wxPLDevice(): SetDC done

  14:42:47: Debug: wxPLDevice(): leave

  14:42:47: Debug: plD_init_wxwidgets(): leave

  14:42:47: Debug: frame->Create

  14:42:47: Debug: Plot()

  14:42:48: Debug: wxPLplotwindow::OnCreate

  14:42:48: Debug: wxPLplotwindow::CreateStream()

   

   

   

  On 2016-12-27 12:58, Alan W. Irwin wrote:

  > On 2016-12-27 10:09-0500 Pedro Vicente wrote:

  > 

  >> @Alan

  >> 

  >>> Isn't that loss of functionality by definition a backwards

  >>> incompatibility in the API for the plplotwxwidgets library?

  >> 

  >> yes

  >> 

  >> but for the current (5.11.1) release compared to the new implemented 

  >> examples,

  >> the effect is the same

  >> 

  >> previously the

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

[Pedro Vicente]

I am using wxwidgets 3.1 built with Visual Studio 2015 and plplot from the 
master branch
and using cmake with


cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON
-DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
-DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF
-DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON
-DwxWidgets_ROOT_DIR:PATH=%WXWIN%
-DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
-DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
-DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF



- Original Message - 
From: "Laurent Berger" <laurent.ber...@univ-lemans.fr>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Tuesday, December 27, 2016 4:32 PM
Subject: Re: [Plplot-devel] legend and label using wxWidgets


> Which version of wxwidgets do you use (can you give last commit using git 
> log)?
>
>
> Le 27/12/2016 à 22:29, Pedro Vicente a écrit :
>>> error is still here. Now what patch should I apply?
>>
>> there is no patch for the scale issue.
>> the patch I send previously on the subject "Using wxWidgets" is for the 
>> issue regarding the use
>> of templates. To test that, add and replace the 2 attached files on that 
>> email to the master you just did the clone,
>> and report here if you have any errors on the master, or in your code 
>> that uses it, please.
>>
>> regarding the scale issue, what compiler and cmake command are you using?
>> is it Visual Studio 2015 build 64bits, doing
>> cmake .. -G "Visual Studio 14 win64" ?
>>
>>
>>
>>
>> On 2016-12-27 16:04, Laurent Berger wrote:
>>> I always clean my build repo and my cmake cache. Now to be sure I
>>> have just clone plplot in another folder :
>>>
>>>
>>> $ git clone git://git.code.sf.net/p/plplot/plplot
>>> Cloning into 'plplot'...
>>> remote: Counting objects: 91527, done.
>>> remote: Compressing objects: 100% (29963/29963), done.
>>> remote: Total 91527 (delta 68265), reused 82342 (delta 60469)
>>> Receiving objects: 100% (91527/91527), 117.46 MiB | 109.00 KiB/s, done.
>>> Resolving deltas: 100% (68265/68265), done.
>>> Checking connectivity... done.
>>> Checking out files: 100% (1962/1962), done.
>>>
>>> Laurent@PC-Laurent-Vision MINGW64 /f/met
>>> $ cd plplot
>>>
>>> Laurent@PC-Laurent-Vision MINGW64 /f/met/plplot (master)
>>> $ git log
>>> commit 26bc4bf13aa41dff0e19345e982eca00a0458578
>>> Author: Alan W. Irwin <air...@users.sourceforge.net>
>>> Date:   Sat Dec 24 14:32:48 2016 -0800
>>>
>>> Apply spell checker to release notes
>>>
>>> build plplot in static using wxwidgets 3.1.0 :
>>>
>>>  git log(wxWidgets 3.1.0)
>>> commit 9bb5d0435a4cce5bcb7b3956cb730f59c37ea5f6
>>> Author: Paul Cornett <paul...@users.noreply.github.com>
>>> Date:   Wed Nov 9 20:06:26 2016 -0800
>>>
>>> Fix non-default window background color with GTK+ >= 3.20
>>>
>>> GTK+ no longer automatically paints non-default window
>>> background. See #17586
>>>
>>> commit b1a19e6b6c9f1a69821c0da773e2e3f94d554292
>>>
>>> error is still here. Now what patch should I apply?
>>>
>>>
>>>
>>> Le 27/12/2016 à 21:47, Alan W. Irwin a écrit :
>>>> On 2016-12-27 15:27-0500 Pedro Vicente wrote:
>>>>
>>>>> ah, yes, that's right "Visual Studio 14" only  is for 32 bits
>>>>>
>>>>> I did not try with 64 bits libs
>>>>
>>>> @Laurent:
>>>>
>>>> Just to interject here, before getting too deeply into 64-bit versus
>>>> 32-bit Windows differences between Pedro and you, it is important you
>>>> answer our question whether the text issues you see are due to stale
>>>> results left over from your previous builds.  So please make a
>>>> completely fresh build and let us know whether those text issues
>>>> persist for that fresh build.
>>>>
>>>> Alan
>>>>
>>>> __
>>>> Alan W. Irwin
>>>>
>>>> Astronomical research affiliation with Department of Physics and 
>>>> Astronomy,
>>>> University of Victoria (astrowww.phys.uvic.ca).
>>>>
>>>> Programming affiliations with the FreeEOS equation-of-state
>>>> implementation for stellar interiors (freeeos.sf.net); the Time
>>>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>>>> software package (plplot.sf.net); the libLASi project
>>>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>>>> and the Linux Brochure Project (lbproject.sf.net).
>>>> __
>>>>
>>>> Linux-powered Science
>>>> __
>>
> 


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

> error is still here. Now what patch should I apply?

there is no patch for the scale issue.
the patch I send previously on the subject "Using wxWidgets" is for the 
issue regarding the use
of templates. To test that, add and replace the 2 attached files on 
that email to the master you just did the clone,
and report here if you have any errors on the master, or in your code 
that uses it, please.

regarding the scale issue, what compiler and cmake command are you 
using?
is it Visual Studio 2015 build 64bits, doing
cmake .. -G "Visual Studio 14 win64" ?




On 2016-12-27 16:04, Laurent Berger wrote:
> I always clean my build repo and my cmake cache. Now to be sure I
> have just clone plplot in another folder :
>
>
> $ git clone git://git.code.sf.net/p/plplot/plplot
> Cloning into 'plplot'...
> remote: Counting objects: 91527, done.
> remote: Compressing objects: 100% (29963/29963), done.
> remote: Total 91527 (delta 68265), reused 82342 (delta 60469)
> Receiving objects: 100% (91527/91527), 117.46 MiB | 109.00 KiB/s, 
> done.
> Resolving deltas: 100% (68265/68265), done.
> Checking connectivity... done.
> Checking out files: 100% (1962/1962), done.
>
> Laurent@PC-Laurent-Vision MINGW64 /f/met
> $ cd plplot
>
> Laurent@PC-Laurent-Vision MINGW64 /f/met/plplot (master)
> $ git log
> commit 26bc4bf13aa41dff0e19345e982eca00a0458578
> Author: Alan W. Irwin <air...@users.sourceforge.net>
> Date:   Sat Dec 24 14:32:48 2016 -0800
>
> Apply spell checker to release notes
>
> build plplot in static using wxwidgets 3.1.0 :
>
>  git log(wxWidgets 3.1.0)
> commit 9bb5d0435a4cce5bcb7b3956cb730f59c37ea5f6
> Author: Paul Cornett <paul...@users.noreply.github.com>
> Date:   Wed Nov 9 20:06:26 2016 -0800
>
> Fix non-default window background color with GTK+ >= 3.20
>
> GTK+ no longer automatically paints non-default window
> background. See #17586
>
> commit b1a19e6b6c9f1a69821c0da773e2e3f94d554292
>
> error is still here. Now what patch should I apply?
>
>
>
> Le 27/12/2016 à 21:47, Alan W. Irwin a écrit :
>> On 2016-12-27 15:27-0500 Pedro Vicente wrote:
>>
>>> ah, yes, that's right "Visual Studio 14" only  is for 32 bits
>>>
>>> I did not try with 64 bits libs
>>
>> @Laurent:
>>
>> Just to interject here, before getting too deeply into 64-bit versus
>> 32-bit Windows differences between Pedro and you, it is important 
>> you
>> answer our question whether the text issues you see are due to stale
>> results left over from your previous builds.  So please make a
>> completely fresh build and let us know whether those text issues
>> persist for that fresh build.
>>
>> Alan
>>
>> __
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and 
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __
>>
>> Linux-powered Science
>> __

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

ah, yes, that's right "Visual Studio 14" only  is for 32 bits

I did not try with 64 bits libs

On 2016-12-27 15:19, Laurent Berger wrote:
> No i think Visual Studio 14 is for 32 bits. Visual Studio 14 win 64
> is for 64 bits libs. I don't use 32 bits libs. All my project are for
> 64 bits platform. Have you checked x04 with 64 bits libs?
>
>
> Le 27/12/2016 à 21:11, Pedro Vicente a écrit :
>>>> "Visual Studio 14"
>>> Does it mean that you use 32 bits libs?
>>
>> No, it means to use Visual Studio 2015 ("Visual Studio 14" is the 
>> version number of Visual Studio 2015)
>>
>>
>>
>> On 2016-12-27 15:05, Laurent Berger wrote:
>>> Does it mean that you use 32 bits libs?
>>>
>>>
>>> Le 27/12/2016 à 21:00, Pedro Vicente a écrit :
>>>> "Visual Studio 14"
>>

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Using wxWidgets

[Pedro Vicente]

Laurent

my mistake, the .gz file has a git patch.
Use the attached files to replace the ones you have in git master

-Pedro


On 2016-12-27 15:08, Pedro Vicente wrote:

Hi Laurent

I did some changes to the current master that will allow you to keep
using this code

wxPLplotwindow *frame = new wxPLplotwindow();

would you mind giving it a try?

do

git clone of Plplot (in Windows I use Tortoise git)
extract the attached .gz
copy the 2 files
wxPLplotwindow.h
wxPLplotDemo.cpp

to to their locations in the master (in bindings/wxwidgets and 
examples/c++)


and rebuild your application

thanks

-Pedro





On 2016-12-27 10:27, Laurent Berger wrote:

Problem is my compiler said

3>c:userslaurent.pc-laurent-visidocumentsvisual studio
2013wxopencvwxopencvmaincourbeplplot.h(55): error C2059: syntax 
error


Now syntax error I need two days to change my code. It was like this
in previous version of plplot. I don't remember 5.xx.xx. I don't 
wan't

to go back in my code. I will use 5.11.1


yes

but for the current (5.11.1) release compared to the new
implemented
examples,
the effect is the same

previously the way to start the demo was

wxPLplotwindow *frame = new wxPLplotwindow();

and now is

wxPLplotwindow *frame = new wxPLplotwindow();

and because wxPLplotwindow is a child of a wxFrame,
the visible effect is exactly the same, a frame window that shows
a
plot.

-Pedro


Le 27/12/2016 à 16:11, Pedro Vicente a écrit :


Laurent


I have installed last version of plplot and last patch (from
pedro).
Can
you confirm me that wxPLplotwindow is now a non template class?


yes, that is correct.

-Pedro

On 2016-12-27 10:04, Laurent Berger wrote:


Hi,

I have installed last version of plplot and last patch (from
pedro).
Can
you confirm me that wxPLplotwindow is now a non template class?

thanks for yours answers






--

Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


--
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/


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

#if !defined ( WXPLPLOTWINDOW_H__INCLUDED_ )
#define WXPLPLOTWINDOW_H__INCLUDED_

#include "plplot.h"
#include "wxPLplotstream.h"
#include 
#include 
#include 
#include 
#include 

// A plplot wxWindow template. To create an actual plplot wxWindow use
// the type of wxWindow you wish to inherit from at the template parameter
// For example to create a plplot wxFrame create a wxPLplotwindow
// then call the base wxWindow's Create method to initialise.
template 
class wxPLplotwindow : public WXWINDOW
{
public:
wxPLplotwindow( bool useGraphicsContext = true, wxSize clientSize = 
wxDefaultSize ); //!< Constructor.
virtual ~wxPLplotwindow( void );
 //!< Destructor.

void RenewPlot( void ); 
 //!< Redo plot.
bool SavePlot( const wxString& driver, const wxString& filename );  
 //!< Save plot using a different driver.
wxPLplotstream* GetStream()  { return m_created ? _stream : NULL; }   
 //!< Get pointer to wxPLplotstream of this widget.
void setUseGraphicsContext( bool useGraphicsContext );
void setCanvasColour( const wxColour  );
bool IsReady() { return GetStream() != NULL; }

bool Create(wxWindow *parent,
  wxWindowID id,
  const wxString& title,
  const wxPoint& pos = wxDefaultPosition,
  const wxSize& size = wxDefaultSize,
  long style = wxDEFAULT_FRAME_STYLE,
  const wxString& name = wxFrameNameStr);

protected:
void CreateStream();
virtual void OnPaint( wxPaintEvent& event ); //!< Paint event
virtual void OnSize( wxSizeEvent & event );  //!< Size event
   

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

[Pedro Vicente]

>> "Visual Studio 14"
> Does it mean that you use 32 bits libs?

No, it means to use Visual Studio 2015 ("Visual Studio 14" is the 
version number of Visual Studio 2015)



On 2016-12-27 15:05, Laurent Berger wrote:
> Does it mean that you use 32 bits libs?
>
>
> Le 27/12/2016 à 21:00, Pedro Vicente a écrit :
>> "Visual Studio 14"

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Using wxWidgets

[Pedro Vicente]

Hi Laurent

I did some changes to the current master that will allow you to keep 
using this code


wxPLplotwindow *frame = new wxPLplotwindow();

would you mind giving it a try?

do

git clone of Plplot (in Windows I use Tortoise git)
extract the attached .gz
copy the 2 files
wxPLplotwindow.h
wxPLplotDemo.cpp

to to their locations in the master (in bindings/wxwidgets and 
examples/c++)


and rebuild your application

thanks

-Pedro





On 2016-12-27 10:27, Laurent Berger wrote:

Problem is my compiler said

3>c:userslaurent.pc-laurent-visidocumentsvisual studio
2013wxopencvwxopencvmaincourbeplplot.h(55): error C2059: syntax error

Now syntax error I need two days to change my code. It was like this
in previous version of plplot. I don't remember 5.xx.xx. I don't 
wan't

to go back in my code. I will use 5.11.1


yes

but for the current (5.11.1) release compared to the new
implemented
examples,
the effect is the same

previously the way to start the demo was

wxPLplotwindow *frame = new wxPLplotwindow();

and now is

wxPLplotwindow *frame = new wxPLplotwindow();

and because wxPLplotwindow is a child of a wxFrame,
the visible effect is exactly the same, a frame window that shows
a
plot.

-Pedro


Le 27/12/2016 à 16:11, Pedro Vicente a écrit :


Laurent


I have installed last version of plplot and last patch (from
pedro).
Can
you confirm me that wxPLplotwindow is now a non template class?


yes, that is correct.

-Pedro

On 2016-12-27 10:04, Laurent Berger wrote:


Hi,

I have installed last version of plplot and last patch (from
pedro).
Can
you confirm me that wxPLplotwindow is now a non template class?

thanks for yours answers






--

Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


--
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

0001-Add-function-Create.patch.tar.gz
Description: Binary data
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@Alan

> So if users stick with the old way of
> creating frame they will get a build error

yes

However, there is something we could try, which is,
keep the current way of wxPLplotwindow beging a template,
and at the same time overriding the Create() function (with template).

this could mean that the template would only work for wxFrame, like
now

wxPLplotwindow *frame = new wxPLplotwindow();

but that would not break current applications

I'll try that later today

-Pedro


On 2016-12-27 12:58, Alan W. Irwin wrote:
> On 2016-12-27 10:09-0500 Pedro Vicente wrote:
>
>> @Alan
>>
>>> Isn't that loss of functionality by definition a backwards
>>> incompatibility in the API for the plplotwxwidgets library?
>>
>> yes
>>
>> but for the current (5.11.1) release compared to the new implemented 
>> examples,
>> the effect is the same
>>
>> previously the way to start the demo was
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>
>> and now is
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>
>> and because wxPLplotwindow is a child of a wxFrame,
>> the visible effect is exactly the same, a frame window that shows a 
>> plot.
>
> @Pedro:
>
> Thanks for that clarification.  So if users stick with the old way of
> creating frame they will get a build error (which I assume is the
> reason why Laurent is now getting build errors with his own code that
> links to the plplotwxwidgets library).  I do not say that in a
> critical way since if the choices are unreliability on some platforms
> versus changing our API in a backwards-incompatible way, then we must
> take the latter choice.
>
> @Phil:
>
> Do you agree with Pedro there is no obvious way out of this choice? 
> If
> so, then so be it, but we do have to warn users in the release notes
> of this backwards-incompatible change.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Uusing wxWidgets

[Pedro Vicente]

Laurent

> I have installed last version of plplot and last patch (from pedro). 
> Can
> you confirm me that wxPLplotwindow is now a non template  class?

yes, that is correct.

-Pedro


On 2016-12-27 10:04, Laurent Berger wrote:
> Hi,
>
> I have installed last version of plplot and last patch (from pedro). 
> Can
> you confirm me that wxPLplotwindow is now a non template  class?
>
> thanks for yours answers
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@Alan

> Isn't that loss of functionality by definition a backwards
> incompatibility in the API for the plplotwxwidgets library?

yes

but for the current (5.11.1) release compared to the new implemented 
examples,
the effect is the same

previously the way to start the demo was

wxPLplotwindow *frame = new wxPLplotwindow();

and now is

wxPLplotwindow *frame = new wxPLplotwindow();

and because wxPLplotwindow is a child of a wxFrame,
the visible effect is exactly the same, a frame window that shows a 
plot.

-Pedro



On 2016-12-27 02:12, Alan W. Irwin wrote:
> On 2016-12-26 21:30-0500 Pedro Vicente wrote:
>
>> @Alan, Phil
>>
>>> Now that we have such a widely tested solution, would you be 
>>> willing
>>> to write a short summary paragraph concerning the changes in the
>>> plplotwxwidgets library API?
>>
>> here it goes. The API really has no visible changes, but has a loss 
>> of functionality
>> (use of templates, i.e, ability to do plots other than in wxFrame 
>> windows)
>
> @Phil and Pedro:
>
> Isn't that loss of functionality by definition a backwards
> incompatibility in the API for the plplotwxwidgets library?  If Phil
> and you confirm that interpretation, I will need to warn about
> that in the release notes.
>
> Important questions below for Phil.
>
>>
>> "Fixed a bug that happened in test_wxPLplotDemo for  some Linux 
>> configurations.
>> The effect of the bug was a segmentation fault, due to the fact that 
>> an invalid
>> plot stream pointer was used. The cause of the stream pointer being 
>> invalid
>> is that the frame window did not initialize in a timely manner. This 
>> behaviour is a
>> wxWidgets feature that can or cannot happen in GTK/X11 window 
>> systems.
>> The solution for test_wxPLplotDemo was to initialize the stream in 
>> the function
>> Create(), which is done immediatley, instead of doing it on the 
>> function OnCreate(),
>> that is called later and executed at an indeterminated time. Note: 
>> the possiblility and request of creating
>> the stream in OnCreate() is still present, because this is a feature 
>> of the driver needed elsewhere.
>> A side effect of creating the new function Create() for the class 
>> wxPLplotwindow,
>> is that the class cannot be a template. At this time the class is 
>> descendant from
>> wxFrame, so only wxFrame windows can be created."
>>
>>
>>> To help you figure out what to say, here is how to discover the
>>> changes since plplot-5.11.1 in the library API and our demo that 
>>> links
>>> with that library:
>>> git diff --ignore-all-space plplot-5.11.1 bindings/wxwidgets/*.h
>>
>>
>> I did not got back in time this way, because all the other changes 
>> were made by Phil.
>>
>> Basically what I did was start with the current master of 
>> wxPLplotwindow and
>>
>> 1) override a function Create()
>> 2) do an auxilirary function CreateStream() that contains the code 
>> that was previously in
>> OnCreate(). This function is both called by Create() and OnCreate(). 
>> A boolean
>> flag assures that is only executed 1 time.
>> 3) Moved the event trigering that was previously on the 
>> wxPLplotwindow constructor
>> by ::Connect() calls
>> to a static event table
>>
>> This change 3) was not really needed, it was just to reflect the 
>> current way of handling events
>>
>> http://docs.wxwidgets.org/3.1/overview_events.html
>>
>> either by the static event table or by ::Bind()
>>
>>
>> feel free to change anything in the description.
>
> @ Pedro:
>
> Thanks for the above description of what you did.
>
> @Phil:
>
> I need your answers to the following questions.
>
> 1. Can you spot any release-critical issues with Pedro's present
>two-commit fix (i.e., any trouble you can forsee for our Unix
>and/or Windows users if we release with this)?
>
> 2. Are there any essential short-term changes you want to make to his
>approach for this release?  (Essential here means release-critical
>as used in question 1.)
>
> 3. Are there any long-term (post-release) changes you want to make to
>his approach?
>
> Your answers to these questions are release critical so I would
> appreciate your timely response to them.
>
> 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-o

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@Alan, Phil

> Now that we have such a widely tested solution, would you be willing
> to write a short summary paragraph concerning the changes in the
> plplotwxwidgets library API?

here it goes. The API really has no visible changes, but has a loss of 
functionality
(use of templates, i.e, ability to do plots other than in wxFrame windows)

"Fixed a bug that happened in test_wxPLplotDemo for  some Linux 
configurations.
 The effect of the bug was a segmentation fault, due to the fact that an 
invalid
plot stream pointer was used. The cause of the stream pointer being invalid
is that the frame window did not initialize in a timely manner. This 
behaviour is a
wxWidgets feature that can or cannot happen in GTK/X11 window systems.
The solution for test_wxPLplotDemo was to initialize the stream in the 
function
Create(), which is done immediatley, instead of doing it on the function 
OnCreate(),
that is called later and executed at an indeterminated time. Note: the 
possiblility and request of creating
the stream in OnCreate() is still present, because this is a feature of the 
driver needed elsewhere.
A side effect of creating the new function Create() for the class 
wxPLplotwindow,
is that the class cannot be a template. At this time the class is descendant 
from
wxFrame, so only wxFrame windows can be created."


> To help you figure out what to say, here is how to discover the
> changes since plplot-5.11.1 in the library API and our demo that links
> with that library:
>
> git diff --ignore-all-space plplot-5.11.1 bindings/wxwidgets/*.h


I did not got back in time this way, because all the other changes were made 
by Phil.

Basically what I did was start with the current master of wxPLplotwindow and

1) override a function Create()
2) do an auxilirary function CreateStream() that contains the code that was 
previously in
OnCreate(). This function is both called by Create() and OnCreate(). A 
boolean
flag assures that is only executed 1 time.
3) Moved the event trigering that was previously on the wxPLplotwindow 
constructor
by ::Connect() calls
to a static event table

This change 3) was not really needed, it was just to reflect the current way 
of handling events

http://docs.wxwidgets.org/3.1/overview_events.html

either by the static event table or by ::Bind()


feel free to change anything in the description.
I did not mention the new debug print option of wxWidgets in cmake,
because you implemented that feature, but that should be mentioned also.


-Pedro






- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "PLplot development list" 
<Plplot-devel@lists.sourceforge.net>
Sent: Monday, December 26, 2016 5:09 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-24 20:24-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>>> Then collect those two files in a tarball using
>>> tar zcf wxwidgets_experimental_commits2.tar.gz 00*
>>
>> I did the git am as explained, and
>> wxwidgets_experimental_commits2.tar.gz
>> is attached
>>
>> examples/c/x01c -dev wxwidgets
>> and
>> test_wxPLplotDemo
>>
>> run with no problems on all my tests
>>
>
> Hi Pedro:
>
> Thanks very much for that compiler warning fix and big testing effort
> on a Windows platform and 4 Linux platforms for this latest iteration
> of your two-commit fix.
>
> I tested this latest version here in the same way I did the previous
> iteration, and all was well.
>
> Now that we have such a widely tested solution, would you be willing
> to write a short summary paragraph concerning the changes in the
> plplotwxwidgets library API?  I cannot write such a summary myself
> because I don't know the correct C++ terminology to use.
>
> That summary would likely help Phil make up his mind about whether we
> will adopt your latest iteration of the fix or try something else.
> However, please write that paragraph with a somewhat larger audience in 
> mind
> than just Phil.  Because if he decides to go with your fix, then I
> will want to include your summary paragraph in our release notes to
> aid those (like you and Greg Jung) who are developing their own
> applications and libraries that link with the plplotwxwidgets library
> and who will therefore have to change those applications and libraries
> to be compatible with our changes.  So the summary should answer the
> question what is the minimum that an outside developer need to know about 
> the
> the changes to the plplotwxwidgets library API?
>
> To help you figure out what to say, here is how to discover the
> changes since plplot-5.11.1 in the library API an

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

Hi Alan


Then collect those two files in a tarball using
tar zcf wxwidgets_experimental_commits2.tar.gz 00*


I did the git am as explained, and
wxwidgets_experimental_commits2.tar.gz
is attached

examples/c/x01c -dev wxwidgets
and
test_wxPLplotDemo

run with no problems on all my tests


Half an hour ago it was the start of Christmas Eve day for me, and
that happened several hours ago for you and quite a while ago for
Phil.  So Merry Christmas and Happy New Year! to both of you and everybody 
else on this

list.


Merry Christmas and Happy New Year as well to everyone

-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "PLplot development list" 
<Plplot-devel@lists.sourceforge.net>

Sent: Saturday, December 24, 2016 3:42 AM
Subject: Re: [Plplot-devel] Infinite Yielding issue



On 2016-12-24 01:13-0500 Pedro Vicente wrote:


Hi Alan

some more upbeat news about the example error , it's gone :-)


It's gone here too.  :-)

So thanks very much Pedro for this early Christmas present!

[...]

I also removed this "PLDLLIMPEXP_WX"

class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame


That change causes a build issue on Linux if you are using

export CXXFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
export CFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
export FFLAGS="-O3 -Wuninitialized -Wunused"

which I highly recommend on Linux to check for symbol visibility
issues on that platform (and to partially check for visibility
issues on Windows as well, but in this case it sounds like it
was not needed, but it should do no harm on that platform.)

So I had to amend your present (second) commit to put it back.


I searched  in all the source code and could not find this symbol ?


The unix find command is good for such tasks:

software@raven> find . -type f |grep -v .git |xargs grep PLDLLIMPEXP_WX
./bindings/wxwidgets/wxPLplot_nanosec.h.in:PLDLLIMPEXP_WX void
./bindings/wxwidgets/wxPLplotwindow.h:class PLDLLIMPEXP_WX wxPLplotwindow 
: public wxFrame
./bindings/wxwidgets/wxPLplotstream.h:class PLDLLIMPEXP_WX wxPLplotstream 
: public plstream
./bindings/wxwidgets/deprecated_wxPLplotwindow.h:class PLDLLIMPEXP_WX 
wxPLplotwindow : public wxWindow
./bindings/wxwidgets/deprecated_wxPLplotstream.h.in:class PLDLLIMPEXP_WX 
wxPLplotstream : public plstream

./include/pldll.h.in:  #define PLDLLIMPEXP_WXPLDLLEXPORT
./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )PLDLLEXPORT 
type

./include/pldll.h.in:  #define PLDLLIMPEXP_WXPLDLLIMPORT
./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )PLDLLIMPORT 
type


Just in case you are curious about find, the above command says get me
all the names of all the files in the source tree, drop all the .git
ones (i.e., drop the git repository to focus on just files in the working 
directory),

then search all those remaining files for PLDLLIMPEXP_WX.  The result
was 9 hits (9 lines somewhere in our source tree files that refer to
PLDLLIMPEXP_WX).

From these results, you can see that the way I use that macro in
wxPLplotwindow.h has also been used for a long time in
wxPLplotstream.h, deprecated_wxPLplotwindow.h, and
deprecated_wxPLplotstream.h.in.  Also, that macro is defined in
include/pldll.h.in (which as you will discover has some complicated
preprocessing logic).

N.B. Use of such *IMPEXP* macros is an integral part of our symbol 
visibility support.



let me know if something on my patch is not clear


I slightly amended the commit message on your first (modified) commit
to indicate this complete fix would be in two commits, amended the
second (present) commit to put back PLDLLIMPEXP_WX again, greatly
expanded the commit message of that second commit using your own 
description

that you made in your post describing that commit, filled in a Tested
by: place-holding section for you that you should later fill out with
all the platforms you tested these two commits on, and finally added
my own Tested by: section.

Would you also look at one compiler warning I got because of the above
-Wuninitialized option?  Here was that complete warning:

/home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp: 
In member function ‘void wxPLplotwindow::setUseGraphicsContext(bool)’:
/home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp:326:33: 
warning: ‘drawDc’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]

 m_stream.SetDC( drawDc );

A lot of the time such warnings are spurious so you have to quiet them
by initializing something that shouldn't really need it.  But
sometimes they really do point to a serious problem with something
that is uninitialized because of bad code logic.

Anyhow, please _amend_ (i.e., do not make a 3rd commit) your sec

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

Hi Alan

Glad it's working !
I'll go through your email later, but a fix for the warning is just changing 
at line 313 of wxPLplotwindow.cpp
wxDC *drawDc;
to
wxDC *drawDc = NULL;
the warning is just because of the preprocessor macro
-Pedro
- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "PLplot development list" 
<Plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 24, 2016 3:42 AM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-24 01:13-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> some more upbeat news about the example error , it's gone :-)
>
> It's gone here too.  :-)
>
> So thanks very much Pedro for this early Christmas present!
>
> [...]
>> I also removed this "PLDLLIMPEXP_WX"
>>
>> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
>
> That change causes a build issue on Linux if you are using
>
> export CXXFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
> export CFLAGS="-O3 -fvisibility=hidden -Wuninitialized"
> export FFLAGS="-O3 -Wuninitialized -Wunused"
>
> which I highly recommend on Linux to check for symbol visibility
> issues on that platform (and to partially check for visibility
> issues on Windows as well, but in this case it sounds like it
> was not needed, but it should do no harm on that platform.)
>
> So I had to amend your present (second) commit to put it back.
>
>> I searched  in all the source code and could not find this symbol ?
>
> The unix find command is good for such tasks:
>
> software@raven> find . -type f |grep -v .git |xargs grep PLDLLIMPEXP_WX
> ./bindings/wxwidgets/wxPLplot_nanosec.h.in:PLDLLIMPEXP_WX void
> ./bindings/wxwidgets/wxPLplotwindow.h:class PLDLLIMPEXP_WX wxPLplotwindow 
> : public wxFrame
> ./bindings/wxwidgets/wxPLplotstream.h:class PLDLLIMPEXP_WX wxPLplotstream 
> : public plstream
> ./bindings/wxwidgets/deprecated_wxPLplotwindow.h:class PLDLLIMPEXP_WX 
> wxPLplotwindow : public wxWindow
> ./bindings/wxwidgets/deprecated_wxPLplotstream.h.in:class PLDLLIMPEXP_WX 
> wxPLplotstream : public plstream
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WXPLDLLEXPORT
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )PLDLLEXPORT 
> type
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WXPLDLLIMPORT
> ./include/pldll.h.in:  #define PLDLLIMPEXP_WX_DATA( type )PLDLLIMPORT 
> type
>
> Just in case you are curious about find, the above command says get me
> all the names of all the files in the source tree, drop all the .git
> ones (i.e., drop the git repository to focus on just files in the working 
> directory),
> then search all those remaining files for PLDLLIMPEXP_WX.  The result
> was 9 hits (9 lines somewhere in our source tree files that refer to
> PLDLLIMPEXP_WX).
>
> From these results, you can see that the way I use that macro in
> wxPLplotwindow.h has also been used for a long time in
> wxPLplotstream.h, deprecated_wxPLplotwindow.h, and
> deprecated_wxPLplotstream.h.in.  Also, that macro is defined in
> include/pldll.h.in (which as you will discover has some complicated
> preprocessing logic).
>
> N.B. Use of such *IMPEXP* macros is an integral part of our symbol 
> visibility support.
>
>> let me know if something on my patch is not clear
>
> I slightly amended the commit message on your first (modified) commit
> to indicate this complete fix would be in two commits, amended the
> second (present) commit to put back PLDLLIMPEXP_WX again, greatly
> expanded the commit message of that second commit using your own 
> description
> that you made in your post describing that commit, filled in a Tested
> by: place-holding section for you that you should later fill out with
> all the platforms you tested these two commits on, and finally added
> my own Tested by: section.
>
> Would you also look at one compiler warning I got because of the above
> -Wuninitialized option?  Here was that complete warning:
>
> /home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp: 
> In member function ‘void wxPLplotwindow::setUseGraphicsContext(bool)’:
> /home/software/plplot/HEAD/plplot.git/bindings/wxwidgets/wxPLplotwindow.cpp:326:33:
>  
> warning: ‘drawDc’ may be used uninitialized in this function 
> [-Wmaybe-uninitialized]
>  m_stream.SetDC( drawDc );
>
> A lot of the time such warnings are spurious so you have to quiet them
> by initializing something that shouldn't really need it.  But
> sometimes they really do point to a serious problem with something
> tha

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

PS:


this is the ouput of the example


pvn@server:~/plplot-plplot/build$ examples/c/x01c -dev wxwidgets
PLplot library version: 5.11.1
00:36:21: Debug: plD_init_wxwidgets(): enter
00:36:21: Debug: wxPLDevice(): enter
00:36:21: Debug: wxPLDevice(): gc done
00:36:21: Debug: wxPLDevice(): m_interactiveTextGcdc done
00:36:21: Debug: SetupMemoryMap(): enter
00:36:21: Debug: SetupMemoryMap(): mapName start
00:36:21: Debug: SetupMemoryMap(): mapName done
00:36:21: Debug: SetupMemoryMap(): m_outputMemoryMap.create call
00:36:21: Debug: SetupMemoryMap(): m_outputMemoryMap.create done
00:36:21: Debug: wxPLplotwindow::wxPLplotwindow
00:36:21: Debug: SetupMemoryMap(): leave
00:36:21: Debug: wxPLDevice(): leave
00:36:21: Debug: plD_init_wxwidgets(): leave
00:36:21: Debug: wxPLplotwindow::OnCreate
00:36:21: Debug: plD_init_wxwidgets(): enter
00:36:21: Debug: wxPLDevice(): enter
00:36:21: Debug: wxPLDevice(): gc done
00:36:21: Debug: wxPLDevice(): m_interactiveTextGcdc done
00:36:21: Debug: wxPLDevice(): SetDC done
00:36:21: Debug: wxPLDevice(): leave
00:36:21: Debug: plD_init_wxwidgets(): leave
00:36:21: Debug: wxPLplotwindow::OnCreate

- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: "PLplot development list" <Plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 24, 2016 1:13 AM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> Hi Alan
>
> some more upbeat news about the example error , it's gone :-)
>
> It's the first time I do this commit patch procedure , so I just did
>
> git format-patch -1
>
> with my new changes (after doing a new branch, from the master, then
> patching your changes, wrote my changes,
> commited, merged into master, did a new patch, phew :-) )
>
> I did not wrote much in the patch , but here it is, basically I 
> reintroduced
> the wxPLplotwindow::OnCreate() event (keeping the wxPLplotwindow::Create()
> also)
>
> I think what was happening is that the PLViewer needs the
> wxPLplotwindow::OnCreate()  to create the stream , since
> wxPLplotwindow::Create() is not called for PLViewer.
>
>
> I also removed this "PLDLLIMPEXP_WX"
>
> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
>
> I searched  in all the source code and could not find this symbol ?
>
>
>> That produces for gcc a symbol visibility that is similar to
>> visibility on Windows platforms. That is, I don't think your changes
>> would have built on Windows.
>
> It builds on Windows.
> also, I think
>
> class "something" wxPLplotwindow : public wxFrame
>
> I believe is not a valid C++ construct
>
> let me know if something on my patch is not clear
>
>
> -Pedro
>
>
> - Original Message - 
> From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
> To: "Pedro Vicente" <pedro.vice...@space-research.org>
> Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "PLplot development list"
> <Plplot-devel@lists.sourceforge.net>
> Sent: Friday, December 23, 2016 2:50 PM
> Subject: Re: [Plplot-devel] Infinite Yielding issue
>
>
>> On 2016-12-23 01:40-0500 Pedro Vicente wrote:
>>
>>> Alan, Phil
>>>
>>> I went ahead and did a patch commit for option 3), attached,
>>> that has this:
>>>
>>> (note: I wrote the code in Windows, then ftp to Linux, I got some
>>> warnings
>>> about line endings, just do
>>> dos2unix if any thing shows up)
>>
>> Hi Pedro:
>>
>> Your change is extremly promising because for the first time I get the
>> same debug output here as you do on Ubunutu.  In other words we have
>> a deterministic order for the first time!
>>
>> However, your commit needs some code revision.  I did some of that
>> here, but there is more for you to do there to avoid the new bitmap
>> errors I detected when running the wxwidgets device driver which
>> launches wxPLViewer and communicates with it to get the plot displayed.
>> I suspect the revision you have done for the wxPLViewer code is
>> somehow interfering with that use of the wxPLViewer application.
>>
>> Now for the details.
>>
>> Your formatted patch (which by the way has no Windows line endings in
>> it) applied relatively cleanly here aside from minor whitespace issues,
>> but
>> did not build.
>>
>> That build issue was caused by incorrect symbol visibility for your
>> changes.  I found that issue on
>> Linux by using the -fvisibility=hidden option, e.g.,
>>
>> software@raven> printenv |grep FL
>> CXXFLAGS=-O3 -fvisibility=hidden -W

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

Hi Alan

some more upbeat news about the example error , it's gone :-)

It's the first time I do this commit patch procedure , so I just did

git format-patch -1

with my new changes (after doing a new branch, from the master, then 
patching your changes, wrote my changes,

commited, merged into master, did a new patch, phew :-) )

I did not wrote much in the patch , but here it is, basically I reintroduced 
the wxPLplotwindow::OnCreate() event (keeping the wxPLplotwindow::Create() 
also)


I think what was happening is that the PLViewer needs the 
wxPLplotwindow::OnCreate()  to create the stream , since

wxPLplotwindow::Create() is not called for PLViewer.


I also removed this "PLDLLIMPEXP_WX"

class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame

I searched  in all the source code and could not find this symbol ?



That produces for gcc a symbol visibility that is similar to
visibility on Windows platforms. That is, I don't think your changes
would have built on Windows.


It builds on Windows.
also, I think

class "something" wxPLplotwindow : public wxFrame

I believe is not a valid C++ construct

let me know if something on my patch is not clear


-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "PLplot development list" 
<Plplot-devel@lists.sourceforge.net>

Sent: Friday, December 23, 2016 2:50 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue



On 2016-12-23 01:40-0500 Pedro Vicente wrote:


Alan, Phil

I went ahead and did a patch commit for option 3), attached,
that has this:

(note: I wrote the code in Windows, then ftp to Linux, I got some 
warnings

about line endings, just do
dos2unix if any thing shows up)


Hi Pedro:

Your change is extremly promising because for the first time I get the
same debug output here as you do on Ubunutu.  In other words we have
a deterministic order for the first time!

However, your commit needs some code revision.  I did some of that
here, but there is more for you to do there to avoid the new bitmap
errors I detected when running the wxwidgets device driver which
launches wxPLViewer and communicates with it to get the plot displayed.
I suspect the revision you have done for the wxPLViewer code is
somehow interfering with that use of the wxPLViewer application.

Now for the details.

Your formatted patch (which by the way has no Windows line endings in
it) applied relatively cleanly here aside from minor whitespace issues, 
but

did not build.

That build issue was caused by incorrect symbol visibility for your 
changes.  I found that issue on

Linux by using the -fvisibility=hidden option, e.g.,

software@raven> printenv |grep FL
CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
FFLAGS=-O3 -Wuninitialized -Wunused

That produces for gcc a symbol visibility that is similar to
visibility on Windows platforms. That is, I don't think your changes
would have built on Windows.

The visibility fix was to replace

class wxPLplotwindow : public wxFrame

by

class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame

in bindings/wxwidgets/wxPLplotwindow.h.

I attach the revised version of your patch with this change and
several line-ending and style changes applied.  However, to quote from
that revised commit message (in the new Tested by: section for me)

I got "the same as the Ubuntu results above which is the first time the
two platforms have the same debugging output meaning we appear to have
a deterministic solution!"

"HOWEVER. There are run-time problems (invalid bitmap) with these
changes for wxPLViewer if you use that in conjunction with -dev
wxwidgets so this should not be the final version of this commit."

software@raven> examples/c/x01c -dev wxwidgets
PLplot library version: 5.11.1
10:54:55: Debug: nanosecs since epoch = 2210969809300109: 
plD_init_wxwidgets(): enter
10:54:55: Debug: nanosecs since epoch = 2210969845142231: wxPLDevice(): 
enter
10:54:55: Debug: nanosecs since epoch = 2210969845351899: wxPLDevice(): gc 
done
10:54:55: Debug: nanosecs since epoch = 2210969867143754: wxPLDevice(): 
m_interactiveTextGcdc done
10:54:55: Debug: nanosecs since epoch = 2210969867214649: 
SetupMemoryMap(): enter
10:54:55: Debug: nanosecs since epoch = 2210969868074842: 
SetupMemoryMap(): mapName start
10:54:55: Debug: nanosecs since epoch = 2210969868110859: 
SetupMemoryMap(): mapName done
10:54:55: Debug: nanosecs since epoch = 2210969868140426: 
SetupMemoryMap(): m_outputMemoryMap.create call
10:54:55: Debug: nanosecs since epoch = 2210969868201560: 
SetupMemoryMap(): m_outputMemoryMap.create done
10:54:55: Debug: nanosecs since epoch = 2210970015888076: 
wxPLplotwindow::wxPLplotwindow
10:54:55: Debug: nanosecs since epoch = 2210970031998161: 
SetupMemoryMap(): leave

Re: [Plplot-devel] Linux testing

[Pedro Vicente]

@Alan

I changed the thread tittle, because I have all kinds of weird results on my 
comprehensing testing.


first the obvious:

items 1) to 3) below are for the master branch

1) a Fortran error on Ubuntu 14.04

this was a simple
cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install -DCMAKE_BUILD_TYPE=Debug 
-DBUILD_TEST=ON

make VERBOSE=1 >& make.txt

but it detected gfortran and tried to build the fortran code.
output is attached

2)

then I disabled Fortran

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install -DCMAKE_BUILD_TYPE=Debug 
-DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DBUILD_TEST=ON

make VERBOSE=1
no errors

then (note , running from the build location)

pvicente@glace:~/plplot-plplot/build$ 
../scripts/comprehensive_test.sh --cmake_added_options 
"-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON 
-DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON -DENABLE_f95:BOOL=OFF" 
--do_test_noninteractive no --do_ctest no


Each of the steps in this comprehensive test may take a while
cmake in the build tree
ERROR: cmake in the build tree failed

How can I capture the output here? It asks for a interactive (yes/no), can I 
disable this and instead redirect the output to a file?



3)

On another Linux, 16.04,  where *I don't* have gfortran

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/plplot-install -DCMAKE_BUILD_TYPE=Debug 
 -DBUILD_TEST=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON

make VERBOSE=1
make VERBOSE=1 test_wxPLplotDemo

Infinite loop
22:25:42: Debug: Plot() Yielding

pvn@server:~/plplot-plplot/build$ 
../scripts/comprehensive_test.sh --cmake_added_options 
"-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON 
-DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON" --do_test_noninteractive 
no --do_ctest no


then it stays here (I suppose because of the infinite loop)
and I get a blank plviewer window

Each of the steps in this comprehensive test may take a while
cmake in the build tree
make -j4 VERBOSE=1 test_interactive in the build tree

4)

results for my patch commit

@Phil
I was able to make the example 01 run with no runtime errors by 
re-introduncing the OnCreate() event (but also keeping the Create() call).

But then I got other errors.
I am not sure what are the consequences of these changes, so here it's 
better for me to wait until you provide some insight into this.


to do items:

1)

it would be great if any of you could reproduce my test_wxPLplotDemo 
behavior on Linux


the response from the developer



This is not completely unexpected, the window is only really created when
it's "realized" in GTK+/X11 terms, which can take quite some time, in
particular if a remote X server is used



could this "remote X server is used" be because I am accesing my linux 
machines remotely ? (by using X2Go)



2)

maybe put the master back with one of the workarounds that I don't have the 
infinite loop,

so that I have a better idea of what happens in the comprehensing testing?

-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>

Sent: Friday, December 23, 2016 5:19 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue



On 2016-12-23 16:43-0500 Pedro Vicente wrote:


by the way, what are the commands to do comprehensing testing?


That script should be able to run on all Unix systems and Unix-like
systems (i.e., Cygwin and MinGW-w64/MSYS2), but not currently for MSVC
("raw Windows").  However, Arjen plans to investigate a possibility for
running that script on MSVC platforms as well in 2017.

So for now, on Unix or Unix-like systems, I suggest you run

scripts/comprehensive_test.sh --cmake_added_options 
"-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON 
 -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON" --do_test_noninteractive 
no --do_ctest no


I used exactly those options recently myself.

Those options are constraints on the script to keep it from doing
time-consuming (several hours?) tests that you probably don't
need/want to run right now.

So my suggested options constrain the script to just test the
plplotwxwidgets library and the wxwidgets device driver for our 3
major configurations and 3 different build trees. (So you will see the
tests repeat 9 times for those combinations.) There are no
noninteractive tests of the wxwidgets device driver or plplotwxwidgets
library.  But to avoid the non-interactive C++ tests, we further
constrain the s

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

by the way, what are the commands to do comprehensing testing?

-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Friday, December 23, 2016 4:30 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-23 15:18-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I applied the patch on CentOS;
>> no errors on build
>> wxPLplotwindow demo does the plot
>> same error on the same example
>
> Thanks, Pedro, for verifying my revision of your commit applies
> cleanly there and for verifying the run-time error I discovered with
> your commit.  And good luck fixing whatever the trouble is that is
> causing that error.
>
> With regard to your suggestion for finding other ways to have
> collaborative git development, this is a really critical time for us
> trying to find a rock-solid fix for this release-critical issue so I
> would prefer we discuss your suggestion post-release when we are all
> more relaxed and have time to consider your suggestion carefully.
>
> 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
> __
> 


--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

Hi Alan

>With regard to your suggestion for finding other ways to have
>collaborative git development, this is a really critical time for us
>trying to find a rock-solid fix for this release-critical issue so I
>would prefer we discuss your suggestion post-release when we are all
>more relaxed and have time to consider your suggestion carefully.

on better thinking doing a "dev" branch where things have errors might not 
be a good idea,
the less entropy the better.

so, this patch exchange is better i.m.o

I''ll check the errors later

-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Friday, December 23, 2016 4:30 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> On 2016-12-23 15:18-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I applied the patch on CentOS;
>> no errors on build
>> wxPLplotwindow demo does the plot
>> same error on the same example
>
> Thanks, Pedro, for verifying my revision of your commit applies
> cleanly there and for verifying the run-time error I discovered with
> your commit.  And good luck fixing whatever the trouble is that is
> causing that error.
>
> With regard to your suggestion for finding other ways to have
> collaborative git development, this is a really critical time for us
> trying to find a rock-solid fix for this release-critical issue so I
> would prefer we discuss your suggestion post-release when we are all
> more relaxed and have time to consider your suggestion carefully.
>
> 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
> __
> 


--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

Hi Alan

I applied the patch on CentOS;
no errors on build
wxPLplotwindow demo does the plot
same error on the same example

I have a small suggestion:
instead of emailling patches and applyting them to multiple machines (I 
have 4)
what about doing a remote branch called "development"  and just commmit 
and push directly there,
even if you get errors like this?
that would make sharing more immediate

I'll take a llok at those errors later

results:

I got this warning

[pedro.vicente@rhw9121 plplot-plplot]$ git am < 
0001-wxwidgets-binding-fix-for-delayed-OnCreate-event.patch
Applying: wxwidgets binding: fix for delayed OnCreate event
.git/rebase-apply/patch:355: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

then

make VERBOSE=1 test_wxPLplotDemo

15:06:20: Debug: wxPLplotwindow::wxPLplotwindow
15:06:20: Debug: wxPLplotwindow::Create()
15:06:20: Debug: wxPLplotwindow::CreateFrame()
15:06:20: Debug: plD_init_wxwidgets(): enter
15:06:20: Debug: wxPLDevice(): enter
15:06:20: Debug: wxPLDevice(): gc done
15:06:20: Debug: wxPLDevice(): m_interactiveTextGcdc done
15:06:20: Debug: wxPLDevice(): SetDC done
15:06:20: Debug: wxPLDevice(): leave
15:06:20: Debug: plD_init_wxwidgets(): leave
15:06:20: Debug: frame->Create
15:06:20: Debug: Plot()

then

[pedro.vicente@rhw9121 build]$ examples/c/x01c -dev wxwidgets
PLplot library version: 5.11.1
15:11:37: Debug: plD_init_wxwidgets(): enter
15:11:37: Debug: wxPLDevice(): enter
15:11:37: Debug: wxPLDevice(): gc done
15:11:37: Debug: wxPLDevice(): m_interactiveTextGcdc done
15:11:37: Debug: SetupMemoryMap(): enter
15:11:37: Debug: SetupMemoryMap(): mapName start
15:11:37: Debug: SetupMemoryMap(): mapName done
15:11:37: Debug: SetupMemoryMap(): m_outputMemoryMap.create call
15:11:37: Debug: SetupMemoryMap(): m_outputMemoryMap.create done
15:11:38: Debug: wxPLplotwindow::wxPLplotwindow
15:11:38: Debug: SetupMemoryMap(): leave
15:11:38: Debug: wxPLDevice(): leave
15:11:38: Debug: plD_init_wxwidgets(): leave
../src/gtk/bitmap.cpp(941): assert ""IsOk()"" failed in GetWidth(): 
invalid bitmap






On 2016-12-23 14:50, Alan W. Irwin wrote:
> On 2016-12-23 01:40-0500 Pedro Vicente wrote:
>
>> Alan, Phil
>>
>> I went ahead and did a patch commit for option 3), attached,
>> that has this:
>>
>> (note: I wrote the code in Windows, then ftp to Linux, I got some 
>> warnings about line endings, just do
>> dos2unix if any thing shows up)
>
> Hi Pedro:
>
> Your change is extremly promising because for the first time I get 
> the
> same debug output here as you do on Ubunutu.  In other words we have
> a deterministic order for the first time!
>
> However, your commit needs some code revision.  I did some of that
> here, but there is more for you to do there to avoid the new bitmap
> errors I detected when running the wxwidgets device driver which
> launches wxPLViewer and communicates with it to get the plot 
> displayed.
> I suspect the revision you have done for the wxPLViewer code is
> somehow interfering with that use of the wxPLViewer application.
>
> Now for the details.
>
> Your formatted patch (which by the way has no Windows line endings in
> it) applied relatively cleanly here aside from minor whitespace 
> issues, but
> did not build.
>
> That build issue was caused by incorrect symbol visibility for your
> changes.  I found that issue on
> Linux by using the -fvisibility=hidden option, e.g.,
>
> software@raven> printenv |grep FL
> CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
> CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
> FFLAGS=-O3 -Wuninitialized -Wunused
>
> That produces for gcc a symbol visibility that is similar to
> visibility on Windows platforms. That is, I don't think your changes
> would have built on Windows.
>
> The visibility fix was to replace
>
> class wxPLplotwindow : public wxFrame
>
> by
>
> class PLDLLIMPEXP_WX wxPLplotwindow : public wxFrame
>
> in bindings/wxwidgets/wxPLplotwindow.h.
>
> I attach the revised version of your patch with this change and
> several line-ending and style changes applied.  However, to quote 
> from
> that revised commit message (in the new Tested by: section for me)
>
> I got "the same as the Ubuntu results above which is the first time 
> the
> two platforms have the same debugging output meaning we appear to 
> have
> a deterministic solution!"
>
> "HOWEVER. There are run-time problems (invalid bitmap) with these
> changes for wxPLViewer if you use that in conjunction with -dev
> wxwidgets so this should not be the final version of this commit."
>
> software@raven> examples/c/x01c -dev wxwidgets
> PLplot library version: 5.11.1
> 10:54:55: Debug: nanosecs since epoch = 2210969809300109:
> plD_

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

Alan, Phil

I went ahead and did a patch commit for option 3), attached,
that has this:

(note: I wrote the code in Windows, then ftp to Linux, I got some warnings 
about line endings, just do

dos2unix if any thing shows up)

Subject: [PATCH] wxwidgets binding: fix for delayed OnCreate event

The delayed call of the create event (OnCreate()) on wxApp::OnInit() is a 
wxWidgets feature.

To avoid that, the fix is to remove the event creation completely,
and instead override Create().
For this to happen, the wxPLplotwindow class cannot be templated.
Other changes are that events are now handled by a static event table,
using wxDECLARE_EVENT_TABLE().
An auxiliary function CreateStream() creates the stream in Create().
The code of wxPLplotwindow was moved to a new source file wxPLplotwindow.cpp

Tested by: Pedro Vicente <pedro.vice...@rhw9121.star1.nesdis.noaa.gov>
on Ubuntu Linux 16.04 with wxwidgets3.0 package installed.
Results from building the test_wxPLplotDemo target:

01:06:35: Debug: wxPLplotwindow::wxPLplotwindow
01:06:35: Debug: wxPLplotwindow::Create()
01:06:35: Debug: wxPLplotwindow::CreateFrame()
01:06:35: Debug: plD_init_wxwidgets(): enter
01:06:35: Debug: wxPLDevice(): enter
01:06:35: Debug: wxPLDevice(): gc done
01:06:35: Debug: wxPLDevice(): m_interactiveTextGcdc done
01:06:35: Debug: wxPLDevice(): SetDC done
01:06:35: Debug: wxPLDevice(): leave
01:06:35: Debug: plD_init_wxwidgets(): leave
01:06:35: Debug: frame->Create
01:06:35: Debug: Plot()

NOTE:

previous to the creation of Create(), the same code was tested using
the event creation of OnCreate(): the error still happens in this case

00:48:12: Debug: wxPLplotwindow::wxPLplotwindow
00:48:12: Debug: frame->Create
00:48:12: Debug: Plot() FALSE IsReady()
00:48:12: Debug: wxPLplotwindow::OnCreate
00:48:12: Debug: plD_init_wxwidgets(): enter
00:48:12: Debug: wxPLDevice(): enter
00:48:12: Debug: wxPLDevice(): gc done
00:48:12: Debug: wxPLDevice(): m_interactiveTextGcdc done
00:48:12: Debug: wxPLDevice(): SetDC done
00:48:12: Debug: wxPLDevice(): leave
00:48:12: Debug: plD_init_wxwidgets(): leave





- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<Plplot-devel@lists.sourceforge.net>

Sent: Thursday, December 22, 2016 11:05 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue



Hi Pedro:

On 2016-12-22 18:34-0500 Pedro Vicente wrote:


@Alan

[...]
[The wxwidgets developer] says we cannot expect a timely response from 
the "create" event in wxApp::OnInit(),

which is the way wxPLplotDemo has.

so, we have to change that, it just cannot be like it is now.


Good point!



@Phil

[Three] options


Your ideas for fixing this issue are rightly directed to Phil because I 
don't have much
expertise to help you in this area.  Therefore, I will confine what I say 
in response to

just one issue with case 3 that you brought up.


But [option 3] would probably break existing applications.
but at the moment this is the only solution that we know has no potencial 
issues.


I don't think we should be too concerned with breaking applications since
Phil's wxwidgets approach is still pretty new and experimental, and it
was breaking them in any case as you have been demonstrating.  :-)

I am not tuned in to wxwidgets very much, but I never heard of anyone
using the old plplotwxwidgets library for anything.  And the only use
of Phil's new plplotwxwidgets library I have heard of up to this point
is your use and Greg Jung's use.  In his case he used that library as
a means of getting the GDL (Gnu Data Language) project (see
<https://en.wikipedia.org/wiki/GNU_Data_Language> to provide
PLplot-generated plots on Windows. But I am pretty sure his approach
was a private experiment and is not an official part of GDL. So I
suspect that it is just you and Greg that we would be inconveniencing
here, but I assume both of you would be happy to accept that
inconvenience if the result was that from then on you were building
your apps and libraries on top of a plplotwxwidgets library that was
rock solid.

It sounds like case 3 is the only rock-solid solution we have up to
now so my naive vote would be for that solution unless Phil comes up
with a different rock-solid solution that he prefers.  So please
thrash it out between you, and I look forward to the decision you two
make and the implementation that will quickly follow that decision
about the best way to fix this issue in a fundamental way.

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 (timeeph

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@Alan


>Does that seem like a reasonable plan for dealing with the fairly
>large release uncertainties created by this issue?

yes

this is the response from the developer


> This is not completely unexpected, the window is only really created when
> it's "realized" in GTK+/X11 terms, which can take quite some time, in
> particular if a remote X server is used. But why should it matter? Just 
> run
> the event loop until the "create" event is received and do whatever
> initialization you need to do once it happens, you don't have to (and 
> won't
> be able to) do it directly in OnInit().

he says we cannot expect a timely response from the "create" event in 
wxApp::OnInit(),
which is the way wxPLplotDemo has.

so, we have to change that, it just cannot be like it is now.

@Phil

several options

1)

remove the frame creation from wxApp::OnInit(),

I don't know where to move it to (or even if it is possible) , but the wxApp 
methods could provide some insight.

http://docs.wxwidgets.org/3.1/classwx_app_console.html

2)

leave the frame creation in wxApp::OnInit(),

this requires that the  "create" event  must not be triggered, so we cannot 
call for OnCreate().

Since the frame creation must be done in the "create" functions (either in 
Create() or OnCreate())
that leaves only the Create()  function.

But , like Phil mentioned , the class that eventually creates the plot could 
not be a wxFrame,
so the Create()  function cannot be overriden.

But maybe we can do the template valid only for classes that have similar 
Create() functions to wxFrame, and where
it is possible to override Create() ?

I don't know wich classes are the intended targets of the plot, maybe also 
dialogs?

3) other option would be not to do the templated plot window, and do a 
version only for wxFrame,
and override the Create() function, and make the frame in wxApp::OnInit().

But this would probably break existing applications.
but at the moment this is the only solution that we know has no potencial 
issues.


> However, that might be the wrong thing to do since the issue is we
> don't really understand what is going on here. So I think we really need a 
> fundamental solution for this issue that
> you guys understand before we release PLplot.

yes, no point in switching to another commit version that could have or not 
the same problem.


> But finding
> a fundamental solution to this issue is important enough that I think
> we should put off that commit (if necessary) until 5 days from now
> (Tuesday,December 27th when I was planning to make the release).

ok


-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<Plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 22, 2016 5:07 PM
Subject: RE: [Plplot-devel] Infinite Yielding issue


> On 2016-12-22 09:48-0500 Pedro Vicente wrote:
>
>> Hi Phil
>>
>> there is a response from a developer
>>
>> https://groups.google.com/forum/#!topic/wx-dev/wsk--AlQNzU
>
> To Pedro and Phil:
>
> I hope that developer is responsive to Pedro's supplementary question,
> but so far he hasn't been.  Therefore, Pedro, I suggest you follow
> Phil's advice to try other wxwidgets help avenues as well such as the
> "wxWidgets trac system" he mentioned for getting help.
>
> Meanwhile, I discovered just this morning that I now
> have the infinite Yielding loop when attempting to build the
> test_wxPLplotDemo target.  I believe that is the first time
> that anybody other than Pedro has encountered this issue.
>
> And if I use
>
> git checkout master^
>
> the test_wxPLplotDemo infinite Yielding loop goes away, i.e., I get
>
> 12:43:03: Debug: nanosecs since epoch = 2131058112372533: 
> wxPLplotwindow::wxPLplotwindow
> 12:43:03: Debug: nanosecs since epoch = 2131058122107520: frame->Create
> 12:43:03: Debug: nanosecs since epoch = 2131058129943746: 
> wxPLplotwindow::OnCreate
> 12:43:03: Debug: nanosecs since epoch = 2131058145174385: 
> plD_init_wxwidgets(): enter
> 12:43:03: Debug: nanosecs since epoch = 2131058145277524: wxPLDevice(): 
> enter
> 12:43:03: Debug: nanosecs since epoch = 2131058145349163: wxPLDevice(): gc 
> done
> 12:43:03: Debug: nanosecs since epoch = 2131058145447089: wxPLDevice(): 
> m_interactiveTextGcdc done
> 12:43:03: Debug: nanosecs since epoch = 2131058145489262: wxPLDevice(): 
> SetDC done
> 12:43:03: Debug: nanosecs since epoch = 2131058145596088: wxPLDevice(): 
> leave
> 12:43:03: Debug: nanosecs since epoch = 2131058145629197: 
> plD_init_wxwidgets(): leave
> 12:43:03: Debug: nano

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

Hi Phil

there is a response from a developer

https://groups.google.com/forum/#!topic/wx-dev/wsk--AlQNzU

-Pedro


On 2016-12-22 04:58, p.d.rosenb...@gmail.com wrote:
> Hi Pedro
>
> It's great that you set that up. I would suggest that you post it to
> the wxWidgets trac system too. The forum is great for advice on how 
> we
> can change things, and doublemax really knows what he’s talking
> about, but the wxWidgets devs only use trac for dealing with bug
> reports. If it is left on the forum then it will get lost.
>
> Phil
>
> Sent from my Windows 10 phone
>
> FROM: Alan W. Irwin [1]
> SENT: 22 December 2016 05:39
> TO: Pedro Vicente [2]; Phil Rosenberg [3]; PLplot development list 
> [4]
> SUBJECT: Re: [Plplot-devel] Infinite Yielding issue
>
> Hi Pedro:
>
> More thoughts:
>
> I like your example because it follows the first rule of debugging
>
> which is to simplify the example that shows the strange behaviour.
>
> And I get success on my platform, and you don't on yours which
>
> confirms there is a problem (either there is a bug in wxwidgets/GTK+
>
> or your simple example uses that software incorrectly). But it is a
> huge
>
> simplification that PLplot is no longer involved, and I highly
>
> approve.
>
> And with regard to the actual problem demonstrated by this simple
>
> example, I am still left wondering if you might be exposing some
>
> wxwidgets or GTK+ bug on your fast hardware there that my slow
>
> hardware does not expose here?  So just for fun, can you get access
> to
>
> a Linux system on a moderately slow PC there to try this simple
>
> example?  It doesn't have to be superslow. But I do have a
>
> nine-year-old PC running at 2.4GHz with two cpus. So if you can find 
> a
>
> Linux PC that has roughly the same speed as that, you might find a
>
> platform where you obtain success with your simple example which 
> might
>
> be a clue about the cause 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
>
> __
>
>
>
> Links:
> --
> [1] mailto:ir...@beluga.phys.uvic.ca
> [2] mailto:pedro.vice...@space-research.org
> [3] mailto:p.d.rosenb...@gmail.com
> [4] mailto:plplot-devel@lists.sourceforge.net

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@Alan


> It appears your proposed solution to swap the order in which Yield and
> Show are called works on your CentOS platform which has always given
> you the most trouble.  If it works on all of them please prepare the 
> relevant commit

ok,

I just posted a question about this on the wxWidgets forum


https://groups.google.com/forum/#!topic/wx-dev/wsk--AlQNzU

If noboby replies in a day or 2, I''ll commit that workaround patch.
It would be nice to sort this out if we can.

@Phil

I did a simple wxWidgets app (no PLplot) that shows the issue

it's here , wx_demo.cpp

https://github.com/pedro-vicente/plplot-wxwidgets

I get this output (OnCreate is called after the main app tries to test 
frame->IsReady() )
the stream here is simulated by a boolean

18:33:43: Debug: wxFrameTest::wxFrameTest
18:33:43: Debug: frame->Create
18:33:43: Debug: wxFrameTest::Show
18:33:43: Debug: frame->Show
18:33:43: Debug: FALSE frame->IsReady
18:33:43: Debug: wxFrameTest::OnSize
18:33:43: Debug: wxFrameTest::OnCreate
18:33:43: Debug: wxFrameTest::CreateStream


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Wednesday, December 21, 2016 7:36 PM
Subject: RE: [Plplot-devel] Infinite Yielding issue


> On 2016-12-21 23:25- p.d.rosenb...@gmail.com wrote:
>
>> Sorry I have not been able to look at this today. I have had family 
>> things on.
>
>> Thanks for looking into that. I half suspected that might be the
> case. So after everything I said about contracts with the Show
> function, it seems it is already broken ☹
>
> To Pedro and Phil:
>
> Since we are all running out of time not only because of family activities
> during this season but also because the release date is only 6 days
> from now, I suggest we come up with a quick compromise fix for this
> release even if you guys don't completely understand why it works.
>
> Here is my suggestion for such a fix.
>
> @Pedro:
>
> It appears your proposed solution to swap the order in which Yield and
> Show are called works on your CentOS platform which has always given
> you the most trouble.  So that sounds promising for a quick fix, but
> please also test your proposed solution on all platforms accessible to
> you including your Windows platform (just in case a change since you
> last tested that platform has somehow clobbered wxwidgets on that
> platform).  If it works on all of them please prepare the relevant
> commit (with a tested by: paragraph listing all the platforms you
> tested for future reference just in case we run into trouble with this
> part of our wxwidgets-related software ever again) and send it to me
> for one final test that it also works here. Assuming all those tests
> work, I will push that commit, and we will be done with this bug for
> at least this release!
>
> Alan
>
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
> 


--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@Alan, Phil

all works on the commit *before* current master, detailed results below


@Phil

Would you mind sending a few lines explaining how the Yield() function works 
and its effect here?
I get a few different results, and I would just like to understand what is 
happening here.

Also, it would be really great if you could replicate my results.

Maybe the VirtualBox on Windows?
If you do,  a must is to install the GuestCD Additions that allows full 
screen and both ways copy and paste to host.
Otherwise you get a tiny window with Linux running inside Windows.
By the way on debian I could not install the GuestCD Additions.

Or even an old machine that you have lying around, if you do a complete new 
install of ubuntu.

ubuntu 14.04
ubuntu 16.04

ok, but curiously we don't have a Yield() wait

65e7b3c Fix bug with plotting in wxPLplotDemo

23:31:38: Debug: wxPLplotwindow::wxPLplotwindow
23:31:38: Debug: frame->Create
23:31:38: Debug: wxPLplotwindow::OnCreate
23:31:38: Debug: plD_init_wxwidgets(): enter
23:31:38: Debug: wxPLDevice(): enter
23:31:38: Debug: wxPLDevice(): gc done
23:31:38: Debug: wxPLDevice(): m_interactiveTextGcdc done
23:31:38: Debug: wxPLDevice(): SetDC done
23:31:38: Debug: wxPLDevice(): leave
23:31:38: Debug: plD_init_wxwidgets(): leave
23:31:38: Debug: Plot()


debian 8.0

also ok, but the result has one Yield()  call
on CentOS I got many Yield()  calls

23:31:38: Debug: wxPLplotwindow::wxPLplotwindow
23:31:38: Debug: frame->Create
23:31:38: Debug: Plot() Yielding
23:31:38: Debug: wxPLplotwindow::OnCreate
23:31:38: Debug: plD_init_wxwidgets(): enter
23:31:38: Debug: wxPLDevice(): enter
23:31:38: Debug: wxPLDevice(): gc done
23:31:38: Debug: wxPLDevice(): m_interactiveTextGcdc done
23:31:38: Debug: wxPLDevice(): SetDC done
23:31:38: Debug: wxPLDevice(): leave
23:31:38: Debug: plD_init_wxwidgets(): leave
23:31:38: Debug: Plot()




- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Tuesday, December 20, 2016 11:27 PM
Subject: Re: [Plplot-devel] Infinite Yielding issue


> @Alan, Phil
>
> yes, my bad, sorry
>
> here are corrected results. *It works* on the commit before the current
> master, for CentOS, I'll try others later
>
> git checkout master
> git log --oneline -3
>
> 995e75e60 Made some items clearer in the wxWigdets Demo
> 65e7b3c99 Fix bug with plotting in wxPLplotDemo
> 67ef7be48 Added a function to check if the window is ready to accept plot
> commands.
>
> on master, infinite loop
>
> make VERBOSE=1 test_wxPLplotDemo
> 23:20:31: Debug: wxPLplotwindow::wxPLplotwindow
> 23:20:31: Debug: frame->Create
> 23:20:31: Debug: Plot() Yielding
> 23:20:31: Debug: Plot() Yielding
>
> going back one , ok
>
> git checkout 65e7b3c99
>
> 65e7b3c99 Fix bug with plotting in wxPLplotDemo
>
>
>
> 23:23:09: Debug: wxPLplotwindow::wxPLplotwindow
> 23:23:09: Debug: frame->Create
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: Plot() Yielding
> 23:23:09: Debug: wxPLplotwindow::OnCreate
> 23:23:09: Debug: plD_init_wxwidgets(): enter
> 23:23:09: Debug: wxPLDevice(): enter
> 23:23:09: Debug: wxPLDevice(): gc done
> 23:23:09: Debug: wxPLDevice(): m_interactiveTextGcdc done
> 23:23:09: Debug: wxPLDevice(): SetDC done
> 23:23:09: Debug: wxPLDevice(): leave
> 23:23:09: Debug: plD_init_wxwidgets(): leave
> 23:23:09: Debug: Plot()
>
>
>
> - Original Message - 
> From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
> To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg"
> <p.d.rosenb...@gmail.com>; "PLplot development list"
> <plplot-devel@lists.sourceforge.net>
> Sent: Tuesday, December 20, 2016 10:47 PM
> Subject: Re: Infinite Yielding issue
>
>
>> On 2016-12-20 21:23-0500 Pedro Vicente wrote:
>>
>>> @Alan
>>>
>>> yes, git is really good for these things, I forgot about that.
>>>
>>> I did
>>>
>>> git checkout 67ef7be48217c098ae49bb893df5

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@Alan, Phil

yes, my bad, sorry

here are corrected results. *It works* on the commit before the current 
master, for CentOS, I'll try others later

git checkout master
git log --oneline -3

995e75e60 Made some items clearer in the wxWigdets Demo
65e7b3c99 Fix bug with plotting in wxPLplotDemo
67ef7be48 Added a function to check if the window is ready to accept plot 
commands.

on master, infinite loop

make VERBOSE=1 test_wxPLplotDemo
23:20:31: Debug: wxPLplotwindow::wxPLplotwindow
23:20:31: Debug: frame->Create
23:20:31: Debug: Plot() Yielding
23:20:31: Debug: Plot() Yielding

going back one , ok

git checkout 65e7b3c99

65e7b3c99 Fix bug with plotting in wxPLplotDemo



23:23:09: Debug: wxPLplotwindow::wxPLplotwindow
23:23:09: Debug: frame->Create
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: Plot() Yielding
23:23:09: Debug: wxPLplotwindow::OnCreate
23:23:09: Debug: plD_init_wxwidgets(): enter
23:23:09: Debug: wxPLDevice(): enter
23:23:09: Debug: wxPLDevice(): gc done
23:23:09: Debug: wxPLDevice(): m_interactiveTextGcdc done
23:23:09: Debug: wxPLDevice(): SetDC done
23:23:09: Debug: wxPLDevice(): leave
23:23:09: Debug: plD_init_wxwidgets(): leave
23:23:09: Debug: Plot()



- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Tuesday, December 20, 2016 10:47 PM
Subject: Re: Infinite Yielding issue


> On 2016-12-20 21:23-0500 Pedro Vicente wrote:
>
>> @Alan
>>
>> yes, git is really good for these things, I forgot about that.
>>
>> I did
>>
>> git checkout 67ef7be48217c098ae49bb893df5e170c3eccc2c
>
> Hi Pedro:
>
> Note this summary of the last three commits (all from Phil) for the
> master branch.
>
> software@raven> git log --oneline -3
> 995e75e Made some items clearer in the wxWigdets Demo
> 65e7b3c Fix bug with plotting in wxPLplotDemo
> 67ef7be Added a function to check if the window is ready to accept plot 
> commands.
>
> So master^^ = 67ef7be is the one you are testing which is simply
> a preparation for master^ = 65e7b3c.  I thought it was master^ that
> worked previously for you on one platform, and master = 995e75e that
> has been causing you trouble since. So I am surprised you are testing
> master^^ = 67ef7be rather than master^ = 65e7b3c.  But maybe I am not
> remembering the sequence of events and tests correctly.
>
> 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
> __
> 


--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@Alan

yes, git is really good for these things, I forgot about that.

I did

git checkout 67ef7be48217c098ae49bb893df5e170c3eccc2c
make VERBOSE=1 test_wxPLplotDemo



hmm, still some issues.

Good thing I decided to try on all platforms because I was almost going to 
shout success after trying the 2 ubuntus and debian (that have wxwidgets 
3.0)
but on CentOS the Yield() has no effect (don't  know if it's because is 
wxWidgets 3.1)

So, it happens that I had a similar problem some weeks ago, the problem was 
that my wxWidgets app (a client) must read some data from a socket on a 
server
and potentially this can take minutes.

Initially I did the reading on the socket on the main window frame.
But the reading blocks all the GUI, it's not even possible to exit the 
program, so I started searching for a way to avoid the blocking, and I found 
the Yield() function on their docs.

However it had no effect at all :-)

So, my next step was to use a separate thread as explained in their 
examples.
It's good that wxWidgets has its own thread API.
This makes the code much more complex, specially the way one thread 
communicates with the other, but works like a charm.
Since my goal was to detect when one task was finished , it may be possible 
to do something similar here.

I'll post on my next email the example I followed.

here it goes the results

ubuntu, debian, a plot shows

20:53:09: Debug: wxPLplotwindow::wxPLplotwindow
20:53:09: Debug: frame->Create
20:53:09: Debug: wxPLplotwindow::OnCreate
20:53:09: Debug: plD_init_wxwidgets(): enter
20:53:09: Debug: wxPLDevice(): enter
20:53:09: Debug: wxPLDevice(): gc done
20:53:09: Debug: wxPLDevice(): m_interactiveTextGcdc done
20:53:09: Debug: wxPLDevice(): SetDC done
20:53:09: Debug: wxPLDevice(): leave
20:53:09: Debug: plD_init_wxwidgets(): leave
20:53:09: Debug: Plot()


centOS, here we get a window with no plot, see the NULL below

21:01:37: Debug: wxPLplotwindow::wxPLplotwindow
21:01:37: Debug: frame->Create
21:01:37: Debug: pls NULL
21:01:37: Debug: wxPLplotwindow::OnCreate
21:01:37: Debug: plD_init_wxwidgets(): enter
21:01:37: Debug: wxPLDevice(): enter
21:01:37: Debug: wxPLDevice(): gc done
21:01:37: Debug: wxPLDevice(): m_interactiveTextGcdc done
21:01:37: Debug: wxPLDevice(): SetDC done
21:01:37: Debug: wxPLDevice(): leave
21:01:37: Debug: plD_init_wxwidgets(): leave



- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "PLplot development list"
<plplot-devel@lists.sourceforge.net>
Sent: Tuesday, December 20, 2016 6:56 PM
Subject: Re: Infinite Yielding issue


> On 2016-12-20 17:49-0500 Pedro Vicente wrote:
>
>> @Alan, Phil
>>
>>
>> here are my results
>>
>> for git master current
>>
>> CentOS 6.8 wxWidgets 3.1
>> Linux 14.04 wxWidgets 3.0
>> Linux 16.04 wxWidgets 3.0
>> Debian 8.0 wxWidgets 3.0
>>
>> all infinite loop
>>
>> 14:25:57: Debug: wxPLplotwindow::wxPLplotwindow
>> 14:25:57: Debug: frame->Create
>> 14:25:57: Debug: Plot() Yielding
>> 14:25:57: Debug: Plot() Yielding
>>
>> made with
>>
>> cmake ..  -G "Unix
>> Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/plplot-install 
>> -DCMAKE_BUILD_TYPE=Debug
>>  -DBUILD_SHARED_LIBS:BOOL=OFF  -DBUILD_TEST=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON
>>
>> yesterday I sent this result for Ubuntu 14.04, but that was with
>> yesterday's master.
>>
>> Phil, today there was a new commit, so could that be it ?
>
> Hi Pedro:
>
> You can prove or disprove the latest commit 995e75e6086 is the source of
> some/all of the above issues by running those tests again on the
> previous commit.  Which from the current "git log" results you should
> be able to get access to as follows:
>
> git checkout 995e75e6086^
>
> or the equivalent
>
> git checkout 65e7b3c9980
>
> 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
> __
>


--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Infinite Yielding issue

[Pedro Vicente]

@Alan, Phil


here are my results

for git master current

CentOS 6.8 wxWidgets 3.1
Linux 14.04 wxWidgets 3.0
Linux 16.04 wxWidgets 3.0
Debian 8.0 wxWidgets 3.0

all infinite loop

14:25:57: Debug: wxPLplotwindow::wxPLplotwindow
14:25:57: Debug: frame->Create
14:25:57: Debug: Plot() Yielding
14:25:57: Debug: Plot() Yielding

made with

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/plplot-install 
-DCMAKE_BUILD_TYPE=Debug 
 -DBUILD_SHARED_LIBS:BOOL=OFF  -DBUILD_TEST=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON

yesterday I sent this result for Ubuntu 14.04, but that was with yesterday's 
master.

Phil, today there was a new commit, so could that be it ?

23:26:43: Debug: wxPLplotwindow::wxPLplotwindow
23:26:44: Debug: frame->Create
23:26:44: Debug: Plot() Yielding
23:26:44: Debug: wxPLplotwindow::OnCreate
23:26:44: Debug: plD_init_wxwidgets(): enter
23:26:44: Debug: wxPLDevice(): enter
23:26:44: Debug: wxPLDevice(): gc done
23:26:44: Debug: wxPLDevice(): m_interactiveTextGcdc done
23:26:44: Debug: wxPLDevice(): SetDC done
23:26:44: Debug: wxPLDevice(): leave
23:26:44: Debug: plD_init_wxwidgets(): leave
23:26:44: Debug: Plot()






- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Pedro Vicente" 
<pedro.vice...@space-research.org>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Tuesday, December 20, 2016 3:10 PM
Subject: Infinite Yielding issue


> On 2016-12-20 13:07-0500 Pedro Vicente wrote:
>
>> Hi Alan, Phil
> [...] I just tried on my CentOS with the latest git
>> code, and what happens
>> is that the execution is always on
>>
>> 12:50:24: Debug: Plot() Yielding
>
> To Pedro and Phil:
>
> @Pedro:
>
> It is good you have checked Phil's latest solution against some of the
> Linux platforms accessible to you, but while waiting for a response
> from him on this infinite Yielding issue you have found on your CentOS
> platform, you might want to check all your Linux platforms to see if
> the issue is confined just to CentOS or not to help give Phil some
> insight as to why his latest solution is not working universally on
> all Linux platforms. And of course when Phil comes up with a fix, it
> would help us a lot if you checked it against all Linux platforms
> accessible to you.
>
> @Phil:
>
> Part of my motivation for responding here is I noticed that Pedro had
> dropped you from the specific recipients list and used an old subject
> line that is no longer relevant.  So you might have missed his post.
> Therefore, I have put your e-mail address back in the recipients list
> and changed the subject line to something more relevant just to make
> sure this infinite Yielding issue gets your immediate attention.  It
> does sound to me like this is a release critical issue, i.e., if it is
> not fixed by our current estimate of the release date (December 27th),
> I should probably hold the release until you do figure out a solution.
>
> 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
> __
> 


--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Subscribing to our git feed

[Pedro Vicente]

Hi Alan, Phil

> Also, it was
> really good to hear that your tests show we finally have the
> definitive fix for this Linux issue

You're welcome, glad I could help.

I was going to send an email questioning the reasoning of both 
solutions assuming both were
working (Phil's  and mine), but I just tried on my CentOS with the 
latest git code, and what happens
is that the execution is always on

12:50:24: Debug: Plot() Yielding

About the solutions

1) Current solution


Right now, this has to be done in the client code

//We must wait for the Create event to be processed and the
//wxPLplotstream to be prepared
while (!frame->IsReady())
{
PLPLOT_wxLogDebug("Plot() Yielding");
wxGetApp().Yield();
}

So, the user has to do some extra step in order to wait for wxWidgets 
to
process some event.
Ideally he should not have to do this but rather all should be done 
inside wxWidgets.
This is error prone, because the usual way to use wxWidgets is

MyFrame *frame = new Frame()
frame->Show()


here we have

MyFrame *frame = new Frame()
frame->Create()
While ()
  {
   wait()
  }
frame->Show()
Plot(


so a user might not even be aware of this wait extra step.

that is assuming it's working, but on my CentOS it gets stuck on the 
Yield()


2) Solution of creating the fame in Show()

Client code is

MyFrame *frame = new Frame()
frame->Create()
frame->Show()
Plot()


there is no wait loop; there is also no need to create the stream in 
OnCreate()

-Pedro





On 2016-12-20 04:01, Alan W. Irwin wrote:
> On 2016-12-19 23:32-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I subscribed to the feed, got the latest master, and all is working 
>> now on wxWidgetsdemo.
>
> Hi Pedro:
>
> That is good that you are subscribed to the git feed.  Also, it was
> really good to hear that your tests show we finally have the
> definitive fix for this Linux issue thanks to your original report of
> the issue, your implementation of an initial solution, your 
> subsequent
> test efforts on various Linux platforms, and your discussions of the
> issue with Phil.  And my thanks to Phil for ultimately finding the
> definitive fix.  That was good collaborative development work on an
> open source project you can both be proud of.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Subscribing to our git feed

[Pedro Vicente]

Hi Alan

I subscribed to the feed, got the latest master, and all is working now on 
wxWidgetsdemo.
on my linux 14.04 it tries to go to Plot() one time, then OnCreate is 
called, then goes to Plot() again


23:26:43: Debug: wxPLplotwindow::wxPLplotwindow
23:26:44: Debug: frame->Create
23:26:44: Debug: Plot() Yielding
23:26:44: Debug: wxPLplotwindow::OnCreate
23:26:44: Debug: plD_init_wxwidgets(): enter
23:26:44: Debug: wxPLDevice(): enter
23:26:44: Debug: wxPLDevice(): gc done
23:26:44: Debug: wxPLDevice(): m_interactiveTextGcdc done
23:26:44: Debug: wxPLDevice(): SetDC done
23:26:44: Debug: wxPLDevice(): leave
23:26:44: Debug: plD_init_wxwidgets(): leave
23:26:44: Debug: Plot()



- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "PLplot development 
list" <plplot-devel@lists.sourceforge.net>
Sent: Monday, December 19, 2016 10:29 PM
Subject: Subscribing to our git feed


> Hi Pedro:
>
> Phil found his own way of solving the two big Linux wxwidgets issues
> this evening with his latest series of commits.  But from your recent
> posts it appears you are not yet aware of those commits.
>
> To take care of that issue, I strongly recommend you subscribe to our git 
> feed.
>
> You do that as follows: visit
> <https://sourceforge.net/p/plplot/plplot/ci/master/tree/> and click on
> the "Feed" icon just to the right of the "Download History" and
> "Snapshot" icons.  That will take you to a page with our most recent
> git commits summarized and with some subscription choices at the top.
> Pick one of those choices, and if it acts like the git feed I am
> subscribed to (which I subscribed to years ago with a different method
> when we first moved to git), from then on you will get e-mail with the
> complete commit message every time a commit is pushed to our SF git
> server.  Which, of course, is highly useful when doing collaborative
> development or testing of PLplot.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
> 


--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] New way to generate wxwidgets debug output

[Pedro Vicente]

you can use the function "getrandom" as explained here


http://stackoverflow.com/questions/2572366/how-to-use-dev-random-or-urandom-in-c

http://man7.org/linux/man-pages/man2/getrandom.2.html

-Pedro

- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Monday, December 19, 2016 8:40 PM
Subject: Re: [Plplot-devel] New way to generate wxwidgets debug output


> you could use "open" to try to open the stream as described here
>
> http://www.cplusplus.com/reference/fstream/fstream/open/
>
> I'll do a small test to see
>
> -Pedro
>
>
> - Original Message - 
> From: "Pedro Vicente" <pedro.vice...@space-research.org>
> To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg"
> <p.d.rosenb...@gmail.com>; "PLplot development list"
> <plplot-devel@lists.sourceforge.net>
> Sent: Monday, December 19, 2016 8:30 PM
> Subject: Re: [Plplot-devel] New way to generate wxwidgets debug output
>
>
>> Hi Alan
>>
>>
>> ok, I see now.
>>
>>> That is check if
>>>
>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>
>>
>> this is the constructor, there is no return value, which is one of the
>> criticisms made to C++.
>>
>> In this case probably you need to do a small I/O operation after that 
>> call
>> and check for the result.
>>
>> Not sure which , because I never use the C++ I/O, I always use the C API,
>> even in C++ programs.
>>
>> the reference is here
>>
>> http://www.cplusplus.com/reference/fstream/fstream/fstream/
>>
>>
>> -Pedro
>>
>>
>>
>> - Original Message - 
>> From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
>> To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg"
>> <p.d.rosenb...@gmail.com>; "PLplot development list"
>> <plplot-devel@lists.sourceforge.net>
>> Sent: Monday, December 19, 2016 7:51 PM
>> Subject: RE: New way to generate wxwidgets debug output
>>
>>
>>> On 2016-12-19 16:33-0500 Pedro Vicente wrote:
>>>
>>>> Hi Alan
>>>>
>>>>
>>>>> The only trouble with the above fix is not every Unix platform has
>>>>> /dev/urandom (although from the above URL most do).
>>>>>
>>>>> So I would like to change the above fix to check for /dev/urandom
>>>>> and use it if it exists, but otherwise fall back to using /dev/random.
>>>>>
>>>>> How do I do that in C++?
>>>>
>>>>
>>>> This is not a C++ (or C) issue.
>>>> This is ideal for cmake to check, the same way it detects for other
>>>> possible system functions/features availability.
>>>> I never did this before, but I think the way it works it is on the 
>>>> cmake
>>>> script
>>>> do a small C or C++ program embedded in the script that includes
>>>> "/dev/urandom" in some way, for example
>>>>
>>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>>>
>>>> and then check if it compiles and pass the result to cmake
>>>>
>>>>> > /dev/urandom (although from the above URL most do).
>>>
>>> Hi Pedro:
>>>
>>> I agree that is a possible approach, but that would mean
>>> I would need to implement a build-system CMake test, propagate the
>>> relevant CMake variable from that test
>>> to the C++ level as a macro, and introduce a preprocessor directive into
>>> our own C++
>>> code based on whether that macro is defined or not.  And I think my
>>> original proposal is simpler than that.
>>>
>>> I never stated clearly what my proposed approach
>>> would be, but it is no coincidence that it is C like.  :-)
>>>
>>> That is check if
>>>
>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>>
>>> works (probably by just checking the return code of that call, but I
>>> could not find the documentation of what the return code would be
>>> on failure),
>>>
>>> and if that return code indicates a failure, then call
>>>
>>> std::fstream 

Re: [Plplot-devel] New way to generate wxwidgets debug output

[Pedro Vicente]

you could use "open" to try to open the stream as described here

http://www.cplusplus.com/reference/fstream/fstream/open/

I'll do a small test to see

-Pedro


- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Monday, December 19, 2016 8:30 PM
Subject: Re: [Plplot-devel] New way to generate wxwidgets debug output


> Hi Alan
>
>
> ok, I see now.
>
>> That is check if
>>
>> std::fstream fin( "/dev/urandom", std::ios::in );
>
>
> this is the constructor, there is no return value, which is one of the
> criticisms made to C++.
>
> In this case probably you need to do a small I/O operation after that call
> and check for the result.
>
> Not sure which , because I never use the C++ I/O, I always use the C API,
> even in C++ programs.
>
> the reference is here
>
> http://www.cplusplus.com/reference/fstream/fstream/fstream/
>
>
> -Pedro
>
>
>
> - Original Message - 
> From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
> To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg"
> <p.d.rosenb...@gmail.com>; "PLplot development list"
> <plplot-devel@lists.sourceforge.net>
> Sent: Monday, December 19, 2016 7:51 PM
> Subject: RE: New way to generate wxwidgets debug output
>
>
>> On 2016-12-19 16:33-0500 Pedro Vicente wrote:
>>
>>> Hi Alan
>>>
>>>
>>>> The only trouble with the above fix is not every Unix platform has
>>>> /dev/urandom (although from the above URL most do).
>>>>
>>>> So I would like to change the above fix to check for /dev/urandom
>>>> and use it if it exists, but otherwise fall back to using /dev/random.
>>>>
>>>> How do I do that in C++?
>>>
>>>
>>> This is not a C++ (or C) issue.
>>> This is ideal for cmake to check, the same way it detects for other
>>> possible system functions/features availability.
>>> I never did this before, but I think the way it works it is on the cmake
>>> script
>>> do a small C or C++ program embedded in the script that includes
>>> "/dev/urandom" in some way, for example
>>>
>>> std::fstream fin( "/dev/urandom", std::ios::in );
>>>
>>> and then check if it compiles and pass the result to cmake
>>>
>>>> > /dev/urandom (although from the above URL most do).
>>
>> Hi Pedro:
>>
>> I agree that is a possible approach, but that would mean
>> I would need to implement a build-system CMake test, propagate the
>> relevant CMake variable from that test
>> to the C++ level as a macro, and introduce a preprocessor directive into
>> our own C++
>> code based on whether that macro is defined or not.  And I think my
>> original proposal is simpler than that.
>>
>> I never stated clearly what my proposed approach
>> would be, but it is no coincidence that it is C like.  :-)
>>
>> That is check if
>>
>> std::fstream fin( "/dev/urandom", std::ios::in );
>>
>> works (probably by just checking the return code of that call, but I
>> could not find the documentation of what the return code would be
>> on failure),
>>
>> and if that return code indicates a failure, then call
>>
>> std::fstream fin( "/dev/random", std::ios::in );
>>
>> instead.  But I assume Phil will do (or has done by now) the
>> equivalent using C++ exception handling.
>>
>> 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
>> __
>>
>
>
> --
> Developer Access Program for Int

Re: [Plplot-devel] New way to generate wxwidgets debug output

[Pedro Vicente]

Hi Alan


ok, I see now.

> That is check if
>
> std::fstream fin( "/dev/urandom", std::ios::in );


this is the constructor, there is no return value, which is one of the 
criticisms made to C++.

In this case probably you need to do a small I/O operation after that call
and check for the result.

Not sure which , because I never use the C++ I/O, I always use the C API, 
even in C++ programs.

the reference is here

http://www.cplusplus.com/reference/fstream/fstream/fstream/


-Pedro



- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Monday, December 19, 2016 7:51 PM
Subject: RE: New way to generate wxwidgets debug output


> On 2016-12-19 16:33-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>>
>>> The only trouble with the above fix is not every Unix platform has
>>> /dev/urandom (although from the above URL most do).
>>>
>>> So I would like to change the above fix to check for /dev/urandom
>>> and use it if it exists, but otherwise fall back to using /dev/random.
>>>
>>> How do I do that in C++?
>>
>>
>> This is not a C++ (or C) issue.
>> This is ideal for cmake to check, the same way it detects for other 
>> possible system functions/features availability.
>> I never did this before, but I think the way it works it is on the cmake 
>> script
>> do a small C or C++ program embedded in the script that includes 
>> "/dev/urandom" in some way, for example
>>
>> std::fstream fin( "/dev/urandom", std::ios::in );
>>
>> and then check if it compiles and pass the result to cmake
>>
>>> > /dev/urandom (although from the above URL most do).
>
> Hi Pedro:
>
> I agree that is a possible approach, but that would mean
> I would need to implement a build-system CMake test, propagate the 
> relevant CMake variable from that test
> to the C++ level as a macro, and introduce a preprocessor directive into 
> our own C++
> code based on whether that macro is defined or not.  And I think my
> original proposal is simpler than that.
>
> I never stated clearly what my proposed approach
> would be, but it is no coincidence that it is C like.  :-)
>
> That is check if
>
> std::fstream fin( "/dev/urandom", std::ios::in );
>
> works (probably by just checking the return code of that call, but I
> could not find the documentation of what the return code would be
> on failure),
>
> and if that return code indicates a failure, then call
>
> std::fstream fin( "/dev/random", std::ios::in );
>
> instead.  But I assume Phil will do (or has done by now) the
> equivalent using C++ exception handling.
>
> 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
> __
> 


--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] New way to generate wxwidgets debug output

[Pedro Vicente]

Hi Alan


> The only trouble with the above fix is not every Unix platform has
> /dev/urandom (although from the above URL most do).
>
> So I would like to change the above fix to check for /dev/urandom
> and use it if it exists, but otherwise fall back to using 
> /dev/random.
>
> How do I do that in C++?


This is not a C++ (or C) issue.
This is ideal for cmake to check, the same way it detects for other 
possible system functions/features availability.
I never did this before, but I think the way it works it is on the 
cmake script
do a small C or C++ program embedded in the script that includes 
"/dev/urandom" in some way, for example

std::fstream fin( "/dev/urandom", std::ios::in );

and then check if it compiles and pass the result to cmake

> > /dev/urandom (although from the above URL most do).

yes, by reading the Wikipedia page,
they don't say of any system that does not have "/dev/urandom"

-Pedro


On 2016-12-19 16:14, Alan W. Irwin wrote:
> On 2016-12-19 19:47- p.d.rosenb...@gmail.com wrote:
>
>> Hi Alan
>
>> I am on my commute home right now. But if you want to test if the 
>> random number generator is the cause then find the Rand constructor – 
>> Rand::Rand() and comment out everything, replacing it with a single 
>> line that sets the seed (probably m_seed or something) to a fixed 
>> value, like 0. That will show whether generating the seed is causing 
>> the slowdown.
>
> Hi Phil:
>
> Thanks to your leap of insight that it was entropy and the random
> number generator that was the source of the issue, I have now found
> the fix!  My tests show all pauses are now gone after the following
> local change, but I need C++ help to finalize this fix.
>
> diff --git a/drivers/wxwidgets_dev.cpp b/drivers/wxwidgets_dev.cpp
> index 1131e9b..e0f215f 100644
> --- a/drivers/wxwidgets_dev.cpp
> +++ b/drivers/wxwidgets_dev.cpp
> @@ -603,7 +603,7 @@ public:
>  #ifdef WIN32
>  rand_s( _seed );
>  #else
> -std::fstream fin( "/dev/random", std::ios::in );
> +std::fstream fin( "/dev/urandom", std::ios::in );
>  fin.read( (char *) ( _seed ), sizeof ( m_seed ) );
>  fin.close();
>  #endif
>
> The difference between /dev/random and /dev/urandom on Linux is the
> former is blocking (and therefore only recommended if you need 
> highest
> security and are willing to wait for it) while the latter is not
> blocking and gives adequate pseudo-randomness for most purposes (such
> as ours). See <https://en.wikipedia.org/wiki//dev/random> for further
> details.
>
> The only trouble with the above fix is not every Unix platform has
> /dev/urandom (although from the above URL most do).
>
> So I would like to change the above fix to check for /dev/urandom
> and use it if it exists, but otherwise fall back to using 
> /dev/random.
>
> How do I do that in C++?
>
> Or, better yet show me by going ahead and making the commit to that
> effect.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] New way to generate wxwidgets debug output

[Pedro Vicente]

Hi Alan

>Was that as a result of running (exactly)

no, my previous output was just
make VERBOSE=1 test_wxPLplotDemo


this is the second output of

time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time 
examples/c/x01c -dev wxwidgets -np;echo "done x01c"


PLplot library version: 5.11.1
15:48:59: Debug: nanosecs since epoch = 21790238265641600: 
plD_init_wxwidgets(): enter
15:48:59: Debug: nanosecs since epoch = 21790238410215451: 
wxPLDevice(): enter
15:48:59: Debug: nanosecs since epoch = 21790238410393014: 
wxPLDevice(): gc done
15:48:59: Debug: nanosecs since epoch = 21790238418937794: 
wxPLDevice(): m_interactiveTextGcdc done
15:48:59: Debug: nanosecs since epoch = 21790238418999419: 
SetupMemoryMap(): enter
15:49:00: Debug: nanosecs since epoch = 21790239004602872: 
SetupMemoryMap(): mapName start
15:49:00: Debug: nanosecs since epoch = 21790239004716998: 
SetupMemoryMap(): mapName done
15:49:00: Debug: nanosecs since epoch = 21790239004770393: 
SetupMemoryMap(): m_outputMemoryMap.create call
15:49:00: Debug: nanosecs since epoch = 21790239005095987: 
SetupMemoryMap(): m_outputMemoryMap.create done
15:49:00: Debug: nanosecs since epoch = 21790239213638522: 
wxPLplotwindow::wxPLplotwindow
15:49:00: Debug: nanosecs since epoch = 21790239218784927: 
wxPLplotwindow::Show
15:49:00: Debug: nanosecs since epoch = 21790239218891790: 
wxPLplotwindow::CreateStream
15:49:00: Debug: nanosecs since epoch = 21790239220942648: 
SetupMemoryMap(): leave
15:49:00: Debug: nanosecs since epoch = 21790239221080760: 
wxPLDevice(): leave
15:49:00: Debug: nanosecs since epoch = 21790239221125073: 
plD_init_wxwidgets(): leave
15:49:00: Debug: nanosecs since epoch = 21790239248789077: 
plD_init_wxwidgets(): enter
15:49:00: Debug: nanosecs since epoch = 21790239248922765: 
wxPLDevice(): enter
15:49:00: Debug: nanosecs since epoch = 21790239249008840: 
wxPLDevice(): gc done
15:49:00: Debug: nanosecs since epoch = 21790239249148977: 
wxPLDevice(): m_interactiveTextGcdc done
15:49:00: Debug: nanosecs since epoch = 21790239249213837: 
wxPLDevice(): SetDC done
15:49:00: Debug: nanosecs since epoch = 21790239249246653: 
wxPLDevice(): leave
15:49:00: Debug: nanosecs since epoch = 21790239249273784: 
plD_init_wxwidgets(): leave
15:49:00: Debug: nanosecs since epoch = 21790239268439414: 
wxPLplotwindow::OnCreate
15:49:00: Debug: nanosecs since epoch = 21790239268543408: 
wxPLplotwindow::CreateStream
15:49:00: Debug: nanosecs since epoch = 21790239268995179: 
wxPLplotwindow::OnCreate
15:49:00: Debug: nanosecs since epoch = 21790239269051483: 
wxPLplotwindow::CreateStream

real0m1.037s
user0m0.047s
sys 0m0.032s
done x01c



On 2016-12-19 15:25, Alan W. Irwin wrote:
> On 2016-12-19 12:33-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> I just did a git pull of the master branch with these changes and I 
>> get compiling errors
>> if I don't add
>>
>> -DPLPLOT_WX_NANOSEC=ON
>
> To Pedro and Phil:
>
> @Pedro:
>
> Thanks for your above report.  I confirmed the issue and fixed it as
> of commit 946b17f.
>
> I noticed for the case with -DPLPLOT_WX_NANOSEC=ON which did
> build for you, you were not able to confirm the pause.  Was that
> as a result of running (exactly)
>
> time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time
> examples/c/x01c -dev wxwidgets -np;echo "done x01c"
>
> and showing the output for the _second_ run of the x01c example?
>
> @Pedro and Phil:
>
> The reason I am still keenly interested in your results and Phil's 
> for
> such tests, is I am having trouble here confirming Phil's hypothesis
> (lack of entropy) for the pause.  Lots of mousing around to build up
> entropy before or during the pause seemed to make absolutely no
> difference.  The pause is never the same from one run to the next but
> it is usually in the 5 to 15 second range.  But when I moused around
> for a couple of tries of the test, the results were always near the
> top-end of that range!
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Developer

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

[Pedro Vicente]

Hi Phil

It seems you got it working

I applied the patch, to 2 previous master commits that compile.
results are:


make VERBOSE=1 test_wxPLplotDemo
14:26:35: Debug: wxPLplotwindow::wxPLplotwindow
14:26:35: Debug: frame->Create
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: Plot() Yielding
14:26:35: Debug: wxPLplotwindow::OnCreate
14:26:35: Debug: Plot()

So, we can just commit and push this patch

-Pedro


On 2016-12-19 13:59, Phil Rosenberg wrote:
> On 19 December 2016 at 17:47, Pedro Vicente
> <pedro.vice...@space-research.org> wrote:
>> Hi Phil
>>
>>> Pedro can you please check if this works on your systems?
>>
>>
>> ok, I'll try it when the patch is pushed to the master .
>>
>> Alan
>>
>> I assume you are going to push the patch?
>> I get some compiling errors on the current master, please see my 
>> last post
>
> It would be good for you to test the patch before it gets pushed to
> master so we don't contaminate master with useless changes that just
> get undone next commit. To do so create a new branch from master, 
> then
> apply the patch
> git checkout master
> git checkout -b myTestBranch
> git apply path/to/patch.patch
>
>
> If master is currently not working then try checking out a previous
> commit as follows
> git checkout master
> git log
> #select a working commit hash one or two back
> git checkout 
> git checkout -b myTestBranch
> git apply path/to/patch.patch
>
>>
>> a new idea:
>>
>> what about if we just override the Create() function of 
>> wxPLplotwindow ?
>
> Unfortunately we can't override the create function because we need 
> to
> call the base class create function. We can't call the base class
> create function inside our own create function because the parameters
> that need to be passed in will differ depending upon whether you use 
> a
> wxFrame, wxPanel or any other wxWindow as the template class that we
> inherit from. In fact this is why we are using the create event in 
> the
> first place, otherwise we would just sort everything in the
> constructor.
>
> I'm pretty confident that the patch I sent will fix things if the
> issue is just that the create event is delayed. If you are having
> trouble getting it to apply, then I'll commit it to master. But I
> guess we need to wait for Alan to fix the logging issues first.
>
> I'm about to leave work and head home. If he hasn't fixed them by the
> time I open my laptop this evening then I'll have a look at fixing 
> the
> issue myself.
>
> Phil

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

Hi Phil

> Pedro can you please check if this works on your systems?

ok, I'll try it when the patch is pushed to the master .

Alan

I assume you are going to push the patch?
I get some compiling errors on the current master, please see my last 
post

a new idea:

what about if we just override the Create() function of wxPLplotwindow 
?

eliminate the Show() override, and the trigger of the OnCreate 
function,
but just simply override the Create() function.

the client call would be

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

and the stream would be created *inside*
frame->Create

not posted to a queue event


> PS - Pedro I just realised from your email address we are in the same
> line of work. I work at the Institute for Climate and Atmospheric
> Science at University of Leeds. Small world!

yes, good to know !

-Pedro


On 2016-12-19 09:03, Phil Rosenberg wrote:
> No worries :-)
>
> Attached is a patch which I hope should fix things. It is the 
> simplest
> possible fix as far as I can tell. It does have a while loop with no
> counter, but unless there is some rather fatal bug in wxWidgets it
> should never turn into an infinite loop. Alan if you prefer I will 
> add
> a counter to ensure things can't go crazy. I have also added some
> extra checks to wxPLplotwindow just in case the create event ends up
> arriving after the first paint event or something - I don't know if
> this can happen but the docs aren't clear so it does no harm to
> include the checks.
>
> I always have to check how to create patches with git. I followed the
> instructions at
> 
> https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/.
> The appropriate apply commands are listed there too.
>
> Pedro can you please check if this works on your systems?
>
> Phil
>
> PS - Pedro I just realised from your email address we are in the same
> line of work. I work at the Institute for Climate and Atmospheric
> Science at University of Leeds. Small world!
>
> On 19 December 2016 at 12:51, Alan W. Irwin
> <ir...@beluga.phys.uvic.ca> wrote:
>> On 2016-12-19 11:31- Phil Rosenberg wrote:
>>
>>> I'm  just generating a test fix. I will send a patch round once 
>>> it's
>>> done. If it works then I'll tidy it up. However you appear to have
>>> bumped up the minimum CMake version so I need to reinstall CMake -
>>> turns out the latest Windows version requires a manual uninstall
>>> first. I'm sure you're not deliberately making my life hard Alan 
>>> ;-)
>>> :-D :-D
>>
>>
>> Sorry about that.  I far prefer to make your life easy.  :-)
>>
>>
>> Alan
>>
>> __
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and 
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __
>>
>> Linux-powered Science
>> __

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
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/intel
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] New way to generate wxwidgets debug output

[Pedro Vicente]

Hi Alan

I just did a git pull of the master branch with these changes and I get 
compiling errors
if I don't add

-DPLPLOT_WX_NANOSEC=ON


I did

cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF 
-DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF 
-DBUILD_TEST:BOOL=ON
make VERBOSE=1 test_wxPLplotDemo

and result is


In file included from 
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets.h:28,
  from 
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp:41:
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets_comms.h:35:30: 
error: wxPLplot_nanosec.h: No such file or directory
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp: In function 
‘void plD_init_wxwidgets(PLStream*)’:
/data/home002/pvicente/plplot-plplot/drivers/wxwidgets.cpp:148: error: 
‘PLPLOT_wxLogDebug’ was not declared in this scope


and the same with

-DPLPLOT_WX_DEBUG_OUTPUT=ON

if I add

-DPLPLOT_WX_NANOSEC=ON

the build succeds and the output is


12:29:29: Debug: nanosecs since epoch = 21778268382005471: 
wxPLplotwindow::wxPLplotwindow
12:29:29: Debug: nanosecs since epoch = 21778268383178783: 
frame->Create
12:29:29: Debug: nanosecs since epoch = 21778268393882737: 
wxPLplotwindow::Show
12:29:29: Debug: nanosecs since epoch = 21778268393941866: 
wxPLplotwindow::CreateStream
12:29:29: Debug: nanosecs since epoch = 21778268401739575: 
plD_init_wxwidgets(): enter
12:29:29: Debug: nanosecs since epoch = 21778268401812999: 
wxPLDevice(): enter
12:29:29: Debug: nanosecs since epoch = 21778268401896369: 
wxPLDevice(): gc done
12:29:29: Debug: nanosecs since epoch = 21778268402036165: 
wxPLDevice(): m_interactiveTextGcdc done
12:29:29: Debug: nanosecs since epoch = 21778268402095492: 
wxPLDevice(): SetDC done
12:29:29: Debug: nanosecs since epoch = 21778268402127174: 
wxPLDevice(): leave
12:29:29: Debug: nanosecs since epoch = 21778268402165801: 
plD_init_wxwidgets(): leave
12:29:29: Debug: nanosecs since epoch = 21778268406212150: Plot()
12:29:29: Debug: nanosecs since epoch = 21778268498272214: 
wxPLplotwindow::OnCreate
12:29:29: Debug: nanosecs since epoch = 21778268498387763: 
wxPLplotwindow::CreateStream





On 2016-12-19 01:22, Alan W. Irwin wrote:
> I have recently (commit 3c4e6be) implemented a new way for users to
> optionally obtain wxwidgets debug output.
>
> The principal change is you must use the CMake option
> -DPLPLOT_WX_DEBUG_OUTPUT=ON to get any debug output at all.  There is
> also now an experimental option -DPLPLOT_WX_NANOSEC=ON which you 
> might
> want to try if your like high-resolution time stamps (but it might
> cause build errors on some Linux systems and virtually all other
> systems, so you must experiment with it to see whether it will work 
> on
> any given system). If you want to insert more debugging output into
> our wxwidgets-related code under the control of the above two CMake
> options, please use the correct macro which is
>
> PLPLOT_wxLogDebug("some string");
>
> That boils down to
>
> wxLogDebug("some string");
>
> if -DPLPLOT_WX_DEBUG_OUTPUT=ON and PLPLOT_WX_NANOSEC is either not
> specified or set to its default value using -DPLPLOT_WX_NANOSEC=OFF.
> The above macro use further boils down to
>
> ;
>
> if PLPLOT_WX_DEBUG_OUTPUT is either not specified or set to its
> default value using -DPLPLOT_WX_DEBUG_OUTPUT=OFF.
>
> For more details (especially what the nanosec time stamp looks like 
> on
> systems that support it), see the above commit message.
>
> Note, that I plan after the release to implement a CMake test so it
> can figure out PLPLOT_WX_NANOSEC automatically, i.e., only set that 
> to
> ON when relevant test code can be built.  However, for now I have
> taken an extremely simplistic approach "try it and see using the
> experimental option -DPLPLOT_WX_NANOSEC=ON" for generating the
> nanonsec time step.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer

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

[Pedro Vicente]

Hi Phil

>This is because there is no
> requirement to call Show() immediately after window creation.

that's true.
but if a user wants to see the plot, he *has* to create Show() at some time, 
because Show()
displays the window on screen.

when he does, then that is the time to create the stream.
if it does not call  Show() , then there is no window and no stream 
(assuming we remove the OnCreate() creation)


> while(!m_created)
>   wxYield();

where is the place to put this code?
in the demo client or in wxplplotwindow?

-Pedro

- Original Message - 
From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Sunday, December 18, 2016 6:27 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


> Hi Pedro
> Ah, I had assumed that the OnCreate event was not being triggered at
> all. I now understand what is happening. Or at least I think I do ;-)
> Actually now you have pointed out the issue I am surprised the code
> works on any platform.
>
> The error is in the wxplplotdemo code, not in the wxplplotwindow. In
> the demo we must simply wait for the OnCreate message to arrive and be
> processed before we grab the stream in Plot(). We may be able to do
> that with
> while(!m_created)
>   wxYield();
>
> Could you try the above instead of your overloaded Show() fix please?
> You can check out an older version of Plplot by using
> git checkout 3a6a49a572e7aa518a5b8a6bbecd9ef1f812
> which will have your debug code in, but not your Show() fix.
>
> Unfortunately, although your fix does work for the example as it is
> written, it will not work in general. This is because there is no
> requirement to call Show() immediately after window creation.
>
> I am sorry that I have not been able to go through this in huge detail
> with you as fast as I would have liked. I have rather a lot on at work
> and I'm sure you understand I have to give that priority.
>
> Phil
>
>
> On 16 December 2016 at 18:01, Pedro Vicente
> <pedro.vice...@space-research.org> wrote:
>> Hi Phil, Alan
>>
>> I tried evtCreateExample.cpp and I get the good expected result.
>> This just means that for this simple example the OnCreate event is
>> triggered.
>>
>> To note that on my bad results of the PLplot demo, the OnCreate event is
>> *also* triggered.
>> the problem is that is triggered after the plot was made
>>
>>
>> 11:09:13: Debug: wxPLplotwindow::wxPLplotwindow
>> 11:09:13: Debug: frame->Create
>> 11:09:13: Debug: pls NULL
>> 11:09:13: Debug: wxPLplotwindow::OnCreate
>>
>> I am not that familiar with the wxWidgets internals but it seems events 
>> are
>> put in a queue.
>>
>> http://docs.wxwidgets.org/3.1/overview_events.html
>>
>> it could be that the event is not processed in the expected order or 
>> delayed
>> for some reason.
>> this could be a good question for the wxWidgets support list.
>>
>> -Pedro
>>
>>
>>
>> On 2016-12-15 21:11, Alan W. Irwin wrote:
>>>
>>> On 2016-12-16 01:05- Phil Rosenberg wrote:
>>>
>>>> Hmm - well another theory down in smoke.
>>>>
>>>> Attached is an absolute minimum example of the use of wxEVT_CREATE. On
>>>> Windows I get the expected behaviour of a popup dialog appearing
>>>> before the frame saying "OnCreate called."
>>>>
>>>> Could you try it on one of your Linux machines? I'm afraid it's way
>>>> past my bedtime here in the UK, so I'll have to continue tomorrow.
>>>
>>>
>>> @Pedro: You should do this test as well since your Linux platforms
>>> are the ones where
>>> (so far at least) issues are showing up.  But for what it is worth, I
>>> did the following
>>>
>>> irwin@raven> g++ $(wx-config --cppflags --libs) evtCreateExample.cpp
>>>
>>> to successfully (no errors/warnings) build Phil's test application.
>>>
>>> Then I ran it with
>>>
>>> irwin@raven> ./a.out
>>>
>>> and a popup window came up (apparently as a subGUI of a grey GUI blank
>>> called "My Frame") with the "OnCreate Called" message displayed (which
>>> I understand was the expected result when everything is working
>>> properly).
>>>
>>> I hope that experiment helps you guys to gain some insigh

Re: [Plplot-devel] The pls NULL fix for some Linux platforms

[Pedro Vicente]

Hi Alan


>> In fact I just did a google search for the terms > event> and there did seem to be a lot of help given on that topic

I am still looking at this.


> What bothers me about these results is there seems to be two
> CreateStream calls in both cases where I suspect (although I don't
> know since I am not that familiar with wxwidgets) one is essentially
> ignored.

> 22:45:01: Debug: wxPLplotwindow::wxPLplotwindow
> 22:45:01: Debug: frame->Create
> 22:45:01: Debug: wxPLplotwindow::Show
> 22:45:01: Debug: wxPLplotwindow::CreateStream
> 22:45:01: Debug: wxPLplotwindow::OnCreate
> 22:45:01: Debug: wxPLplotwindow::CreateStream
> 22:45:01: Debug: Plot()


The two CreateStream calls are made but the second is ignored .
The 2 calls are made because both
Show()
OnCreate()

call
CreateStream()

But the boolean flag "m_created" below makes that the actual creation of the 
stream
is only made once

void wxPLplotwindow::CreateStream( void )
{
wxLogDebug("wxPLplotwindow::CreateStream");
if ( !m_created )
   {
...
m_created = true;
  }

 also the print statement is made right at the start,
so it's always printed.


>So is Pedro's current fix simply one method of inserting a
> small timing wait before you get to Plot()?

No, my changes are just to make
Show()
create the stream, there are no events and timing in any way modified.


This is the client code sequence in wxPLplotDemo.cpp

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

Since the Show(); function is *always* called in a deterministic way,
creating the stream there makes sure that it is always called at that time.

making the stream to be *eventually* created later in
frame->Create
puts a lag in the actual creation time and sequence , because it goes
to an event queue


One way to solve this matter completely is just to make the stream
creation in
frame->Show();
and not in
frame->Create

I just left it now also in
frame->Create

so that we have an understanding of what is actually happening.


> Do you know how to trivially override FormatTime to give us at least
> millisecond resolution here?  If that is not a trivial change, another
> alternative I am thinking of is (strictly for the Linux case) is to
> call clock_gettime which will help give us a nanosecond time stamp.


ok, I'll try to change the time format.

to summarize, there are 3 options

1) Make the stream creation call happen *only* in
frame->Show();
delete the function
wxPLplotwindow::OnCreate

this makes the stream creation to always happen in Show(); only

2) Leave the code like it is
like it is the stream creation is always created in Show(); actually,
as you can see from both (yours, mine)  print sequences

so the
wxPLplotwindow::OnCreate
does not actually have any effect now, but it's there for debugging reasons


the differences in sequences in your linux and mine is that in your case
both Show() and OnCreate() are called *before* Plot()
the OnCreate() call has no effect, it is ignored

22:45:01: Debug: wxPLplotwindow::Show
22:45:01: Debug: wxPLplotwindow::OnCreate
22:45:01: Debug: Plot()

in my case

22:45:01: Debug: wxPLplotwindow::Show
22:45:01: Debug: Plot()
22:45:01: Debug: wxPLplotwindow::OnCreate

Plot() is called before OnCreate()
and this was what was causing the bug (no stream created when Plot() is 
called)



3) Leave the code like it is but add further debugging features like
the millisecond resolution


let me know which option you prefer

-Pedro



- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Sunday, December 18, 2016 3:12 AM
Subject: Re: [Plplot-devel] The pls NULL fix for some Linux platforms


> On 2016-12-17 00:38-0800 Alan W. Irwin wrote:
>
> [...]
>> So if that is a good summary of the problem (the timing for when the
>> OnCreate event fires is not deterministic which your debug output
>> seems to have proved again and again) doesn't wxwidgets have a decent
>> way to wait for that event to fire in the Plot routine before
>> proceeding with defining pls? That would be the definitive fix for
>> this nondeterministic event timing issue (assuming that is the issue).
>>
>> In fact I just did a google search for the terms > event> and there did seem to be a lot of help given on that topic
>> right in the first reference found
>> <https://forums.wxwidgets.org/viewtopic.php?t=22893>. Could you adapt
>> one of those ideas?  Or if that reference is too old (2009) so not
>> wxwidgets-3.x relevant, perhaps one of the other hits you get with the
>> above search terms might

Re: [Plplot-devel] Cmake generation with wxWidgets on Windows

[Pedro Vicente]

Hi Alan

>My point is CMake find commands only look for a certain tiny subset of a 
>given
>installation, and if you haven't clobbered anything in that subset it won't 
>detect
>anything wrong.  But of course when you try and build and run with
>Visual Studio, the missing .lib files were detected.

yes that was what happened.
In the end the missing files are detected, but I was under the impression 
that the cmake
step would detect the missing files when I assumed they were there, 
therefore my original report
(where I was thinking the files existed, it was only after sending the first 
report that I noticed they did not exist).

all good then

-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Sunday, December 18, 2016 2:28 AM
Subject: Re: [Plplot-devel] Cmake generation with wxWidgets on Windows


> On 2016-12-17 19:25-0500 Pedro Vicente wrote:
>
>>
>> Hi Alan
>>
>>> (3) Static PLplot libraries + device driver code embedded in our core
>>> static library (identified by its "plplot" basename).
>>
>> I always use (3).
>>
>> I repeated what I had done before:
>>
>> My wxwidgets libraries are located at
>>
>> M:\wx\wxwidgets-3.1.0\lib\vc_lib
>>
>> here there are several .lib files like this one
>>
>> wxmsw31ud_core.lib
>>
>> 1) I deleted all .lib files from that location
>> 2) did a PLplot cmake run with
>>
>> cmake ".." -G "Visual Studio 
>> 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON 
>> -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
>>  -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF 
>> -DSTATIC_RUNTIME:BOOL=ON 
>>  -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% 
>> -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib 
>>  -DwxWidgets_CONFIGURATION=mswud 
>> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>>> cmake.out.txt 2>&1
>>
>> where
>> %WXWIN%
>> is
>> M:\wx\wxwidgets-3.1.0
>>
>> cmake.out.txt  is attached and it detected wxwidgets
>>
>> 2) Built the Visual Studio generated solution and got the wxwidgets 
>> linking errors
>>
>> 4) rebuilt wxwidgets libraries at M:\wx\wxwidgets-3.1.0\lib\vc_lib
>>
>> 5) did the same  PLplot cmake run
>>
>> 6) Built the Visual Studio generated solution , no errors
>
> Hi Pedro:
>
> Am I understanding your test properly?  You clobbered your wxwidgets
> installation (by removing the .lib files), our build system did not
> detect those removed .lib files, but Visual Studio did in step 2.  You
> fixed that wxwidgets installation issue, ran cmake again, and this
> time Visual Studio worked.  Isn't this exactly how you would like
> our build system to work in conjunction with Visual Studio?
>
> My point is CMake find commands only look for a certain tiny subset of a 
> given
> installation, and if you haven't clobbered anything in that subset it 
> won't detect
> anything wrong.  But of course when you try and build and run with
> Visual Studio, the missing .lib files were detected.
>
> Anyhow, I don't see anything wrong here.  Am I missing something?
>
>>
>> I took a look at the PLplot
>> FindwxWidgets.cmake
>> module and it seems that there is an attempt to find the wxwidgets 
>> libraries (the actual file names), here
>>
>> find_library(WX_${LIB}${_DBG}
>>   NAMES
>>   wxbase31${_UCD}${_DBG}_${LIB}
>>
>>
>> so, not sure exactly what happened, and probably we could leave this 
>> possible non-critical bug for after the release (if it's a bug).
>
> As far as I can tell from the above argument it is not a bug.  But if it
> turns out to be a bug, I will likely wait to fix it until post-release
> because it doesn't seem to be release critical (if a bug at all).
>
>>
>> I started using cmake in my projects some months ago, and what I do to 
>> detect libraries is like this,
>> an example for the JSON jansson library:
>>
>>
>> find_library(JANSSON_LIBRARY NAMES jansson HINTS 
>> "/data/data127/pvicente/install/jansson-2.9/lib/")
>> if(NOT JANSSON_LIBRARY)
>> message(FATAL_ERROR "jansson library not found")
>> else()
>> message("-- Found jansson library at: " ${JANSSON_LIBRARY})
>> endif()
>
> Good.
>
> []
>> Here's my Windows call (the path like /C/ is because this is in Git Bash)
>>
>> cmak

Re: [Plplot-devel] Cmake generation with wxWidgets on Windows

[Pedro Vicente]

attached

cmake.out.txt = first cmake run without existing .libs

cmake.out.2.txt = second cmake run with existing .libs

- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>

To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 17, 2016 7:25 PM
Subject: Re: [Plplot-devel] Cmake generation with wxWidgets on Windows




Hi Alan


(3) Static PLplot libraries + device driver code embedded in our core
static library (identified by its "plplot" basename).


I always use (3).

I repeated what I had done before:

My wxwidgets libraries are located at

M:\wx\wxwidgets-3.1.0\lib\vc_lib

here there are several .lib files like this one

wxmsw31ud_core.lib

1) I deleted all .lib files from that location
2) did a PLplot cmake run with

cmake ".." -G "Visual Studio
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON 
-DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
-DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF 
-DSTATIC_RUNTIME:BOOL=ON
-DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% 
-DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
-DwxWidgets_CONFIGURATION=mswud -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
> cmake.out.txt 2>&1

where
%WXWIN%
is
M:\wx\wxwidgets-3.1.0

cmake.out.txt  is attached and it detected wxwidgets

2) Built the Visual Studio generated solution and got the wxwidgets 
linking

errors

4) rebuilt wxwidgets libraries at M:\wx\wxwidgets-3.1.0\lib\vc_lib

5) did the same  PLplot cmake run

6) Built the Visual Studio generated solution , no errors


I took a look at the PLplot
FindwxWidgets.cmake
module and it seems that there is an attempt to find the wxwidgets 
libraries

(the actual file names), here

find_library(WX_${LIB}${_DBG}
   NAMES
   wxbase31${_UCD}${_DBG}_${LIB}


so, not sure exactly what happened, and probably we could leave this
possible non-critical bug for after the release (if it's a bug).

I started using cmake in my projects some months ago, and what I do to
detect libraries is like this,
an example for the JSON jansson library:


find_library(JANSSON_LIBRARY NAMES jansson HINTS
"/data/data127/pvicente/install/jansson-2.9/lib/")
if(NOT JANSSON_LIBRARY)
 message(FATAL_ERROR "jansson library not found")
else()
 message("-- Found jansson library at: " ${JANSSON_LIBRARY})
endif()

on a typical Unix system where jansson is installed on a standard place I
get this by doing just

cmake ..

-- Found jansson.h header file at: /usr/include
-- Found jansson library at: /usr/lib/i386-linux-gnu/libjansson.so

On a Unix system where I don't have jansson on a standard place , I do the
HINTS option , like

find_library(JANSSON_LIBRARY NAMES jansson HINTS
"/data/data127/pvicente/install/jansson-2.9/lib/")

and I can do also

cmake ..


On a Windows system (or  a Unix system) I provide the option

cmake .. -DJANSSON_LIBRARY=/my/path/to/jansson

Here's my Windows call (the path like /C/ is because this is in Git Bash)

cmake
.. -DSTATIC_CRT:BOOL=ON -DJANSSON_INCLUDE:PATH=/C/include 
-DJANSSON_LIBRARY=/C/lib/jansson.lib


my library file is actually called (extra _d)
/C/lib/jansson_d.lib

and cmake said

-- Found jansson.h header file at: C:/include
-- Found jansson library at: C:/lib/jansson.lib

then when I build Visual Studio I get

LINK : fatal error LNK1104: cannot open file 'C:\lib\jansson.lib'

my understanding is that
find_library

does not actually detect if the argument is an existent file

Or could be that it does not because I am using the same variable name
JANSSON_LIBRARY
for both the argument of
cmake .. -DJANSSON_LIBRARY
and
find_library(JANSSON_LIBRARY

so , this print
-- Found jansson library at: C:/lib/jansson.lib

is not actually true for this example.

Probably it would be possible to actually detect if the file does indeed
exist, but I did it like this to keep things simple

So, the solution I have for
find_library

assumes that the supplied argument
-DJANSSON_LIBRARY
is a valid file

-Pedro



- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 17, 2016 4:26 AM
Subject: Re: [Plplot-devel] Cmake generation with wxWidgets on Windows



On 2016-12-17 03:30-0500 Pedro Vicente wrote:


false alarm, sorry

what happened is that my wxWidgets libraries were not built.

In Windows , I don't do install, but rather build software and leave it
where it was built, and sometimes delete and rebuild.

In PLplot 5.11.1 the build actually did not include the wxWidgets
projects and files, so it built.
but in the git version it did include the wxWidgets projects and files,
so it failed.

there'

Re: [Plplot-devel] Cmake generation with wxWidgets on Windows

[Pedro Vicente]

Hi Alan

> (3) Static PLplot libraries + device driver code embedded in our core
> static library (identified by its "plplot" basename).

I always use (3).

I repeated what I had done before:

My wxwidgets libraries are located at

M:\wx\wxwidgets-3.1.0\lib\vc_lib

here there are several .lib files like this one

wxmsw31ud_core.lib

1) I deleted all .lib files from that location
2) did a PLplot cmake run with

cmake ".." -G "Visual Studio 
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON 
-DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
 -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF 
-DSTATIC_RUNTIME:BOOL=ON 
 -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% 
-DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib 
 -DwxWidgets_CONFIGURATION=mswud -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF 
 > cmake.out.txt 2>&1

where
%WXWIN%
is
M:\wx\wxwidgets-3.1.0

 cmake.out.txt  is attached and it detected wxwidgets

2) Built the Visual Studio generated solution and got the wxwidgets linking 
errors

4) rebuilt wxwidgets libraries at M:\wx\wxwidgets-3.1.0\lib\vc_lib

5) did the same  PLplot cmake run

6) Built the Visual Studio generated solution , no errors


I took a look at the PLplot
FindwxWidgets.cmake
module and it seems that there is an attempt to find the wxwidgets libraries 
(the actual file names), here

find_library(WX_${LIB}${_DBG}
NAMES
wxbase31${_UCD}${_DBG}_${LIB}


so, not sure exactly what happened, and probably we could leave this 
possible non-critical bug for after the release (if it's a bug).

I started using cmake in my projects some months ago, and what I do to 
detect libraries is like this,
an example for the JSON jansson library:


find_library(JANSSON_LIBRARY NAMES jansson HINTS 
"/data/data127/pvicente/install/jansson-2.9/lib/")
if(NOT JANSSON_LIBRARY)
  message(FATAL_ERROR "jansson library not found")
else()
  message("-- Found jansson library at: " ${JANSSON_LIBRARY})
endif()

on a typical Unix system where jansson is installed on a standard place I 
get this by doing just

cmake ..

-- Found jansson.h header file at: /usr/include
-- Found jansson library at: /usr/lib/i386-linux-gnu/libjansson.so

On a Unix system where I don't have jansson on a standard place , I do the 
HINTS option , like

find_library(JANSSON_LIBRARY NAMES jansson HINTS 
"/data/data127/pvicente/install/jansson-2.9/lib/")

and I can do also

cmake ..


On a Windows system (or  a Unix system) I provide the option

cmake .. -DJANSSON_LIBRARY=/my/path/to/jansson

Here's my Windows call (the path like /C/ is because this is in Git Bash)

cmake 
.. -DSTATIC_CRT:BOOL=ON -DJANSSON_INCLUDE:PATH=/C/include 
-DJANSSON_LIBRARY=/C/lib/jansson.lib


my library file is actually called (extra _d)
/C/lib/jansson_d.lib

and cmake said

-- Found jansson.h header file at: C:/include
-- Found jansson library at: C:/lib/jansson.lib

then when I build Visual Studio I get

LINK : fatal error LNK1104: cannot open file 'C:\lib\jansson.lib'

my understanding is that
find_library

does not actually detect if the argument is an existent file

Or could be that it does not because I am using the same variable name 
JANSSON_LIBRARY
for both the argument of
cmake .. -DJANSSON_LIBRARY
and
find_library(JANSSON_LIBRARY

so , this print
-- Found jansson library at: C:/lib/jansson.lib

is not actually true for this example.

Probably it would be possible to actually detect if the file does indeed 
exist, but I did it like this to keep things simple

So, the solution I have for
find_library

assumes that the supplied argument
-DJANSSON_LIBRARY
is a valid file

-Pedro



- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 17, 2016 4:26 AM
Subject: Re: [Plplot-devel] Cmake generation with wxWidgets on Windows


> On 2016-12-17 03:30-0500 Pedro Vicente wrote:
>
>> false alarm, sorry
>>
>> what happened is that my wxWidgets libraries were not built.
>>
>> In Windows , I don't do install, but rather build software and leave it 
>> where it was built, and sometimes delete and rebuild.
>>
>> In PLplot 5.11.1 the build actually did not include the wxWidgets 
>> projects and files, so it built.
>> but in the git version it did include the wxWidgets projects and files, 
>> so it failed.
>>
>> there's the small detail that cmake should have had allerted that 
>> wxWidgets was not built...but probably not important , or could just have 
>> been my mistake somewhere.
>>
>> so the result is for cmake build with wxWidgets
>>
>> Rebuild All: 88 succeeded, 0 failed, 0 skipped =
>
> To give some quic

Re: [Plplot-devel] The pls NULL fix for some Linux platforms

[Pedro Vicente]

Hi Alan
Patch is attached, it's a good idea to have the "git format-patch" format.
-Pedro



- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 17, 2016 4:40 AM
Subject: Re: [Plplot-devel] The pls NULL fix for some Linux platforms



On 2016-12-17 03:43-0500 Pedro Vicente wrote:


There's a small change that must be done in my 2nd patch

here

bool wxPLplotwindow::Show(bool show)
{
wxLogDebug("wxPLplotwindow::Show");
CreateStream();
WXWINDOW::Show(show);

}


it should be instead

return WXWINDOW::Show(show);

gcc let me get away with it, but it's an error in Visual Studio


Please go ahead and make a commit to that effect, and send it to me
for pushing.  Please include a tested by: paragraph identifying the
system where you did the test similar to how I have been massaging
your recent commit messages when I describe the tests that you did for
them.  I will amend the commit message in any case to add my own
tested by: paragraph for my own test of your commit here.

I hope you don't find that commit + "git format-patch" process too
difficult. I used that method a lot when colloborating on maturing a
major private topic branch (our new Fortran binding) with Arjen, and that
process became very easy and straightforward for us very soon in that
quite extensive collaboration process although neither of us had used
"git format-patch" (or "git am") extensively before our collaboration.

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
__



0001-wxwidgets-binding-workaround-fix-for-delayed-OnCreat.patch.tar.gz
Description: GNU Zip compressed data
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The pls NULL fix for some Linux platforms

[Pedro Vicente]

Hi Alan

It's kind of late here on the East Coast, so I'll try to elaborate more on 
the second issue related to the bug later.

> I assumed when massaging your
> second commit message, that your test debug sequence was on the same
> OS as you used in the commit message associated with your first
> commit.

yes, I did all coding/testing/commit on the same machine (a CentOS at work);
I always do this.
in this case it was the wxWidgets 3.1 built from source

>>You should see those two
> commits with massaged commit messages when you update your local
> master branch

I saw it, thanks


-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 17, 2016 3:38 AM
Subject: Re: The pls NULL fix for some Linux platforms


> On 2016-12-16 13:30-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> the patch with the 2nd commit with fix is  attached
>
> Hi Pedro:
>
> Much thanks for your revised first commit and this second one.
> I applied them one at a time and for each
> case ran
>
> git commit --amend
>
> to massage each commit message (some more in the first case) before
> pushing them to the SF master branch.  I assumed when massaging your
> second commit message, that your test debug sequence was on the same
> OS as you used in the commit message associated with your first
> commit.  If I got that wrong, it is too late to change (because it is
> generally a bad idea to amend already published commits).  However, it
> is reasonably well understood that sometimes commit messages don't
> reflect actual test conditions, but I was willing to accept that
> chance and make the most intelligent guess I could so I would not have
> to go through another iteration with you. You should see those two
> commits with massaged commit messages when you update your local
> master branch (using the cookbook in README.developers if you are not
> quite sure how to do that with an already existing git local repository).
>
> Also, it struck me when comparing your results with mine for each of
> those tested by: stanzas for each commit, that I have a 9-year-old box
> here that was fast for its era (2.4GHz, 2 cpu's), but its memory is
> limited so that slows it down, and two users (my wife and I) have KDE
> desktop software running on it simultaneously which also slows it down
> a bit (principally by consuming a lot of memory).  So I suspect you
> have a much faster test setup there.  So if this event order bug is
> all about hardware and general box conditions affecting the
> indeterminate time when the OnCreate event fires, this difference
> might explain the differences in when that event occurs between my
> results and yours both before and after your bug fix.
>
> So if that is a good summary of the problem (the timing for when the
> OnCreate event fires is not deterministic which your debug output
> seems to have proved again and again) doesn't wxwidgets have a decent
> way to wait for that event to fire in the Plot routine before
> proceeding with defining pls? That would be the definitive fix for
> this nondeterministic event timing issue (assuming that is the issue).
>
> In fact I just did a google search for the terms  event> and there did seem to be a lot of help given on that topic
> right in the first reference found
> <https://forums.wxwidgets.org/viewtopic.php?t=22893>. Could you adapt
> one of those ideas?  Or if that reference is too old (2009) so not
> wxwidgets-3.x relevant, perhaps one of the other hits you get with the
> above search terms might give you the one-liner you need to
> efficiently wait for the onCreate event before proceeding with
> defining pls in Plot().  And that one-liner would allow you to remove
> the changes you made in the present workaround bug fix.  Anyhow, if
> you can come up with that one-liner + dropping the changes in commit
> e5b7485 (your workaround fix) I would be very happy to push that
> commit.
>
> 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-pow

Re: [Plplot-devel] The pls NULL fix for some Linux platforms

[Pedro Vicente]

There's a small change that must be done in my 2nd patch

here

bool wxPLplotwindow::Show(bool show)
{
  wxLogDebug("wxPLplotwindow::Show");
  CreateStream();
  WXWINDOW::Show(show);

}


it should be instead

return WXWINDOW::Show(show);

gcc let me get away with it, but it's an error in Visual Studio

-Pedro






- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Friday, December 16, 2016 1:30 PM
Subject: Re: [Plplot-devel] The pls NULL fix for some Linux platforms


> Hi Alan
>
> the patch with the 2nd commit with fix is  attached
> -Pedro
>
>
> On 2016-12-15 20:14, Alan W. Irwin wrote:
>> On 2016-12-15 18:39-0500 Pedro Vicente wrote:
>>
>>> I did what the README file said and here it is my first patch
>>> attached:-)
>>>
>>> what it has it's *just* some print messages (not my fix yet) so that
>>> you and Phil could get a better idea of the bug
>>>
>>> I have
>>>
>>> 17:57:49: Debug: wxPLplotwindow::wxPLplotwindow
>>> 17:57:49: Debug: frame->Create
>>> 17:57:49: Debug: pls NULL
>>> 17:57:49: Debug: wxPLplotwindow::RenewPlot
>>> 17:57:49: Debug: wxPLplotwindow::OnCreate
>>> 17:57:49: Debug: wxPLplotwindow::RenewPlot
>>>
>>> so this clearly shows that the stream is NULL on my linux build
>>
>> Hi Pedro:
>>
>> Your commit applied cleanly here on a topic branch.  And I like the
>> fact you have a separate commit for the debugging output and
>> later you will follow up with your commit with your actual
>> fix (for VirtualBox'd Linux platforms).
>>
>> I do have a strong suggestion that the style of your commit message
>> needs to be reformatted.
>>
>> So instead of saying
>>
>> add debug messages that show sequence of events for a bug that
>> happens
>> on linux with wxwidgets3.0 installed from packages cause is that
>> frame->Create does not trigger a OnCreate() event before the PLot()
>> call
>>
>> in your very first paragraph, you should reformat that as follows:
>>
>> wxwidgets binding: insert debug messages
>> 
>> Add debug messages that show sequence of events for a bug that
>> happens
>> on linux with wxwidgets3.0 installed from packages.  The cause (at
>> least on VirtualBox Linux platforms) is that frame->Create does not
>> trigger an OnCreate() event before the PLot() call as shown by the
>> following debug messages when the test_wxPLplotDemo target is built
>> on a VirtualBox'd Linux system.
>> 
>> 17:57:49: Debug: wxPLplotwindow::wxPLplotwindow
>> 17:57:49: Debug: frame->Create
>> 17:57:49: Debug: pls NULL
>> 17:57:49: Debug: wxPLplotwindow::RenewPlot
>> 17:57:49: Debug: wxPLplotwindow::OnCreate
>> 17:57:49: Debug: wxPLplotwindow::RenewPlot
>>
>> That first very short (one line) paragraph is important (as I also
>> noted in README.developers) because that short summary of
>> the commit is used in all sorts of places within git.
>>
>> IF you haven't done any further commits,
>> you can change to this new style by simply using
>>
>> git commit --amend
>>
>> which allows you to amend your current commit message if you have
>> nothing staged yet for your next commit.
>>
>> Or I can do a similar commit amend here (but I prefer you do it for
>> the
>> practice).
>>
>> @Phil:
>>
>> I implemented the current form of Pedro's first commit here as
>> follows:
>>
>> First update local git master to latest git master from SF as per
>> usual.  Then
>>
>> # If not there already
>> git checkout master
>> # Always develop on topic branches starting from fresh master
>> git checkout -b wxwidgets_fixes
>> # Create Pedro's commit on that new branch
>> git am
>>
>> >
>> That commit applied cleanly (except for a minor warning about a
>> trailing whitespace issue).
>>
>> @Pedro:
>>
>> I then got the following result here from building test_wxPLplotDemo
>>
>> 16:37:03: Debug: wxPLplotwindow::wxPLplotwindow
>> 16:37:03: Debug: frame->Create
>> 16:37:03: Debug: wxPLplotwindow::RenewPlot
>> 16:37:03: Debug: wxPLplotwindow::RenewPlot
>> 16:37:03: Debug: wxPLplotwindow::OnCreate
>> 16:37:03: Debug: wxPLplotwindow::RenewPlot
>> 16:37:03: Debug: Plot()
>> 16:37:03: Debug: wxPLplotwindow::RenewPl

Re: [Plplot-devel] Cmake generation with wxWidgets on Windows

[Pedro Vicente]

false alarm, sorry

what happened is that my wxWidgets libraries were not built.

In Windows , I don't do install, but rather build software and leave it 
where it was built, and sometimes delete and rebuild.

In PLplot 5.11.1 the build actually did not include the wxWidgets projects 
and files, so it built.
but in the git version it did include the wxWidgets projects and files, so 
it failed.

there's the small detail that cmake should have had allerted that wxWidgets 
was not built...but probably not important , or could just have been my 
mistake somewhere.

so the result is for cmake build with wxWidgets

Rebuild All: 88 succeeded, 0 failed, 0 skipped =







- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 17, 2016 1:55 AM
Subject: [Plplot-devel] Cmake generation with wxWidgets on Windows


> Hi Alan
>
> I am having linking errors on the latest git clone in Windows when I use
> wxWidgets.
>
> It seems that the all the examples (or plplot.lib) are trying to link with
> wxWidgets , and I get this kind of errors
>
>
> -- Build started: Project: x00c, Configuration: Debug Win32 --
> plplot.lib(wxwidgets.obj) : error LNK2019: unresolved external symbol 
> "void
> __cdecl wxEntryCleanup(void)" (?wxEntryCleanup@@YAXXZ) referenced in
> function __catch$?plD_bop_wxwidgets@@YAXPAUPLStream@@@Z$1
>
>
> I tried the same cmake call on my PLplot 5.11.1 version and no problems, 
> so
> I am sure it's not my cmake call or my wxWidgets.
>
> my cmake call is
>
> cmake ".." -G "Visual Studio
> 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON 
> -DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
> -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF 
> -DSTATIC_RUNTIME:BOOL=ON
> -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% 
> -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
> -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON 
> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>
> and the output is attached
>
> I'm trying to figure out this by looking for ${wxwidgets_LINK_FLAGS} in 
> the
> scripts;
> all the mentions of it are below, in 4 different source files.
>
>
>
> P:\plplot\plplot\bindings\wxwidgets\CMakeLists.txt(76):
> target_link_libraries(plplotwxwidgets PRIVATE plplot plplotcxx
> ${wxwidgets_LINK_FLAGS})
>  P:\plplot\plplot\bindings\wxwidgets\CMakeLists.txt(78):
> target_link_libraries(plplotwxwidgets PUBLIC plplot plplotcxx
> ${wxwidgets_LINK_FLAGS})
>  P:\plplot\plplot\bindings\wxwidgets\CMakeLists.txt(119):
> pkg_config_file("wxwidgets" "wxWidgets" " wxWidgets binding"
> "plplotwxwidgets" "${libplplotwxwidgets_COMPILE_FLAGS}"
> "-lplplot;-lplplotcxx;${wxwidgets_LINK_FLAGS}")
>
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(27):#
> widgets_LINK_FLAGS   - list of full path names of libraries and
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(57):
> cmake_link_flags(wxwidgets_LINK_FLAGS "${wxWidgets_LIBRARIES}")
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(58):  if(NOT
> wxWidgets_FOUND OR NOT wxwidgets_LINK_FLAGS)
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(65):  else(NOT
> wxWidgets_FOUND OR NOT wxwidgets_LINK_FLAGS)
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(68):  endif(NOT
> wxWidgets_FOUND OR NOT wxwidgets_LINK_FLAGS)
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(126):  message(STATUS
> "wxwidgets_LINK_FLAGS = ${wxwidgets_LINK_FLAGS}")
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(144):
> wxwidgets_LINK_FLAGS
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(145):
> ${wxwidgets_LINK_FLAGS}
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(156): wxwidgets_LINK_FLAGS
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(157):
> ${wxwidgets_LINK_FLAGS}
>  P:\plplot\plplot\cmake\modules\wxwidgets.cmake(183):
> ${wxwidgets_LINK_FLAGS}
>
>  P:\plplot\plplot\examples\c++\CMakeLists.txt(131):
> target_link_libraries(wxPLplotDemo plplotwxwidgets plplotcxx
> ${wxwidgets_LINK_FLAGS} ${MATH_LIB})
>  P:\plplot\plplot\examples\c++\CMakeLists.txt(133):  # Transform
> wxwidgets_LINK_FLAGS from list of libraries to the standard pkg-config 
> form
>  P:\plplot\plplot\examples\c++\CMakeLists.txt(135):
> pkg_config_link_flags(pkg_config_wxwidgets_LINK_FLAGS
> "${wxwidgets_LINK_FLAGS}")
>
>  P:\plplot\plplot\utils\CMakeLists.txt(92):
> target_link_libraries(wxPLVie

[Plplot-devel] Cmake generation with wxWidgets on Windows

[Pedro Vicente]

Hi Alan

I am having linking errors on the latest git clone in Windows when I use 
wxWidgets.


It seems that the all the examples (or plplot.lib) are trying to link with 
wxWidgets , and I get this kind of errors



-- Build started: Project: x00c, Configuration: Debug Win32 --
plplot.lib(wxwidgets.obj) : error LNK2019: unresolved external symbol "void 
__cdecl wxEntryCleanup(void)" (?wxEntryCleanup@@YAXXZ) referenced in 
function __catch$?plD_bop_wxwidgets@@YAXPAUPLStream@@@Z$1



I tried the same cmake call on my PLplot 5.11.1 version and no problems, so 
I am sure it's not my cmake call or my wxWidgets.


my cmake call is

cmake ".." -G "Visual Studio 
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
-DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON 
-DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib 
-DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF


and the output is attached

I'm trying to figure out this by looking for ${wxwidgets_LINK_FLAGS} in the 
scripts;

all the mentions of it are below, in 4 different source files.



P:\plplot\plplot\bindings\wxwidgets\CMakeLists.txt(76): 
target_link_libraries(plplotwxwidgets PRIVATE plplot plplotcxx 
${wxwidgets_LINK_FLAGS})
 P:\plplot\plplot\bindings\wxwidgets\CMakeLists.txt(78): 
target_link_libraries(plplotwxwidgets PUBLIC plplot plplotcxx 
${wxwidgets_LINK_FLAGS})
 P:\plplot\plplot\bindings\wxwidgets\CMakeLists.txt(119): 
pkg_config_file("wxwidgets" "wxWidgets" " wxWidgets binding" 
"plplotwxwidgets" "${libplplotwxwidgets_COMPILE_FLAGS}" 
"-lplplot;-lplplotcxx;${wxwidgets_LINK_FLAGS}")


 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(27):# 
widgets_LINK_FLAGS   - list of full path names of libraries and
 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(57): 
cmake_link_flags(wxwidgets_LINK_FLAGS "${wxWidgets_LIBRARIES}")
 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(58):  if(NOT 
wxWidgets_FOUND OR NOT wxwidgets_LINK_FLAGS)
 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(65):  else(NOT 
wxWidgets_FOUND OR NOT wxwidgets_LINK_FLAGS)
 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(68):  endif(NOT 
wxWidgets_FOUND OR NOT wxwidgets_LINK_FLAGS)
 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(126):  message(STATUS 
"wxwidgets_LINK_FLAGS = ${wxwidgets_LINK_FLAGS}")
 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(144): 
wxwidgets_LINK_FLAGS
 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(145): 
${wxwidgets_LINK_FLAGS}

 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(156): wxwidgets_LINK_FLAGS
 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(157): 
${wxwidgets_LINK_FLAGS}
 P:\plplot\plplot\cmake\modules\wxwidgets.cmake(183): 
${wxwidgets_LINK_FLAGS}


 P:\plplot\plplot\examples\c++\CMakeLists.txt(131): 
target_link_libraries(wxPLplotDemo plplotwxwidgets plplotcxx 
${wxwidgets_LINK_FLAGS} ${MATH_LIB})
 P:\plplot\plplot\examples\c++\CMakeLists.txt(133):  # Transform 
wxwidgets_LINK_FLAGS from list of libraries to the standard pkg-config form
 P:\plplot\plplot\examples\c++\CMakeLists.txt(135): 
pkg_config_link_flags(pkg_config_wxwidgets_LINK_FLAGS 
"${wxwidgets_LINK_FLAGS}")


 P:\plplot\plplot\utils\CMakeLists.txt(92): 
target_link_libraries(wxPLViewer plplotwxwidgets plplotcxx 
${wxwidgets_LINK_FLAGS} ${MATH_LIB} ${RT_LIB})
 Matching lines: 18Matching files: 4Total files searched: 370 

-- The C compiler identification is MSVC 19.0.24213.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- CMake version = 3.6.2
-- CMAKE_SYSTEM_NAME = Windows
-- SH_EXECUTABLE = SH_EXECUTABLE-NOTFOUND
-- WARNING: bash shell not found, ctest will not work properly
-- Checking whether system has ANSI C header files
-- Looking for 4 include files stdlib.h, ..., float.h
-- Looking for 4 include files stdlib.h, ..., float.h - found
-- Performing Test memchrExists
-- Performing Test memchrExists - Success
-- Performing Test freeExists
-- Performing Test freeExists - Success
-- Check for whether ctype.h macros work on characters with the
  high bit set.
-- High-bit characters - work
-- ANSI C header files - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - not found
-- Looking for include file termios.h
-- Looking for include file termios.h - not found
-- Looking for include file stdint.h
-- Looking for include file stdint.h - found
-- Looking for crt_externs.h
-- Looking for crt_externs.h - not found
-- Performing Test HAVE_SYS_WAIT_H
-- Performing Test HAVE_SYS_WAIT_H - Failed
-- Looking for DIR symbol in sys/types.h;dirent.h
-- Looking for DIR symbol in sys/types.h;dirent.h - not found.
-- Looking for DIR symbol in 

Re: [Plplot-devel] The pls NULL fix for some Linux platforms

[Pedro Vicente]

Hi Alan

the patch with the 2nd commit with fix is  attached
-Pedro


On 2016-12-15 20:14, Alan W. Irwin wrote:

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

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


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


I have

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

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


Hi Pedro:

Your commit applied cleanly here on a topic branch.  And I like the
fact you have a separate commit for the debugging output and
later you will follow up with your commit with your actual
fix (for VirtualBox'd Linux platforms).

I do have a strong suggestion that the style of your commit message
needs to be reformatted.

So instead of saying

add debug messages that show sequence of events for a bug that 
happens

on linux with wxwidgets3.0 installed from packages cause is that
frame->Create does not trigger a OnCreate() event before the PLot() 
call


in your very first paragraph, you should reformat that as follows:

wxwidgets binding: insert debug messages

Add debug messages that show sequence of events for a bug that 
happens

on linux with wxwidgets3.0 installed from packages.  The cause (at
least on VirtualBox Linux platforms) is that frame->Create does not
trigger an OnCreate() event before the PLot() call as shown by the
following debug messages when the test_wxPLplotDemo target is built
on a VirtualBox'd Linux system.

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

That first very short (one line) paragraph is important (as I also
noted in README.developers) because that short summary of
the commit is used in all sorts of places within git.

IF you haven't done any further commits,
you can change to this new style by simply using

git commit --amend

which allows you to amend your current commit message if you have
nothing staged yet for your next commit.

Or I can do a similar commit amend here (but I prefer you do it for 
the

practice).

@Phil:

I implemented the current form of Pedro's first commit here as 
follows:


First update local git master to latest git master from SF as per
usual.  Then

# If not there already
git checkout master
# Always develop on topic branches starting from fresh master
git checkout -b wxwidgets_fixes
# Create Pedro's commit on that new branch
git am

Create
16:37:03: Debug: wxPLplotwindow::RenewPlot
16:37:03: Debug: wxPLplotwindow::RenewPlot
16:37:03: Debug: wxPLplotwindow::OnCreate
16:37:03: Debug: wxPLplotwindow::RenewPlot
16:37:03: Debug: Plot()
16:37:03: Debug: wxPLplotwindow::RenewPlot
PLMemoryMap::close: just entering close
[100%] Built target test_wxPLplotDemo

which continues to show non-NULL pls here.

Nevertheless from my perspective as release manager we want to
accommodate all platforms including VirtualBox ones (even if we are
missing something now, as Phil suggested, to explain this difference
between those platforms and ordinary Linux).

So please go ahead and send me both commits (the first one amended as
above, and your next commit to take care of this pls NULL issue on
VirtualBox'd Linux platforms). And then assuming there are no 
problems

here due to these two commits, I will merge both commits to SF master
unless I hear differently from Phil between now and then.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and 
Astronomy,

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

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

Linux-powered Science
__


--
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

0001-wxwidgets-binding-workaround-fix-for-delayed-OnCreat.patch.tar.gz
Description: Binary data
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

Hi Phil, Alan

I tried evtCreateExample.cpp and I get the good expected result.
This just means that for this simple example the OnCreate event is 
triggered.

To note that on my bad results of the PLplot demo, the OnCreate event 
is *also* triggered.
the problem is that is triggered after the plot was made


11:09:13: Debug: wxPLplotwindow::wxPLplotwindow
11:09:13: Debug: frame->Create
11:09:13: Debug: pls NULL
11:09:13: Debug: wxPLplotwindow::OnCreate

I am not that familiar with the wxWidgets internals but it seems events 
are put in a queue.

http://docs.wxwidgets.org/3.1/overview_events.html

it could be that the event is not processed in the expected order or 
delayed for some reason.
this could be a good question for the wxWidgets support list.

-Pedro


On 2016-12-15 21:11, Alan W. Irwin wrote:
> On 2016-12-16 01:05- Phil Rosenberg wrote:
>
>> Hmm - well another theory down in smoke.
>>
>> Attached is an absolute minimum example of the use of wxEVT_CREATE. 
>> On
>> Windows I get the expected behaviour of a popup dialog appearing
>> before the frame saying "OnCreate called."
>>
>> Could you try it on one of your Linux machines? I'm afraid it's way
>> past my bedtime here in the UK, so I'll have to continue tomorrow.
>
> @Pedro: You should do this test as well since your Linux platforms
> are the ones where
> (so far at least) issues are showing up.  But for what it is worth, I
> did the following
>
> irwin@raven> g++ $(wx-config --cppflags --libs) evtCreateExample.cpp
>
> to successfully (no errors/warnings) build Phil's test application.
>
> Then I ran it with
>
> irwin@raven> ./a.out
>
> and a popup window came up (apparently as a subGUI of a grey GUI 
> blank
> called "My Frame") with the "OnCreate Called" message displayed 
> (which
> I understand was the expected result when everything is working
> properly).
>
> I hope that experiment helps you guys to gain some insight in what 
> the
> heck is going on for wxwidgets-gtk+ on Linux.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The pls NULL fix for VirtualBox'd Linux platforms

[Pedro Vicente]

Hi Alan

my new commit with debug prints and new commit message is attached
-Pedro

On 2016-12-15 20:14, Alan W. Irwin wrote:

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

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


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


I have

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

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


Hi Pedro:

Your commit applied cleanly here on a topic branch.  And I like the
fact you have a separate commit for the debugging output and
later you will follow up with your commit with your actual
fix (for VirtualBox'd Linux platforms).

I do have a strong suggestion that the style of your commit message
needs to be reformatted.

So instead of saying

add debug messages that show sequence of events for a bug that 
happens

on linux with wxwidgets3.0 installed from packages cause is that
frame->Create does not trigger a OnCreate() event before the PLot() 
call


in your very first paragraph, you should reformat that as follows:

wxwidgets binding: insert debug messages

Add debug messages that show sequence of events for a bug that 
happens

on linux with wxwidgets3.0 installed from packages.  The cause (at
least on VirtualBox Linux platforms) is that frame->Create does not
trigger an OnCreate() event before the PLot() call as shown by the
following debug messages when the test_wxPLplotDemo target is built
on a VirtualBox'd Linux system.

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

That first very short (one line) paragraph is important (as I also
noted in README.developers) because that short summary of
the commit is used in all sorts of places within git.

IF you haven't done any further commits,
you can change to this new style by simply using

git commit --amend

which allows you to amend your current commit message if you have
nothing staged yet for your next commit.

Or I can do a similar commit amend here (but I prefer you do it for 
the

practice).

@Phil:

I implemented the current form of Pedro's first commit here as 
follows:


First update local git master to latest git master from SF as per
usual.  Then

# If not there already
git checkout master
# Always develop on topic branches starting from fresh master
git checkout -b wxwidgets_fixes
# Create Pedro's commit on that new branch
git am

Create
16:37:03: Debug: wxPLplotwindow::RenewPlot
16:37:03: Debug: wxPLplotwindow::RenewPlot
16:37:03: Debug: wxPLplotwindow::OnCreate
16:37:03: Debug: wxPLplotwindow::RenewPlot
16:37:03: Debug: Plot()
16:37:03: Debug: wxPLplotwindow::RenewPlot
PLMemoryMap::close: just entering close
[100%] Built target test_wxPLplotDemo

which continues to show non-NULL pls here.

Nevertheless from my perspective as release manager we want to
accommodate all platforms including VirtualBox ones (even if we are
missing something now, as Phil suggested, to explain this difference
between those platforms and ordinary Linux).

So please go ahead and send me both commits (the first one amended as
above, and your next commit to take care of this pls NULL issue on
VirtualBox'd Linux platforms). And then assuming there are no 
problems

here due to these two commits, I will merge both commits to SF master
unless I hear differently from Phil between now and then.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and 
Astronomy,

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

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

Linux-powered Science
__


--
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

0001-wxwidgets-binding-insert-debug-messages.patch.tar.gz
Description: Binary data
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

Hi Alan

ok, I will reformat the commit message later today.
since I am not that familiar with git to do the  amend, I'll just create a 
new branch and do the same commit with the message you sent in the last 
email

that's a good idea to have messages as detailed as possible,

-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 15, 2016 8:34 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


> On 2016-12-15 19:56-0500 Pedro Vicente wrote:
>
>> Alan
>>
>> All my linux failures were on 3 different "real" machines (CentOS with 
>> personal wxwidgets 3.1 build, 2 ubuntus 14.04 16.4 from packages)
>>
>> the 4th linux failure was on a debian I installed on VirtualBox.
>
> Hi Pedro:
>
> Sorry.  As Phil said, one more theory goes up in smoke.  :-(
>
> My suggestion for reformatting your commit message still stands but 
> obviously
> without the Virtual box remark I inserted.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
> 


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

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

not at all ! :-)

the beauty of Virtual Box is that it has this feature called dynamic size.
you can install ubuntu with 8GB or less.

all the OS is contained on a single file on the host system.
so it does not alter the host in any shape or form

I routinely install and delete linux installations just to test something


>> > I have also just tried on the Bash on Ubuntu on Windows (still trying
> to decide if I like this or Cygwin best. Anyway...).


go for Bash on Ubuntu on Windows if you have Windows 10
I have Windows 7 and I use git bash ;
so I can run bash on Windows 7

>> Again everything
> works fine on this (I'm using Xming for my X server).

the bug does not happen in Windows ;
that is if you mean the Visual Studio build that uses the wxWidgets WIN32 
API
completely different from the GTK part on Linux


>> > I suspect that you are correct Alan and this is a subtle VitualBox
> thing.

see my previous email
the errors happened on real linux installations



- Original Message - 
From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: "Pedro Vicente" <pedro.vice...@space-research.org>; "PLplot development 
list" <plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 15, 2016 7:26 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


> Unfortunately I don't think I have enough space to install virtualbox.
> I presume I need a few 10s of GB for an Ubuntu install?
>
> I have also just tried on the Bash on Ubuntu on Windows (still trying
> to decide if I like this or Cygwin best. Anyway...). Again everything
> works fine on this (I'm using Xming for my X server).
>
> Is there something different with the X server or something in a
> VirtualBox install?
>
> I suspect that you are correct Alan and this is a subtle VitualBox
> thing. We should create a minimum working example of a wxFrame using
> the two stage creation totally independent of plplot and see if this
> works. If it doesn't then we know this is a VirtualBox/wxWidgets bug.
> If it does then we can start adding complexity to find where it
> breaks.
>
> On 16 December 2016 at 00:05, Alan W. Irwin <ir...@beluga.phys.uvic.ca> 
> wrote:
>> On 2016-12-15 17:19-0500 Pedro Vicente wrote:
>>
>>> Hi Phil
>>>
>>>
>>>>> I can't help feeling that there is something that we are missing here.
>>>>> Given both I and Pedro have tested on Ubuntu 14.04 there must be
>>>>> something different between the two systems.
>>>
>>>
>>> it seems so.
>>> the only way to be sure is that on your side to install a completely new
>>> Ubuntu, or Debian on VirtualBox, and then do
>>>
>>> sudo apt-get install libwxgtk3.0-dev
>>>
>>> VirtualBox can be installed on Windows or Mac (this is called the host
>>> system).
>>> I am running it on my Windows machine and I have three linux installed 
>>> on
>>> it , ubuntu, centos, debian
>>
>>
>> @ Phil and Pedro:
>>
>> I am beginning to wonder whether something that is being done
>> differently but legitimately by VirtualBox is highlighting some subtle
>> bug we have in the Linux wxwidgets code that doesn't happen to show any
>> symptoms for the non-VirtualBox'd case.
>>
>> @Phil:
>>
>> I am just going to go ahead and merge Pedro's patch (once he gets it
>> to me in "git format-patch" form) to SF master since it apparently
>> solves his "VirtualBox" issue (if we can call it that) without messing
>> up the Linux success we have on non-VirtualBox'ed Linux.  But if you
>> have any qualms about his changes, feel free to either contact me
>> immediately (if you are not sleeping now) or ask me to revert my merge
>> of his work tomorrow.
>>
>>
>> Alan
>> __
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and 
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __
>>
>> Linux-powered Science
>> __
> 


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

Alan

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

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


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 15, 2016 7:05 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


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


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

Hi Alan


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


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


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

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


I have

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

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

-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <Plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 15, 2016 6:22 PM
Subject: Recruiting members of the core development team



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


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


Hi Pedro:

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

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

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

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and 
Astronomy,

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

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

Linux-powered Science
__



0001-add-debug-messages-that-show-sequence-of-events.tar.gz
Description: GNU Zip compressed data
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

Hi Phil


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

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

sudo apt-get install libwxgtk3.0-dev

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

-Pedro




- Original Message - 
From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "PLplot development list" 
<plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 15, 2016 5:06 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


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


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

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


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

otherwise you would have this


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

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

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

in all functions

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

ok

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

your're welcome, glad I could help


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


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


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


ok

-Pedro

On 2016-12-15 16:12, Alan W. Irwin wrote:
> On 2016-12-15 11:24-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>>
>> Success
>>
>> The solution is to override the Show() function of the window, that 
>> is called in the demo.
>> So no need to modify the demo at all with a custom function call.
>>
>>
>> in wxPLplotwindow.h I just added this function
>>
>> template
>> bool wxPLplotwindow::Show(bool show)
>> {
>>  wxLogDebug("wxPLplotwindow::Show");
>>  CreateStream();
>>  WXWINDOW::Show(show);
>>
>> }
>>
>> where
>> CreateStream();
>> is a new internal function of the class that contains the code that 
>> is now in OnCreate()
>>
>> the 2 files are attached
>> they contain a couple of debug messages
>>
>> this is the sequence I get
>>
>> 11:13:52: Debug: wxPLplotwindow
>> 11:13:52: Debug: frame->Create
>> 11:13:52: Debug: wxPLplotwindow::Show
>> 11:13:52: Debug: wxPLplotwindow::CreateStream
>> 11:13:52: Debug: wxPLplotwindow::RenewPlot
>> 11:13:52: Debug: Plot()
>> 11:13:52: Debug: wxPLplotwindow::RenewPlot
>> 11:13:52: Debug: wxPLplotwindow::RenewPlot
>> 11:13:52: Debug: wxPLplotwindow::OnCreate
>> 11:13:52: Debug: wxPLplotwindow::CreateStream
>> 11:13:52: Debug: wxPLplotwindow::OnErase
>>
>>
>> as you can see the stream is NOT NULL when we get at
>> 11:13:52: Debug: Plot()
>
> I get something different here
>
> 12:45:37: Debug: wxPLplotwindow
> 12:45:37: Debug: frame->Create
> 12:45:37: Debug: wxPLplotwindow::Show
> 12:45:37: Debug: wxPLplotwindow::CreateStream
> 12:45:37: Debug: wxPLplotwindow::RenewPlot
> 12:45:37: Debug: wxPLplotwindow::RenewPlot
> 12:45:37: Debug: wxPLplotwindow::RenewPlot
> 12:45:37: Debug: wxPLplotwindow::OnCreate
> 12:45:37: Debug: wxPLplotwindow::CreateStream
> 12:45:37: Debug: Plot()
> 12:45:37: Debug: wxPLplotwindow::RenewPlot
> 12:45:37: Debug: wxPLplotwindow::OnErase
> 12:45:43: Debug: wxPLplotwindow::OnErase
> 12:45:45: Debug: wxPLplotwindow::OnErase
> PLMemoryMap::close: just entering close
> [100%] Built target test_wxPLplotDemo
>
> Perhaps this different result is why the issue did not cause
> any problems on my system?
>
> But regardless of that system difference issue, your changes work
> here, and also work there.  So a big thanks for that fundamental
> fix for the problem!
>
> Important!  Also please follow the cookbook instructions in
> README.developers to format your change in "git format-patch" form. 
> (I
> just [commit ae4af16] updated those instructions with you in mind so 
> I
> hope you will find them easy to follow.)
>
> The alternative is I could just go ahead and commit your changed 
> files
> here, but then that would give me git credit for your work (as seen
> by, e.g

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

[Pedro Vicente]

Hi Alan


Success

The solution is to override the Show() function of the window, that is 
called in the demo.

So no need to modify the demo at all with a custom function call.


in wxPLplotwindow.h I just added this function

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

}

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


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

this is the sequence I get

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


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

-Pedro



On 2016-12-15 10:22, Pedro Vicente wrote:

Hi Alan

I installed the latest from the debian site, here

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

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

sudo apt-get install libwxgtk3.0-dev



On 2016-12-15 04:32, Alan W. Irwin wrote:

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


Hi Alan

I just installed the latest debian on VirtualBox, and I get the 
same

errors.
the results are attached, same thing that I did for ubuntu.


Hi Pedro:

Just for the record, what version of Debian?

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

that Debian release epoch, and Sid is always going to be unstable.
:-)

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


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


Half my computer memory fried itself a year or so ago so my computer
(already 9 years old but with ASUS motherboard, Intel CPU's, new
disks, and new power supply still doing pretty well) is a little
short
of memory. Thus, I don't plan to look at VirtualBox at the moment,
but
when (if?) one of my motherboard, CPU's, or remaining RAM die so 
that

I really do have to replace all three, I intend to buy a huge amount
of memory for the new system so I can play with VirtualBox with 
ease.


Alan
__
Alan W. Irwin

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

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

Linux-powered Science
______


--
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


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

// For compilers that support precompilation,

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

[Pedro Vicente]

Hi Alan

I installed the latest from the debian site, here

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

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

sudo apt-get install libwxgtk3.0-dev



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

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

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

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

returning on PLot() avoids the assertion

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

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

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


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

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

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

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

should have some solutions

-Pedro


- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 15, 2016 1:57 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


> Hi Alan, Phil
>
> I forgot about a very simple fix that does need a custom function call
> (therefore a "real" fix, or better a non intrusive fix for users)
>
> that is, right now, the code is responding to these 2 events
>
> WXWINDOW::Connect( wxEVT_SIZE, wxSizeEventHandler(
> wxPLplotwindow::OnSize ) );
> WXWINDOW::Connect( wxEVT_PAINT, wxPaintEventHandler(
> wxPLplotwindow::OnPaint ) );
>
> so, it's just a matter of calling the OnCreate() stream on one
>
> wxEVT_SIZE is a bad idea, because it's only called when the user moves the
> window
> but I think wxEVT_PAINT is *continuously* called in a event loop (meaning
> always)
>
> right now it even has some calls that are called there as a workaround
>
>
> template
> void wxPLplotwindow::OnPaint( wxPaintEvent ( event ) )
> {
>//Really this should be in the constructor, but it caused a segfault
>//on at least one system (CentOS with intel compiler and wxWidgets
> 2.8.12).
>//Moving it here after WXWINDOW::Create has been called stops this and
>//the call does nothing if the style is the same as previous calls so
>//should be safe to call here.
>
>
> the boolean flag
>
> if ( !m_created )
>{
>//create the stream
>
>
> makes it that it's only called 1 time
>
> I'll try this tomorrow
>
> -Pedro
>
>
>
> - Original Message - 
> From: "Pedro Vicente" <pedro.vice...@space-research.org>
> To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg"
> <p.d.rosenb...@gmail.com>
> Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
> Sent: Thursday, December 15, 2016 1:31 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error
>
>
>> Hi Alan
>>
>>> I think you will agree with me that smells like a workaround rather
>>> than a fundamental fix.
>>
>> yes, I agree.
>>
>>>> Eventually, we had to change our
>>>> minimum acceptable wxwidgets version from 2.8 to 3.0 because of one
>>>> commit which only worked for 3.0.
>>
>> hhm, ok
>> I have to double check this but the comments in your code say ::Bind() is
>> only available
>> for 3.0, and ::Bind()  is not used
>>
>> so probably the code as of now is compatible with 2.8 (meaning it only 
>> has
>> 2.8 calls, not 3.0 calls)
>>
>>
>>>>I would appreciate
>>>> your thoughts on this matter of moving to pure 3.0.
>>
>> we could try the ::Bind()   route, yes, to see what happens
>>
>> another thing
>> wxPLplotwindow.h is a header file
>> we can try to move the implementation to a .ccp file (with templates 
>> there
>> are some idiosyncrasies about the use of headers versus .cpp,
>> that's why I never use templates)
>>
>>
>>>>I would be willing to hold the release for you for a few
>>>> extra days beyond December 27th
>>
>> that would be great, that should be

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

[Pedro Vicente]

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

I meant does NOT need a custom function call

- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 15, 2016 1:57 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


> Hi Alan, Phil
>
> I forgot about a very simple fix that does need a custom function call
> (therefore a "real" fix, or better a non intrusive fix for users)
>
> that is, right now, the code is responding to these 2 events
>
> WXWINDOW::Connect( wxEVT_SIZE, wxSizeEventHandler(
> wxPLplotwindow::OnSize ) );
> WXWINDOW::Connect( wxEVT_PAINT, wxPaintEventHandler(
> wxPLplotwindow::OnPaint ) );
>
> so, it's just a matter of calling the OnCreate() stream on one
>
> wxEVT_SIZE is a bad idea, because it's only called when the user moves the
> window
> but I think wxEVT_PAINT is *continuously* called in a event loop (meaning
> always)
>
> right now it even has some calls that are called there as a workaround
>
>
> template
> void wxPLplotwindow::OnPaint( wxPaintEvent ( event ) )
> {
>//Really this should be in the constructor, but it caused a segfault
>//on at least one system (CentOS with intel compiler and wxWidgets
> 2.8.12).
>//Moving it here after WXWINDOW::Create has been called stops this and
>//the call does nothing if the style is the same as previous calls so
>//should be safe to call here.
>
>
> the boolean flag
>
> if ( !m_created )
>{
>//create the stream
>
>
> makes it that it's only called 1 time
>
> I'll try this tomorrow
>
> -Pedro
>
>
>
> - Original Message - 
> From: "Pedro Vicente" <pedro.vice...@space-research.org>
> To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg"
> <p.d.rosenb...@gmail.com>
> Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
> Sent: Thursday, December 15, 2016 1:31 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error
>
>
>> Hi Alan
>>
>>> I think you will agree with me that smells like a workaround rather
>>> than a fundamental fix.
>>
>> yes, I agree.
>>
>>>> Eventually, we had to change our
>>>> minimum acceptable wxwidgets version from 2.8 to 3.0 because of one
>>>> commit which only worked for 3.0.
>>
>> hhm, ok
>> I have to double check this but the comments in your code say ::Bind() is
>> only available
>> for 3.0, and ::Bind()  is not used
>>
>> so probably the code as of now is compatible with 2.8 (meaning it only 
>> has
>> 2.8 calls, not 3.0 calls)
>>
>>
>>>>I would appreciate
>>>> your thoughts on this matter of moving to pure 3.0.
>>
>> we could try the ::Bind()   route, yes, to see what happens
>>
>> another thing
>> wxPLplotwindow.h is a header file
>> we can try to move the implementation to a .ccp file (with templates 
>> there
>> are some idiosyncrasies about the use of headers versus .cpp,
>> that's why I never use templates)
>>
>>
>>>>I would be willing to hold the release for you for a few
>>>> extra days beyond December 27th
>>
>> that would be great, that should be enough to have a better idea.
>> I have more time to work on this on the weekends only.
>>
>> -Pedro
>>
>>
>> - Original Message - 
>> From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
>> To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg"
>> <p.d.rosenb...@gmail.com>
>> Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
>> Sent: Thursday, December 15, 2016 12:35 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error
>>
>>
>>> On 2016-12-14 22:30-0500 Pedro Vicente wrote:
>>>
>>>> Hi Alan
>>>>
>>>> see my replies between your questions
>>>>
>>>>> This certainly qualifies as a release-critical wxwidgets bug.  And you
>>>>> have certainly supplied enough information that Phil should find this
>>>>> to be straightforward to reproduce.
>>>>
>>>> easy to reproduce on the PLplot code, but not immediatley obvious to

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

[Pedro Vicente]

Hi Alan, Phil

I forgot about a very simple fix that does need a custom function call 
(therefore a "real" fix, or better a non intrusive fix for users)

that is, right now, the code is responding to these 2 events

WXWINDOW::Connect( wxEVT_SIZE, wxSizeEventHandler( 
wxPLplotwindow::OnSize ) );
WXWINDOW::Connect( wxEVT_PAINT, wxPaintEventHandler( 
wxPLplotwindow::OnPaint ) );

so, it's just a matter of calling the OnCreate() stream on one

wxEVT_SIZE is a bad idea, because it's only called when the user moves the 
window
but I think wxEVT_PAINT is *continuously* called in a event loop (meaning 
always)

right now it even has some calls that are called there as a workaround


template
void wxPLplotwindow::OnPaint( wxPaintEvent ( event ) )
{
//Really this should be in the constructor, but it caused a segfault
//on at least one system (CentOS with intel compiler and wxWidgets 
2.8.12).
//Moving it here after WXWINDOW::Create has been called stops this and
//the call does nothing if the style is the same as previous calls so
//should be safe to call here.


the boolean flag

if ( !m_created )
{
//create the stream


makes it that it's only called 1 time

I'll try this tomorrow

-Pedro



- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 15, 2016 1:31 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


> Hi Alan
>
>> I think you will agree with me that smells like a workaround rather
>> than a fundamental fix.
>
> yes, I agree.
>
>>> Eventually, we had to change our
>>> minimum acceptable wxwidgets version from 2.8 to 3.0 because of one
>>> commit which only worked for 3.0.
>
> hhm, ok
> I have to double check this but the comments in your code say ::Bind() is
> only available
> for 3.0, and ::Bind()  is not used
>
> so probably the code as of now is compatible with 2.8 (meaning it only has
> 2.8 calls, not 3.0 calls)
>
>
>>>I would appreciate
>>> your thoughts on this matter of moving to pure 3.0.
>
> we could try the ::Bind()   route, yes, to see what happens
>
> another thing
> wxPLplotwindow.h is a header file
> we can try to move the implementation to a .ccp file (with templates there
> are some idiosyncrasies about the use of headers versus .cpp,
> that's why I never use templates)
>
>
>>>I would be willing to hold the release for you for a few
>>> extra days beyond December 27th
>
> that would be great, that should be enough to have a better idea.
> I have more time to work on this on the weekends only.
>
> -Pedro
>
>
> - Original Message - 
> From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
> To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg"
> <p.d.rosenb...@gmail.com>
> Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
> Sent: Thursday, December 15, 2016 12:35 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error
>
>
>> On 2016-12-14 22:30-0500 Pedro Vicente wrote:
>>
>>> Hi Alan
>>>
>>> see my replies between your questions
>>>
>>>> This certainly qualifies as a release-critical wxwidgets bug.  And you
>>>> have certainly supplied enough information that Phil should find this
>>>> to be straightforward to reproduce.
>>>
>>> easy to reproduce on the PLplot code, but not immediatley obvious to 
>>> find
>>> the root cause.
>>
>> Amen!
>>
>>>
>>> My speculation is that it happens because this function located in
>>> \bindings\wxwidgets\wxPLplotwindow.h
>>>
>>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
>>> {
>>>   if ( !m_created )
>>>
>>> is not automatically called in an wxwidgets event triggered by this code
>>> in wxPLplotDemo.cpp, the Create() call
>>>
>>> wxPLplotwindow *frame = new wxPLplotwindow();
>>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>
>>> this can be easily confirmed if you put a print statement here
>>>
>>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
>>> {
>>> wxLogDebug("wxPLplotwindow::OnCreate");
>>>   if ( !m_created )
>>>
>>> so, my solution is simple, it's just to specifically call the code that
>>> is inside
>&

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

[Pedro Vicente]

Hi Alan

> I think you will agree with me that smells like a workaround rather
> than a fundamental fix.

yes, I agree.

>> Eventually, we had to change our
>> minimum acceptable wxwidgets version from 2.8 to 3.0 because of one
>> commit which only worked for 3.0.

hhm, ok
I have to double check this but the comments in your code say ::Bind() is 
only available
for 3.0, and ::Bind()  is not used

so probably the code as of now is compatible with 2.8 (meaning it only has 
2.8 calls, not 3.0 calls)


>>I would appreciate
>> your thoughts on this matter of moving to pure 3.0.

we could try the ::Bind()   route, yes, to see what happens

another thing
wxPLplotwindow.h is a header file
we can try to move the implementation to a .ccp file (with templates there 
are some idiosyncrasies about the use of headers versus .cpp,
that's why I never use templates)


>>I would be willing to hold the release for you for a few
>> extra days beyond December 27th

that would be great, that should be enough to have a better idea.
I have more time to work on this on the weekends only.

-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Thursday, December 15, 2016 12:35 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


> On 2016-12-14 22:30-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> see my replies between your questions
>>
>>> This certainly qualifies as a release-critical wxwidgets bug.  And you
>>> have certainly supplied enough information that Phil should find this
>>> to be straightforward to reproduce.
>>
>> easy to reproduce on the PLplot code, but not immediatley obvious to find 
>> the root cause.
>
> Amen!
>
>>
>> My speculation is that it happens because this function located in 
>> \bindings\wxwidgets\wxPLplotwindow.h
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
>> {
>>   if ( !m_created )
>>
>> is not automatically called in an wxwidgets event triggered by this code 
>> in wxPLplotDemo.cpp, the Create() call
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>
>> this can be easily confirmed if you put a print statement here
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
>> {
>> wxLogDebug("wxPLplotwindow::OnCreate");
>>   if ( !m_created )
>>
>> so, my solution is simple, it's just to specifically call the code that 
>> is inside
>> void wxPLplotwindow::OnCreate
>>
>>
>> I did this by doing a function that I called CreatePLplotstream(), that 
>> contains the stream initialization code
>> that is in
>> wxPLplotwindow::OnCreate
>>
>>
>> so, in the demo code the call is now
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>> frame->CreatePLplotstream();
>
> I think you will agree with me that smells like a workaround rather
> than a fundamental fix.  Nevertheless, if you turn that change into a
> PLplot patch AND that solves the present build issue for all the Linux
> distros you have tried, and if it works here on Debian Jessie, then I
> will apply that patch as a temporary fix for the release which we can
> undo afterwards (or even before the release if we are lucky) with a
> more fundamental fix.
>
>>
>>> Do you see any use of (presumably deprecated) wxwidgets-2.x calls
>>> in our wxwidgets binding or device driver?  If so, that might be
>>> a good place to start to work on this issue.
>>
>>
>> not sure, I'll check
>>
>> events are explained here
>>
>> http://docs.wxwidgets.org/3.1/overview_events.html
>>
>> I always do a static event table in my code.
>> it's also possible to do a dynamic event (with ::Bind())
>> actually in the PLplot code this is done another way, that I am not sure 
>> about
>>
>> //We use connect instead of Bind for compatiblity with wxWidgets 2.8
>> //but should move to bind in the future.
>> WXWINDOW::Connect( wxEVT_CREATE, wxWindowCreateEventHandler( 
>> wxPLplotwindow::OnCreate ) );
>
> Implementing a fundamental fix for the current build issue is already
> way beyond my meager C++ and wxwidgets expertise, but I do have some
> sense of the overview that may help you.
>
>

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

[Pedro Vicente]

Hi Alan

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

I even put out 2 print statements in wxPLplotwindow.h,
one in the constructor, other in OnCreate, as I explained before.
the print in OnCreate() is *NOT* printed

this is from the output

00:47:42: Debug: wxPLplotwindow
wxPLplotDemo: /home/pvn/plplot-plplot/examples/c++/wxPLplotDemo.cpp:158: 
void Plot(wxPLplotwindow*) [with WXWINDOW = wxFrame]: Assertion 
`0' failed.

Aborted


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


https://www.virtualbox.org/wiki/Downloads

then I just did

sudo apt-get install libwxgtk3.0-dev
git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot

virtualbox is ideal to test this because we can have just a clean linux that 
can be easily installed and deleted


-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Pedro Vicente" 
<pedro.vice...@space-research.org>

Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Wednesday, December 14, 2016 7:16 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error



On 2016-12-14 18:00-0500 Pedro Vicente wrote:


Hi Alan


What happens if you try a Ubuntu platform with a system version
of wxwidgets version = 3.0.x?  Same question for a Ubuntu
platform with wxwidgets version = 3.1.x?


I was actually just going to do that  just now, so here it goes

lsb_release -a
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty


sudo apt-get install libwxgtk3.0-dev
git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
cd plplot-plplot
mkdir build
cd build
cmake ..  -G "Unix Makefiles"
-DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install
-DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF
-DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DBUILD_TEST=ON >&
cmake.ubuntu.txt &
make VERBOSE=1 test_wxPLplotDemo >& test_wxPLplotDemo.out.ubuntu.txt &


So you have the same bad result for system version of everything on
Ubuntu trusty including wxwidgets-3.0.x (except for Qt5 which should not 
matter here).


This certainly qualifies as a release-critical wxwidgets bug.  And you
have certainly supplied enough information that Phil should find this
to be straightforward to reproduce. So if I get a communication from
Phil that he is actively working on this, I will hold the PLplot
release past December 22 for this.  However, if he is out of e-mail
contact, I won't hold the release, and we will just have to live with
the fact that the fundamental wxwidgets binding just plain does not
work on most Linux distros, ugh!

Also, just in case any of those cmake options of yours were affecting the 
result I

just tried here

cmake -G "Unix 
Makefiles" -DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF 
 -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DBUILD_TEST=ON ../plplot.git 
 >& cmake.out


and

make test_wxPLplotDemo >& test_wxPLplotDemo.out

with the same (good) results.

N.B. I have attached those two files in compressed form so you can see
what is different between them and your results.  (Say if you get
failure there even on Debian Jessie.)


By looking at cmake.ubuntu.txt  it uses this GTK+

-- Checking for module 'gtk+-x11-2.0'
--   Found gtk+-x11-2.0, version 2.24.27

so, exactly the same as my CentOS, if that matters


The corresponding output here is

-- Checking for module 'gtk+-x11-2.0'
--   Found gtk+-x11-2.0, version 2.24.25

So you are two patch-versions later with GTK+ which I doubt
matters much at all.


I also have another 16.04 ubuntu , I will try that next

also, you mentioned that on Debian Jessie it's OK.
so i'll try to install that or a recent Fedora on a VirtualBox to see


That's a good idea to at least make sure you can reproduce my good
result on Debian Jessie.  If you can do that, but get bad results for
every other distro, I would begin to wonder what magic and secret
elixir the Debian Jessie packagers applied to wxwidgets and GTK+ to
get them to work properly together? :-)

Seriously, Phil's new wxwidgets binding and device driver first
started life as a wxwidgets-2.x software if I recall correctly. So it is 
possible that

Debian Jessie has maintained better wxwidgets-2 compatibility in their
wxwidgets-3 libraries than other distros. In which case to solve this,
Phil would have to figure out how to modernize the wxwidgets binding
and device driver so it does not rely on any wxwidgets-2.x capability
at all.

Do you see any use of (presumably deprecated) wxwidgets-2.x calls
in our wxwidgets binding or device driver?  If so, that might be
a good place to s

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

[Pedro Vicente]

Hi Alan

see my replies between your questions

> This certainly qualifies as a release-critical wxwidgets bug.  And you
> have certainly supplied enough information that Phil should find this
> to be straightforward to reproduce.

easy to reproduce on the PLplot code, but not immediatley obvious to find 
the root cause.

My speculation is that it happens because this function located in 
\bindings\wxwidgets\wxPLplotwindow.h

void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
{
if ( !m_created )

is not automatically called in an wxwidgets event triggered by this code in 
wxPLplotDemo.cpp, the Create() call

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

this can be easily confirmed if you put a print statement here

void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
{
  wxLogDebug("wxPLplotwindow::OnCreate");
if ( !m_created )

so, my solution is simple, it's just to specifically call the code that is 
inside
void wxPLplotwindow::OnCreate


I did this by doing a function that I called CreatePLplotstream(), that 
contains the stream initialization code
that is in
wxPLplotwindow::OnCreate


so, in the demo code the call is now

wxPLplotwindow *frame = new wxPLplotwindow();
frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
frame->CreatePLplotstream();

> Do you see any use of (presumably deprecated) wxwidgets-2.x calls
> in our wxwidgets binding or device driver?  If so, that might be
> a good place to start to work on this issue.


not sure, I'll check

events are explained here

http://docs.wxwidgets.org/3.1/overview_events.html

I always do a static event table in my code.
it's also possible to do a dynamic event (with ::Bind())
actually in the PLplot code this is done another way, that I am not sure 
about

//We use connect instead of Bind for compatiblity with wxWidgets 2.8
//but should move to bind in the future.
WXWINDOW::Connect( wxEVT_CREATE, wxWindowCreateEventHandler( 
wxPLplotwindow::OnCreate ) );


-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Pedro Vicente" 
<pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Wednesday, December 14, 2016 7:16 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error


> On 2016-12-14 18:00-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>>> What happens if you try a Ubuntu platform with a system version
>>> of wxwidgets version = 3.0.x?  Same question for a Ubuntu
>>> platform with wxwidgets version = 3.1.x?
>>
>> I was actually just going to do that  just now, so here it goes
>>
>> lsb_release -a
>> Description: Ubuntu 14.04.5 LTS
>> Release: 14.04
>> Codename: trusty
>>
>>
>> sudo apt-get install libwxgtk3.0-dev
>> git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
>> cd plplot-plplot
>> mkdir build
>> cd build
>> cmake ..  -G "Unix Makefiles"
>> -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install
>> -DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF
>> -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DBUILD_TEST=ON >&
>> cmake.ubuntu.txt &
>> make VERBOSE=1 test_wxPLplotDemo >& test_wxPLplotDemo.out.ubuntu.txt &
>
> So you have the same bad result for system version of everything on
> Ubuntu trusty including wxwidgets-3.0.x (except for Qt5 which should not 
> matter here).
>
> This certainly qualifies as a release-critical wxwidgets bug.  And you
> have certainly supplied enough information that Phil should find this
> to be straightforward to reproduce. So if I get a communication from
> Phil that he is actively working on this, I will hold the PLplot
> release past December 22 for this.  However, if he is out of e-mail
> contact, I won't hold the release, and we will just have to live with
> the fact that the fundamental wxwidgets binding just plain does not
> work on most Linux distros, ugh!
>
> Also, just in case any of those cmake options of yours were affecting the 
> result I
> just tried here
>
> cmake -G "Unix 
> Makefiles" -DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS:BOOL=OFF 
> -DENABLE_f95:BOOL=OFF 
>  -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DBUILD_TEST=ON ../plplot.git 
>  >& cmake.out
>
> and
>
> make test_wxPLplotDemo >& test_wxPLplotDemo.out
>
> with the same (good) results.
>
> N.B. I have attached those two files in compressed form so you can see
> what is different between them and your results.  (Say if you get
> failure there even on 

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

[Pedro Vicente]

Hi Alan

Results for

lsb_release -a
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial

sudo apt-get install libwxgtk3.0-dev

cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/plplot-install -DCMAKE_BUILD_TYPE=Debug 
-DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF 
-DBUILD_TEST=ON >& cmake.ubuntu.16.04.txt &


make VERBOSE=1 test_wxPLplotDemo >& test_wxPLplotDemo.out.ubuntu.16.04.txt &

files are attached, the same happens


-Pedro




- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>

To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Wednesday, December 14, 2016 6:00 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error



Hi Alan


What happens if you try a Ubuntu platform with a system version
of wxwidgets version = 3.0.x?  Same question for a Ubuntu
platform with wxwidgets version = 3.1.x?


I was actually just going to do that  just now, so here it goes

lsb_release -a
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty


sudo apt-get install libwxgtk3.0-dev
git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
cd plplot-plplot
mkdir build
cd build
cmake ..  -G "Unix
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install 
-DCMAKE_BUILD_TYPE=Debug
-DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF 
-DENABLE_tk:BOOL=OFF
-DBUILD_TEST=ON >& cmake.ubuntu.txt &
make VERBOSE=1 test_wxPLplotDemo >& test_wxPLplotDemo.out.ubuntu.txt &

and the output files are attached


By looking at cmake.ubuntu.txt  it uses this GTK+

-- Checking for module 'gtk+-x11-2.0'
--   Found gtk+-x11-2.0, version 2.24.27

so, exactly the same as my CentOS, if that matters


I also have another 16.04 ubuntu , I will try that next

also, you mentioned that on Debian Jessie it's OK.
so i'll try to install that or a recent Fedora on a VirtualBox to see


> Building wxwidgets is tricky (e.g., I have had some rather peculiar

results for wxwidgets versions I built myself)


I never have any problems

I always do what says here

https://wiki.wxwidgets.org/Compiling_and_getting_started

cd /path/to/wxWidgets-3.0.x # adapt path as needed
mkdir gtk-build # or any other name you fancy
cd gtk-build
../configure --prefix=/my/path --enable-debug --disable-shared

I try as much as possible to use static and debug builds, it's always less
problems down the road, specially if you are distributing binaries


-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Wednesday, December 14, 2016 5:39 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error



On 2016-12-14 15:30-0500 Pedro Vicente wrote:


Hi Alan



Can you confirm that is the case for
unmodified PLplot from the tip of the git master branch?


Yes, it is the unmodified PLplot from the tip of the git master branch
cloned today.
I only added this line
assert(pls)
in wxPLplotDemo.cpp, which you can see in the output


Hi Pedro:

Thanks very much for that bug report.  This is where you should report
such issues unless or until it turns out we cannot solve them in a
timely manner (in which case you should use the bugtracker to remind
us of the issue in the future).

Your cmake.out looks fine to me (although you should double-check all
of that wxwidgets-related and GTK+-related output for library
consistency).

And obviously from your test_wxPLplotDemo.out file, building
wxPLplotDemo failed right where you inserted the above assert
statement (from the output somewhere in void
Plot(wxPLplotwindow*) presumably after the

wxPLplotstream* pls = plotwindow->GetStream();

statement).

And clearly pls has to be nonnegative if the above assigment succeeded.

However, a potential issue is it appears you are using a wxwidgets
version that you built yourself.

What happens if you try a Ubuntu platform with a system version
of wxwidgets version = 3.0.x?  Same question for a Ubuntu
platform with wxwidgets version = 3.1.x?

Building wxwidgets is tricky (e.g., I have had some rather peculiar
results for wxwidgets versions I built myself) so I doubt I am going
to delay the release for this issue unless you can give me a bug
report (same cmake.out and test_wxPLplotDemo.out files requested) for
a system version of wxwidgets.

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

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

[Pedro Vicente]

Hi Alan


What happens if you try a Ubuntu platform with a system version
of wxwidgets version = 3.0.x?  Same question for a Ubuntu
platform with wxwidgets version = 3.1.x?


I was actually just going to do that  just now, so here it goes

lsb_release -a
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty


sudo apt-get install libwxgtk3.0-dev
git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
cd plplot-plplot
mkdir build
cd build
cmake ..  -G "Unix 
Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/pvicente/plplot-install -DCMAKE_BUILD_TYPE=Debug 
-DBUILD_SHARED_LIBS:BOOL=OFF -DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF 
-DBUILD_TEST=ON >& cmake.ubuntu.txt &

make VERBOSE=1 test_wxPLplotDemo >& test_wxPLplotDemo.out.ubuntu.txt &

and the output files are attached


By looking at cmake.ubuntu.txt  it uses this GTK+

-- Checking for module 'gtk+-x11-2.0'
--   Found gtk+-x11-2.0, version 2.24.27

so, exactly the same as my CentOS, if that matters


I also have another 16.04 ubuntu , I will try that next

also, you mentioned that on Debian Jessie it's OK.
so i'll try to install that or a recent Fedora on a VirtualBox to see


> Building wxwidgets is tricky (e.g., I have had some rather peculiar

results for wxwidgets versions I built myself)


I never have any problems

I always do what says here

https://wiki.wxwidgets.org/Compiling_and_getting_started

cd /path/to/wxWidgets-3.0.x # adapt path as needed
mkdir gtk-build # or any other name you fancy
cd gtk-build
../configure --prefix=/my/path --enable-debug --disable-shared

I try as much as possible to use static and debug builds, it's always less 
problems down the road, specially if you are distributing binaries



-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Wednesday, December 14, 2016 5:39 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp -- linux build error



On 2016-12-14 15:30-0500 Pedro Vicente wrote:


Hi Alan



Can you confirm that is the case for
unmodified PLplot from the tip of the git master branch?


Yes, it is the unmodified PLplot from the tip of the git master branch 
cloned today.

I only added this line
assert(pls)
in wxPLplotDemo.cpp, which you can see in the output


Hi Pedro:

Thanks very much for that bug report.  This is where you should report
such issues unless or until it turns out we cannot solve them in a
timely manner (in which case you should use the bugtracker to remind
us of the issue in the future).

Your cmake.out looks fine to me (although you should double-check all
of that wxwidgets-related and GTK+-related output for library
consistency).

And obviously from your test_wxPLplotDemo.out file, building
wxPLplotDemo failed right where you inserted the above assert
statement (from the output somewhere in void
Plot(wxPLplotwindow*) presumably after the

wxPLplotstream* pls = plotwindow->GetStream();

statement).

And clearly pls has to be nonnegative if the above assigment succeeded.

However, a potential issue is it appears you are using a wxwidgets
version that you built yourself.

What happens if you try a Ubuntu platform with a system version
of wxwidgets version = 3.0.x?  Same question for a Ubuntu
platform with wxwidgets version = 3.1.x?

Building wxwidgets is tricky (e.g., I have had some rather peculiar
results for wxwidgets versions I built myself) so I doubt I am going
to delay the release for this issue unless you can give me a bug
report (same cmake.out and test_wxPLplotDemo.out files requested) for
a system version of wxwidgets.

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
__


-- The C compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMake version = 3.7.1
-- CMAKE_SYSTEM_NAME = Linux
-- SH_EXECUTABLE = /bin/bash
-- Checking whether system has ANSI C header files
-- Looking for 4 include files stdlib.h, ..., float.h
-- Looking for 4 include files stdlib.h, ..., float.h - found
-- Performing Test memchrExists
-- Performing T

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

[Pedro Vicente]

Hi Alan



Can you confirm that is the case for
unmodified PLplot from the tip of the git master branch?


Yes, it is the unmodified PLplot from the tip of the git master branch 
cloned today.

I only added this line
assert(pls)
in wxPLplotDemo.cpp, which you can see in the output


here on Debian Jessie with
the GTK+ version of wxwidgets-3.0.2


it could be the GTK+ version, yes.
In this case, I think the wxwidgets version does not matter, since it 
picks whatever GTK+ it finds.


This can be checked on Debian with
rpm -qa | grep -i gtk2

and it shows on my CentOS 6.8

gtk2-devel-2.24.23-8.el6.x86_64

I also tried in
Ubuntu 16.04 i386
Ubuntu 14.04 x86_64

and the same happens (don't know which GTK+ they have)
these 2 above I just used the wxwidgets libraries from packages


the only way I was able to solve this to use PLplot/wxwidgets in my 
code was to do a custom
wxwidgets window that does not use wxPLplotwindow (the class used by 
the demo)


this code is here

https://github.com/pedro-vicente/plplot-wxwidgets

and the way to avoid the bug is just to explicitally call the stream 
creation code with a function call,

named CreatePLplotstream()
(that as of now is supposed to be automatically called in the wxWidgets 
window OnCreate(),

but apparently it is not)

my use is

wx_PLplotFrame_stream *frame = new wx_PLplotFrame_stream();
  frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
wxDefaultPosition,
wxSize(900, 700));
  frame->CreatePLplotstream();
  frame->Show();
  wx_PLplotstream* pls = frame->GetStream();
  assert(pls);


to submit a proper bug report to us with complete cmake output


is there a place to submit bug reports?
or just send here by email?
The output is attached

-Pedro




On 2016-12-14 14:47, Alan W. Irwin wrote:

On 2016-12-14 11:47-0500 Pedro Vicente wrote:


Hi Phil

I am using the attached qt project file on my CentOS 6.8 build, 
adapted to build

examples/c++/wxPLplotDemo.cpp

to use, place the file in
examples/c++

just change these lines for your own case

dir_inc_plplot = 
/data/home002/pvicente/plplot-plplot-install/include/plplot

dir_lib_plplot = /data/home002/pvicente/plplot-plplot-install/lib
dir_inc_wx = 
/data/data127/pvicente/install/wxwidgets-3.1.0d/include/wx-3.1
dir_inc_wx_setup = 
/data/data127/pvicente/install/wxwidgets-3.1.0d/lib/wx/include/gtk2-unicode-static-3.1

dir_lib_wx = /data/data127/pvicente/install/wxwidgets-3.1.0d/lib

in QtCreator change in Projects/Run, disable the  the "Run in 
Terminal"


this is the stack on the window creation as shown in QtCreator


0   wxWindow::PostCreation  window.cpp  27530x4d9ea4
1   wxTopLevelWindowGTK::Create toplevel.cpp674 0x4cdb79
2   wxFrame::Create frame.cpp   48  0x4e672b
3   MyApp::OnInit   wxPLplotDemo.cpp148 0x4259d8
4   wxAppConsoleBase::CallOnInitapp.h   93  0x426c23
5   wxEntry init.cpp487 0x6bf36d
6   wxEntry init.cpp515 0x6bf475
7   mainwxPLplotDemo.cpp131 0x4258a4


As opposed to the wxWidgets Windows build, that uses the WIN32 API, 
for linux it's a totally different API (GTK),

so the issue may be a wxWidgets GTK code thing


Hi Pedro:

Just to interject here, my impression of this thread is you have
mostly been discussing issues with your own software, but now it
appears you finding issues with the git version of wxPLplotDemo 
rather

than your own software.  Can you confirm that is the case for
unmodified PLplot from the tip of the git master branch?  Because if
so, that would be quite interesting because here on Debian Jessie 
with

the GTK+ version of wxwidgets-3.0.2 installed, when I build the
test_wxPLplotDemo target, the wxPLplotDemo GUI builds and runs with
absolutely no issues.

If you really do have some build or run-time issue there with
wxPLplotDemo for _unmodified_ PLplot, then my advice is to submit a
proper bug report to
us with complete cmake output from an initially empty build tree
captured in the usual way, i.e.,

cmake   >& 
cmake.out


_where those options include using the "Unix Makefiles" generator_.  
Then

run

make VERBOSE=1 test_wxPLplotDemo >& test_wxPLplotDemo.out

and submit both cmake.out and test_wxPLplotDemo.out here.

It may be that your issue is simply that the PLplot wxwidgets-related
code is not compatible with the GTK+ version of wxwidgets you have
installed on your Linux platforms, i.e., your GTK+ version of
wxwidgets may be too old (which we can see from your cmake.out file)
or too new.  In the latter case I assume iPhil will eventually be 
able to
replicate your issue with that same GTK+ version of wxwidgets and 
then

fix whatever that incompatibility is.

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-st

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

[Pedro Vicente]

Hi Phil

I am using the attached qt project file on my CentOS 6.8 build, adapted 
to build

examples/c++/wxPLplotDemo.cpp

to use, place the file in
examples/c++

just change these lines for your own case

dir_inc_plplot = 
/data/home002/pvicente/plplot-plplot-install/include/plplot

 dir_lib_plplot = /data/home002/pvicente/plplot-plplot-install/lib
 dir_inc_wx = 
/data/data127/pvicente/install/wxwidgets-3.1.0d/include/wx-3.1
 dir_inc_wx_setup = 
/data/data127/pvicente/install/wxwidgets-3.1.0d/lib/wx/include/gtk2-unicode-static-3.1

 dir_lib_wx = /data/data127/pvicente/install/wxwidgets-3.1.0d/lib

in QtCreator change in Projects/Run, disable the  the "Run in Terminal"

this is the stack on the window creation as shown in QtCreator


0   wxWindow::PostCreation  window.cpp  27530x4d9ea4
1   wxTopLevelWindowGTK::Create toplevel.cpp674 0x4cdb79
2   wxFrame::Create frame.cpp   48  0x4e672b
3   MyApp::OnInit   wxPLplotDemo.cpp148 0x4259d8
4   wxAppConsoleBase::CallOnInitapp.h   93  0x426c23
5   wxEntry init.cpp487 0x6bf36d
6   wxEntry init.cpp515 0x6bf475
7   mainwxPLplotDemo.cpp131 0x4258a4


As opposed to the wxWidgets Windows build, that uses the WIN32 API, for 
linux it's a totally different API (GTK),

so the issue may be a wxWidgets GTK code thing

-Pedro

On 2016-12-14 10:59, Pedro Vicente wrote:

Hi Phil

Were you able to reproduce the error I get on my linux builds of
wxPLplotDemo?

I just did a git clone of the last plplot and I still get the error

see my last email from today, there are instructions on how to debug
with Qt

project here


https://github.com/pedro-vicente/plplot-wxwidgets/blob/master/wx_plplot/wx_plplot.qt.ubuntu.x86_64.pro

then install QtCreator

https://www.qt.io/download-open-source/#section-2

and use the file wx_plplot.qt.ubuntu.x86_64.pro

what I did

git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot

then I edited the file examples/c++/wxPLplotDemo.cpp and added this
assert here

wxPLplotstream* pls = plotwindow->GetStream();
assert(pls);

just to make sure this is the issue.
then

cd plplot-plplot
cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF
-DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF
-DBUILD_TEST:BOOL=ON >& cmake2.txt &
make >& make2.txt &
cd examples/c++/
./wxPLplotDemo
wxPLplotDemo:

/data/home002/pvicente/plplot-plplot/examples/c++/wxPLplotDemo.cpp:158:
void Plot(wxPLplotwindow*) [with WXWINDOW = wxFrame]:
Assertion `pls' failed.
Aborted




On 2016-12-10 03:57, Phil Rosenberg wrote:

Hi Pedro
I have included the devel list on this email, so the thread will get
documented on the mailing list.

It is very strange that the OnCreate function is not being called. 
If

you are calling Create then you should be generating a create event.
Am I correct in saying that you are getting this segfault with the
unchanged demo app?

This location really is the best (and maybe only) place this
initialisation should be done. It cannot be included in the
constructor, because the generic nature of the template 
specification

means the code in the constructor does not know which type of
wxWindow
we are inheriting from so cannot pass the correct parameters to the
constructor. By the time OnPaint is called it is really too late,
because we would like to already have the plot initialised and ready
to draw and it would be a real pain for you in your code if you had
to
somehow wait for the first paint or resize event.

I do have access to a CentOS machine at work, although I think I 
have

only got access to wxWidgets 2.8 on that system. I will check. I may
be able to build 3.1 from source. I presume you are using 3.1.0 as
released in February, rather than the head of the master branch?

On 10 December 2016 at 07:52, Pedro Vicente
<pedro.vice...@space-research.org> wrote:

Hi Phil

My idea for a fix is to move the stream initialization that is now
on

void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
{
if ( !m_created )

either to the OnSize or onPaint events

void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event
) )

and also in the plot call do this

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

   if (pls == NULL)
   {
 return;
   }


Like this , in this sequence


wxPLplotwindow *frame = new wxPLplotwindow();
   frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
   frame->SetIcon( wxIcon( graph ) );
   frame->Show();
   Plot( frame );


first we go to
Plot( frame );

but the stream is NULL because
:OnCreate
was not called, but the function returns, avoiding the seg fault

then the window gets a paint or size event, and the stream
initialization
code is called
at this time I have a PLplot empty black window

but because
Plot( frame );
was only called

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

[Pedro Vicente]

Hi Phil

Were you able to reproduce the error I get on my linux builds of 
wxPLplotDemo?

I just did a git clone of the last plplot and I still get the error

see my last email from today, there are instructions on how to debug 
with Qt

project here

https://github.com/pedro-vicente/plplot-wxwidgets/blob/master/wx_plplot/wx_plplot.qt.ubuntu.x86_64.pro

then install QtCreator

https://www.qt.io/download-open-source/#section-2

and use the file wx_plplot.qt.ubuntu.x86_64.pro

what I did

git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot

then I edited the file examples/c++/wxPLplotDemo.cpp and added this 
assert here

wxPLplotstream* pls = plotwindow->GetStream();
assert(pls);

just to make sure this is the issue.
then

cd plplot-plplot
cmake ..  -G "Unix Makefiles" -DBUILD_SHARED_LIBS:BOOL=OFF 
-DENABLE_f95:BOOL=OFF -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF 
-DBUILD_TEST:BOOL=ON >& cmake2.txt &
make >& make2.txt &
cd examples/c++/
./wxPLplotDemo
wxPLplotDemo: 
/data/home002/pvicente/plplot-plplot/examples/c++/wxPLplotDemo.cpp:158: 
void Plot(wxPLplotwindow*) [with WXWINDOW = wxFrame]: 
Assertion `pls' failed.
Aborted




On 2016-12-10 03:57, Phil Rosenberg wrote:
> Hi Pedro
> I have included the devel list on this email, so the thread will get
> documented on the mailing list.
>
> It is very strange that the OnCreate function is not being called. If
> you are calling Create then you should be generating a create event.
> Am I correct in saying that you are getting this segfault with the
> unchanged demo app?
>
> This location really is the best (and maybe only) place this
> initialisation should be done. It cannot be included in the
> constructor, because the generic nature of the template specification
> means the code in the constructor does not know which type of 
> wxWindow
> we are inheriting from so cannot pass the correct parameters to the
> constructor. By the time OnPaint is called it is really too late,
> because we would like to already have the plot initialised and ready
> to draw and it would be a real pain for you in your code if you had 
> to
> somehow wait for the first paint or resize event.
>
> I do have access to a CentOS machine at work, although I think I have
> only got access to wxWidgets 2.8 on that system. I will check. I may
> be able to build 3.1 from source. I presume you are using 3.1.0 as
> released in February, rather than the head of the master branch?
>
> On 10 December 2016 at 07:52, Pedro Vicente
> <pedro.vice...@space-research.org> wrote:
>> Hi Phil
>>
>> My idea for a fix is to move the stream initialization that is now  
>> on
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
>> {
>> if ( !m_created )
>>
>> either to the OnSize or onPaint events
>>
>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event 
>> ) )
>>
>> and also in the plot call do this
>>
>> template< class WXWINDOW >
>> void Plot( wxPLplotwindow *plotwindow )
>> {
>>wxPLplotstream* pls = plotwindow->GetStream();
>>
>>if (pls == NULL)
>>{
>>  return;
>>}
>>
>>
>> Like this , in this sequence
>>
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>frame->SetIcon( wxIcon( graph ) );
>>frame->Show();
>>Plot( frame );
>>
>>
>> first we go to
>> Plot( frame );
>>
>> but the stream is NULL because
>> :OnCreate
>> was not called, but the function returns, avoiding the seg fault
>>
>> then the window gets a paint or size event, and the stream 
>> initialization
>> code is called
>> at this time I have a PLplot empty black window
>>
>> but because
>> Plot( frame );
>> was only called at start, it is not called again, so there is no 
>> draw
>>
>> any ideas here ?
>>
>> of course making the Plot() call in another app function should work
>>
>>
>> If you could replicate this issue, that would be great.
>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>
>>
>>
>>
>>
>> - Original Message - From: Pedro Vicente
>> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
>> Sent: Saturday, December 10, 2016 12:59 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>
>>
>> Hi Phil
>>
>> So, the issue seems to be the same that I have been reporting
>>
>>
>> In the wxPLplotDemo.cpp code you have these callling functions
>>
>>
>> wxPLplotwindow *

Re: [Plplot-devel] Freeze and release dates now much better determined

[Pedro Vicente]

Hi Alan

>>spend an hour or so inserting write statments until I finally 
>> identify
>>the Linux system call that is causing the long pause.

debugging with write statements is for me the last option.
it's ok for small bits of our own code, but in cases where you need to 
go deep into third
party libraries's code it's no fun.

when I found the  linux wxwidgets bug I reported last week, I wrote
a Qt project that allows to debug PLplot and wxWidgets

it's here

https://github.com/pedro-vicente/plplot-wxwidgets/blob/master/wx_plplot/wx_plplot.qt.ubuntu.x86_64.pro

this project is hardcoded for Ubuntu 14.04 x86_64

to adapt to other linux and PLplot/wxWidgets installations, just 
replace these locations

dir_inc_plplot = /usr/local/include/plplot
  dir_lib_plplot = /usr/local/lib
  dir_inc_wx = /usr/include/wx-3.0
  dir_inc_wx_gtk = /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0
dir_lib_wx = /usr/local/lib

and then do

wx-config --cxxflags

the output is like this

-I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-pthread

so, replace here

DEFINES += _FILE_OFFSET_BITS=64
DEFINES += WXUSINGDLL

and the same for

wx-config --libs

on the LIBS part

then build all libraries with -g

-Pedro



On 2016-12-14 04:28, Alan W. Irwin wrote:
> Short story: freeze deadline now chiselled in stone as December 17th.
> But that is just for intrusive fixes, and small bug fixes and large
> or small documentation updates can continue through to the day
> of the release which might be only 5 days later, December 22nd (if
> our further
> comprehensive testing doesn't turn up any release critical issues) or
> 10 days later
> December 27th if there are some release-critical issues to address.
>
> Longer story with remarks relevant to Phil's current bug hunt at the 
> end:
>
> For quite some time I have been working (off and on) on a high impact
> topic branch where I am attempting to restore const correctness to 
> our
> PLplot code.  That topic branch is high impact because there will be 
> a
> backwards incompatibility introduced for most of our generic pointer
> use [which will effectively change from void * to const void *].
> Several days ago I finally realized it was hopeless to get this topic
> matured enough for the present release so I am putting off merging
> this topic to master until early in the next release cycle.  At the
> same time I managed to copy the updated include/plplot.h for this
> topic branch (which defines some additional useful self-documenting
> PLplot typedef additions) to the master branch with one typedef 
> change
> to retain backwards compatibility for now.  There were excellent
> results for that superficially intrusive change using unconstrained
> comprehensive testing with CMake-3.7.0.  Today I followed up with a
> similar excellent results for unconstrained comprehensive testing
> using CMake-3.0.2.  (See
> 
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> for the summary of these recent tests, and
> <http://my.cdash.org/index.php?project=PLplot_git> for the ctest
> subset of these results for the CMake-3.0.2 test.
>
> So I now have nearly the total range of CMake versions that we accept
> for Linux covered by excellent comprehensive test results of our git
> master tip, and for non-Linux systems where the minimum version of
> CMake that we accept is 3.6.2, I am hoping for similar good results
> for Arjen on Cygwin (latest CMake version there is currently 3.6.2)
> and MinGW-w64/MSYS2 (latest CMake version there is currently 3.7.0). 
> I
> also hope that someone here with access to Mac OS X will try
> comprehensive testing on that platform with needed open-source
> libraries from one of Fink, MacPorts, or HomeBrew (all of whom 
> provide
> CMake-3.7.0 or 3.7.1) to make at least one of those platforms as well
> supported as Linux or the above two Windows platforms.
>
> But regardless of the response I get on my request for comprehensive
> testing I am already done with my own comprehensive testing.  Thus, I
> am in a mode where I plan to pick off just small bug issues and work
> on my topic branch consisting of a large update to our documentation
> that I plan to merge to master tip some time shortly before the
> release.
>
> So as far as I am concerned, because of the above decision to put off
> working on the const correctness topic, I am already in post-freeze
> mode (where only small bug fixes and/or large documentation updates
> are acceptable for merging to master) and even beyond comprehensive
> testing mode.  Of course, the formal date of the freeze still remains
> December 17th to accomodate Phil if he has any chance at all of
> tracking down and fixi

Re: [Plplot-devel] wxPLplotDemo.cpp errors - FIXED , with workaround

[Pedro Vicente]

Hi Phil

Here's the fix I did for the linux wxwidgets driver bug

https://github.com/pedro-vicente/plplot-wxwidgets


these are the comments I added in the code



// Modified from PLplot Copyright (C) 2015  Phil Rosenberg
// Changes:
// A non templated class derived from wxFrame
// Use of events by wxDECLARE_EVENT_TABLE()
// Explicit call to CreatePLplotstream() after Create()
//wx_PLplotFrame_stream *frame = new wx_PLplotFrame_stream();
//frame->Create(...);
//frame->CreatePLplotstream();
//frame->Show();

one thing that caught my attention in your code was this way of handling 
events

WXWINDOW::Connect( wxEVT_SIZE, wxSizeEventHandler( 
wxPLplotwindow::OnSize ) );

I usually do a static event table, in fact all the wxWidgets samples do the 
same, except
for some thread related code

but even using the static event table in your code, the bug still was there.
so the only way was to do an explicit call to

frame->CreatePLplotstream();

let me know if you have any questions
-Pedro


- Original Message ----- 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; 
<plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 10, 2016 11:25 PM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors - FIXED , with 
workaround


> Hi Phil
>
> There is actually a very simple solution.
> Instead of figuring out why the OnCreate event is not triggered in some
> linux cases, you can explicitally call that code with some function.
>
> I did just that, like this, where
> frame->CreatePLplotstream();
>
> is a function that contains your code that is in OnCreate()
>
> this makes it needed to a user to call this extra function, but well, you
> can't win them all
>
> this code below makes a plot in Windows and Linux
>
> Note:
> I did my own class
> wx_PLplotFrame
>
> that is virtually identical to wxPLplotwindow, but not templated
>
> I'll put this code in github when I have a chance later
>
> bool wxAppPlot::OnInit()
> {
>  wx_PLplotFrame *frame = new wx_PLplotFrame();
>  frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
>wxDefaultPosition,
>wxSize(900, 700));
>  frame->CreatePLplotstream();
>  frame->Show();
>  wxPLplotstream* pls = frame->GetStream();
>  assert(pls);
>  PLFLT x[4] = { 1, 2, 3, 4 };
>  PLFLT y[4] = { 1, 2, 3, 4 };
>  pls->env(0, 5, 0, 5, 0, 0);
>  pls->line(4, x, y);
>  return true;
> }
>
> -Pedro
>
>
> - Original Message - 
> From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
> To: "Pedro Vicente" <pedro.vice...@space-research.org>;
> <plplot-devel@lists.sourceforge.net>
> Sent: Saturday, December 10, 2016 3:57 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
>> Hi Pedro
>> I have included the devel list on this email, so the thread will get
>> documented on the mailing list.
>>
>> It is very strange that the OnCreate function is not being called. If
>> you are calling Create then you should be generating a create event.
>> Am I correct in saying that you are getting this segfault with the
>> unchanged demo app?
>>
>> This location really is the best (and maybe only) place this
>> initialisation should be done. It cannot be included in the
>> constructor, because the generic nature of the template specification
>> means the code in the constructor does not know which type of wxWindow
>> we are inheriting from so cannot pass the correct parameters to the
>> constructor. By the time OnPaint is called it is really too late,
>> because we would like to already have the plot initialised and ready
>> to draw and it would be a real pain for you in your code if you had to
>> somehow wait for the first paint or resize event.
>>
>> I do have access to a CentOS machine at work, although I think I have
>> only got access to wxWidgets 2.8 on that system. I will check. I may
>> be able to build 3.1 from source. I presume you are using 3.1.0 as
>> released in February, rather than the head of the master branch?
>>
>> On 10 December 2016 at 07:52, Pedro Vicente
>> <pedro.vice...@space-research.org> wrote:
>>> Hi Phil
>>>
>>> My idea for a fix is to move the stream initialization that is now  on
>>>
>>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
>>> {
>>> if ( !m_created )
>>>
>>> either to the OnSize or onPaint events
>>>
>>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>>
>>> and also in the plot call do this
>>>
>>> template< class WXWINDOW >

Re: [Plplot-devel] wxPLplotDemo.cpp errors - FIXED , with workaround

[Pedro Vicente]

Hi Phil

There is actually a very simple solution.
Instead of figuring out why the OnCreate event is not triggered in some 
linux cases, you can explicitally call that code with some function.

I did just that, like this, where
 frame->CreatePLplotstream();

is a function that contains your code that is in OnCreate()

this makes it needed to a user to call this extra function, but well, you 
can't win them all

this code below makes a plot in Windows and Linux

Note:
I did my own class
wx_PLplotFrame

that is virtually identical to wxPLplotwindow, but not templated

I'll put this code in github when I have a chance later

bool wxAppPlot::OnInit()
{
  wx_PLplotFrame *frame = new wx_PLplotFrame();
  frame->Create(NULL, wxID_ANY, wxT("wxPLplot"),
wxDefaultPosition,
wxSize(900, 700));
  frame->CreatePLplotstream();
  frame->Show();
  wxPLplotstream* pls = frame->GetStream();
  assert(pls);
  PLFLT x[4] = { 1, 2, 3, 4 };
  PLFLT y[4] = { 1, 2, 3, 4 };
  pls->env(0, 5, 0, 5, 0, 0);
  pls->line(4, x, y);
  return true;
}

-Pedro


- Original Message - 
From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; 
<plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 10, 2016 3:57 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors


> Hi Pedro
> I have included the devel list on this email, so the thread will get
> documented on the mailing list.
>
> It is very strange that the OnCreate function is not being called. If
> you are calling Create then you should be generating a create event.
> Am I correct in saying that you are getting this segfault with the
> unchanged demo app?
>
> This location really is the best (and maybe only) place this
> initialisation should be done. It cannot be included in the
> constructor, because the generic nature of the template specification
> means the code in the constructor does not know which type of wxWindow
> we are inheriting from so cannot pass the correct parameters to the
> constructor. By the time OnPaint is called it is really too late,
> because we would like to already have the plot initialised and ready
> to draw and it would be a real pain for you in your code if you had to
> somehow wait for the first paint or resize event.
>
> I do have access to a CentOS machine at work, although I think I have
> only got access to wxWidgets 2.8 on that system. I will check. I may
> be able to build 3.1 from source. I presume you are using 3.1.0 as
> released in February, rather than the head of the master branch?
>
> On 10 December 2016 at 07:52, Pedro Vicente
> <pedro.vice...@space-research.org> wrote:
>> Hi Phil
>>
>> My idea for a fix is to move the stream initialization that is now  on
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
>> {
>> if ( !m_created )
>>
>> either to the OnSize or onPaint events
>>
>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>
>> and also in the plot call do this
>>
>> template< class WXWINDOW >
>> void Plot( wxPLplotwindow *plotwindow )
>> {
>>wxPLplotstream* pls = plotwindow->GetStream();
>>
>>if (pls == NULL)
>>{
>>  return;
>>}
>>
>>
>> Like this , in this sequence
>>
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>frame->SetIcon( wxIcon( graph ) );
>>frame->Show();
>>Plot( frame );
>>
>>
>> first we go to
>> Plot( frame );
>>
>> but the stream is NULL because
>> :OnCreate
>> was not called, but the function returns, avoiding the seg fault
>>
>> then the window gets a paint or size event, and the stream initialization
>> code is called
>> at this time I have a PLplot empty black window
>>
>> but because
>> Plot( frame );
>> was only called at start, it is not called again, so there is no draw
>>
>> any ideas here ?
>>
>> of course making the Plot() call in another app function should work
>>
>>
>> If you could replicate this issue, that would be great.
>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>
>>
>>
>>
>>
>> - Original Message - From: Pedro Vicente
>> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
>> Sent: Saturday, December 10, 2016 12:59 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>
>>
>> Hi Phil
>>
>> So, the issue seems to be the same that I have been reporting
>>
>>
>

Re: [Plplot-devel] wxPLplotDemo.cpp errors

[Pedro Vicente]

Hi Phil

I tested on a third Linux, with libwxgtk3.0-dev from package (the latest 
ubuntu package)

uname -a
Linux glace 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:42:26 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

then
git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
sudo apt-get install libwxgtk3.0-dev
cd plplot-plplot/build/
cmake .. -DBUILD_TEST=ON -DENABLE_f95:BOOL=OFF
make
cd /home/pvicente/plplot-plplot/build/examples/c++
pvicente@glace:~/plplot-plplot/build/examples/c++$ ./wxPLplotDemo
Segmentation fault (core dumped)



- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; 
<plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 10, 2016 4:18 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors


> Hi Phil
>
>>>I do have access to a CentOS machine at work, although I think I have
>>>only got access to wxWidgets 2.8 on that system.
>
> What I usually do when I want to quick test on many unices , I install
> Virtual Box
>
> https://www.virtualbox.org/
>
> For example on my Windows PC I have a CentOS and Ubuntu as virtual guests
> (not the ones I did the PLplot test)
>
> -Pedro
>
>
>
>
> - Original Message - 
> From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
> To: "Pedro Vicente" <pedro.vice...@space-research.org>;
> <plplot-devel@lists.sourceforge.net>
> Sent: Saturday, December 10, 2016 3:57 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
>> Hi Pedro
>> I have included the devel list on this email, so the thread will get
>> documented on the mailing list.
>>
>> It is very strange that the OnCreate function is not being called. If
>> you are calling Create then you should be generating a create event.
>> Am I correct in saying that you are getting this segfault with the
>> unchanged demo app?
>>
>> This location really is the best (and maybe only) place this
>> initialisation should be done. It cannot be included in the
>> constructor, because the generic nature of the template specification
>> means the code in the constructor does not know which type of wxWindow
>> we are inheriting from so cannot pass the correct parameters to the
>> constructor. By the time OnPaint is called it is really too late,
>> because we would like to already have the plot initialised and ready
>> to draw and it would be a real pain for you in your code if you had to
>> somehow wait for the first paint or resize event.
>>
>> I do have access to a CentOS machine at work, although I think I have
>> only got access to wxWidgets 2.8 on that system. I will check. I may
>> be able to build 3.1 from source. I presume you are using 3.1.0 as
>> released in February, rather than the head of the master branch?
>>
>> On 10 December 2016 at 07:52, Pedro Vicente
>> <pedro.vice...@space-research.org> wrote:
>>> Hi Phil
>>>
>>> My idea for a fix is to move the stream initialization that is now  on
>>>
>>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
>>> {
>>> if ( !m_created )
>>>
>>> either to the OnSize or onPaint events
>>>
>>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>>
>>> and also in the plot call do this
>>>
>>> template< class WXWINDOW >
>>> void Plot( wxPLplotwindow *plotwindow )
>>> {
>>>wxPLplotstream* pls = plotwindow->GetStream();
>>>
>>>if (pls == NULL)
>>>{
>>>  return;
>>>}
>>>
>>>
>>> Like this , in this sequence
>>>
>>>
>>> wxPLplotwindow *frame = new wxPLplotwindow();
>>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>>frame->SetIcon( wxIcon( graph ) );
>>>frame->Show();
>>>Plot( frame );
>>>
>>>
>>> first we go to
>>> Plot( frame );
>>>
>>> but the stream is NULL because
>>> :OnCreate
>>> was not called, but the function returns, avoiding the seg fault
>>>
>>> then the window gets a paint or size event, and the stream 
>>> initialization
>>> code is called
>>> at this time I have a PLplot empty black window
>>>
>>> but because
>>> Plot( frame );
>>> was only called at start, it is not 

Re: [Plplot-devel] wxPLplotDemo.cpp errors

[Pedro Vicente]

Hi Phil

>>I do have access to a CentOS machine at work, although I think I have
>>only got access to wxWidgets 2.8 on that system.

What I usually do when I want to quick test on many unices , I install 
Virtual Box

https://www.virtualbox.org/

For example on my Windows PC I have a CentOS and Ubuntu as virtual guests 
(not the ones I did the PLplot test)

-Pedro




- Original Message - 
From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; 
<plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 10, 2016 3:57 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors


> Hi Pedro
> I have included the devel list on this email, so the thread will get
> documented on the mailing list.
>
> It is very strange that the OnCreate function is not being called. If
> you are calling Create then you should be generating a create event.
> Am I correct in saying that you are getting this segfault with the
> unchanged demo app?
>
> This location really is the best (and maybe only) place this
> initialisation should be done. It cannot be included in the
> constructor, because the generic nature of the template specification
> means the code in the constructor does not know which type of wxWindow
> we are inheriting from so cannot pass the correct parameters to the
> constructor. By the time OnPaint is called it is really too late,
> because we would like to already have the plot initialised and ready
> to draw and it would be a real pain for you in your code if you had to
> somehow wait for the first paint or resize event.
>
> I do have access to a CentOS machine at work, although I think I have
> only got access to wxWidgets 2.8 on that system. I will check. I may
> be able to build 3.1 from source. I presume you are using 3.1.0 as
> released in February, rather than the head of the master branch?
>
> On 10 December 2016 at 07:52, Pedro Vicente
> <pedro.vice...@space-research.org> wrote:
>> Hi Phil
>>
>> My idea for a fix is to move the stream initialization that is now  on
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
>> {
>> if ( !m_created )
>>
>> either to the OnSize or onPaint events
>>
>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>
>> and also in the plot call do this
>>
>> template< class WXWINDOW >
>> void Plot( wxPLplotwindow *plotwindow )
>> {
>>wxPLplotstream* pls = plotwindow->GetStream();
>>
>>if (pls == NULL)
>>{
>>  return;
>>}
>>
>>
>> Like this , in this sequence
>>
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>frame->SetIcon( wxIcon( graph ) );
>>frame->Show();
>>Plot( frame );
>>
>>
>> first we go to
>> Plot( frame );
>>
>> but the stream is NULL because
>> :OnCreate
>> was not called, but the function returns, avoiding the seg fault
>>
>> then the window gets a paint or size event, and the stream initialization
>> code is called
>> at this time I have a PLplot empty black window
>>
>> but because
>> Plot( frame );
>> was only called at start, it is not called again, so there is no draw
>>
>> any ideas here ?
>>
>> of course making the Plot() call in another app function should work
>>
>>
>> If you could replicate this issue, that would be great.
>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>
>>
>>
>>
>>
>> - Original Message - From: Pedro Vicente
>> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
>> Sent: Saturday, December 10, 2016 12:59 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>
>>
>> Hi Phil
>>
>> So, the issue seems to be the same that I have been reporting
>>
>>
>> In the wxPLplotDemo.cpp code you have these callling functions
>>
>>
>> wxPLplotwindow *frame = new wxPlDemoFrame();
>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>
>>
>> that make 2 calls to the PLplot library, or the wxWidgets driver of it
>> all these calls are in the header file wxPLplotwindow.h
>>
>> first the constructor is called
>>
>> template
>> wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize
>> clientSize )
>>: m_created( false ), m_initialSize( clientSize )
>>
>>
>> then this call OnCreate() is called, like you mentioned
>> 

Re: [Plplot-devel] wxPLplotDemo.cpp errors

[Pedro Vicente]

Hi Phil

> I have included the devel list on this email, so the thread will get
> documented on the mailing list.


I have been posting everything to the list

> Am I correct in saying that you are getting this segfault with the
> unchanged demo app?


yes, correct


>It cannot be included in the
> constructor, because the generic nature of the template specification

yes, exactly


>>> I do have access to a CentOS machine at work, although I think I have
> only got access to wxWidgets 2.8 on that system.

I just did a build on Ubuntu with wxWidgets installed from package (not sure 
which version, I will check)
see last email

>> I presume you are using 3.1.0 as
> released in February,

yes, on CentOS


-Pedro




- Original Message - 
From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; 
<plplot-devel@lists.sourceforge.net>
Sent: Saturday, December 10, 2016 3:57 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors


> Hi Pedro
> I have included the devel list on this email, so the thread will get
> documented on the mailing list.
>
> It is very strange that the OnCreate function is not being called. If
> you are calling Create then you should be generating a create event.
> Am I correct in saying that you are getting this segfault with the
> unchanged demo app?
>
> This location really is the best (and maybe only) place this
> initialisation should be done. It cannot be included in the
> constructor, because the generic nature of the template specification
> means the code in the constructor does not know which type of wxWindow
> we are inheriting from so cannot pass the correct parameters to the
> constructor. By the time OnPaint is called it is really too late,
> because we would like to already have the plot initialised and ready
> to draw and it would be a real pain for you in your code if you had to
> somehow wait for the first paint or resize event.
>
> I do have access to a CentOS machine at work, although I think I have
> only got access to wxWidgets 2.8 on that system. I will check. I may
> be able to build 3.1 from source. I presume you are using 3.1.0 as
> released in February, rather than the head of the master branch?
>
> On 10 December 2016 at 07:52, Pedro Vicente
> <pedro.vice...@space-research.org> wrote:
>> Hi Phil
>>
>> My idea for a fix is to move the stream initialization that is now  on
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
>> {
>> if ( !m_created )
>>
>> either to the OnSize or onPaint events
>>
>> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>>
>> and also in the plot call do this
>>
>> template< class WXWINDOW >
>> void Plot( wxPLplotwindow *plotwindow )
>> {
>>wxPLplotstream* pls = plotwindow->GetStream();
>>
>>if (pls == NULL)
>>{
>>  return;
>>}
>>
>>
>> Like this , in this sequence
>>
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>frame->SetIcon( wxIcon( graph ) );
>>frame->Show();
>>Plot( frame );
>>
>>
>> first we go to
>> Plot( frame );
>>
>> but the stream is NULL because
>> :OnCreate
>> was not called, but the function returns, avoiding the seg fault
>>
>> then the window gets a paint or size event, and the stream initialization
>> code is called
>> at this time I have a PLplot empty black window
>>
>> but because
>> Plot( frame );
>> was only called at start, it is not called again, so there is no draw
>>
>> any ideas here ?
>>
>> of course making the Plot() call in another app function should work
>>
>>
>> If you could replicate this issue, that would be great.
>> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>>
>>
>>
>>
>>
>> - Original Message - From: Pedro Vicente
>> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
>> Sent: Saturday, December 10, 2016 12:59 AM
>> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>>
>>
>> Hi Phil
>>
>> So, the issue seems to be the same that I have been reporting
>>
>>
>> In the wxPLplotDemo.cpp code you have these callling functions
>>
>>
>> wxPLplotwindow *frame = new wxPlDemoFrame();
>> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>>
>>
>> that make 2 calls to the PLplot library, or the wxWidgets driver of it
>&g

Re: [Plplot-devel] wxPLplotDemo.cpp errors

[Pedro Vicente]

Hi Phil

I tested on a different setting

Ubuntu i686 GNU/Linux

Using wxWidgets installed from packages
using the PLplot from git

git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
cd plplot-plplot/
mkdir build
cd  build
cmake ..  -G "Unix 
Makefiles" -DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS:BOOL=OFF 
-DENABLE_f95:BOOL=OFF 
 -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF 
-DCMAKE_INSTALL_PREFIX:PATH=/home/pvn/install/plplot-5.11.1 
 -DPL_HAVE_PTHREAD:BOOL=OFF -DPLD_xwin:BOOL=OFF -DPLD_wxwidgets:BOOL=ON 
-DwxWidgets_ROOT_DIR:PATH=/usr/lib/i386-linux-gnu 
 -DwxWidgets_LIB_DIR:PATH=/usr/lib/i386-linux-gnu 
-DwxWidgets_CONFIGURATION=mswud 
 -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF 
-DBUILD_TEST:BOOL=ON 
 >& cmake.txt &
make >& make.txt &
 cd /home/pvn/svn/plot/plplot-5.11.1/build/examples/c++/
./wxPLplotDemo
Segmentation fault (core dumped)



-Pedro



- Original Message - 
From: "Pedro Vicente" <pedro.vice...@space-research.org>
To: <plplot-devel@lists.sourceforge.net>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>
Sent: Saturday, December 10, 2016 2:52 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors


> Hi Phil
>
> My idea for a fix is to move the stream initialization that is now  on
>
> void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
> {
> if ( !m_created )
>
> either to the OnSize or onPaint events
>
> void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )
>
> and also in the plot call do this
>
> template< class WXWINDOW >
> void Plot( wxPLplotwindow *plotwindow )
> {
>wxPLplotstream* pls = plotwindow->GetStream();
>
>if (pls == NULL)
>{
>  return;
>}
>
>
> Like this , in this sequence
>
>
> wxPLplotwindow *frame = new wxPLplotwindow();
>frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>frame->SetIcon( wxIcon( graph ) );
>frame->Show();
>Plot( frame );
>
>
> first we go to
> Plot( frame );
>
> but the stream is NULL because
> :OnCreate
> was not called, but the function returns, avoiding the seg fault
>
> then the window gets a paint or size event, and the stream initialization
> code is called
> at this time I have a PLplot empty black window
>
> but because
> Plot( frame );
> was only called at start, it is not called again, so there is no draw
>
> any ideas here ?
>
> of course making the Plot() call in another app function should work
>
>
> If you could replicate this issue, that would be great.
> I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0
>
>
>
>
>
> - Original Message - 
> From: Pedro Vicente
> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
> Sent: Saturday, December 10, 2016 12:59 AM
> Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
> Hi Phil
>
> So, the issue seems to be the same that I have been reporting
>
>
> In the wxPLplotDemo.cpp code you have these callling functions
>
>
> wxPLplotwindow *frame = new wxPlDemoFrame();
> frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
>
>
> that make 2 calls to the PLplot library, or the wxWidgets driver of it
> all these calls are in the header file wxPLplotwindow.h
>
> first the constructor is called
>
> template
> wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize
> clientSize )
>: m_created( false ), m_initialSize( clientSize )
>
>
> then this call OnCreate() is called, like you mentioned
> and the !m_created bool makes the initialization of the stream happen
>
> the problem is  that this function id *NOT* called on my linux build (it 
> is
> on the Windows build)
> so therefore later
> wxPLplotstream* pls = plotwindow->GetStream();
> this is NULL, so therefore it seg faults on the plot calls
>
> //! This is called when the widow is created i.e. after WXWINDOW::Create
> // has been called. We note that this has been called to avoid attempting
> // to redraw a plot on a window that hasn't been created yet.
> template
> void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
> {
> if ( !m_created )
>
> so, one quick try is to put the code of
>
> void wxPLplotwindow::OnCreate
> that is not called on the constructor maybe ?
>
> -Pedro
>
> - Original Message - 
> From: Pedro Vicente
> To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
> Sent: Friday, December 09, 2016 11:57 PM
> Subject: [Plplot-devel] wxPLplotDemo.cpp errors
>
>
> Hi Phil
>
> So, resuming the last thread about wxWidgets, what I did was to build and
> run wxPLplotDemo.cpp from PLpplot 5.11.1 on CentOS 6.8
>

Re: [Plplot-devel] wxPLplotDemo.cpp errors

[Pedro Vicente]

Hi Phil

My idea for a fix is to move the stream initialization that is now  on

void wxPLplotwindow::OnCreate( wxWindowCreateEvent 
{
if ( !m_created )

either to the OnSize or onPaint events

void wxPLplotwindow::OnSize( wxSizeEvent& WXUNUSED( event ) )

and also in the plot call do this

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

if (pls == NULL)
{
  return;
}


Like this , in this sequence


wxPLplotwindow *frame = new wxPLplotwindow();
frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );
frame->SetIcon( wxIcon( graph ) );
frame->Show();
Plot( frame );


first we go to
Plot( frame );

but the stream is NULL because
:OnCreate
was not called, but the function returns, avoiding the seg fault

then the window gets a paint or size event, and the stream initialization 
code is called
at this time I have a PLplot empty black window

but because
Plot( frame );
was only called at start, it is not called again, so there is no draw

any ideas here ?

of course making the Plot() call in another app function should work


If you could replicate this issue, that would be great.
I am using CentOS 6.8, PLplot.5.11.1 , wxWidgets 3.1.0





- Original Message - 
From: Pedro Vicente
To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
Sent: Saturday, December 10, 2016 12:59 AM
Subject: Re: [Plplot-devel] wxPLplotDemo.cpp errors


Hi Phil

So, the issue seems to be the same that I have been reporting


In the wxPLplotDemo.cpp code you have these callling functions


wxPLplotwindow *frame = new wxPlDemoFrame();
frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );


that make 2 calls to the PLplot library, or the wxWidgets driver of it
all these calls are in the header file wxPLplotwindow.h

first the constructor is called

template
wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize 
clientSize )
: m_created( false ), m_initialSize( clientSize )


then this call OnCreate() is called, like you mentioned
and the !m_created bool makes the initialization of the stream happen

the problem is  that this function id *NOT* called on my linux build (it is 
on the Windows build)
so therefore later
wxPLplotstream* pls = plotwindow->GetStream();
this is NULL, so therefore it seg faults on the plot calls

//! This is called when the widow is created i.e. after WXWINDOW::Create
// has been called. We note that this has been called to avoid attempting
// to redraw a plot on a window that hasn't been created yet.
template
void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
{
if ( !m_created )

so, one quick try is to put the code of

void wxPLplotwindow::OnCreate
that is not called on the constructor maybe ?

-Pedro

- Original Message - 
From: Pedro Vicente
To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg
Sent: Friday, December 09, 2016 11:57 PM
Subject: [Plplot-devel] wxPLplotDemo.cpp errors


Hi Phil

So, resuming the last thread about wxWidgets, what I did was to build and 
run wxPLplotDemo.cpp from PLpplot 5.11.1 on CentOS 6.8

all builds fine, but when I do run , I get a seg fault

[pedro.vicente@rhw9121 c++]$ cd 
/data/home002/pvicente/plplot/build/examples/c++
[pedro.vicente@rhw9121 c++]$ ./wxPLplotDemo
Segmentation fault

I know that only this information is not much help to you to debug, but in 
the next couple of days I'll be debugging this and posting here any 
solution.

my cmake call was

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.1d 
 -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 
 -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DBUILD_TEST:BOOL=ON >& cmake.txt &


the output of
cmake
and
make
are attached

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




--
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 s

Re: [Plplot-devel] wxPLplotDemo.cpp errors

[Pedro Vicente]

Hi Phil

So, the issue seems to be the same that I have been reporting


In the wxPLplotDemo.cpp code you have these callling functions


wxPLplotwindow *frame = new wxPlDemoFrame();
frame->Create( NULL, wxID_ANY, wxT( "wxPLplotDemo" ) );


that make 2 calls to the PLplot library, or the wxWidgets driver of it
all these calls are in the header file wxPLplotwindow.h

first the constructor is called

template
wxPLplotwindow::wxPLplotwindow( bool useGraphicsContext, wxSize 
clientSize )
: m_created( false ), m_initialSize( clientSize )


then this call OnCreate() is called, like you mentioned
and the !m_created bool makes the initialization of the stream happen

the problem is  that this function id *NOT* called on my linux build (it is on 
the Windows build)
so therefore later
wxPLplotstream* pls = plotwindow->GetStream();

this is NULL, so therefore it seg faults on the plot calls


//! This is called when the widow is created i.e. after WXWINDOW::Create

// has been called. We note that this has been called to avoid attempting

// to redraw a plot on a window that hasn't been created yet.

template

void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )

{

if ( !m_created )


so, one quick try is to put the code of 
 
void wxPLplotwindow::OnCreate

that is not called on the constructor maybe ?



-Pedro


  - Original Message - 
  From: Pedro Vicente 
  To: plplot-devel@lists.sourceforge.net ; Phil Rosenberg 
  Sent: Friday, December 09, 2016 11:57 PM
  Subject: [Plplot-devel] wxPLplotDemo.cpp errors


  Hi Phil

  So, resuming the last thread about wxWidgets, what I did was to build and run 
wxPLplotDemo.cpp from PLpplot 5.11.1 on CentOS 6.8

  all builds fine, but when I do run , I get a seg fault 

  [pedro.vicente@rhw9121 c++]$ cd 
/data/home002/pvicente/plplot/build/examples/c++
  [pedro.vicente@rhw9121 c++]$ ./wxPLplotDemo
  Segmentation fault

  I know that only this information is not much help to you to debug, but in  
the next couple of days I'll be debugging this and posting here any solution.

  my cmake call was

  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.1d 
-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 -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DBUILD_TEST:BOOL=ON >& cmake.txt &


  the output of 
  cmake 
  and 
  make 
  are attached

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

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

[Pedro Vicente]

Hi Phil

Yes, my explanation was not very clear.
I know that I have to do what you mentioned, I do call Create().
Actually I am copying the code from wxPLplotDemo.cpp

but let's forget this thread, when something is failing for several days, 
and I don't know why,
what I do is delete everything and start from scratch.

So, the scratch here is to build and run wxPLplotDemo.cpp from the PLplot 
distribution

I did that, but it am having a seg fault :-)
I''ll just start a new thread with the debug results

thanks

-Pedro

- Original Message - 
From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; 
<plplot-devel@lists.sourceforge.net>
Sent: Friday, December 09, 2016 8:44 PM
Subject: Re: [Plplot-devel] build PLPlot with debug symbols in linux / cmake


> Hi Pedro
> I'm sorry but I'm not sure I understand the point at which you get the 
> segfault.
>
> However, I think you are trying to call GetStream, before the stream
> has been created. The stream requires the window's device context at
> the point of creation, in order for the device context to exist the
> window must have been "Create"d. Often this is done by the
> constructor, but in this case to maintain generality the default
> wxWindow constructor is called which takes no parameters and does not
> create the window. An explicit call to wxSomeWindowType::Create is
> required - only once that has happened does the device context exist
> allowing the stream to be created.
>
> It would actually be very easy to have something like
>
> class myPlFrame :public wxPlWindow
> {
> };
>
> then have
> myPlFrame::myPlFrame(/*All the variables needed to initialise a wxFrame*/)
> {
>Create(/*The varibles from above*/);
> }
>
> Then you can call GetStream immediately after construction.
>
> On 9 December 2016 at 03:27, Pedro Vicente
> <pedro.vice...@space-research.org> wrote:
>> 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 *plotwindow)
>> {
>>  wxPLplotstream* pls = plotwindow->GetStream();
>>
>> so all pls-> calls seg fault
>>
>>
>> what happens is that this function is *not* called
>>
>>
>> void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
>> {
>>if ( !m_created )
>>
>>
>> and it should have been in these calls
>>
>>
>> wxPLplotwindow *frame = new wxPLplotwindow();
>>  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::OnCreate(wxWindowCreateEvent &)' (compiling
>> source file wx_explorer_star.cpp)
>>  wx_explorer_star.cpp(860): note: see reference to class template
>> instantiation 'wx_PLplotwindow' 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))
>>
>

Re: [Plplot-devel] Fwd: Deprecated wxWidgets error

[Pedro Vicente]

Hi Phil

I agree, it does not make much sense going back to the old wxwidgets.
My usage of it is inside a wxWidgets GUI app, so I don't need any special 
features.
In fact it has been working well for me in the last couple of months, but 
last week I started having errors
 so I just gave  a try to the old wxWidgets out of curiosity.

thanks

-Pedro

- Original Message - 
From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
To: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Cc: "Pedro Vicente" <pedro.vice...@space-research.org>; 
<plplot-devel@lists.sourceforge.net>
Sent: Friday, December 09, 2016 6:49 PM
Subject: Re: [Plplot-devel] Fwd: Deprecated wxWidgets error


> Hi Pedro
> As Alan said, we can't have both working together. Well, I suppose we
> could, but the effort required would be large and time is finite. If
> you are interested in the usage differences then:
>
> The new wx backend discarded use of AGG and freetype as wxWidgets now
> has much better support for antialiased graphics and text. This also
> massively simplifies support.
>
> For calling from a wxWidgets application the wxPlplotwindow class is
> now template, meaning it can inherit from any wxWindow - so as well as
> having a plplot panel, you can have anything from a plplot frame to a
> plplot button should you wish.
>
> For calling wxWidgets from a console application all the rendering is
> performed in a separate utility which has commands sent from the
> console application. This removes some problems we had with large
> amounts of almost duplicated, but subtly code, plus possible threading
> issues. Unfortunately there at performance issues that I haven't been
> able to get to the bottom of yet.
>
> Lastly, some of the less well used features of Plplot are not yet
> supported, like maybe changing the fill algorithm. But certainly all
> the well used things are there.
>
> So basically, unless you really want to use AGG or FreeType, then I
> don't see much need to use the deprecated version. I certainly won't
> be going back and fixing any bugs in the deprecated version. If,
> however, there is some feature that is still missing from the new
> version then let me know and I'll try to prioritise.
>
> Phil
>
> On 9 December 2016 at 21:45, Alan W. Irwin <ir...@beluga.phys.uvic.ca> 
> wrote:
>> On 2016-12-09 15:39-0500 Pedro Vicente wrote:
>>
>>> so, it seems that the cmake option is really needed
>>> -DOLD_WXWIDGETS=ON
>>>
>>> I only found out this by reading the script
>>
>> Reading the script is an excellent idea so I encourage you to keep doing
>> that.  However, we also document such changes in our release notes.
>> In this case you won't find that documentation in README.release
>> because OLD_WXWIDGETS was introduced in a previous release.  So
>> instead you have to look in the cumulated old release notes,
>> OLD-README.release for the relevant documentation of
>> -DOLD_WXWIDGETS=ON.
>>
>> [...]
>>
>>> I have a request, would it be possible to have the "deprecated"
>>> wxWidgets code and the templated one at the same time?
>>
>> No.  If you want access to both for comparisons, use separate build
>> trees (and install trees).  Also, -DOLD_WXWIDGETS=ON is deprecated
>> because it is an emergency measure which gives you access to the old
>> frozen wxwidgets code. There is no further support for
>> -DOLD_WXWIDGETS=ON beyond that because that old wxwidgets code was not
>> Phil's responsibility and there are lots of known issues with it. So
>> Phil is focussing exclusively on development of the new wxwidgets.
>> Thus, if you find some features you like with -DOLD_WXWIDGETS=ON, then
>> ideally you should make changes to your local _new_ wxwidgets to add
>> that feature and send patches (ideally generated by "git
>> format-patch") to this list for Phil to evaluate.  N.B. it is a
>> virtual certainty your patch will be rejected if it contains fixes for
>> multiple issues.  So instead each of your individual patches should
>> focus on just one logical issue at a time.  And sometimes we do reject
>> ideas such as yours above to have both old and new wxwidgets in the
>> same build tree.  But so long as your patches are focussed on one
>> thing at a time (and not necessarily limited to just the new
>> wxwidgets) and otherwise acceptable, then such development help with
>> PLplot would be much appreciated.  (Note, we recommend "git
>> format-patch" for generating patches because that gives you full
>> credit for your work in the git log.)
>>
>> Alan
>> ___

Re: [Plplot-devel] Soft freeze on December 3rd and release on December 17th?

[Pedro Vicente]

ok, simple issue , ignore

I tool a quick look at the ouput , it's just


CMake 3.0.2 or higher is required.  You are running version 2.8.12.2


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: <plplot-devel@lists.sourceforge.net>
Sent: Friday, December 09, 2016 5:05 PM
Subject: Re: [Plplot-devel] Soft freeze on December 3rd and release on 
December 17th?


> On 2016-12-09 11:38-0500 Pedro Vicente wrote:
>
>>
>> Hi Alan
>>
>> I get an error on the script
>>
>> ERROR: cmake in the build tree failed
>>
>> what I did (CentOS 6.8)
>>
>> git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
>> cd plplot-plplot/scripts
>> ./comprehensive_test.sh
>
> Please look in the prefix directory  (by default that is
> ../comprehensive_test_disposable relative to the top
> of the source tree) for the report tarball, comprehensive_test.tar.gz,
> and send that tarball (on or off list) to me.  That should allow me to
> find out why that cmake invocation failed for you, and give you
> some recommendations about running this test again.
>
>
>> then I tried
>>
>> mkdir build
>> cd build
>> cmake ..
>> make
>
> This is already a big difference with your comprehensive test result
> above because cmake succeeded here but not there.  But I will know
> a lot more once I receive the above report tarball from you that
> is generated by the comprehensive test.
>
>> Note:
>>
>> 1)
>>
>>>>> Essentially all you have to do is set up
>>>>> the relevant environment variables that you normally use to build
>>>>> PLplot
>>
>>
>> I never did set any environment variables to build PLplot before, which
>> ones?
>
> It depends on your individual needs.  I like to test PLplot with certain
> compiler options so I typically set
>
> export CFLAGS='-O3 -fvisibility=hidden -Wuninitialized'
> export CXXFLAGS='-O3 -fvisibility=hidden -Wuninitialized'
> export FFLAGS='-O3 -Wuninitialized -Wunused'
>
> But when debugging issues I reduce those to
>
> export CFLAGS='-g'
> export CXXFLAGS='-g'
> export FFLAGS='-g'
>
> Also, I generally find setting the environment variables PATH, 
> CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, and PKG_CONFIG_PATH are often
> a big help if cmake is having trouble finding software installed in
> non-standard locations.
>
>> I can provide further debug output, let me know to which email address
>> should I send to
>
> I would prefer to work with your results for the comprehensive test
> script since that often supplies me with all the information I need to
> answer your questions.  In this case, that script did not get very far
> the first time you invoked it, but once I see that report tarball, I
> can likely advise you what simple fix to make so that cmake completes
> without errors, which means your next comprehensive test run should
> get to this current build problem concerning wxwidgets with all the
> information I need, and we can take it from there.
>
> 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
> __
> 


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

Re: [Plplot-devel] Soft freeze on December 3rd and release on December 17th?

[Pedro Vicente]

Hi Alan

comprehensive_test.tar.gz is attached



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



ok, I see I thought you meant environment variables specific  for PLplot to 
build.
These are gcc compiler flags, personally I never set them this way, but 
instead I do it for each makefile.


In this build they are the above  environment variables

thanks

-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: <plplot-devel@lists.sourceforge.net>
Sent: Friday, December 09, 2016 5:05 PM
Subject: Re: [Plplot-devel] Soft freeze on December 3rd and release on 
December 17th?




On 2016-12-09 11:38-0500 Pedro Vicente wrote:



Hi Alan

I get an error on the script

ERROR: cmake in the build tree failed

what I did (CentOS 6.8)

git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
cd plplot-plplot/scripts
./comprehensive_test.sh


Please look in the prefix directory  (by default that is
../comprehensive_test_disposable relative to the top
of the source tree) for the report tarball, comprehensive_test.tar.gz,
and send that tarball (on or off list) to me.  That should allow me to
find out why that cmake invocation failed for you, and give you
some recommendations about running this test again.



then I tried

mkdir build
cd build
cmake ..
make


This is already a big difference with your comprehensive test result
above because cmake succeeded here but not there.  But I will know
a lot more once I receive the above report tarball from you that
is generated by the comprehensive test.


Note:

1)


Essentially all you have to do is set up
the relevant environment variables that you normally use to build
PLplot



I never did set any environment variables to build PLplot before, which
ones?


It depends on your individual needs.  I like to test PLplot with certain
compiler options so I typically set

export CFLAGS='-O3 -fvisibility=hidden -Wuninitialized'
export CXXFLAGS='-O3 -fvisibility=hidden -Wuninitialized'
export FFLAGS='-O3 -Wuninitialized -Wunused'

But when debugging issues I reduce those to

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

Also, I generally find setting the environment variables PATH, 
CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, and PKG_CONFIG_PATH are often

a big help if cmake is having trouble finding software installed in
non-standard locations.


I can provide further debug output, let me know to which email address
should I send to


I would prefer to work with your results for the comprehensive test
script since that often supplies me with all the information I need to
answer your questions.  In this case, that script did not get very far
the first time you invoked it, but once I see that report tarball, I
can likely advise you what simple fix to make so that cmake completes
without errors, which means your next comprehensive test run should
get to this current build problem concerning wxwidgets with all the
information I need, and we can take it from there.

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
__



comprehensive_test.tar.gz
Description: GNU Zip compressed data
--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Fwd: Deprecated wxWidgets error

[Pedro Vicente]

Hi Phil

so, it seems that the cmake option is really needed
-DOLD_WXWIDGETS=ON

I only found out this by reading the script

I tried in Linux

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.1do 
-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 
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DOLD_WXWIDGETS=ON >& cmake.txt &


and deprecated_wxPLplotDemo.cpp runs perfectly
It even has an option to change the background which is exactly what I 
needed

I have a request, would it be possible to have the "deprecated" 
wxWidgets code and the templated one at the same time?
This would allow us to try either one or the other without the need to 
recompiling with the -DOLD_WXWIDGETS flag.
I think some classes have the same name now in the old/new code, is 
that correct ?
If that's the case maybe you could give them different names

thanks much





 Original Message 
Subject: [Plplot-devel] Deprecated wxWidgets error
Date: 2016-12-09 14:39
 From: Pedro Vicente <pedro.vice...@space-research.org>
To: <plplot-devel@lists.sourceforge.net>

Hi Phil

Is the deprecated wxWidgets still functioning?

I gave it a try am I'm getting an error
This is Windows Visual Studio, wxWidgets 3.1, plplot 5.11.1

what I did

used the commented code in the sample wxPLplotDemo.cpp

that starts with

//class MyPlotwindow : public wxPLplotwindow

I did not run any cmake flag to use the old code (is there one?),
so my shortcut was to rename

deprecated_wxPLplotstream.h.in
to
deprecated_wxPLplotstream.h

and set this
#define WX_TEMP_PL_HAVE_FREETYPE_IS_@PL_HAVE_FREETYPE@
to either
#define WX_TEMP_PL_HAVE_FREETYPE_IS_ON
#define WX_TEMP_PL_HAVE_FREETYPE_IS_OFF

my error call stack is

wx_plplot.exe!plParseDrvOpts(DrvOpt * acc_opt) Line 1521C
wx_plplot.exe!plD_init_wxwidgets(PLStream * pls) Line 167   C++
wx_plplot.exe!plP_init() Line 144   C
wx_plplot.exe!c_plinit() Line 2341  C
wx_plplot.exe!plstream::init() Line 1008C++
wx_plplot.exe!wxPLplotstream::Create(wxDC * dc, int width, int
height, int style) Line 85  C++
wx_plplot.exe!wxPLplotstream::wxPLplotstream(wxDC * dc, int width,
int height, int style) Line 36  C++
wx_plplot.exe!wxPLplotwindow::wxPLplotwindow(wxWindow * parent, int
id, const wxPoint & pos, const wxSize & size, long style, int pl_style)
Line 60 C++
wx_plplot.exe!MyPlotwindow::MyPlotwindow(wxFrame * frame, wxWindow *
parent, int id, const wxPoint & pos, const wxSize & size, long style,
int pl_style) Line 58   C++
wx_plplot.exe!MyFrame::MyFrame(const wxString & title) Line 95  C++
wx_plplot.exe!wxAppPlot::OnInit() Line 210  C++



so the error comes from this function

plParseDrvOpts( DrvOpt *acc_opt )

and the exit is this code

if ( !fl )
  {
  snprintf( msg, sizeof ( msg ) - 1, "Option '%s' not
recognized.\n\nRecognized options for this driver are:\n", drvp->option
);
  plwarn( msg );
  plHelpDrvOpts( acc_opt );
  plexit( "" );
  }

where
drvp->option
is "backend" at this point


thanks

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

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

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

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

[Plplot-devel] Deprecated wxWidgets error

[Pedro Vicente]

Hi Phil

Is the deprecated wxWidgets still functioning?

I gave it a try am I'm getting an error
This is Windows Visual Studio, wxWidgets 3.1, plplot 5.11.1

what I did

used the commented code in the sample wxPLplotDemo.cpp

that starts with

//class MyPlotwindow : public wxPLplotwindow

I did not run any cmake flag to use the old code (is there one?),
so my shortcut was to rename

deprecated_wxPLplotstream.h.in
to
deprecated_wxPLplotstream.h

and set this
#define WX_TEMP_PL_HAVE_FREETYPE_IS_@PL_HAVE_FREETYPE@
to either
#define WX_TEMP_PL_HAVE_FREETYPE_IS_ON
#define WX_TEMP_PL_HAVE_FREETYPE_IS_OFF

my error call stack is

wx_plplot.exe!plParseDrvOpts(DrvOpt * acc_opt) Line 1521C
wx_plplot.exe!plD_init_wxwidgets(PLStream * pls) Line 167   C++
wx_plplot.exe!plP_init() Line 144   C
wx_plplot.exe!c_plinit() Line 2341  C
wx_plplot.exe!plstream::init() Line 1008C++
wx_plplot.exe!wxPLplotstream::Create(wxDC * dc, int width, int 
height, int style) Line 85  C++
wx_plplot.exe!wxPLplotstream::wxPLplotstream(wxDC * dc, int width, 
int height, int style) Line 36  C++
wx_plplot.exe!wxPLplotwindow::wxPLplotwindow(wxWindow * parent, int 
id, const wxPoint & pos, const wxSize & size, long style, int pl_style) 
Line 60 C++
wx_plplot.exe!MyPlotwindow::MyPlotwindow(wxFrame * frame, wxWindow * 
parent, int id, const wxPoint & pos, const wxSize & size, long style, 
int pl_style) Line 58   C++
wx_plplot.exe!MyFrame::MyFrame(const wxString & title) Line 95  C++
wx_plplot.exe!wxAppPlot::OnInit() Line 210  C++



so the error comes from this function

plParseDrvOpts( DrvOpt *acc_opt )

and the exit is this code

if ( !fl )
 {
 snprintf( msg, sizeof ( msg ) - 1, "Option '%s' not 
recognized.\n\nRecognized options for this driver are:\n", drvp->option 
);
 plwarn( msg );
 plHelpDrvOpts( acc_opt );
 plexit( "" );
 }

where
drvp->option
is "backend" at this point


thanks

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

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

Re: [Plplot-devel] Soft freeze on December 3rd and release on December 17th?

[Pedro Vicente]

Hi Alan

I get an error on the script

ERROR: cmake in the build tree failed

what I did (CentOS 6.8)

git clone http://git.code.sf.net/p/plplot/plplot plplot-plplot
cd plplot-plplot/scripts
./comprehensive_test.sh


then I tried

mkdir build
cd build
cmake ..
make

and I get a compiling error , below
it seems it's related to wxwidgets-3.1.0 library

Note:

1)

>>>Essentially all you have to do is set up
>>>the relevant environment variables that you normally use to build 
>>> PLplot


I never did set any environment variables to build PLplot before, which 
ones?

2)

I just used
cmake ..
with no options

usually I do with options (no problems) but I just wanted to try like 
this

I can provide further debug output, let me know to which email address 
should I send to

error is


[ 16%] Building C object src/CMakeFiles/plplot.dir/__/drivers/xfig.c.o
[ 16%] Building C object src/CMakeFiles/plplot.dir/__/drivers/xwin.c.o
[ 17%] Linking CXX shared library libplplot.so
/usr/bin/ld: 
/data/data127/pvicente/install/wxwidgets-3.1.0/lib/libwx_gtk2u_core-3.1.a(corelib_event.o):
 
relocation R_X86_64_32 against `wxCommandEvent::ms_classInfo' can not 
be used when making a shared object; recompile with -fPIC
/data/data127/pvicente/install/wxwidgets-3.1.0/lib/libwx_gtk2u_core-3.1.a: 
could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [src/libplplot.so.13.1.2] Error 1
make[1]: *** [src/CMakeFiles/plplot.dir/all] Error 2
make: *** [all] Error 2





On 2016-11-22 19:50, Alan W. Irwin wrote:
> Tom Schoonjans made some good points on plplot-general about
> officially releasing timely fixes for PLplot rather than expecting
> packagers and others to dig those out of git, and I also feel it is
> critical to give our users good access to the recent big improvements
> in both our Fortran and Tcl bindings.  So to answer these concerns my
> plan is to release PLplot-5.12.0 on ** December 17th 
> **.
> That is roughly the last release date possible in December without
> intruding on Christmas holiday time, and I don't want to put off this
> release until January for the above reasons.
>
> Note, I don't want the release any sooner than the above date because
> there are a lot of (fairly minor) topics I am still working on that I
> would like to get into this release.  Therefore, I plan to continue
> working on those topics for the rest of this week and the next one 
> and
> declare a soft freeze (where only minor bug fixing and documentation
> improvements should occur after that freeze date until the release) 
> on
> ** December 3rd **. That freeze date should give us
> two weeks for extensive testing of PLplot (and fixing all bugs that
> are turned up by such testing) on all platforms accessible to PLplot
> developers and users.  (Note, I do plan to ask our users on
> plplot-general to help with testing during those two critical weeks 
> on
> the platforms accessible to them.)
>
> Please speak out if either of the two dates above need an adjustment
> from your perspective.  For example, another freeze date alternative
> could be December 10th (which still gives us the minimum one week of
> time we need for testing).  But that freeze date would be completely
> inflexible, and I would prefer a more flexible freeze date (to
> accommodate last-minute requests to change it for those developers 
> who
> discover they need a few more days to get their topics merged) which
> is why I have suggested December 3rd as the freeze date.
>
> If nobody has any suggestions for changes in the above two critical
> dates by (say) late Wednesday I will follow up by announcing the 
> above
> two critical dates on PLplot-general.
>
> Alan (your friendly release manager).
> __
> 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 mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

-- 
Pedro Vicente
pedro.vice...@space-research.org
http://www.space-research.org/

---

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

[Pedro Vicente]

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 *plotwindow)
{
  wxPLplotstream* pls = plotwindow->GetStream();

so all pls-> calls seg fault


what happens is that this function is *not* called


void wxPLplotwindow::OnCreate( wxWindowCreateEvent  )
{
if ( !m_created )


and it should have been in these calls


wxPLplotwindow *frame = new wxPLplotwindow();
  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::OnCreate(wxWindowCreateEvent &)' (compiling 
source file wx_explorer_star.cpp)
  wx_explorer_star.cpp(860): note: see reference to class template 
instantiation 'wx_PLplotwindow' 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...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: <plplot-devel@lists.sourceforge.net>
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 QtC

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

[Pedro Vicente]

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

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

[Pedro Vicente]

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





#include 
#include 
#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 *plotwindow);
template< class WXWINDOW >
void plot_bars(wx_PLplotwindow *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(, );
  

Re: [Plplot-devel] Soft freeze on December 3rd and release on December17th?

[Pedro Vicente]

Hi Alan
Those dates look good to me, and I will investigate my 3 thread issues 
(wxWidgets, Qt, error messages ) well before the freezing date
-Pedro

- Original Message - 
From: "Alan W. Irwin" 
To: "PLplot development list" 
Sent: Tuesday, November 22, 2016 7:50 PM
Subject: [Plplot-devel] Soft freeze on December 3rd and release on 
December17th?


> Tom Schoonjans made some good points on plplot-general about
> officially releasing timely fixes for PLplot rather than expecting
> packagers and others to dig those out of git, and I also feel it is
> critical to give our users good access to the recent big improvements
> in both our Fortran and Tcl bindings.  So to answer these concerns my
> plan is to release PLplot-5.12.0 on ** December 17th **.
> That is roughly the last release date possible in December without
> intruding on Christmas holiday time, and I don't want to put off this
> release until January for the above reasons.
>
> Note, I don't want the release any sooner than the above date because
> there are a lot of (fairly minor) topics I am still working on that I
> would like to get into this release.  Therefore, I plan to continue
> working on those topics for the rest of this week and the next one and
> declare a soft freeze (where only minor bug fixing and documentation
> improvements should occur after that freeze date until the release) on
> ** December 3rd **. That freeze date should give us
> two weeks for extensive testing of PLplot (and fixing all bugs that
> are turned up by such testing) on all platforms accessible to PLplot
> developers and users.  (Note, I do plan to ask our users on
> plplot-general to help with testing during those two critical weeks on
> the platforms accessible to them.)
>
> Please speak out if either of the two dates above need an adjustment
> from your perspective.  For example, another freeze date alternative
> could be December 10th (which still gives us the minimum one week of
> time we need for testing).  But that freeze date would be completely
> inflexible, and I would prefer a more flexible freeze date (to
> accommodate last-minute requests to change it for those developers who
> discover they need a few more days to get their topics merged) which
> is why I have suggested December 3rd as the freeze date.
>
> If nobody has any suggestions for changes in the above two critical
> dates by (say) late Wednesday I will follow up by announcing the above
> two critical dates on PLplot-general.
>
> Alan (your friendly release manager).
> __
> 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 mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 


--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Finding wxWidgets

[Pedro Vicente]

all is fine

so, the problem was that I was using git bash for Windows as shell (where 
back-slash forward-slash convention is different from Unix/Windows; as a 
software engineer I end up losing hours of my life fixing

different Unix/Windows path conventions. Thanks Microsoft).

Using just a "normal" Windows shell , this works

-DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib

in

cmake ".." -G "Visual Studio 
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
-DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON 
-DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib 
-DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF



sorry for all the false alarms

Just 2 last notes :-)


1)

If we specify the root of wxWidgets with

-DwxWidgets_ROOT_DIR:PATH=%WXWIN%

it seems that having to specify the library path could be eliminated

-DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib

I believe this path

\lib\vc_lib

is always the same for any Windows build? If not than my point is not valid

2)

After building with Visual Studio, all built ok

== Rebuild All: 88 succeeded, 0 failed, 0 skipped ==

but in the last release there was an automatic run of the plot demo, that 
shows a plot window, that did not show up this time


no big deal, but it's a nice feature that shows that all went fine

thanks


-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Laurent Berger" 
<laurent.ber...@univ-lemans.fr>; <plplot-devel@lists.sourceforge.net>

Sent: Monday, November 14, 2016 3:23 AM
Subject: Re: [Plplot-devel] Finding wxWidgets



On 2016-11-13 22:14-0500 Pedro Vicente wrote:


I have


WXWIN = M:\wx\wxwidgets-3.1.0


Hi Pedro:

That form is consistent with the examples at
<https://wiki.wxwidgets.org/Adding_an_Environment_Variable_under_Windows>.
Nevertheless, CMake is sometimes difficult about the back-slash Windows
directory notation and may need the "native CMake" forward slash notation 
instead for

these cmake options that are specifying directories.

So this is just an informed guess, but what happens if you replace

-DwxWidgets_ROOT_DIR:PATH=%WXWIN%
-DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib

with

-DwxWidgets_ROOT_DIR:PATH=M:/wx/wxwidgets-3.1.0
-DwxWidgets_LIB_DIR:PATH=M:/wx/wxwidgets-3.1.0/lib/vc_lib

in your cmake options?

Also, if that still does not do the trick, please send the
CMakeCache.txt file 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
__


-- The C compiler identification is MSVC 19.0.24213.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- CMake version = 3.6.2
-- CMAKE_SYSTEM_NAME = Windows
-- SH_EXECUTABLE = SH_EXECUTABLE-NOTFOUND
-- WARNING: bash shell not found, ctest will not work properly
-- Checking whether system has ANSI C header files
-- Looking for 4 include files stdlib.h, ..., float.h
-- Looking for 4 include files stdlib.h, ..., float.h - found
-- Performing Test memchrExists
-- Performing Test memchrExists - Success
-- Performing Test freeExists
-- Performing Test freeExists - Success
-- Check for whether ctype.h macros work on characters with the
  high bit set.
-- High-bit characters - work
-- ANSI C header files - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - not found
-- Looking for include file termios.h
-- Looking for include file termios.h - not found
-- Looking for include file stdint.h
-- Looking for include file stdint.h - found
-- Looking for crt_externs.h
-- Looking for crt_externs.h - not found
-- Performing Test HAVE_SYS_WAIT_H
-- Performing Test HAVE_SYS_WAIT_H - Failed
-- Looking for DIR symbol in sys/types.h;dirent.h
-- Looking for DIR symbol in sys/types.h;dirent.h - not found.
-- Looking for DIR symbol in sys/types.h;sys/ndir.h
-- Looking for DIR symbol in sys/types.h;sys/ndir.h - not foun

Re: [Plplot-devel] Finding wxWidgets

[Pedro Vicente]

sorry wrong thread, reposting this

I have


WXWIN = M:\wx\wxwidgets-3.1.0

in my PATH there is

;%WXWIN%\lib\vc_lib;

but wxwidgets is still not detected

attached make.txt

done with

cmake ".." -G "Visual Studio
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON 
-DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
 -DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF 
-DSTATIC_RUNTIME:BOOL=ON
 -DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% 
-DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
 -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON 
-DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
 > make.txt


I'll debug this when I have some time, hopefully before the release

-Pedro



- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Laurent Berger" 
<laurent.ber...@univ-lemans.fr>; <plplot-devel@lists.sourceforge.net>
Sent: Saturday, November 12, 2016 4:00 AM
Subject: Re: [Plplot-devel] Finding wxWidgets


> On 2016-11-12 00:08-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> it seems all is ok now
>
>> doing
>
>> $ cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON
>> -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
>> -DCMAKE_BUILD_TYPE:STRING="Deb ug" -DBUILD_SHARED_LIBS:BOOL=OFF
>> -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON
>> -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\
>> lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
>> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF > make.txt 2>&1
>
>
> Actually, there are still problems finding wxWidgets on your platform.
> Specifically, from the make.txt file you sent you have the following
> (bad) find results:
>
> -- wxWidgets_FOUND   : FALSE
> -- wxWidgets_INCLUDE_DIRS: -- wxWidgets_LIBRARY_DIRS: --  
> wxWidgets_LIBRARIES   : -- wxWidgets_CXX_FLAGS   : --  
> wxWidgets_USE_FILE: UsewxWidgets
> -- WARNING: wxWidgets or its libraries not found so setting all wxwidgets 
> devices to OFF.
>
> CMake is pretty good at finding libraries installed in standard
> locations so the first thing I suggest you try is to drop the options
> above that set wxWidgets_ROOT_DIR and wxWidgets_LIB_DIR.  But if that
> doesn't work (i.e., wxWidgets_FOUND is still FALSE). then you should
> consider the large likelihood that those variables are set incorrectly
> (i.e., do not point to the non-standard location where you have
> installed wxwidgets). For example, is WXWIN defined properly to the
> location where you have installed wxWidgets? (I have asked this key
> question before, but so far you have not responded.)
>
> 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
> __
> 


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

Re: [Plplot-devel] Reducing loudness of compiler "Error" messages

[Pedro Vicente]

I have


WXWIN = M:\wx\wxwidgets-3.1.0

in my PATH there is

;%WXWIN%\lib\vc_lib;

but wxwidgets is still not detected

attached make.txt

done with

cmake ".." -G "Visual Studio 
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
-DCMAKE_BUILD_TYPE:STRING="Debug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON 
-DPLD_wxwidgets:BOOL=ON -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib 
-DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF 
> make.txt



I'll debug this when I have some time, hopefully before the release

-Pedro

- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>

To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Laurent Berger" 
<laurent.ber...@univ-lemans.fr>; <plplot-devel@lists.sourceforge.net>

Sent: Saturday, November 12, 2016 4:07 AM
Subject: Reducing loudness of compiler "Error" messages



On 2016-11-12 00:08-0500 Pedro Vicente wrote:


I have a couple suggestions, however

the Cmake output is full of messages like

CMake Error at CMakeLists.txt:18 (enable_language):

No CMAKE_Fortran_COMPILER could be found.

-- Configuring incomplete, errors occurred!

these are not really errors, just features that are not detected, like a 
Fortran compiler


would it be possible to replace this just with a information message , 
like


--detected fortran compiler
--fortran compiler not found


I agree those "Error" messages are too loud for simply an issue with a
missing compiler so ideally it would be good to reduce that loudness.
I will think about methods of doing that, but it may be a bit tricky
so no promises.

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
__


-- The C compiler identification is MSVC 19.0.24213.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- CMake version = 3.6.2
-- CMAKE_SYSTEM_NAME = Windows
-- SH_EXECUTABLE = C:/Program Files/Git/usr/bin/bash.exe
-- Checking whether system has ANSI C header files
-- Looking for 4 include files stdlib.h, ..., float.h
-- Looking for 4 include files stdlib.h, ..., float.h - found
-- Performing Test memchrExists
-- Performing Test memchrExists - Success
-- Performing Test freeExists
-- Performing Test freeExists - Success
-- Check for whether ctype.h macros work on characters with the
  high bit set.
-- High-bit characters - work
-- ANSI C header files - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - not found
-- Looking for include file termios.h
-- Looking for include file termios.h - not found
-- Looking for include file stdint.h
-- Looking for include file stdint.h - found
-- Looking for crt_externs.h
-- Looking for crt_externs.h - not found
-- Performing Test HAVE_SYS_WAIT_H
-- Performing Test HAVE_SYS_WAIT_H - Failed
-- Looking for DIR symbol in sys/types.h;dirent.h
-- Looking for DIR symbol in sys/types.h;dirent.h - not found.
-- Looking for DIR symbol in sys/types.h;sys/ndir.h
-- Looking for DIR symbol in sys/types.h;sys/ndir.h - not found.
-- Looking for DIR symbol in sys/types.h;sys/dir.h
-- Looking for DIR symbol in sys/types.h;sys/dir.h - not found.
-- Looking for DIR symbol in sys/types.h;ndir.h
-- Looking for DIR symbol in sys/types.h;ndir.h - not found.
-- Check for signal return type in 
-- Check for signal handler return type type void  - found
-- Looking for popen
-- Looking for popen - not found
-- Looking for usleep
-- Looking for usleep - not found
-- Looking for nanosleep
-- Looking for nanosleep - not found
-- Looking for mkstemp
-- Looking for mkstemp - not found
-- Looking for mkdtemp
-- Looking for mkdtemp - not found
-- Looking for mkfifo
-- Looking for mkfifo - not found
-- Looking for unlink
-- Looking for unlink - found
-- Looking for _NSGetArgc
-- Looking for _NSGetArgc - not found
-- Looking for isfinite
-- Looking for isfinite - found
-- Looking for finite
-- Looking for finite - not found
-- Looking for isnan
-- Looking for isnan - found
-- Looking for 

Re: [Plplot-devel] Finding wxWidgets

[Pedro Vicente]

>> > Actually, there are still problems finding wxWidgets on your platform

yes, my bad, I don't know how I missed this
My WXWIN is wrong, sorry

I'll try again

-Pedro





- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Laurent Berger" 
<laurent.ber...@univ-lemans.fr>; <plplot-devel@lists.sourceforge.net>
Sent: Saturday, November 12, 2016 4:00 AM
Subject: Re: [Plplot-devel] Finding wxWidgets


> On 2016-11-12 00:08-0500 Pedro Vicente wrote:
>
>> Hi Alan
>>
>> it seems all is ok now
>
>> doing
>
>> $ cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON
>> -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug"
>> -DCMAKE_BUILD_TYPE:STRING="Deb ug" -DBUILD_SHARED_LIBS:BOOL=OFF
>> -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON
>> -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\
>> lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON
>> -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF > make.txt 2>&1
>
>
> Actually, there are still problems finding wxWidgets on your platform.
> Specifically, from the make.txt file you sent you have the following
> (bad) find results:
>
> -- wxWidgets_FOUND   : FALSE
> -- wxWidgets_INCLUDE_DIRS: -- wxWidgets_LIBRARY_DIRS: --  
> wxWidgets_LIBRARIES   : -- wxWidgets_CXX_FLAGS   : --  
> wxWidgets_USE_FILE: UsewxWidgets
> -- WARNING: wxWidgets or its libraries not found so setting all wxwidgets 
> devices to OFF.
>
> CMake is pretty good at finding libraries installed in standard
> locations so the first thing I suggest you try is to drop the options
> above that set wxWidgets_ROOT_DIR and wxWidgets_LIB_DIR.  But if that
> doesn't work (i.e., wxWidgets_FOUND is still FALSE). then you should
> consider the large likelihood that those variables are set incorrectly
> (i.e., do not point to the non-standard location where you have
> installed wxwidgets). For example, is WXWIN defined properly to the
> location where you have installed wxWidgets? (I have asked this key
> question before, but so far you have not responded.)
>
> 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
> __
> 


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

Re: [Plplot-devel] Finding wxWidgets

[Pedro Vicente]

Hi Alan

it seems all is ok now

doing


$ cmake ".." -G "Visual Studio 
14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" 
-DCMAKE_BUILD_TYPE:STRING="Deb 
ug" -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON 
-DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\ 
lib\vc_lib -DwxWidgets_CONFIGURATION=mswud -DENABLE_MIX_CXX=ON -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF 
> make.txt 2>&1


and then building

== Build: 86 succeeded, 0 failed, 0 up-to-date, 0 skipped ==

good job, thanks


the file make.txt is attached

I have a couple suggestions, however

the Cmake output is full of messages like

CMake Error at CMakeLists.txt:18 (enable_language):

 No CMAKE_Fortran_COMPILER could be found.

-- Configuring incomplete, errors occurred!

these are not really errors, just features that are not detected, like a 
Fortran compiler


would it be possible to replace this just with a information message , like

--detected fortran compiler
--fortran compiler not found


-Pedro


- Original Message - 
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>; "Phil Rosenberg" 
<p.d.rosenb...@gmail.com>; "Laurent Berger" <laurent.ber...@univ-lemans.fr>; 
<plplot-devel@lists.sourceforge.net>

Sent: Wednesday, October 19, 2016 8:56 PM
Subject: Re: [Plplot-devel] Finding wxWidgets



N.B. I have just (commit 3ab6396) updated the PLplot wxWidgets find
module again to conform (identically except for one necessary line) to
the latest (CMake-3.7.0-rc2) official version.  See the commit log
message for a description of the changes in the PLplot version of this
find module (which we are maintaining separately from the official
version since that version is being actively maintained and many of
our users are using a CMake version that is earlier than
CMake-3.7.0-rc2 so would access a buggy version of this find module
unless we supply the latest version like this).

I am pretty sure this latest version will work fine for everybody
(since it is maintained by the CMake developer team who are responding
so actively to bug reports concerning it), but further tests by
everybody to confirm good wxWidgets find results using our latest
master branch would be much appreciated.

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
__


-- The C compiler identification is MSVC 19.0.24213.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- CMake version = 3.6.2
-- CMAKE_SYSTEM_NAME = Windows
-- SH_EXECUTABLE = C:/Program Files/Git/usr/bin/bash.exe
-- Checking whether system has ANSI C header files
-- Looking for 4 include files stdlib.h, ..., float.h
-- Looking for 4 include files stdlib.h, ..., float.h - found
-- Performing Test memchrExists
-- Performing Test memchrExists - Success
-- Performing Test freeExists
-- Performing Test freeExists - Success
-- Check for whether ctype.h macros work on characters with the
  high bit set.
-- High-bit characters - work
-- ANSI C header files - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - not found
-- Looking for include file termios.h
-- Looking for include file termios.h - not found
-- Looking for include file stdint.h
-- Looking for include file stdint.h - found
-- Looking for crt_externs.h
-- Looking for crt_externs.h - not found
-- Performing Test HAVE_SYS_WAIT_H
-- Performing Test HAVE_SYS_WAIT_H - Failed
-- Looking for DIR symbol in sys/types.h;dirent.h
-- Looking for DIR symbol in sys/types.h;dirent.h - not found.
-- Looking for DIR symbol in sys/types.h;sys/ndir.h
-- Looking for DIR symbol in sys/types.h;sys/ndir.h - not found.
-- Looking for DIR symbol in sys/types.h;sys/dir.h
-- Looking for DIR symbol in sys/types.h;sys/dir.h - not found.
-- Looking for DIR symbol in sys/types.h;ndir.h
-- Looking for DIR symbol in sys/types.h;ndir.h - not found.
-- Check for signal return type in 
-- Check for signal handler return type type void  - found
-- Looking for popen
-- Looking for popen - not found
-- Looki