On 2011-03-17 20:09-0000 Andrew Ross wrote: > On Wed, Mar 16, 2011 at 10:55:04AM -0700, Alan Irwin wrote: >> On 2011-03-16 09:38-0000 Andrew Ross wrote: >> >>> Well one thing that immediately springs to mind is removing the contents of >>> src/pldeprecated.c . >> >> Hi Andrew: >> >> Yes, please! We have long given notice in this case so there is no >> question. And adjust doc/docbook/src/api-obsolete.xml accordingly >> while you are at it. > > Done. > >> >>> There may be other API changes that we have discussed. It would be worth a >>> trawl back through the archives. >> >> Scanning through headers for some keywords may give some ideas. For >> example, I recently noticed in bindings/c++/plstream.h a whole list of >> functions with the comment >> >> // Deprecated versions of methods which use PLINT instead of bool >> >> Is it time for you to remove those? > > I'll think about this one. > >> Also, searches for "deprecated", "compatability", and "backwards" in >> include/*.h show a number of possibilities for removal. > > I've removed a number of macros (e.g. for plcol) which have been marked as > obsolete for some time. Plplot code + examples updated accordingly. > >> The other question is whether mention of "deprecated" in the source >> code is sufficient notice to our users. For example, you might want >> to ease them into these removals by making the removals by default, >> but give them an option PL_DEPRECATED to keep all the old cruft just >> for this release with a well-publicized promise to remove that option >> (and all the associated cruft) early in the next release cycle. OTOH, >> you might not want to do that because it extends the period of >> uncertainty, gives more chance for errors to creep in due to that >> extra complication, and those who want to cling to the old ways will >> do so until the last minute in any case. > > I've moved a number of such functions into pldeprecated and added a > runtime warning. This file (and associated C++ and fortran bindings) are > wrapped in #ifdef PL_DEPRECATED. You need to explicitly add this to > the cmake command line to get support. This should push users into > updating code. This puts a formal system in place for deprecating > functions and then removing them at a later release. > >> I am going to leave all of these decisions (and the implementation and >> timing of that implementation) to you because I trust your judgement >> more than mine on these tricky API matters, and I also still have lots >> of time-consuming stuff left on my PLplot agenda before the release of >> 5.9.8 including extensive testing on the Linux, wine/MinGW/MSYS, >> wine/MinGW, and possibly even wine/Cygwin platforms. > > Please test this. User reports useful too. This is quite a change and > a number of the old functions such as plcol still appeared dotted > around the plplot code so I suspect users may be affected too.
Wow! Thanks for all this extirpation and deprecation work! As of revision 11659 I have done some additional plcol extirpation/replacement by plcol0, and dealt with some independent bit-rot revealed by my preliminary tests. I have just completed 7 comprehensive tests for the shared configuration type. These consist of ctest, and 3 versions (build tree, installed examples tree and traditional installed examples tree) of the test_noninteractive and test_interactive targets. The results show no obvious errors. Furthermore, grep -v 'java/x' \ ../comprehensive_test_disposeable/shared/output_tree/*.out |\ grep -v problems | \ grep -v WARNING | \ grep -v 'x[0-9][0-9].java:' | \ grep -i warning (where all the -v stanzas are to get rid of java warnings, cmake WARNINGs, and PLplot run-time WARNING messages) show no build-time warnings from C/C++ compilers (a nice improvement!), and only gives this remaining stupid octave run-time warnings: ../comprehensive_test_disposeable/shared/output_tree/ctest.out:6: warning: split is obsolete and will be removed from a future version of Octave; please use strsplit instead etc. I think changing split to strsplit in plplot_test/test_octave.sh.in should fix this octave run-time issue, but I don't understand the strsplit syntax for octave. Would you have a go at that change, please, to remove this irritating warning? Here is the current status of the languages that don't have a perfect diff report: x29c octave Missing examples : 19 Differing postscript output : Missing stdout : Differing stdout : ada Missing examples : 33 Differing postscript output : 26 27 Missing stdout : Differing stdout : adathick Missing examples : 33 Differing postscript output : 26 27 Missing stdout : Differing stdout : ocaml Missing examples : 33 Differing postscript output : Missing stdout : Differing stdout : lua Missing examples : 33 Differing postscript output : 04 19 26 Missing stdout : Differing stdout : d Missing examples : 33 Differing postscript output : 04 26 Missing stdout : Differing stdout : Jerry has recently done all the hard pllegend, plstring, and plstring3 API work so the remaining Ada examples 26, 27, and 33 issues should be straightforward to fix for him, and similarly for Hez and OCaml example 33. I am going to try to perfect lua in the next day or so (except for example 19). So the difference issues should continue to be reduced in the next little while. I am pleased with all this progress toward what I hope is going to be a perfect diff report for this 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
