On 2017-04-22 17:55-0400 Hazen Babcock wrote: > On 04/21/2017 03:42 AM, Alan W. Irwin wrote: >> >> Hi Hazen: >> >> Could you please test commit 578b028?
[...] > It works for me with Python3 and pyqt5. Hi Hazen: That positive test result on your Linux platform is a big relief to me. I looked through your previous e-mails, and from one you wrote last November you were using at that time Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial Is that still the case for this test? If so, that should be almost exactly a year more modern than my current Debian Jessie platform (released almost exactly two years ago), and if you have now moved to a later Ubuntu release that is an even larger disparity in time of release. > My understanding is that error > messages like you are seeing mean that the C library was built for the wrong > version of Python. That seems like a plausible explanation which I can address by updating to Debian Stretch (not quite yet ready for official release, but likely that official release will occur later this year and Stretch is likely already quite stable enough on my particular hardware platform, x86_64). Anyhow, I will put that update to Stretch on my agenda in the intermediate term (within a month or two) even if it isn't completely polished into an official release by then. > I've attached my CMakeCache.txt file. That's somewhat useful information, but capturing the combined stdout and stderr output from your cmake command, e.g., cmake <CMake options> <Top directory for PLplot source tree> >& cmake.out is even more useful. That captured output gives the sip (since commit 7f1f5ce earlier today), Python, Qt, and pyqt detailed version numbers. Also, since the above works for you I have changed (commit 7653e24 today) our default Python version to Python 3 (if it is available) and Python 2 otherwise. The Python 3 find is now only skipped if the user specifies -DFORCE_PYTHON2=ON, but normally they would not want to do that since Python 3 is likely less buggy than Python 2. For example, the Python developer I talked to implied I was very much less likely to experience the python-generated Plframe.pyc corruption issue that was showing up for me fairly regularly for Python 2, if I switched to Python 3, and that expectation has been born out so far in fairly limited Python 3 testing by me. 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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
