My plan is to have it done by Friday, perhaps sooner.
> On Feb 18, 2015, at 2:04 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > >> On 2015-02-17 22:16-0500 Jim Dishaw wrote: >> >> >>> On Feb 17, 2015, at 3:23 PM, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> >>> wrote: >>> >>> Hi Jim: >>> >>>> On 2015-02-17 13:11-0500 Jim Dishaw wrote: >>>> >>>> Hopefully this patch series will work correctly. I started a new >>> topic branch as recommended. >>> >>> IMPORTANT. Which means your patch series and my subsequent patch >>> to style it are now in the master branch at SourceForge and any further >>> changes you do to plmeta/plbuf should start from a fresh new topic >>> branch based on master tip. >> >> Thanks for the tip. >> >>> Although I am obviously willing to run scripts/style_source.sh myself, >>> I also encourage you to look at the recent thread here concerning how >>> to do that for yourself to get the result of your series of commits to >>> match PLplot code standards. > >> I tried to use the plplot-c-style.el, but I'm not sure it is working >> correctly. Does that file have the correct formatting style? > > Hi Jim: > > Short answer; no. > > As stated in the recent thread (which you should consult for important > directions for building uncrustify) we style our source using > scripts/style-source.sh (which in turns uses uncrustify to do the > majority of the styling although a python script is called as well to > convert all C comments to // style). Aside from the comments, the > uncrustify.cfg file is the one that really controls the style of our > source code. > > At the time we were putting scripts/style-source.sh, I also thought it > might be possible to configure emacs to do approximately the same styling > to reduce the white space changes when we run the script so that was > where plplot-c-style.el came in. However, I could never get it to > even come close to approximating our uncrustify-enforced style so I > don't use it any more. However, if someone who has more knowledge of > emacs than I do could make that approach even work approximately, it > would be quite helpful to our emacs users. > >> >>>> The plot metafile read will generate an output identical to >>> plrender. Visually, the plot is similar to the output generated by >>> plplot directly; however, due to the difference in coordinates the >>> file contents are not identical. >>> >>> For me, this is a big issue for the current code in master tip. I did >>> read the comments in your 6th patch which said this change in >>> coordinates was necessary, but is that really the case? >>> >>> I am concerned you are trying to replicate the old bad behaviour of >>> the plmeta device rather than rewriting plmeta/plrender completely >>> (without that old bad behaviour) using plbuf capabilities. > >> In the long term I don't think it is necessary. My goal for this > version was not to change the behavior that plrender exhibits--I > wanted to avoid turning to many knobs while getting things working. > > Understood. But at the same time if it would simplify your life to > completely abandon support for old plmeta formats or methods, I would > encourage you to do that since it has been years since that device > worked properly. > >> >>> Here is my mental model of what goes on with PLplot coordinates. >>> (Please update/correct this if your recent digging into >>> PLplot code shows you something different is going on.) >>> >>> The user specifies a series of plot commands using a variety of >>> coordinate systems that are available to the user (world coordinates, >>> normalized subpage coordinates, etc.) Then when using any device, that >>> series of plot commands containing a variety of coordinates are >>> transformed into (currently 16-bit) internal physical coordinates >>> which the device driver code linearly transforms into real physical >>> coordinates of the device. > >> I have not untangled the hierarchy of coordinate system > transformations. When I directly used the coordinates from the plmeta > driver, the resulting plots were not rendered correctly. I think I > need to change what is generated by the plmeta driver and that will be > incorporated in the 2015-1 metafile format. > >> >>> >>> So to my mind, if the new plmeta device did no linear transformation >>> from internal physical coordinates to real physical coordinates (i.e, >>> simply stored in the plmeta file the internal physical coordinates >>> associated with each command), and plrender replayed those commands >>> using their associated internal coordinates for <some device> then the >>> "indirect" results from >>> >>> <some_standard_example> -dev plmeta -o test.plm >>> plrender test.plm -dev <some device> >>> >>> should be absolutely identical (by construction of the new plmeta/plrender >>> capability) with the "direct" result >>> >>> <some_standard_example> -dev <some device> >> >> That is also my goal. > > I liked this and all the other answers you gave me above. Thanks for > responding to my questions and good luck reaching that goal! > > You implied above this is likely a long-term goal, but just in case I > should still ask as release manager if there is any chance of meeting > that goal by this next weekend (when the soft freeze will occur for > the release). If indirect and direct results are designed to be > exactly the same with plmeta/plrender, then any deviation from that > result for one of our standard examples becomes a stringent test of > plbuf capabilities, and it would be nice to have access to such > stringent tests for the test week leading up to the release. However, > this really is a "would be nice" rather than something more urgent so > if you cannot make the soft freeze deadline next weekend, that is > fine. In that case we can just continue to leave plmeta disabled by > default (i.e., the user has to specifically use the -DPLD_plmeta=ON > option) until you realize your goal post-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 > __________________________ ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
