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