Hi Alan, Hez, I had to plough through a myriad of mails, so my response was a bit premature/late. Okay, I see it has been solved. My task will then be to propagate the recent changes to the Fortran 77/95 and Tcl examples, if not done yet.
Regards, Arjen On 2010-05-03 08:58, Arjen Markus wrote: > Hi Alan, Hez, > > I will have a look at the interface for Tcl - the coordinate > transformation is a bit roundabout there, as I need a C function > to call the actual Tcl procedure for the transformation. Possibly > this is causing the empty page. My guess is the same holds for > the Python bindings. > > Regards, > > Arjen > > On 2010-05-01 23:30, Alan W. Irwin wrote: >> 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 >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
