Hi Alan,
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
...
> > [...]
> > *** PLPLOT WARNING ***
> > plmaptex is a no-op because shapelib is not available.
> > No matrix operator named "62"
> >
> > So from that last line I am pretty sure that the "62" in
> >
> > $w cmd plmaptex {} "ss/ss64ne_General_Text" 1.0 0.0 0.5
> > "Caffyns\nHeanton\nDown" $minx $maxx $miny $maxy 62
> >
> > in examples/tcl/x19.tcl is the cause of the above matrix operator
> > warning on Linux.
> >
> > That warning message comes from line 382 of bindings/tcl/tclMatrix.c.
> > I notice that for all other error conditions that are handled with
> > Tcl_AppendResult, the returned value is TCL_ERROR, but in this
> > particular case the returned value is NULL. Is that difference in
> > pattern significant?
>
> Hi Arjen:
>
> Never mind. That was a badly informed question. This Tcl_GetMatrixPtr
> routine
> obviously returns a pointer to the specified matrix operator's data so the
> only way to
> signal error conditions is with a NULL pointer.
>
> That means every call to Tcl_GetMatrixPtr should be checked for that NULL
> error
> condition and return TCL_ERROR if that error condition is found. It appears
> that
> bindings/tcl/tclgen.tcl does exactly that (and the generated file
> bindings/tcl/tclgen.c
> bears that out), but bindings/tcl/tclAPI.c is hand crafted so the potential
> was there
> for typographical errors in the error propagation for the call to
> Tcl_GetMatrixPtr.
> Accordingly as of commit 55f40c0 I have #defined and used the
> CHECK_Tcl_GetMatrixPtr macro to handle the error propagation in a uniform way.
>
> In that commit I also got rid of the bug that was emitting the message
>
> No matrix operator named "62"
This message shows up only if you run the example manually as you indicate
below.
>
> for the case where example 19 was run exactly as follows:
>
> cd examples/tcl #(in the build tree)
> ../../bindings/tcl/pltcl -dev psc -o testt.psc
> pltcl> source x19.tcl
> pltcl> plinit
> pltcl> x19
> pltcl> plend
>
> So will you please check master tip (which has a style commit after commit
> 55f40c0)
> to see whether the segfault is now gone for Cygwin?
>
That segmentation fault was due to the wrapper for plmapline tryingto access
argument 45 instead of 4.
> Even if that segfault is now gone, there is still an extremely important issue
> remaining which is that before commit 55f40c0 the
>
> No matrix operator named "62"
>
> message failed to appear for the following scripted version of the above test:
>
> ../../bindings/tcl/pltcl -f x19 -dev psc -o testt.psc
>
> The major concern here is error messages might be silently lost like this for
> other
> Tcl examples that we test by script rather than directly. (We rarely use the
> direct
> method for tests since it is so laborious.) Therefore, I hope you are
> willing to use
> your Tcl expertise to pursue this issue further. For example, I just now
> locally made
> the following modification:
>
...
> I would naively assume this change should generate a "No matrix operator
> named ..." message for the very first call to Tcl_GetMatrixPtr within the
> binding and
> then immediately exit.
>
> However, for the direct test above I get the following message instead:
>
> Matrix operator "x" already in use
>
> and for the scripted test above I get
>
> software@raven> ../../bindings/tcl/pltcl -f x19 -dev psc -o testt.psc Matrix
> operator
> "x" already in use
> while executing
> "matrix x f 15"
> invoked from within
> "$w cmd plmap mapform19 globe $minx $maxx $miny $maxy"
> (procedure "x19" line 38)
> invoked from within
> "x19"
> (file "x19" line 16)
>
> So for this case it appears there are consistent
>
> Matrix operator "x" already in use
>
> basic error messages between the two methods. but that basic error message is
> not at all consistent with the above naive interpretation of what should
> happen due
> to the above one-line change. Also I don't understand at all why the
> scripted test
> adds so much additional information to the basic error message while the
> direct test
> does not do that!
>
This is a characteristic feature of the Tcl shell: in interactive mode it
produces a more concise error message than in "batch" mode, i.e. when running a
script. So there is nothing wrong there. On the other hand I did see one or two
error messages being printed to stderr directly. Most uses of fprintf() concern
debug statements, but the ones that do not merit a closer look.
By the way, your most recent commits did not show up in the log. But when I did
"git merge -ff-only origin/master" I did get the changes. Very odd.
Well, testing the "62" message ...
Regards,
Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
