Re: [Plplot-devel] python branch now merged
On 2009-06-30 23:29-0500 Geoffrey Furnish wrote: Alan W. Irwin writes: [...]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. Great! Other cleanups: * Can we now delete the directory bindings/python/1.4b3 ? Yes. DONE (revision 10106). * 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. DONE (revision 10107). The long anser is: I'll have to probably revisit the whole topic and explain things again. In my rewrite of README.pythonbuild, I now refer specifically to your recent work. That may already be enough since short explanations that just stick to the overview may be preferable. However, feel free to supplement that further if you like. 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
[Plplot-devel] python branch now merged
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. 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 You'll notice that the plframe appears right along with other Tk widgets in this teeny little Python/Tk application which is intended just to show off the various demo programs (the python versions thereof). 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. There is still much to do. Plframe.py is suffering badly from years of atrophy. I'll see what I can do. Please let me know of any problems. I'll try to be watching our e-mail lists a little more carefully over the coming days, in case anyone is screaming for releif from my unclueful ways. Oh, btw, one more thing. Why did I say merged? Because it turns out that git-svn is far lamer than I previously knew. I guess it's constrained by what the svn protocol supports, but I had certainly hoped for more. So I think I said before that I didn't personally like git-svn, and didn't consider it really a very good way for the git-inclined to deal with PLplot, and I am much more convinced of that now after trying to work with it a bit. I will continue working to document some git work-flow cases, or scenarios, so that people can dip their toes in, if inclined. But git-svn is really just a wrapper around svn which gives it a git-ish interface. But it's not really git in the way that git is git, if you see what I mean. I guess what I'm trying to say here is no one should conclude that experience with git-svn gives much of a picture of a git work flow. git-svn is very slow, clunky, and merge-iimpaired, compared to git. So it will be hard to develop much clarity of expectation of what a git workflow would be like, from using git-svn. As I get further along in my documentation of the git work-flow, I'll try to include some example of bare git. Those will help people to get a better taste of what a git-hosted project is really like. But it will be considerably harder to feed work done in such situations back into svn. Personally, I could live with git-svn being slow, if it just supported a more git-like work flow. But I'm not prepared to go working on git-svn itself at this time. Way too much else to do. Oh, one more really last thing. I haven't gotten around to trying out Alan's proposal for plplot-mode. But I did pull down and install cmake-mode.el. Hoping to keep our style as similar as possible, despite several different languages being in play in the PLplot project, I changed cmake-mode.el to use 4 (rather than 2) for the tab stop setting. It seemed from our former discussion about C style, that people were all good with 4 char indentation levels, so I plan to use that also in my cmake-mode.el (and today's commits reflect that). Does anyone know why describe-mode doesn't seem to have much to say about cmake-mode? Skimming the file, you'd think there would be a number of functions bound to keys, but apparently not. Seems strange. Am I missing something that anyone else has found? Cheers, -- Geoff -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] python branch now merged
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
Re: [Plplot-devel] python branch now merged
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
