> The attached patch should include all our commits and the conflict > fix. Jim and Alan and anyone else interested in testing this can you > please do the following steps > git checkout master > git fetch > git merge origin master --ff-only > git branch wxAndBufTestMaster > git checkout wxAndBufTestMaster > git am < wxAndBuf.patch > git branch wxAndBufTestWorking
Instead of the bare git branch commands above (which I am not sure would work), I simply use git checkout -b <newbranchname> to create a new branch and check it out. > > Then do any work on the wxAndBuffTestWorking branch and if we need to > create any futher patches do it via > git format-patch wxAndBuffTestMaster --stdout > mypatch.patch > > Jim if you have already done further work after your path then can I > recommend that you create a patch of just those commits and apply them > to wxAndBuffTestWorking or rebase your working branch with > wxAndBufTestMaster. Please only do the latter if it doesn't cause a > conflict otherwise we will end up with another conflict resolution > that hasn't been propagated around. > > I hope the reasoning for this makes sense. This will preserve the > conflict merge, but also allow Jim and I and anyone else to perform > any fixes independently and pass new patches if needed. Then when > everything is done I will hopefully have a branch containing all > patches and commits which I can ff merge into master. > > Jim in particular, once you have followed the steps above, can you > check that the conflict merge and the commits I skipped have not > introduced any problems. > > I hope the above step by step recipe isn't patronising. But if we are > all working within the same structure it will make things easier to > deal with. Of course the names of the branches doesn't matter. Much better to be explicit like above as we all learn git together. I did the above, and the integrated patch applied cleanly, and the wxwidgets target built without issues. Also, many of the examples ran without issues. So this whole integrated series is a huge improvement over what I saw before so IMPORTANT... I strongly encourage you to go ahead and push this whole integrated series of commits to master. After that push then you and Jim should fix the remaining wxwidgets/plbuf issues that I mention below in the normal git way before the release date. Here are some issues I noticed where this new wxwidgets device does not yet achieve the quality of the old device. 1. Page up and down are great for page navigation but please also add back the old navigation behaviour where hitting the enter key either moves to the next page if it exists or else exits. 2. Obvious rendering issues that did not occur for the old wxwidgets device. I have looked at every page of every standard example, and here are the principal issues I noticed. * Example 3 has a badly misplaced label (although strangely the equivalent example 14 page does not have this issue). * Examples 8, 11, 16, 19 (last page), 20 (at least first page), 21 (second page), 24, 25, 27 (some but not all pages), 30, 32, and 33. There is a substantially incorrect size part of each of these plot pages. If you use a large geometry so you can see what is going on, e.g., examples/c/x08c -dev wxwidgets -geometry 1200x800 you can see that "small" part of the plot is crammed into a tiny little area at the top left of the plot. * Example 9 first page. Contour labels are unreadable because they are much too small. * Example 17. Fails to erase each time automatic rescaling of the plot occurs as the plot proceeds. And fails to show intermediate results. So the end result is the smoothly evolving nature of this plot is lost and all intermediate results are simply crammed on top of each other for the final plot. See any of the xwin, xcairo, or qtwidget devices to see how this plot is supposed to look. Actually, the logic in the old wxwidgets device rendered this example correctly so I suggest you simply reuse that logic (if possible) to restore the correct behaviour. * Example 23. Text much too small. * Example 28 (last page) transformation issues for 3D text. (Note this is the only place I noticed such issues in all our examples so this is a huge improvement over last time.) That's the end of the rendering issues that are specific to the new wxwidgets device. However, I also noticed A "no such file" message when I attempt to move to beyond the first page of the example 20 plot, but that now occurs for all devices so I am pretty sure this is a master branch regression and nothing to do with wxwidgets/plbuf, and I will look into it further. @Phil: I assume you are going to immediately push this integrated patch to master. Then, ideally I hope you are able to deal with all the above issues in the normal git way before the release. However, if you have to set priorities, then the highest priority for me would be the page navigation fix and the fix for a large number of different pages with a portion of the page plotted with very small size. If you don't get those two issues fixed before release I would be tempted to label wxwidgets as experimental in the release notes and also disable it by default (i.e, the user would have to explicitly ask for it with the -DPLD_wxwidgets=ON option). But to my mind the other rendering issues are not as critical and could be dealt with post release instead if necessary with -DPLD_wxwidgets defaulting to ON rather than OFF for the release. @Jim: Assuming Phil does the immediate push as I suggest above, then I suggest you follow up with full new plbuf-based plmeta and plrender functionality as quickly as possible (any time until next weekend when the soft freeze will occur, but the earlier the better). Once we have the new plmeta and plrender capabilities in place that opens a huge opportunity to test plbuf independently without depending on wxwidgets. In other words, it will give you an opportunity to fix plbuf bugs quicker than when trying to deal with some of the above issues (where it is not clear whether those symptoms are due to wxwidgets issues or plbuf issues). 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
