Menu
▾
▴
plplot-devel
|
From: Maurice L. <mj...@ga...> - 2002-12-24 22:56:41
|
In my tests from last Sept, I found that swig versions:
1.3.11 - 1.3.13
were the only ones that worked with the plplot python wrapper code.
Specifically:
1.3.14 & 1.3.15
did NOT work, due to the following change:
> < #define SWIG_init initplplotc
> < #define SWIG_name "plplotc"
>
> > #define SWIG_init init_plplotc
> > #define SWIG_name "_plplotc"
>
> The latter ones are those generated by swig 1.3.14. Ugh.
Has this been fixed? I don't recall seeing cvs commits for it but could've
missed it.
BTW the latest swig is up to 1.3.17. If we do go to release with it working
only with swig 1.3.11 - 1.3.13, this needs to be very prominently stated
*somewhere*.
--
Maurice LeBrun mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)
|
|
From: Alan W. I. <ir...@be...> - 2002-12-25 00:07:34
|
On Tue, 24 Dec 2002, Maurice LeBrun wrote: > In my tests from last Sept, I found that swig versions: > > 1.3.11 - 1.3.13 > > were the only ones that worked with the plplot python wrapper code. > Specifically: > > 1.3.14 & 1.3.15 > > did NOT work, due to the following change: > > > < #define SWIG_init initplplotc > > < #define SWIG_name "plplotc" > > > > > #define SWIG_init init_plplotc > > > #define SWIG_name "_plplotc" > > > > The latter ones are those generated by swig 1.3.14. Ugh. > > Has this been fixed? I don't recall seeing cvs commits for it but could've > missed it. Not fixed. I may get to it in the next few days, but I am not sure I will have the time. I am playing with swig-1.3.17 at the moment, but the focus is on java. There *might* be a chance to produce a complete plplot API under java which is an exciting possibility. I have already gotten it to work well enough so I can produce our simplest example (x10.java), but I am still on pretty steep parts of both the swig and java learning curves so it is not clear how long this will take. It is possible I could get it done before January, but otherwise I will go with the present hand-crafted but fairly incomplete java interface we have now for the release, and try again with swig and java after the release. > > BTW the latest swig is up to 1.3.17. If we do go to release with it working > only with swig 1.3.11 - 1.3.13, this needs to be very prominently stated > *somewhere*. I am willing to state that somewhere, but it may not be necessary (or may not need to be very prominent) since it is only going to affect CVS developers as now. The tarball will have the swig-generated interface file in it already so no tarball (or rpm or deb) user will require swig at all. So in light of that extra information, what do you think of just putting a comment in the Makefile.am where swig is invoked and letting it go at that (assuming I don't have time to make 1.3.17 work)? If I use the right number of # characters in the front of such a comment it propagates to Makefile.in and Makefile as well. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
|
From: Maurice L. <mj...@ga...> - 2002-12-25 17:21:53
|
Alan W. Irwin writes:
> So in light of that extra information, what do you think of just putting a
> comment in the Makefile.am where swig is invoked and letting it go at that
> (assuming I don't have time to make 1.3.17 work)? If I use the right
> number of # characters in the front of such a comment it propagates to
> Makefile.in and Makefile as well.
I think it's needed there and in the README.pythondemos as well, since the
latter is where people trying to run the python demos will look.
BTW does this work for anyone?
ged$ ./prova.py
Traceback (most recent call last):
File "./prova.py", line 9, in ?
from qt import *
ImportError: No module named qt
I followed the prescription for finding libqt but it didn't work.
ged$ echo $LD_LIBRARY_PATH
.:/home/mjl/gts/lib:/usr/lib/qt-3.0.3/lib
ged$ ll -L /usr/lib/qt-3.0.3/lib/libqt.so
-rwxr-xr-x 1 root root 7644546 Apr 16 2002 /usr/lib/qt-3.0.3/lib/libqt.so
--
Maurice LeBrun mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)
|
|
From: Alan W. I. <ir...@be...> - 2002-12-25 22:20:54
|
On Wed, 25 Dec 2002, Maurice LeBrun wrote: > BTW does this work for anyone? > > ged$ ./prova.py > Traceback (most recent call last): > File "./prova.py", line 9, in ? > from qt import * > ImportError: No module named qt > > I followed the prescription for finding libqt but it didn't work. > > ged$ echo $LD_LIBRARY_PATH > .:/home/mjl/gts/lib:/usr/lib/qt-3.0.3/lib > > ged$ ll -L /usr/lib/qt-3.0.3/lib/libqt.so > -rwxr-xr-x 1 root root 7644546 Apr 16 2002 /usr/lib/qt-3.0.3/lib/libqt.so Yes, works for me. qt refers to the python module (/usr/lib/python2.1/site-packages/qt.py(o)), not the qt library. The module is in the python-pyqt package on Debian. I don't know what that package is named on RedHat, but you should be able to find it using rpmfind on qt.py. You will also need libsip. Good luck, and Merry Christmas! Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
|
From: Maurice L. <mj...@ga...> - 2002-12-26 02:05:00
|
Alan W. Irwin writes:
> On Wed, 25 Dec 2002, Maurice LeBrun wrote:
>
> > BTW does this work for anyone?
> >
> > ged$ ./prova.py
> > Traceback (most recent call last):
> > File "./prova.py", line 9, in ?
> > from qt import *
> > ImportError: No module named qt
> >
> > I followed the prescription for finding libqt but it didn't work.
> >
> > ged$ echo $LD_LIBRARY_PATH
> > .:/home/mjl/gts/lib:/usr/lib/qt-3.0.3/lib
> >
> > ged$ ll -L /usr/lib/qt-3.0.3/lib/libqt.so
> > -rwxr-xr-x 1 root root 7644546 Apr 16 2002 /usr/lib/qt-3.0.3/lib/libqt.so
>
> Yes, works for me. qt refers to the python module
> (/usr/lib/python2.1/site-packages/qt.py(o)), not the qt library. The module
> is in the python-pyqt package on Debian. I don't know what that package is
> named on RedHat, but you should be able to find it using rpmfind on qt.py.
>
> You will also need libsip.
OK, I found it on my RH7.3 system in the python1.5 install. But
unfortunately, not under python2.2. Probably the biggest flaw of RH7.3 in my
book is this split python distribution. There's no rpm specifically for
RH7.3 & python2.2 either, so instead of installing from source I'm trying
the default python1.5.
There's a problem with the configuration under bindings/python. It locates
/usr/bin/python which is 1.5 but otherwise gets the 2.2 libraries which
of course won't work. From bindings/python/Makefile:
PYTHON = /usr/bin/python
PYTHON_CFG_DIR = /usr/lib/python2.2/config
PYTHON_DIR = /home/mjl/tools/lib/python2.2/site-packages
PYTHON_EXEC_PREFIX = ${exec_prefix}
PYTHON_INC_DIR = /usr/include/python2.2
PYTHON_INSTDIR = lib/python2.2/site-packages
PYTHON_MACH_DIR = /usr/lib/python2.2/site-packages
PYTHON_MOD_DIR = /usr/lib/python2.2
PYTHON_NUM_DIR = /usr/include/python2.2/Numeric
PYTHON_PLATFORM = linux-i386
PYTHON_PREFIX = ${prefix}
PYTHON_VERSION = 1.5
Ugh. I'll look into it a little more but am about out of time to spend on
this problem.
--
Maurice LeBrun mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)
|
|
From: Alan W. I. <ir...@be...> - 2002-12-26 05:44:53
|
On Wed, 25 Dec 2002, Maurice LeBrun wrote:
> OK, I found it on my RH7.3 system in the python1.5 install. But
> unfortunately, not under python2.2. Probably the biggest flaw of RH7.3 in my
> book is this split python distribution.
I agree 100 per cent. When making the RH 7.3 rpm, I got around the RH split
python problem by forcing a number of variables for plplot-5.1.0. I haven't
tried this for CVS HEAD, but I believe it should work since I copied most of
plplot/cf/sysloc.in to plplot/sysloc.in where these variables should
override the python search that ordinarily fails completely on RH 7.3
because of their split system.
PY_VERSION=python -c 'import sys ; print sys.version[0:3]'
export
PYTHON_INC_DIR=/usr/include/python${PY_VERSION}/
export PYTHON_MOD_DIR=/usr/lib/python${PY_VERSION}/
export PYTHON_CFG_DIR=${PYTHON_MOD_DIR}/config
export PYTHON_NUM_DIR=${PYTHON_INC_DIR}/Numeric/
export PYTHON_MACH_DIR=${PYTHON_MOD_DIR}/site-packages
export PYTHON_DIR=${PYTHON_MACH_DIR}
./configure --prefix=/usr --with-double --enable-dyndrivers --enable-gnome
--ena
ble-ntk --disable-linuxvga
See plplot/rpm/plplot_redhat7.3.spec.
Of course it is just a workaround, but it may be a necessary one since I am
not sure we should expect sysloc.in to be able to deal with a split python
version system.
Hope this helps.
Alan
email: ir...@be...
phone: 250-727-2902 FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________
Linux-powered astrophysics
__________________________
|
|
From: Maurice L. <mj...@ga...> - 2003-01-18 19:30:06
|
Trying to clean out my inbox and finally getting back to this.
Alan W. Irwin writes:
> On Wed, 25 Dec 2002, Maurice LeBrun wrote:
>
> > OK, I found it on my RH7.3 system in the python1.5 install. But
> > unfortunately, not under python2.2. Probably the biggest flaw of RH7.3 in my
> > book is this split python distribution.
>
> I agree 100 per cent. When making the RH 7.3 rpm, I got around the RH split
> python problem by forcing a number of variables for plplot-5.1.0. I haven't
> tried this for CVS HEAD, but I believe it should work since I copied most of
> plplot/cf/sysloc.in to plplot/sysloc.in where these variables should
> override the python search that ordinarily fails completely on RH 7.3
> because of their split system.
>
> PY_VERSION=python -c 'import sys ; print sys.version[0:3]'
> export
> PYTHON_INC_DIR=/usr/include/python${PY_VERSION}/
> export PYTHON_MOD_DIR=/usr/lib/python${PY_VERSION}/
> export PYTHON_CFG_DIR=${PYTHON_MOD_DIR}/config
> export PYTHON_NUM_DIR=${PYTHON_INC_DIR}/Numeric/
> export PYTHON_MACH_DIR=${PYTHON_MOD_DIR}/site-packages
> export PYTHON_DIR=${PYTHON_MACH_DIR}
> ./configure --prefix=/usr --with-double --enable-dyndrivers --enable-gnome
> --ena
> ble-ntk --disable-linuxvga
Unfortunately this doesn't work. Putting:
# Fixes to work with python 1.5 under RH 7.3
enable_python="yes"
PY_VERSION=`python -c 'import sys ; print sys.version[0:3]'`
export PYTHON_INC_DIR=/usr/include/python${PY_VERSION}/
export PYTHON_MOD_DIR=/usr/lib/python${PY_VERSION}/
export PYTHON_CFG_DIR=${PYTHON_MOD_DIR}/config
export PYTHON_NUM_DIR=${PYTHON_INC_DIR}/Numeric/
export PYTHON_MACH_DIR=${PYTHON_MOD_DIR}/site-packages
export PYTHON_DIR=${PYTHON_MACH_DIR}
in my ~/config/cf_plplot.in, gives the following line in
bindings/python/Makefile:
ourpythondir = ${prefix}//usr/lib/python1.5//site-packages
so since I have set prefix to $HOME/tools, this results in absolute nonsense.
The culprit is:
ourpythondir = ${prefix}/@PYTHON_INSTDIR@
in bindings/python/Makefile.am. How to fix this?
--
Maurice LeBrun mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)
|
|
From: Alan W. I. <ir...@be...> - 2003-01-18 22:41:43
|
On Sat, 18 Jan 2003, Maurice LeBrun wrote:
> Unfortunately this doesn't work. Putting:
>
> # Fixes to work with python 1.5 under RH 7.3
>
> enable_python="yes"
> PY_VERSION=`python -c 'import sys ; print sys.version[0:3]'`
> export PYTHON_INC_DIR=/usr/include/python${PY_VERSION}/
> export PYTHON_MOD_DIR=/usr/lib/python${PY_VERSION}/
> export PYTHON_CFG_DIR=${PYTHON_MOD_DIR}/config
> export PYTHON_NUM_DIR=${PYTHON_INC_DIR}/Numeric/
> export PYTHON_MACH_DIR=${PYTHON_MOD_DIR}/site-packages
> export PYTHON_DIR=${PYTHON_MACH_DIR}
>
> in my ~/config/cf_plplot.in, gives the following line in
> bindings/python/Makefile:
>
> ourpythondir = ${prefix}//usr/lib/python1.5//site-packages
>
> so since I have set prefix to $HOME/tools, this results in absolute nonsense.
> The culprit is:
>
> ourpythondir = ${prefix}/@PYTHON_INSTDIR@
>
> in bindings/python/Makefile.am. How to fix this?
Sorry, I gave you a specific example that is hard to generalize since it
mixes two different prefixes (the one for the python that is already
installed and the one for the plplot to be installed) which are both /usr in
this specific case of building rpm's.
I think almost all of these variables are essentially unused for the new
configuration system which does the same thing an entirely different way.
For example, see how the python version is set with the new configuration
scheme. (See info automake and search there for PYTHON_VERSION.) For now, I
am not going to hack out all this stuff from sysloc.in so you will still
have to set all those variables (although they will be mostly meaningless
except to bypass the bad sysloc.in logic when you have a split python
system). To my knowledge the only variable that matters now is
PYTHON_INSTDIR which is used in bindings/python/Makefile.am and which
therefore is used to create ourpythondir.
sysloc.in sets this variable using
PYTHON_INSTDIR=`echo $PYTHON_DIR | sed s%$prefix/%%`
So I think you have to change the last line above. Use
export PYTHON_DIR=$HOME/tools/lib/python${PY_VERSION}/site-packages
(or is that ${HOME}?) instead.
That should turn the outpythondir definition into
ourpythondir = ${prefix}/lib/python1.5//site-packages
which is exactly what you want if the version associated with the python
command (not python2!) is 1.5.
Anyhow, please change the last export line and let me know whether that works.
Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).
__________________________
Linux-powered Science
__________________________
|
|
From: Maurice L. <mj...@ga...> - 2003-01-19 05:44:21
|
Alan W. Irwin writes: > sysloc.in sets this variable using > PYTHON_INSTDIR=`echo $PYTHON_DIR | sed s%$prefix/%%` > > So I think you have to change the last line above. Use > ... OK, by only setting this in sysloc.in if it's not already set I can override it as needed in my ~/config/cf_plplot.in. After configuring it looks like a winner so I've committed the change. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Maurice L. <mj...@ga...> - 2003-01-19 07:10:56
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > sysloc.in sets this variable using > > PYTHON_INSTDIR=`echo $PYTHON_DIR | sed s%$prefix/%%` > > > > So I think you have to change the last line above. Use > > ... > > OK, by only setting this in sysloc.in if it's not already set I can override > it as needed in my ~/config/cf_plplot.in. After configuring it looks like > a winner so I've committed the change. I finally was able to run this.. it's cool.. yay! Meanwhile I have about 10 immediate plplot projects to work on, I just need to figure out how to create a warp bubble around my office where time will run more slowly and I can get it all done. :/ -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Alan W. I. <ir...@be...> - 2002-12-26 00:33:53
|
On Wed, 25 Dec 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > So in light of that extra information, what do you think of just putting a > > comment in the Makefile.am where swig is invoked and letting it go at that > > (assuming I don't have time to make 1.3.17 work)? If I use the right > > number of # characters in the front of such a comment it propagates to > > Makefile.in and Makefile as well. > > I think it's needed there and in the README.pythondemos as well, since the > latter is where people trying to run the python demos will look. > I have updated bindings/python/README.pythonbuild to reflect the current swig situation. I have also updated examples/python/README.pythondemos to refer to README.pythonbuild and also reflect the current install situation as well as what is required to get the prova.py example to work. I have also updated bindings/python/Makefile.am to a style where the double and single-precision forms of the interface can be pre-generated. (I thought I had this before, but it wasn't really the case.) In the same file I have also documented the required swig version as well. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X