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_WX PLDLLEXPORT > ./include/pldll.h.in: #define PLDLLIMPEXP_WX_DATA( type ) PLDLLEXPORT > type > ./include/pldll.h.in: #define PLDLLIMPEXP_WX PLDLLIMPORT > ./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 second > commit to either quiet this warning if it is spurious or deal with the > bad code logic if that turns out to be the issue, test these two > commits thoroughly on all your platforms including Windows, and fill > in the commit message Tested by: section of the second commit with > that platform list. > > Quick directions again for amending the last commit on a topic branch. > > If a file is changed (i.e., you fixed the above warning). Then stage > that changed file with "git add" and get that change into your last > commit by using "git commit --amend". If there are no file changes, > then simply use "git commit --amend" to modify the commit message of > the last commit. Note amending a commit is very useful if you > have second thoughts about some aspect of it, want to update the > commit message or whatever. But the --amend option only works > on the _last_ commit so make it a very strong habit to review your > last commit completely to make sure it is good before you make another > commit because that second commit makes it impossible to amend > the first. (I used such care this time to amend the first commit > before applying your second commit and amending it.) > > Also, once a commit is published (i.e., pushed to our SF server), then > it should never be amended or changed in any way, i.e., further > changes have to be made using further commits rather than modifying an > existing commit. The reason for that "fundamental courtesy" rule is > someone could clone the SF git repository, and branch a new topic > branch off of any commit they desire, but if you subsequently modify > that particular _public_ branch commit in any way, they get completely > screwed. > > I have attached a tarball containing your two commits (both of which > have been revised by me for this iteration as discussed above). Apply > them both in numerical order to a new topic branch using "git am". If > you get tired of running git am twice by hand in the correct order, > then use "git help am" to figure out how to do that with just one "git > am" command. > > Then generate another iteration consisting of the first > (unchanged by you this time) commit, and the second commit that you revise > as above using > > git format-patch -2 > > Then collect those two files in a tarball using > > tar zcf wxwidgets_experimental_commits2.tar.gz 00* > > and attach that result to a post to this list for Phil to look at > to make sure he understands and approves of the changes in these > two commits. > > 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. > > I will likely check my e-mail again in ~12 hours and again on > Christmas, and the 26th but I will totally understand if I don't here > anything from you until the 27th. However, by early on that date, I > hope you will have prepared the two commits as specified above > including testing on all your platforms. And I hope we can get in > touch with Phil on that date to get his recommendation for what to do > with regard to those two revised commits and the release. > > But right now I feel fairly confident about your two commits because > there exist at least two platforms where they appear to work. But > hopefully you will have considerably expanded that number of "good" > platforms by the 27th! > > 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
