On 2010-05-01 14:43-0400 Hezekiah M. Carty wrote:

> Alan,
>
> Thank you for looking in to this.  My reason for making that change
> was that it doesn't make sense to me in a general context to require
> that both arguments are non-NULL - if the pltr function does not
> require any extra data to be passed in then it seems strange to
> require a non-NULL pltr_data argument.  This holds for any language.
>
> This check:
>
>    if ( pltr == NULL && plsc->coordinate_transform == NULL )
>        rectangular = 1;
>
> had the pltr_data check removed because it causes rendering errors if
> pltr or plsc->coordinate_transform is defined and the transform is
> non-rectangular.  I ran in to this when generating the example plot I
> sent to the list with my message about global transform support.  If
> the pltr_data check == NULL check is included then cracks and gaps
> appear in the shaded contours.
>
> The other checks for both pltr and pltr_data lead to similar errors as
> they will disregard any pltr function which does not require extra
> data to be passed in.  This can lead to some very confusing and
> difficult to track down bugs in users' plotting code.
>
> I don't know Python or Tcl well enough to see where this affects their
> code, but I think that it is a bug in either the bindings or the
> relevant Python and Tcl examples if they fail with these changes,
> particularly when other language bindings seem to handle the change
> gracefully.  Unfortunately I haven't had any luck in the past when
> trying to build the Python or Tcl bindings on my system.
>
> In summary, I think that the changes reverted in revision 10959 are
> important bug fixes and should be re-applied to PLplot, even though it
> likely requires changes to the Python and Tcl bindings.

Your arguments above sound like good ones to me, but the problem is that the
Python and Tcl bindings are important and long-standing ones that a lot of
people use so we don't want to clobber their ability to make shade plots.
That regression would become especially critical just before a release. So I
think we really do have to fix our Python and Tcl bindings so they are no
longer sensitive to dropping the pltr_data checks before we actually did
drop those checks.

At the same time I realize those pltr_data checks are messing up some
interesting uses of your new transformation work.  So clearly this is an
important issue that we hopefully will be able to solve before the release,
and I encourage everyone here with Python and Tcl bindings expertise to help
us do that.

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
__________________________

------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to