Re: [Plplot-devel] Linux OnCreate delay bug -- solution
On 2017-01-04 20:08-0500 Pedro Vicente wrote: >>> Yes that is the expected output, although the window titles should be >>> different. But actually it may be nicer to at least use 2 different curves. >>> An easy change. What do you think? > > I don't have an opinion on the plot itself, but regarding the > test_c_wxwidgets test, it would be a good idea to put a simple > sleep(1) > betwwen each test so we can see that it's doing what it should do Hi Pedro: That workaround would work for both -dev wxwidgets (or more likely the wxPLViewer application that that device communciates with) and -dev wingcc. But since a common script is used for all interactive device tests, that workaround would put an unnecessary delay into the results for -dev xwin, tk, xcairo, and qtwidget. Therefore in this case I prefer the definitive fix for these -np issues for wxPLViewer and -dev wingcc. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
On 2017-01-05 00:54- p.d.rosenb...@gmail.com wrote: > 1. Yes [two plots are] expected output, although the window titles should be different. But actually it may be nicer to at least use 2 different curves. An easy change. What do you think? Good idea. So, yes please! > 2. Will do [README.release paragraph] plus this all really needs properly > adding to the docs. I will try to do that asap. Thanks. README.release paragraph is release-essential. DocBook update concerning wxwidgets is a "would-be-wonderful". Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] A pre release buffer bug
On 2017-01-05 00:48- p.d.rosenb...@gmail.com wrote: > Hi All, but mostly aimed at Alan I guess > > I found a bug today based on some of my code. I have some code that uses wxWidgets then I was attempting to use plreplot to write to a file. But I was getting just a black screen. After a first look I think the problem is the plclear calls are not being logged to the buffer so the clearing to a white background isn't happening so the black lines I used aren't showing up. If possible I'd like to get this fixed this release cycle if only because I will be sharing the code I'm writing with others and it would be easier for me if I could direct other users to the current release rather than the git version. > Would that be okay? Hi Phil: That decision critically depends on what your fix touches. So please go ahead and make the definitive fix (i.e., touching everything that is required for a definitive fix as opposed to, e.g., working around some bug in the plbuf part of PLplot using a temporary wxwidgets fix) in a private topic branch. Then share that fix on list, and we can make the push decision based on that actual fix then. By the way, please take a look at the first page of example 16 (whose -dev wxwidgets background is currently an incorrect black rather than the correct white) on Linux platforms at least. This problem sounds quite similar to your own so I am hoping when you have the definitive fix for your issue, the example 16 issue will also be fixed. 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
>> 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 vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.li
Re: [Plplot-devel] 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 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] A pre release buffer bug
Hi All, but mostly aimed at Alan I guess I found a bug today based on some of my code. I have some code that uses wxWidgets then I was attempting to use plreplot to write to a file. But I was getting just a black screen. After a first look I think the problem is the plclear calls are not being logged to the buffer so the clearing to a white background isn't happening so the black lines I used aren't showing up. If possible I'd like to get this fixed this release cycle if only because I will be sharing the code I'm writing with others and it would be easier for me if I could direct other users to the current release rather than the git version. Would that be okay? Sent from my Windows 10 phone -- 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
Hi Alan I agree it would be good to look at this pre release. It's on my to do list for asap. Sent from my Windows 10 phone From: Alan W. Irwin Sent: 04 January 2017 20:37 To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list Subject: Re: [Plplot-devel] legend and label using wxWidgets On 2016-12-28 23:19+0100 Laurent Berger wrote: > wxwidgets commit 0bf38e1 x04 y axis label is good > (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be) > > wxwidgets commit 49000def x04 y axis label is false > (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3) Hi Phil: Assuming (subject to Pedro's further extensive testing) that you have found a good fix for that bug he had discovered, then the only remaining potentially release critical issue for the wxwidgets-related components of PLplot is the issue discovered by Laurent above. So to learn more about what Laurent reported above, I described those two commits as follows: software@raven> git clone https://github.com/wxWidgets/wxWidgets.git wxwidgets.git software@raven> cd wxwidgets.git software@raven> git branch * master software@raven> git describe 0bf38e1 v3.1.0-620-g0bf38e1 software@raven> git describe 49000def v3.1.0-621-g49000de So it is clear from these results that Laurent already bisected this issue with the 621st commit beyond the last official release (3.1.0) of wxwidgets showing the issue for the first time. And since this is an issue that will not affect any user of an official wxwidgets release at this time, that gives us a good excuse to do nothing at this time if the potential fix is going to be intrusive. Of course, this issue will affect our users as soon as the next wxwidgets official release is out so it would be nice at this time for you to (a) confirm the above results for 0bf38e1 and 49000def from Laurent and figure out what the issue is. If it turns out to be a wxwidgets regression introduced for 49000def it would be good for you to draw this quickly to the attention of the wxwidgets developers so they can fix that regression before their next official release to avoid making life difficult for PLplot wxwidgets users. But if it turns out to be our problem, then please prepare the fix and use your best judgement (depending on, e.g., whether the fix is more or less intrusive than the fix you just made) whether to push it now or wait until after the 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 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
On 2017-01-04 16:21-0500 Pedro Vicente wrote: > I did [on CentOS] > make VERBOSE=1 test_c_wxwidgets >& out.txt & > > there were no plots, just black and grey windows that quickly showed and > disappeared > > output is attached As you can see for yourself there are no warnings or errors so that looks promising. However, you should skim those debug results (which I did not do myself) to make sure there is nothing unexpected going on for any of those examples that are run by that test. Those "black and grey windows" are what I see here as well. They are apparently an artifact of the current wxPLViewer implementation where nothing is displayed for that GUI until the buffer representing all the plot activity for a particular page has been accumulated, then at EOP that display is immediately removed again. That is fine for normal interactive use where you are clicking on the GUI to move through the pages. But the effect for the -np (no pause) option is the page flashes on the screen for a microsec or so, and you end up only seeing that weird effect. If I recall correctly from when I was testing on -dev wingcc on the Wine version of Windows there was a similar weird effect with -np there (which was likely due to the same cause). As a low-priority item I have asked Phil to fix this -np issue for -dev wxwidgets by following the buffer models used by -dev xwin, -dev xcairo, and -dev qtwidget which display the buffer results as they become available for the test_c_xwin, test_c_xcairo, and test_c_qtwidget targets rather than waiting until the buffer has been accumulated for the entire page. But since I plan to greatly improve the efficiency of the IPC between -dev wxwidgets and wxPLViewer in any case right after this release I may end up fixing the -np issue myself at the same time since the two issues are likely closely related. And someone should similarly fix -dev wingcc. But meanwhile even with these weird-looking results for the -np option for -dev wxwidgets and -dev wingcc, that option is still extremely useful for the interactive tests associated with building the test_c_wxwidgets and test_c_wingcc targets because it means you test several examples (rather than just one or two) for such obvious run-time issues as segfaults, and you don't have to babysit the test by constantly clicking on the GUI as the test goes through those several examples. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
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/plplot-plplot/build /data/home002/p
Re: [Plplot-devel] legend and label using wxWidgets
On 2016-12-28 23:19+0100 Laurent Berger wrote: > wxwidgets commit 0bf38e1 x04 y axis label is good > (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be) > > wxwidgets commit 49000def x04 y axis label is false > (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3) Hi Phil: Assuming (subject to Pedro's further extensive testing) that you have found a good fix for that bug he had discovered, then the only remaining potentially release critical issue for the wxwidgets-related components of PLplot is the issue discovered by Laurent above. So to learn more about what Laurent reported above, I described those two commits as follows: software@raven> git clone https://github.com/wxWidgets/wxWidgets.git wxwidgets.git software@raven> cd wxwidgets.git software@raven> git branch * master software@raven> git describe 0bf38e1 v3.1.0-620-g0bf38e1 software@raven> git describe 49000def v3.1.0-621-g49000de So it is clear from these results that Laurent already bisected this issue with the 621st commit beyond the last official release (3.1.0) of wxwidgets showing the issue for the first time. And since this is an issue that will not affect any user of an official wxwidgets release at this time, that gives us a good excuse to do nothing at this time if the potential fix is going to be intrusive. Of course, this issue will affect our users as soon as the next wxwidgets official release is out so it would be nice at this time for you to (a) confirm the above results for 0bf38e1 and 49000def from Laurent and figure out what the issue is. If it turns out to be a wxwidgets regression introduced for 49000def it would be good for you to draw this quickly to the attention of the wxwidgets developers so they can fix that regression before their next official release to avoid making life difficult for PLplot wxwidgets users. But if it turns out to be our problem, then please prepare the fix and use your best judgement (depending on, e.g., whether the fix is more or less intrusive than the fix you just made) whether to push it now or wait until after the 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 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
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 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
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 > 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
Re: [Plplot-devel] Using wxWidgets
Hello Laurent If you grab the latest version of PLPlot from the git repo then you should find that the API for wxWidgets is as it was and Pedro's problems are now hopefully also fixed. There should be no need to apply Pedro's patch. If you find that your existing code does not work for any reason then please let me know and I will ensure that this is fixed before the next release. All the best Phil On 27 December 2016 at 15:27, Laurent Berger wrote: > Problem is my compiler said > > 3>c:\users\laurent.pc-laurent-visi\documents\visual studio > 2013\wxopencv\wxopencvmain\courbeplplot.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 > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Linux OnCreate delay bug -- solution
Just to add that I've just tested on my Ubuntu 16.04 system logging on remotely using Cygwin ssh and X11 server and n my work CentOS system logging on directly. Everything seems fine! Hopefully you will both get the same results Pedro and Alan. Phil On 4 January 2017 at 14:26, Phil Rosenberg 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 > 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 -- 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
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 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 -- 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