From: <si...@mu...> - 2010-07-01 17:13:37
Attachments:
plplot_mem_test.py
plplot_python_plsmem.patch
|
> Anyhow, if you get a python version of plsmem to work following the general > PLplot/swig implementation overview I have described, then I would be > pleased to accept your patch to bindings/python/plplotcmodule.i as well as > the trivial patch for bindings/swig-support/plplotcapi.i that I > mentioned above. > Turns out that the whole patch is pretty trival, see attached. The sample script will plot to a memory buffer, and then uses PIL to write this to a file. You can even open an image, convert to buffer, plot and write back to image if you want to do overlays, etc. Have fun, and let me know if it causes any problems. Simon. |
From: Hazen B. <hba...@ma...> - 2010-07-07 02:09:02
|
si...@mu... wrote: >> Anyhow, if you get a python version of plsmem to work following the general >> PLplot/swig implementation overview I have described, then I would be >> pleased to accept your patch to bindings/python/plplotcmodule.i as well as >> the trivial patch for bindings/swig-support/plplotcapi.i that I >> mentioned above. >> > > Turns out that the whole patch is pretty trival, see attached. The sample > script will plot to a memory buffer, and then uses PIL to write this to a > file. > > You can even open an image, convert to buffer, plot and write back to > image if you want to do overlays, etc. > > Have fun, and let me know if it causes any problems. This has a dependency on pybuffer that is not part of "standard" Python? I at least do not seem to have this library w/ Python 2.6 on Ubuntu. How hard is it do get the same result relying solely on Numpy? I'm not sure we want another dependency just for the purposes of being able to use plsmem. -Hazen |
From: <si...@mu...> - 2010-07-08 23:01:27
|
> This has a dependency on pybuffer that is not part of "standard" Python? > I at least do not seem to have this library w/ Python 2.6 on Ubuntu. How > hard is it do get the same result relying solely on Numpy? I'm not sure > we want another dependency just for the purposes of being able to use > plsmem. My (novice) understanding is that pybuffer is part of the standard python/C api: http://docs.python.org/release/2.6.5/c-api/buffer.html#bufferobjects I did not install anything special on Windows Python 2.6, that said I can't find an appropriate package for ubuntu. Simon |
From: Hazen B. <hba...@ma...> - 2010-07-09 15:54:56
|
si...@mu... wrote: >> This has a dependency on pybuffer that is not part of "standard" Python? >> I at least do not seem to have this library w/ Python 2.6 on Ubuntu. How >> hard is it do get the same result relying solely on Numpy? I'm not sure >> we want another dependency just for the purposes of being able to use >> plsmem. > > My (novice) understanding is that pybuffer is part of the standard > python/C api: > http://docs.python.org/release/2.6.5/c-api/buffer.html#bufferobjects > > I did not install anything special on Windows Python 2.6, that said I > can't find an appropriate package for ubuntu. It looks like it is a new feature in Python 3.0 that was backported to at least some versions of Python 2.6. I have 2.6.2, which does not seem to have it? http://docs.python.org/c-api/buffer.html -Hazen |
From: <si...@mu...> - 2010-07-09 17:07:06
|
> It looks like it is a new feature in Python 3.0 that was backported to > at least some versions of Python 2.6. I have 2.6.2, which does not seem > to have it? Just for the record I have Python 2.6.2 on WinXP which does appear to have this. That said, it's not something which is hugely important and the patch is relatively simple should anyone wish to play with it at a later date. Simon. |
From: Hazen B. <hba...@ma...> - 2010-07-09 17:21:13
|
si...@mu... wrote: >> It looks like it is a new feature in Python 3.0 that was backported to >> at least some versions of Python 2.6. I have 2.6.2, which does not seem >> to have it? > > Just for the record I have Python 2.6.2 on WinXP which does appear to have > this. Which version of swig do you have? The file that I seem to be missing, pybuffer.i, should be in my swigX.X/python folder. > That said, it's not something which is hugely important and the patch is > relatively simple should anyone wish to play with it at a later date. Apologies, we do appreciate getting this patch. I will add it to svn once I figure out how to do this in a way that avoids breaking the build for people with older versions of Python and/or swig. -Hazen |
From: Alan W. I. <ir...@be...> - 2010-07-09 20:14:19
|
On 2010-07-09 13:20-0400 Hazen Babcock wrote: > si...@mu... wrote: >>> It looks like it is a new feature in Python 3.0 that was backported to >>> at least some versions of Python 2.6. I have 2.6.2, which does not seem >>> to have it? >> >> Just for the record I have Python 2.6.2 on WinXP which does appear to have >> this. > > Which version of swig do you have? The file that I seem to be missing, > pybuffer.i, should be in my swigX.X/python folder. > >> That said, it's not something which is hugely important and the patch is >> relatively simple should anyone wish to play with it at a later date. > > Apologies, we do appreciate getting this patch. I will add it to svn > once I figure out how to do this in a way that avoids breaking the build > for people with older versions of Python and/or swig. Finding the python version should be straightforward. The last stanza of cmake/modules/plplot.cmake provides a template for running python to generate useful information about python. Modify that template to run, e.g., python -c "import sys; print sys.version.split()[0]" to obtain the version. I suggest the result should be stored unmodified (see below) in the PYTHON_VERSION variable. Note, however, that the version generated this way may have some trailing non-numeric data you will need to filter out with the cmake string command before you can make numerical comparisons between say 2.6.0 (when the necessary buffer functionality is first available to python) and ${PYTHON_VERSION}. For my (Debian squeeze) system I obtain, for example, "2.6.5+" from the above command. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2010-07-15 20:46:24
|
Alan W. Irwin wrote: > > Finding the python version should be straightforward. The last stanza > of cmake/modules/plplot.cmake provides a template for running python > to generate useful information about python. > > Modify that template to run, e.g., > > python -c "import sys; print sys.version.split()[0]" > > to obtain the version. I suggest the result should be stored unmodified > (see below) in the PYTHON_VERSION variable. > > Note, however, that the version generated this way may have some > trailing non-numeric data you will need to filter out with the cmake > string command before you can make numerical comparisons between say > 2.6.0 (when the necessary buffer functionality is first available to > python) and ${PYTHON_VERSION}. For my (Debian squeeze) system I > obtain, for example, "2.6.5+" from the above command. Ok, I think I figured out how to do this and to check the Python and Swig versions to make sure that they are ok, but I can't figure out how to set an environment variable for the build process. In: bindings/swig-support/plplotcapi.i I have: #ifdef PYTHON_HAVE_PYBUFFER %include <pybuffer.i> %pybuffer_mutable_string(void * plotmem) %feature("autodoc", "Set the memory area to be plotted (with the 'mem' driver).") plsmem; void plsmem(PLINT maxx, PLINT maxy, void *plotmem); #endif Now I need cmake to set PYTHON_HAVE_PYBUFFER appropriately. I tried: SET(ENV{PYTHON_HAVE_PYBUFFER} ON), but that does not seem to work. -Hazen |
From: Alan W. I. <ir...@be...> - 2010-07-15 23:52:46
|
On 2010-07-15 16:45-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> >> Finding the python version should be straightforward. The last stanza >> of cmake/modules/plplot.cmake provides a template for running python >> to generate useful information about python. >> >> Modify that template to run, e.g., >> >> python -c "import sys; print sys.version.split()[0]" >> >> to obtain the version. I suggest the result should be stored unmodified >> (see below) in the PYTHON_VERSION variable. >> >> Note, however, that the version generated this way may have some >> trailing non-numeric data you will need to filter out with the cmake >> string command before you can make numerical comparisons between say >> 2.6.0 (when the necessary buffer functionality is first available to >> python) and ${PYTHON_VERSION}. For my (Debian squeeze) system I >> obtain, for example, "2.6.5+" from the above command. > > Ok, I think I figured out how to do this and to check the Python and Swig > versions to make sure that they are ok, but I can't figure out how to set an > environment variable for the build process. In: > bindings/swig-support/plplotcapi.i I have: > > #ifdef PYTHON_HAVE_PYBUFFER > > %include <pybuffer.i> > %pybuffer_mutable_string(void * plotmem) > > %feature("autodoc", "Set the memory area to be plotted (with the 'mem' > driver).") plsmem; > void > plsmem(PLINT maxx, PLINT maxy, void *plotmem); > > #endif > > Now I need cmake to set PYTHON_HAVE_PYBUFFER appropriately. I tried: > SET(ENV{PYTHON_HAVE_PYBUFFER} ON), but that does not seem to work. Set that PYTHON_HAVE_PYBUFFER macro like the usual SWIG_PYTHON macro is set in bindings/python/CMakeLists.txt with the appropriate CMAKE_SWIG_FLAGS list element. Of course, in that CMake logic you will ultimately want to avoid setting the PYTHON_HAVE_PYBUFFER macro when the python version is too old to support this, but that is a nuance you can deal with later if you don't have the python version logic set up yet. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2010-07-16 18:32:25
|
Alan W. Irwin wrote: > > Set that PYTHON_HAVE_PYBUFFER macro like the usual SWIG_PYTHON macro > is set in bindings/python/CMakeLists.txt with the appropriate > CMAKE_SWIG_FLAGS list element. Of course, in that CMake logic you will > ultimately want to avoid setting the PYTHON_HAVE_PYBUFFER macro when > the python version is too old to support this, but that is a nuance > you can deal with later if you don't have the python version logic set > up yet. Thank you Alan, I think that I have figured out how to do this w/ the appropriate version checks. It seems to work on my system, but my version of swig is not of recent enough vintage to support plsmem() so I did not test the with plsmem() case. v11090 -Hazen |
From: Alan W. I. <ir...@be...> - 2010-07-17 07:12:49
|
On 2010-07-16 14:32-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> >> Set that PYTHON_HAVE_PYBUFFER macro like the usual SWIG_PYTHON macro >> is set in bindings/python/CMakeLists.txt with the appropriate >> CMAKE_SWIG_FLAGS list element. Of course, in that CMake logic you will >> ultimately want to avoid setting the PYTHON_HAVE_PYBUFFER macro when >> the python version is too old to support this, but that is a nuance >> you can deal with later if you don't have the python version logic set >> up yet. > > Thank you Alan, I think that I have figured out how to do this w/ the > appropriate version checks. It seems to work on my system, but my version of > swig is not of recent enough vintage to support plsmem() so I did not test > the with plsmem() case. Thanks, Hazen, for your work on this, and thanks Simon for the original patch. Simon (or Hazen) could you explain why there is a minimum swig version requirement? Is the issue that this python capability only was available after a certain epoch, corresponding swig adjustments had to be made subsequent to that epoch, and those adjustments landed in the release after 1.3.38 so our build system must test for swig version greater than 1.3.38? 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2010-07-17 15:53:53
|
On Jul 17, 2010, at 3:14 AM, Alan W. Irwin wrote: > On 2010-07-16 14:32-0400 Hazen Babcock wrote: > >> Alan W. Irwin wrote: >>> Set that PYTHON_HAVE_PYBUFFER macro like the usual SWIG_PYTHON macro >>> is set in bindings/python/CMakeLists.txt with the appropriate >>> CMAKE_SWIG_FLAGS list element. Of course, in that CMake logic you >>> will >>> ultimately want to avoid setting the PYTHON_HAVE_PYBUFFER macro when >>> the python version is too old to support this, but that is a nuance >>> you can deal with later if you don't have the python version >>> logic set >>> up yet. >> >> Thank you Alan, I think that I have figured out how to do this w/ >> the appropriate version checks. It seems to work on my system, but >> my version of swig is not of recent enough vintage to support >> plsmem() so I did not test the with plsmem() case. > > Thanks, Hazen, for your work on this, and thanks Simon for the > original patch. > > Simon (or Hazen) could you explain why there is a minimum swig version > requirement? Is the issue that this python capability only was > available after a certain epoch, corresponding swig adjustments had to > be made subsequent to that epoch, and those adjustments landed in the > release after 1.3.38 so our build system must test for swig version > greater than 1.3.38? Yep. As near as I can tell the critical swig file, pybuffer.i, was not added until swig 1.3.38. I have python 2.6, but swig 1.3.36, so I can't compile with plsmem support. -Hazen |
From: <si...@mu...> - 2010-07-19 19:55:25
|
> Thank you Alan, I think that I have figured out how to do this w/ the > appropriate version checks. It seems to work on my system, but my > version of swig is not of recent enough vintage to support plsmem() so I > did not test the with plsmem() case. For the record; I grabbed a copy from SVN and built it on my XP machine. Seems to be good, my little test script for plotting via plsmem worked fine. Simon |
From: Alan W. I. <ir...@be...> - 2010-07-23 18:24:46
|
On 2010-07-19 15:55-0400 si...@mu... wrote: > >> Thank you Alan, I think that I have figured out how to do this w/ the >> appropriate version checks. It seems to work on my system, but my >> version of swig is not of recent enough vintage to support plsmem() so I >> did not test the with plsmem() case. > > For the record; I grabbed a copy from SVN and built it on my XP machine. > Seems to be good, my little test script for plotting via plsmem worked > fine. Hi Simon: I have changed the subject line corresponding to the new direction I would like to take this discussion. As of revision 11103, I did some rearranging of python plsmem support. I tested that rearrangement on Linux (Debian testing with the python-imaging package installed), and I found that your test script continued to work. Important question: Would you be willing to donate your script to PLplot under the LGPL? If so, I would make it part of our source tree as a special python test for now, but later on (assuming substantial improvements to mem-type functionality, see below) we would probably want to create a standard example (with all that implies about propagating plsmem to all our language interfaces) using some ideas from the test script. I have to say this is the first time I have seen the mem device in action, and there are several glaring issues; e.g., no support for transparency, no support for fills (and the software fallback for that really sucks as can be seen from the test script results), and no support for unicode fonts. Adding transparency support should be straightforward, and it is possible we could do something about fills, but I have substantial doubts about support for unicode fonts. One possibility there is to use the deprecated plfreetype approach, but that has so many limitations I would definitely prefer not to expand its use, and IMHO the best way to support unicode in PLplot is to use the excellent unicode facilities of external libraries like cairo and qt. One important question for further discussion is whether our current qt and cairo devices could be modified along with plsmem to provide similar functionality to the mem device with automatic high-quality support of transparency, fills, and unicode fonts? If so, I would strongly support making a change to plsmem to propagate the user-prepared memory area to the qt, cairo, and mem devices as needed, and not bothering at all with further mem device improvements. Of course, even if mem-type functionality could be arranged via our cairo and qt devices with suitable changes to plsmem, we would probably want to continue to keep the more primitive mem device driver for those cases where the user doesn't want to bother with dealing with the cairo and Qt dependencies. 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 __________________________ |
From: <si...@mu...> - 2010-07-23 19:44:19
|
> Would you be willing to donate your script to PLplot under the LGPL? If it would be of use... I'd be happy to LGPL it. > Adding transparency support should be straightforward I presume that you mean psuedo-transparency, as the underlying image must be RGB (rather then RGBA) at present. I should add my tinkering was with the idea of augmenting the individual frames of a video with graphing, but this was really based around hard requirement. Simon. |
From: Alan W. I. <ir...@be...> - 2010-07-23 20:36:50
|
On 2010-07-23 15:44-0400 si...@mu... wrote: >> Would you be willing to donate your script to PLplot under the LGPL? > > If it would be of use... I'd be happy to LGPL it. Hi Simon: Thanks for that donation under the LGPL. I have named the demo test_mem.py and made it copyright Simon Wood (revision 11104) since SF says that is your real-world name. If you would prefer a different name to appear in the copyright line, let me know. 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 __________________________ |