Just before the release I discovered that the interactive pygcw demos
plplotcanvas_*.py in the examples/python tree errored out.  Therefore, we
had to disable ENABLE_pygcw by default for the release.

My investigation over the weekend showed there were actually two issues
responsible for these errors.

(1) Python gtk bindings of version 2.13.0 or higher switched from Numeric to
numpy by default.  Thus, if the PLplot user's choice of Numeric/numpy is not
consistent with that of those bindings you get errors in the above examples.
I have implemented a build-system solution to check for such consistency
depending on the version of the Python gtk bindings, and if that consistency
does not exist turn ENABLE_pygcw OFF.  My system version of the python
bindings for gtk (which is contained in package python-gtk2-dev) is 2.12 so
I have to use -DHAVE_NUMPY=OFF to achieve the desired consistency if I want
to test our support for pygcw.  For now, probably most other Linux distros
are also deploying version 2.12 of the Python gtk bindings for gtk, but
that should change since version 2.1.3 has been released and presumably
will propagate to most distros in the next 6 months or so.

(2) Further checks using -DHAVE_NUMPY=OFF using a lot of binary searching of
various revision numbers showed the remaining error (a recursion depth
exceeded message) was introduced as of revision 8891. Further tests then
narrowed the problem down to the specific (and seemingly innocuous)
visibility changes for include/plplotcanvas.h. I have temporarily reverted
those visibility changes for that file.

So as of revision 9217 the two issues above have been fixed and ENABLE_pygcw
defaults to ON again (unless the user makes a choice for
HAVE_NUMPY that is inconsistent with his Python bindings for gtk).

However, that still leaves the visibility issues which will make it impossible
to build using gcc option -fvisibility=hidden on Linux or to build gcw, gnome2
or pygcw components of PLPlot on windows.

Although revision 8891 was by me, I was just deploying those visibility
changes by rote with no deep understanding of what was going on. So someone
else with better understanding of visibility issues (probably Andrew) should
take over now to reinstate visibility changes for plplotcanvas.h in a way
that does not clobber our pygcw examples.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to