Hi Alan, all: Would this change require re-writing the perl interface to
the 2D functions? Would this be required right away, or would there be
backwards compatible variants left around to ease the transition?
It might be useful to know which demos are affected by this.
UCAR - COSMIC, Tel. (303) 497-2611
On Tue, 16 Feb 2010, Alan W. Irwin wrote:
> On 2010-02-15 14:10-0500 Hazen Babcock wrote:
>> David MacMahon wrote:
>>> Adds support for arbitrary storage of 2D user data. This is very
>>> similar to the technique employed by some existing functions (e.g.
>>> plfcont and plfshade) that use "evaluator" functions to access 2D user
>>> data that is stored in an arbtrary format. The new approach extends
>>> the concept of a user-supplied (or predefined) "evaluator" function to a
>>> group of user-supplied (or predefined) "operator" functions. The
>>> operator functions provide for various operations on the arbitrarily
>>> stored 2D data including: get, set, +=, -=, *=, /=, isnan, and minmax.
>>> To facilitate the passing of an entire family of operator functions (via
>>> function pointers), a plf2ops_t structure is defined to contain a
>>> pointer to each type of operator function. Predefined operator
>>> functions are defined for several common 2D data storage techniques.
>>> Variables (of type plf2ops_t) containing function pointers for these
>>> operator functions are also defined.
>>> New variants of functions that accept 2D data are created. The new
>>> variants accept the 2D data as two parameters: a pointer to a plf2ops_t
>>> structure containing (pointers to) suitable operator functions and a
>>> PLPointer to the actual 2D data store. Existing functions that accept
>>> 2D data are modified to simply pass their parameters to the
>>> corresponding new variant of the function, along with a pointer to the
>>> suitable predefined plf2ops_t stucture of operator function pointers.
>>> The list of functions for which new variants are created is:
>>> c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc, c_plot3dcl,
>>> c_plsurf3d, and c_plsurf3dl, and c_plgriddata. The new variants are
>>> named the same as their corresponding existing function except that the
>>> "c_" prefix is changed to "plf" (e.g. the new variant of c_plmesh is
>>> called plfmesh).
>>> Adds plfvect declaration to plplot.h and changes the names (and only the
>>> names) of some plfvect arguments to make them slightly clearer. In
>>> order to maintain backwards API compatibility, this function and the
>>> other existing functions that use "evaluator" functions are NOT changed
>>> to use the new operator functions.
>>> Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d.
>>> Moves the definitions of pltr2f (already declared in plplot.h) from the
>>> sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c.
>>> Removes pltr0f declaration from plplot.h.
>>> bindings/f77/sccont.c | 182 ----------------------
>>> bindings/f95/sccont.c | 182 ----------------------
>>> include/plplot.h | 196 +++++++++++++++++++++++--
>>> src/CMakeLists.txt | 1 +
>>> src/plcont.c | 207 +++++++++++++++++++++++++-
>>> src/plf2ops.c | 397 +++++++++++++++++++++++++++++++++++++++++++++++++
>>> src/plgridd.c | 119 ++++++++-------
>>> src/plimage.c | 16 ++-
>>> src/plot3d.c | 212 +++++++++++++++++----------
>>> src/plshade.c | 8 +-
>>> src/plvect.c | 17 +--
>>> 11 files changed, 1004 insertions(+), 533 deletions(-)
>>> create mode 100644 src/plf2ops.c
>> Unless anyone objects I will test & commit this change in about a week.
> I think we need more time than that. How about two weeks, instead? It
> concerns me there has been no discussion of this API since David sent in the
> patch. If you like it please say so! Of course, if you don't like it, say
> so as well!
> I want to emphasize there was consensus on list (lead by Maurice) that an
> API to handle arbitrary 2D data storage was well worth having, and I am
> certainly willing to go along with that major change. However, I think it is
> important for everyone with good C skills here (that let's me out!) to take
> a good look at the overview of this implementation to be sure this new API
> is right for our needs. My point is there is going to be a lot of work
> propagating this to all our languages, updating our standard examples in all
> languages to use the new API, and also documenting the new API. So I ask
> for a thorough review of the new API in the next two weeks by those with
> good C skills.
> Hazen, by all means test the patch as well to make sure the implementation
> of the new API actually builds. But you should probably hold off on
> committing until everyone competent has had a chance to review the API to
> make sure this is the 2D array handling we want to have for the forseeable
> PLplot future.
> Dave, I thank you for your implementation work. It takes courage to be the
> first to implement something that is going to be thoroughly (I hope)
> reviewed by others, and I thank you for that courage!
> 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
> Linux-powered Science
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> Plplot-devel mailing list