Alan W. Irwin writes: > On 2009-06-30 15:20-0500 Geoffrey Furnish wrote: > > 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.
Thanks much. > > 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. Yes, agreed, it's very rudimentary at best. > > 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 > [...] > 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. The story is somewhat involved. I'll explain in a separate e-mail dedicated to the subject. > 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. I will look into this. I certainly agree it would be desirable to leverage what you've already hammered out. > 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. Yes, I share this goal. I'll be working on that in the coming days, along with some other PLplot+Python improvement plans I have. > Other cleanups: > > * Can we now delete the directory bindings/python/1.4b3 ? Yes. > * 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. :-) The short answer is: "yes". The long anser is: "I'll have to probably revisit the whole topic and explain things again." Python is *stunningly/staggeringly* hard to fathom in matters relating to its installation and configuration. Just this week I have learned some more very disheartening factoids about how uncooperative Python is with some seemingly innocuous and basic goals which I doubt I am the only sw developer on earth to have. Trying to be positive here, I've had the thought that maybe I should spend some time on python-dev and see if I can contribute somehow to untangling the mess and making it all work in a way that regular-Joe (regular-Geoff?) developers would find more natural. But it seems like a daunting proposition. Here's an example of what I mean. Did you know that Fedora 11's package manager (yum) won't work correctly behind a firewall? Traced to a python bug (in urllib) in https proxy interaction for which a corrective patch was sent to the Python maintainers in March *2008*, but it hasn't been integrated yet. In that context, somehow I doubt anything I could say would result in a short-timescale movement to a redesign of the Python system configuration and installation procedure... <wink>. Maybe the most useful thing I can actually do, is simply to write up my findings so that others have at least some worked examples of how to do some of these things that are so vexing. Anyway, thanks again for so quickly reviewing and tweaking my meager efforts in bindings/python/CMakeLists.txt. -- Geoff ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
