On 2016-03-14 17:34-0700 Alan W. Irwin wrote:
> [...]
> *** 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"
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?
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:
software@raven> git diff --unified=10
diff --git a/bindings/tcl/tclMatrix.c b/bindings/tcl/tclMatrix.c
index f41e63c..25d0b26 100644
--- a/bindings/tcl/tclMatrix.c
+++ b/bindings/tcl/tclMatrix.c
@@ -370,20 +370,21 @@ Tcl_GetMatrixPtr( Tcl_Interp *interp, const char *matName
)
Tcl_HashEntry *hPtr;
dbug_enter( "Tcl_GetMatrixPtr" );
if ( !matTable_initted )
{
return NULL;
}
hPtr = Tcl_FindHashEntry( &matTable, matName );
+ hPtr = NULL;
if ( hPtr == NULL )
{
Tcl_AppendResult( interp, "No matrix operator named \"",
matName, "\"", (char *) NULL );
return NULL;
}
return (tclMatrix *) Tcl_GetHashValue( hPtr );
}
//--------------------------------------------------------------------------
(I used the --unified=10 option to give more context for my one-line
change.)
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!
So my current conclusion is PLplot has one or more fundamental
problems in how it handles Tcl errors (at least on Linux), and I hope
you can figure out how to fix those problems.
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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________
------------------------------------------------------------------------------
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
