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
