Hi Geoffrey: Thanks for your continuing efforts to resurrect access to plframe from python.
On 2009-06-30 15:20-0500 Geoffrey Furnish wrote: > Hi all, > > I've injected the work formerly done on the python branch, onto svn trunk > tip. > > I've done a little messing around with cmake, so I would appreciate it if > people could look over bindings/python/CMakeLists.txt in particular. One > concern I have is that someone might disable Tcl/Tk, but enable python. In > that case, it seems to me the python widget module should be built without > linking to the Tcl/Tk stuff, and without using the TCL_INCLUDE dir. But I'm > not able to author that in cmake-ese yet, so if someone could tweak that, I'd > be really appreciative. DONE. revision(10105). I have also implemented an install of pytkdemo and its associated x??.py examples. > > If you build in a way that allows Tcl/Tk and Python to all be found and > activated, you'll now have some new options in the Python code. One way to > see this would be something along the lines of: > > cd <wherever>/plplot/examples/python > env PYTHONPATH=$CMAKE_BUILD_PREFIX/lib64/python2.6/site-pakages \ > python pytkdemo I tried that in the installed examples tree and I could click on several of the examples and get plotted results. I had never seen pytkdemo work before since I got involved with PLplot in 2000 so that result was nice to see. However, the GUI hung on an attempt to exit by hitting the dismiss button. Furthermore, there is cross-talk between the examples so that after running example 2 (I think), all subsequent examples were displayed at about 1/10th size. So it is "working", but it is pretty rough. > The other thing worth discussing is just to draw attention to the fact that > in the past I had trouble with how the python modules are being linked. I > haven't gotten as far as reinvestigating that, so I'll post more on it > later. But in the past I found that explicitly linking to PYTHON_LIBRARIES > caused problems for some applications. So, that's an open issue that I'll be > reporting more on later, after I look into it again. I have a very simple rule that normally assures that linking AND dynamic loading (as occurs when Python loads an extension module) will work cross-platform for PLplot. That rule is ldd -r must not show any undefined symbols on Linux. Now, that is probably not a Linux necessity for the python case where python itself is dynamically loading the extension modules and making its own symbols available that way, but dynamic loading does not necessarily work that way on all platforms so the only safe thing to do with dynamically loaded modules is to link explicitly to resolve all symbols. To illustrate the point try to remove PYTHON_LIBRARIES, and the ldd -r result (which I just demonstrated to myself) is many undefined symbols (which makes sense since the plplot_widgets source code calls functions in the python library). I suspect the problems you had with explicit linking before was multiple versions of python interfering with each other so the python libraries found by cmake were not consistent with your python executable. I am tempted to remove your FIXME comments right now because I am virtually positive that explanation is correct, but I will wait until you are completely satisifed with the results of your further investigations with consistent python libraries and python executable. One additional obvious issue is the old x??.py python examples used by pytkdemo are showing their age, are buggy, and are seriously incomplete. Is there a straightforward way to use the "new" heavily debugged python examples xw??.py instead without interfering with the widgetless way of using those examples? If so, then please tell me how to do it, or else please make that change yourself. Assuming that works, it would allow us to get rid of those old examples and also rename all the current "new" xw??.py examples as the corresponding x??.py. Historically, the "w" in xw??.py stands for widgetless which was not one of my better naming convention moments! Anyhow, I would like to take this opportunity to claim back the x??.py namespace with the modern debugged examples if you can figure out a way to use those examples from pytkdemo so we can ditch the old ones. Other cleanups: * Can we now delete the directory bindings/python/1.4b3 ? * Can I now edit README.pythonbuild to get rid of the explanation of the old method you used to access plframe from python? That old method required a rebuild of a patched version of Python. That gives a bad impression of your work since I suspect most modern users would run away screaming with horror from the idea of rebuilding Python. :-) 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
