On Thu, Aug 16, 2007 at 08:56:31AM -0700, Alan Irwin wrote: > On 2007-08-16 08:52+0100 Andrew Ross wrote: > > > > >Alan, > > > >Example 21 is now disabled in the automatic tests since is doesn't work > >with Numeric anyway. > > > >I've commented out the use of RandomArray for now since the only place > >it is used is in example 21. Example 17 actually uses random.random, > >which is part of python. This only generates single random numbers > >though, not an array of random numbers. > > > >Works for me - can you check? > > Hi Andrew: > > This thread has spawned a number of related sub-topics which I want to > address here. Let me take them one at a time.... > > (1) Sorry for the false alarm about RandomArray. I did have > python-numeric-ext installed, but that referred to the python-2.3 version > while I am running PLplot off of python-2.4. The fix was to install > python2.4-numeric-ext. For now this minor Python versioning issue is not an > issue for RandomArray because you have disabled its use in your current > workaround, but at some point if such versioning issues get irritating > enough we may want to take over maintenance of the CMake > FindPythonLibs.cmake and FindPythonInterp.cmake modules and bring them into > the modern world.
There are some irritating features of the FindPython*.cmake modules. (And also some of the others, e.g. Java). I suspect we might have to try our own versions at some stage. The insistence on using the "newest" version of python is annoying. Ideally I would like to be able to specify a version and pick up all the correct libraries and includes FOR THAT VERSION. This avoids exactly the kind of problems you describe. I encounted similar things trying to build debian packages using multiple versions of python. > > (2) For exactly the same revision as last night (i.e., without your recent > workaround to disable example 21) and with python2.4-numeric-ext installed, > the error messages from ctest turned into > > *** PLPLOT ERROR *** > plw3d: Invalid axis range, aborting operation > > *** PLPLOT WARNING *** > plot3dcl: Maximum and minimum Z values are equal! "fixing"... > > *** PLPLOT ERROR *** > plw3d: Invalid axis range, aborting operation > > .... > > -- Process completed > Passed > > The following tests passed: > examples_python > > > >From your remarks and my later successful test with your workaround (see 3 > below) those errors are due to example 21 (without your update to disable > it). But why do all those PLPLOT ERRORs not propagate to the overall test > status? If somebody ran the test without verbose, they would be convinced > all was well with python even when example 21 has problems. The question > boils down to why a python error such as a missing module generates a > non-zero status code (which we do test for in test/test_python.sh), but > PLPLOT ERROR does not. Hope you know how to fix this PLPLOT ERROR irritation > with ctest (which I assume is a general PLplot problem and nothing > specifically to do with our python interface). This is nothing to do with python - a quick test with the C examples shows the same thing if you make zg all zeros in example 21 (this is what is returned by griddata in the faulty Numeric case). The reason appears to be that the PLPLOT ERROR is not actually treated like an error - the program continues regardless. If it really is an error then the programme would abort with an error code. It's the program error code that ctest picks up. If we decide it should continue in this case, then the error should be a warning. > > (3) With your workaround (Updated to revision 7807), I confirm that ctest > works fine. However, Numeric is deprecated in favour of NumPy so I don't > think we should cater to the Numeric deficiencies if the user has already > upgraded to NumPy. So I think a better workaround would be to go ahead and > import RandomArray (which makes current Numeric users like me import > something they don't need, but too bad), and configure the examples list to > exclude example 21 (perhaps with a warning message to upgrade to NumPy) if > the user is using the deprecated Numeric interface. What do you think of > this approach? Sounds good. The reason I didn't do this at first was that I couldn't think of a "neat" way of doing it without making x21 a configurable file. I've tried to avoid doing this for too many cases. Perhaps I should get plplot_py_demos.py to set a variable which I can test in the examples? > > BTW, I assume you agree with me there is no point at this stage in trying to > get plgriddata to work for Numeric. In my view Numeric is a dead duck; I > don't think the major Linux distros will support it on their own for too > much longer since the core Numeric team has given up on it and joined the > NumPy bandwagon. Anyhow, I personally plan to migrate to NumPy after I have > finished my current research project. Precisely why I've not put too much more effort into it. There never was a working griddata before so anyone using the old Numeric interface won't miss it. Andrew ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
