Alan, Thanks for this, and sorry for introducing part of the bug. Hopefully the new interactive tests should help pick this kind of thing up sooner in future. I will try to take a look when time permits.
Andrew On Mon, Dec 22, 2008 at 04:21:45PM -0800, Alan Irwin wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
