Here are my ToDo lists for some remaining things I want to do with the Fortran binding that just landed and also some further general PLplot issues I want to address before the release. None of these topics are release critical, but they are all in the "would be nice" category.
I assume most of these issues are "only" going to take from just a few hours to a few days each to address, but there sure are a lot of them! Anyhow, I would like to get through all the Fortran ones and most of the others before even starting to plan when the forthcoming release of 5.12.0 should occur (with the "12" in honor of the major change in the Fortran binding and examples). ____________________________________________________ Fortran binding: * Tidy/beautify our Fortran code which is currently in an identation mess. I am currently researching a GPL'd tool called f90ppr to do this. It's a dead project (no development for more than a decade), but a lot of people swear by it, and I could easily revive it again by storing its Fortran 90 (!) source code plus a CMake-based build system I plan to implement myself as a subproject under the epa_build umbrella. * Replace all use of plflt by test_flt in the examples and set this type for arbitrary precision testing purposes in plplot.f90. We still provide plflt for backwards compatibility for users, but it is strongly deprecated so I want it removed from our examples. However, an arbitrary kind values called test_flt should be of little interest to users because of its name, and it is extremely useful for developmental testing of our examples to force the case where the example floating-point precision disagrees with PLFLT configured for our C library. * Redo sed script to generate included_plplot_parameters.f90 * Systematically update testing of all dimensions when there are multiple associated arrays in the argument list following what is done in bindings/swig-support/plplotcapi.i. Ultimately, there should be a complete list of functions in README.release where the API has been changed because of this. (Note, this topic was recently discussed on list, and the consensus is this is the correct way to test dimension consistency.) * Add plcont, plshade, and plshades real Fortran callback API (as opposed to the xg, and yg 1D and 2D arguments we have always used before to simulate Fortran callback functionality. (We will continue to support those variants for backwards compatibility.) * Test the routines that have callback arguments with every variant of the callbacks (to make sure there are no typographical errors in our interface for the callbacks). ____________________________________________________ Other PLplot issues I have noticed and would like to fix "soon". * search for trailing whitespace and fix it. Arjen's editor caught a lot of those during our collaboration on the new Fortran binding private topic branch, but I am sure there are more that need to be addressed. After the issue is fixed, I vaguely recall there is a git configuration item that can automatically keep our source code clean of such issues. But just running a trailing-whitespace-cleanup script periodicially might be a better solution. * c_plparseopts API change (that function messes with its arguments a lot by design so that const attribute should be removed.) * All returned values from functions changed from type of int to PLINT. This affects c_plparseopts and plsetopt amongst others? * test_diff_psc generates two runs of the examples to generate the results. Fix that build-system bug which I very likely introduced myself. * test blank in source, build, and install directory names. * Documentation problems I am currently aware of that need addressing. i. All changes above, e.g., plparsopts, plsetopt changes ii. plerrx, plerry, plurals iii. plimage zmin, zmax 0, 0 (this is from handwritten notes, and I am not sure what the issue is there). iv. Add plpat documentation v. plmapstring is not tested in any example. vi. Callback documentation should be done consistently with named arguments and discussion of each of those arguments. I need to check what has already been done for plfill, pltr0, pltr1, and pltr2 callbacks and fix those if required, but this improvement definitely is required for the documentation of the label_func callback (currently documented without last argument within the plslabelfunc documentation), the coordinate_transform callback (currently documented within the plstransform documentation), and the mapform callback (repeatedly documented without naming arguments for each of the plmap* routines as well as the plmeridians routine). * -dev svg should be used by default for all tests rather than -dev psc since the former is a full-fledged modern device driver that does essentially everything correctly so it tests our C and bindings API's to the limit while the latter often just produces incorrect results (e.g., anything having to do with unicode text, alpha-transparent, gradients, or text size) from our examples so our PostScript difference testing merely assures us that the garbage produced is the same for C and our language bindings. * Lena replaced by Westie as discussed on list. ---------------------------------------------------------------- Post-release * The rare fill issues that occur. This may be promoted to the above "would be nice" category if Phil can come up with even a complicated example I can test here. * Use arbitrary units (mm, pt, and pixels) for -dev svg just to explore what is possible (I have an svg private topic branch for this, but it has been a while since I worked on it). * Remove "c_" prefix. I just realized the current "c_" prefix manipulations are essential for the old_f95 binding and examples. So I don't have to worry about this change until we finally get rid of the old_f95 approach (probably at least several releases from now depending on the reception our new Fortran binding gets from our users.) 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 __________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
