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_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 > 10:54:55: Debug: nanosecs since epoch = 2210970032100417: > wxPLDevice(): leave > 10:54:55: Debug: nanosecs since epoch = 2210970032134179: > plD_init_wxwidgets(): leave > software@raven> ../src/gtk/bitmap.cpp(923): assert "IsOk()" failed in > GetWidth(): invalid bitmap > > So Pedro, my version of your patch should be applied there with > > git am < > /tmp/0001-wxwidgets-binding-fix-for-delayed-OnCreate-event.patch > > You should use that command on a fresh topic branch without your > changes, i.e., latest master from SF. And make sure it is my > version of your patch you apply and not your own patch of the same > name. > > Please use my revision of your patch that way to preserve the style > and line ending > issues I fixed and the tested-by section I inserted in the commit > message > rather than just cherry-picking the visibility fix. > > The next step after that is to build the wxwidgets, wxPLViewer, and > x01c targets and try the experiment above. Assuming you will see the > same > bitmap error as above, then please revise your patch again to > fix that. > > (Just use "git add" to stage additional changes you want to add to > your commit, and "git commit --amend" to add those staged changes to > your commit. This very common git pattern avoids a series of > non-working commits which are successive approximations to the final > working commit.) > > Then follow up by testing the second revision of your patch on all > systems accessible to you by building the test_wxPLplotDemo and > test_c_wxwidgets targets on each of them. (The latter does the above > experiment on a small subset of the examples with all prerequisite > targets built first automatically.) Then send that second revised > version of your patch to Phil and me for more testing/analysis. > > If it passes Phil's tests and mine, AND he likes your new approach, > then I will revise my "Tested by:" section in the commit message > appropriately and push your patch to finally put this > release-critical > issue to rest. > > 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
