On Sat, May 1, 2010 at 12:58 PM, Alan W. Irwin
<ir...@beluga.phys.uvic.ca> wrote:
> On 2010-04-29 14:46-0700 Alan W. Irwin wrote:
>
>> On 2010-04-29 14:22-0700 Alan W. Irwin wrote:
>>
>>> python
>>> Missing examples :
>>> Differing postscript output : 06 07 15 19 21
>>> Missing stdout :
>>> Differing stdout :
>>> tcl
>>> Missing examples :
>>> Differing postscript output : 06 07 15 16 19 21 28
>>> Missing stdout :
>>> Differing stdout : 21
>>
>> I have looked further at the 15 and 16 issues. Interestingly, the errors
>> for example 15 (empty first page, mostly empty second) are identical for
>> python and tcl. For tcl example 16, the issue is a mostly empty first page.
>> My guess is something got badly clobbered with python and tcl with the
>> recent extensive API additions for either arbitrary organization of 2D data
>> or arbitrary transformation of world coordinates. Dave and Hez, will
>> either/both of you have a look at this?
>
> My apologies to Dave and Hez who may have been looking in the wrong
> direction due to the above speculation. I should have used svn-bisect right
> away rather than speculating. That showed the problem was caused by Hez's
> revision 10895 which just changed 3 lines of plshade.c to remove tests on
> whether pltr_data was NULL. It turns out those tests are important for both
> our python and tcl bindings. I reinstated the tests for revision 10959 and
> the result was substantially improved python and tcl differences (results
> for examples 15 and 21 became consistent with C for python while results for
> examples 15 and 16 became consistent with C for tcl). Here are the current
> python and tcl results in full.
>
> <cut>
>
> Hez, from your revision 10895 commit message you likely just wanted to make
> it a little easier to use your OCaml bindings. However, this change to
> ignore the pltr_data tests for NULL obviously affected the python and tcl
> example results (for reasons I haven't looked into), and our C users may also
> depend on these tests being made. So if you would like to pursue this idea
> further, you should try to figure out how to deal with the python and tcl
> issues and also consider the significance of this change for our C users.
>
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.
Hez
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
