Hi Andrew and Phil: On 2012-10-24 09:36+0100 Andrew Ross wrote:
> On Tue, Oct 23, 2012 at 06:11:51AM -0700, phil rosenberg wrote: >> I hadn't noticed the missing Antarctica boundary section, I'm not sure why it should be missing, in one but not the other, but if I'm honest I'm not going to lose too much sleep if you intend to depreciate the old files anyway. Was it missing pre patch? The SourceForge websites (including plplot.sf.net) are now back up so I was able to answer that question. See http://plplot.sourceforge.net/examples-data/demo19/x19.01.png which does show the correct Antarctica boundary (right lower part near the edge of the map) for the code for the last release. So _apparently_ some change you did does compromise how the old maps without shapelibs are rendered when HAVE_SHAPELIB is not #defined. On the other hand, my impression has been the old code has always had difficulty rendering the old maps in a consistent way. If you have been following the Wine thread, I had a case where that old code (before your changes were incorporated) rendered one of the pages of example 19 completely badly with what looks like bits and pieces of other maps rendered on half of the map and the rest of it blank. I just now double checked the Wine run again for that case. (This time done with the new code, but with HAVE_SHAPELIB not #defined at the C level because I haven't built shapelib for Wine yet.) That previous bad page is now rendered fine although the Antarctica boundary problem still occurs on the first page just like it does on Linux with HAVE_SHAPELIB not #defined. So from this result it looks like the new code is at least not making huge errors in rendering like happened for the old code from time to time. And I think the chances are that we will be removing support for the old map formats in any case (see below). So I am not too concerned about the Antartica boundary problem for the old map format case. >> ? >> As for your questions Alan. >> ? >> I don't have a preference about depreciation period. >> ? > > This really boils down to whether we want to force a shapelib > dependency. If we do, then I think we could deprecate the old maps now > and maybe remove in the next but one release, so users of releases > have at least some warning. Otherwise we seem to be committed to > supporting the old version indeterminately to avoid the dependency, > which is probably not wise. I believe the shapelib dependency for plmap (alone!) is not a big issue since the vast majority of PLplot users don't use plmap in any case. Furthermore, the minority that do attempt to use that functionality in a serious way are probably already fairly familiar with mapping software. So the chances are they already know about shapelib and have it installed on their system. Or at least they won't feel that is an onerous requirement especially if installing shapelib gives them access to a blowaway example. As to the blowaway shapefile example, it appears like both of you have a couple of possibilities in mind. So please go for it! If everybody is satisfied that forcing shapelib dependency for plmap is only a matter of time, then what remains is the decision about when/how to force that dependency. In this case, I think we should deprecate now in a realistic way. That is plmap becomes a no-op if HAVE_SHAPELIB not #defined unless the user specifically opts in (with a specific CMake option) to using the code that accesses and uses the old format files. We can decide later when to remove that option and pull the plug on the old data formats and the code that supports that old format depending on user feedback to the opt-in CMake option. For example, if we get no reaction at all (which I think is fairly likely) to this deprecation period which requires opt-in for the old formats, then I think we can safely pull the plug on those old formats for the release after this one. 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 __________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
