From: Alan W. I. <ir...@be...> - 2004-01-21 00:32:46
|
Koen has summarized recently his problems concerning the java examples (which I couldn't figure out since his java interface seemed to build without obvious problems and his CLASSPATH was set correctly), the octave examples (ascribed to possible fink octave problems), and python. I think we can temporarily write off java and octave because I am not sure there is much we can do about them, but it would be a shame to lose the python interace to Plplot from his fink package since the python interface is one of our most powerful interfaces now. I asked for help sorting out the python examples problem from Rafael. Note, the Debian python interface package could be affected as well if this is a general problem as I suspect. I think my request for help got lost in the noise so I am going to forward my request (slightly modified) again. Alan ---------- Forwarded message ---------- Date: Fri, 16 Jan 2004 18:52:16 -0800 (PST) From: Alan W. Irwin <ir...@uv...> To: PLplot development list <Plp...@li...> Subject: Re: [Plplot-devel] more on Mac OS X (part 2) Executive summary: [...] need help from Rafael to confirm python2.3 problem. [...] > Traceback (most recent call last): > File "python/pythondemos.py", line 9, in ? > from plplot import * > File "/sw/lib/python2.3/site-packages/plplot.py", line 20, in ? > from plplotc import * > File "/sw/lib/python2.3/site-packages/plplotc.py", line 4, in ? > import _plplotc > ImportError: No module named _numpy > > > (out of order) I do have a package 'numeric-py' installed through fink, maybe 'numpy' > is something else? Your configure step almost certainly detected Numeric (which also has the names "numpy" and "numeric-python"). Otherwise, your python interface would not have been built, the python examples would not have been installed, etc. The problem you report has me puzzled. I am now concerned that the way swig sets up the python interface to PLplot is generally inconsistent with python2.3. swig sets up python1.5 and python2.1 interfaces to PLplot without problems, but I don't have access to python2.3 myself for my Debian stable system so I need some testing help for that situation. Rafael, can you confirm this problem on your Debian testing or Debian unstable systems? Both should have python2.3 (and python-numeric 23.1) installed. You don't have to run all the examples or even compile any of the examples. Simply cd to the _installed_ examples/python and run pythondemos.py from that directory. Please also make sure first to execute the "python" command from the command-line to confirm you really have the 2.3 version as default (since I believe other versions of python are available as well on Debian testing and unstable). 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-21 01:03:52
|
On Jan 20, 2004, at 7:28 PM, Alan W. Irwin wrote: > I asked for help sorting out the python examples problem from Rafael. > Note, > the Debian python interface package could be affected as well if this > is a > general problem as I suspect. I think my request for help got lost in > the > noise so I am going to forward my request (slightly modified) again. > > IIRC, the python examples used to work in an earlier 5.2.1-cvs tarball, I will check that later tonight, if I still have the tarball :) - Koen. |
From: Alan W. I. <ir...@be...> - 2004-01-21 02:08:33
|
On 2004-01-20 20:05-0500 Koen van der Drift wrote: > > On Jan 20, 2004, at 7:28 PM, Alan W. Irwin wrote: > > > I asked for help sorting out the python examples problem from Rafael. > > Note, > > the Debian python interface package could be affected as well if this > > is a > > general problem as I suspect. I think my request for help got lost in > > the > > noise so I am going to forward my request (slightly modified) again. > > > > > > IIRC, the python examples used to work in an earlier 5.2.1-cvs tarball, > I will check that later tonight, if I still have the tarball :) I think I remember a good reported result for the python examples from you before also. Did you also have a good result in the past for Java examples or had you ever tried them before? Is it possible you changed python versions between the two tests using some fink system update? As far as I know, we haven't changed anything in the python interface for a while except possibly Rafael's "*DIR" changes, but any problem with them would ordinarily show up as a Linux error in the python interface which we don't see. Rafael has also updated the version of swig used to generate the python and java interfaces. I use swig-1.3.17, he uses swig-1.3.19, and the latest swig available from the swig site is swig-1.3.20. I will try swig-1.3.20 to see if that makes any difference in the *python-2.1* and java results. But I also need the test from Rafael of building and running the examples with python-2.3. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-21 02:30:08
|
On Jan 20, 2004, at 9:08 PM, Alan W. Irwin wrote: > > I think I remember a good reported result for the python examples from > you > before also. Did you also have a good result in the past for Java > examples > or had you ever tried them before? No luck, I deleted most tarballs. And I'm on dialup at home, so I am not going to download older versions right now ;) I can d/l them at work tomorrow. I will also check the archives, if SF is working again. > > Is it possible you changed python versions between the two tests using > some fink system update? No, version is 2.3.3. Maybe Michel or Per can try this too on their Mac OS X system? - Koen. |
From: Alan W. I. <ir...@be...> - 2004-01-21 05:03:00
|
On 2004-01-20 21:30-0500 Koen van der Drift wrote: > > No luck, I deleted most tarballs. And I'm on dialup at home, so I am > not going to download older versions right now ;) > I can d/l them at work tomorrow. I will also check the archives, if SF > is working again. I don't think any of the old tarballs are still around, but in any case let's not worry about those old results (whose results are difficult to remember in any case because there have been so many of them) and instead try to deal with the situation we have now. Tonight I tried swig-1.3.21 to build the python and java interfaces. There was one additional file to be installed for the java case (compared to swig-1.3.17), but that extra file is not in Rafael's swig-1.3.19 generated tarballs so that should not be a problem (until he moves to swig-1.3.21). Once I installed that extra file for my local version, the java example results were identical to before. So were the python results. My conclusion is the Mac OS X problems with the java and python examples are extremely unlikely to be due to swig interface differences. > > > > Is it possible you changed python versions between the two tests using > > some fink system update? > > No, version is 2.3.3. Maybe Michel or Per can try this too on their Mac > OS X system? That would be useful, but I am principally interested in python 2.3.3 example results from Rafael to see whether the problem you report with python-2.3.3 is widespread with that python version or just confined to Mac OS X. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-01-21 07:34:53
|
* Alan W. Irwin <ir...@be...> [2004-01-20 16:28]: > I asked for help sorting out the python examples problem from Rafael. Note, > the Debian python interface package could be affected as well if this is a > general problem as I suspect. I think my request for help got lost in the > noise [...] Yes, it did. Too much noise these days... Sorry for that. > so I am going to forward my request (slightly modified) again. Thanks. > The problem you report has me puzzled. I am now concerned that the way swig > sets up the python interface to PLplot is generally inconsistent with > python2.3. > > swig sets up python1.5 and python2.1 interfaces to PLplot without problems, > but I don't have access to python2.3 myself for my Debian stable system so > I need some testing help for that situation. > > Rafael, can you confirm this problem on your Debian testing or Debian > unstable systems? Both should have python2.3 (and python-numeric 23.1) > installed. You don't have to run all the examples or even compile any of > the examples. Simply cd to the _installed_ examples/python and run > pythondemos.py from that directory. Please also make sure first to execute > the "python" command from the command-line to confirm you really have the > 2.3 version as default (since I believe other versions of python are > available as well on Debian testing and unstable). I have here, in both Debian testing (sarge) and unstable (sid): $ python -V Python 2.3.3 Then I go to the installed tree (cd examples/python), type ./pythondemos.py and everything works like a charm. -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-21 22:23:07
|
On Jan 21, 2004, at 2:33 AM, Rafael Laboissiere wrote: > I have here, in both Debian testing (sarge) and unstable (sid): > > $ python -V > Python 2.3.3 > > Then I go to the installed tree (cd examples/python), type > ./pythondemos.py > and everything works like a charm. > Doesn't work here - still get the error that _numpy cannot be found :( I checked for numpy, and this is what I have in /sw/lib/python2.3/site-packages/Numeric/: -rw-r--r-- 1 root staff 7981 31 Oct 2002 ArrayPrinter.py -rw-r--r-- 1 root staff 9819 25 Dec 17:23 ArrayPrinter.pyc drwxr-xr-x 7 root staff 238 20 Jan 20:30 FFT/ -rw-r--r-- 1 root staff 18123 6 Aug 12:39 LinearAlgebra.py -rw-r--r-- 1 root staff 20686 25 Dec 17:23 LinearAlgebra.pyc drwxr-xr-x 8 root staff 272 20 Jan 20:30 MA/ -rw-r--r-- 1 root staff 12294 28 Aug 2002 MLab.py -rw-r--r-- 1 root staff 20085 25 Dec 17:23 MLab.pyc -rw-r--r-- 1 root staff 6192 6 Jun 2003 Matrix.py -rw-r--r-- 1 root staff 10131 25 Dec 17:23 Matrix.pyc -rw-r--r-- 1 root staff 27530 4 Mar 2003 Numeric.py -rw-r--r-- 1 root staff 39754 25 Dec 17:23 Numeric.pyc -rw-r--r-- 1 root staff 3244 6 Aug 12:39 Precision.py -rw-r--r-- 1 root staff 4556 25 Dec 17:23 Precision.pyc drwxr-xr-x 7 root staff 238 20 Jan 20:30 RNG/ -rw-r--r-- 1 root staff 14268 6 Aug 12:39 RandomArray.py -rw-r--r-- 1 root staff 18884 25 Dec 17:23 RandomArray.pyc -rw-r--r-- 1 root staff 7582 10 Mar 2002 UserArray.py -rw-r--r-- 1 root staff 21412 25 Dec 17:23 UserArray.pyc -rw-r--r-- 1 root staff 33548 25 Dec 17:23 _dotblas.so -rw-r--r-- 1 root staff 251008 25 Dec 17:23 _numpy.so -rw-r--r-- 1 root staff 60224 25 Dec 17:22 arrayfns.so drwxr-xr-x 4 root staff 136 20 Jan 20:30 dotblas/ -rw-r--r-- 1 root staff 54032 25 Dec 17:23 lapack_lite.so -rw-r--r-- 1 root staff 74376 25 Dec 17:22 multiarray.so -rw-r--r-- 1 root staff 15 14 Apr 2003 numeric_version.py -rw-r--r-- 1 root staff 210 25 Dec 17:23 numeric_version.pyc -rw-r--r-- 1 root staff 95968 25 Dec 17:23 ranlib.so -rw-r--r-- 1 root staff 221856 25 Dec 17:22 umath.so The plplot files are in /sw/lib/python2.3/site-packages/: drwxr-xr-x 31 root staff 1054 20 Jan 20:30 Numeric/ -rw-r--r-- 1 root staff 8 25 Dec 17:23 Numeric.pth -rw-r--r-- 1 root staff 119 31 Dec 17:59 README -rwxr-xr-x 1 root staff 111056 20 Jan 17:13 _plplotcmodule.so* -rw-r--r-- 1 root staff 15691 20 Jan 17:13 plplot.py -rw-r--r-- 1 root staff 9750 21 Jan 06:36 plplot.pyc -rwxr-xr-x 1 root staff 9556 20 Jan 17:13 plplot_widgetmodule.so* -rw-r--r-- 1 root staff 6991 20 Jan 17:13 plplotc.py -rw-r--r-- 1 root staff 8976 21 Jan 06:36 plplotc.pyc Maybe the file organization is different on the Mac? - Koen. |
From: Alan W. I. <ir...@be...> - 2004-01-21 23:21:25
|
On 2004-01-21 17:24-0500 Koen van der Drift wrote: > > On Jan 21, 2004, at 2:33 AM, Rafael Laboissiere wrote: > > > I have here, in both Debian testing (sarge) and unstable (sid): > > > > $ python -V > > Python 2.3.3 > > > > Then I go to the installed tree (cd examples/python), type > > ./pythondemos.py > > and everything works like a charm. > > > > Doesn't work here - still get the error that _numpy cannot be found :( > > > I checked for numpy, and this is what I have in > /sw/lib/python2.3/site-packages/Numeric/: [...] > -rw-r--r-- 1 root staff 251008 25 Dec 17:23 _numpy.so [...] ^^^^^^^^^ So it is there just as on my machine with exactly the same permissions as mine. Why isn't python finding it? Try the following simple test: Invoke python from the examples/python directory python from plplot_python_start import * # See whether you have access to Numeric (and indirectly to _numpy). from Numeric import * # exit from python ctrl-d Try the experiment both with and without the from plplot_python_start import * line. If you look at plplot_python_start.py in examples/python, all it does is append to the effective python path in case you have a non-standard prefix. For your case of a standard prefix, it should make no difference. If both cases (with and without the plplot_python_start import) work, then I am really puzzled since the from Numeric import * command is failing (from the imported xw01) when you run pythondemos.py from that same directory. If you look inside Numeric.py there is a line that does the following: import _numpy # for freeze dependency resolution (at least on Mac) You can try that directly yourself under python as well as a single command. (It is interesting that there is some Mac dependent commentary for that line at least for my python-2.1 system). If you cannot import _numpy (which works here) as a single python command, then that problem has nothing to do with PLplot, and it is time to hit the fink lists to find out what they are doing to resolve that fundamental problem with their Numeric package. Thanks very much, Koen, for all the care and trouble you are taking to try and get the python interface to Plplot to work on Mac OS X. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-22 00:10:23
|
On Jan 21, 2004, at 6:21 PM, Alan W. Irwin wrote: > (which works here) as a single python command, then that problem has > nothing > to do with PLplot, and it is time to hit the fink lists to find out > what > they are doing to resolve that fundamental problem with their Numeric > package. No need for that. I figured out the problem. Fink has a package for python23 for version 2.3.x, which I have installed. However, it turns out there is also a package 'python' which is only a placeholder, and puts a symlink from /sw/bin/python to /sw/bin/python23. I forgot to install python, causing the problems. > > Thanks very much, Koen, for all the care and trouble you are taking to > try > and get the python interface to Plplot to work on Mac OS X. you're welcome - it's a great exercise and journey for myself too, - Koen. |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-22 00:53:35
|
On Jan 21, 2004, at 7:12 PM, Koen van der Drift wrote: > No need for that. I figured out the problem. Fink has a package for > python23 for version 2.3.x, which I have installed. However, it turns > out there is also a package 'python' which is only a placeholder, and > puts a symlink from /sw/bin/python to /sw/bin/python23. I forgot to > install python, causing the problems. > One small addition - the file ./test_python.sh has a line /usr/bin/python, I had to change this to /sw/bin/python to get the batch script to work. - Koen. |
From: Alan W. I. <ir...@be...> - 2004-01-22 02:23:34
|
On 2004-01-21 19:55-0500 Koen van der Drift wrote: > > On Jan 21, 2004, at 7:12 PM, Koen van der Drift wrote: > > > No need for that. I figured out the problem. Fink has a package for > > python23 for version 2.3.x, which I have installed. However, it turns > > out there is also a package 'python' which is only a placeholder, and > > puts a symlink from /sw/bin/python to /sw/bin/python23. I forgot to > > install python, causing the problems. > > > I am glad that is sorted out. > One small addition - the file ./test_python.sh has a line > /usr/bin/python, I had to change this to /sw/bin/python to get the > batch script to work. That is most peculiar. That is a configured file (source test/test_python.sh.in) where @PYTHON@ is changed to what should be the correct python command on your system for test_python.sh. When Rafael creates the tarball he runs configure on his system so @PYTHON@ gets replaced by his location for the python executable which I am sure is /usr/bin/python. But then when you run configure on your system test/test_python.sh should be completely overwritten corresponding to your system. Would you please check that the date of test/test_python.sh is consistent with when you ran ./configure, and test/test_python.sh is identical with the file in the installed examples? (diff them against each other). Also, please let us know the results of the following command run at the top of your build tree. grep PYTHON Makefile on my system, that command returns PYTHON = /usr/bin/python PYTHON_EXEC_PREFIX = ${exec_prefix} PYTHON_INC_DIR = /usr/include/python2.1 PYTHON_INSTDIR = /usr/local/plplot_at/lib/python2.1/site-packages PYTHON_NUM_DIR = /usr/include/python2.1/Numeric PYTHON_PLATFORM = linux2 PYTHON_PREFIX = ${prefix} PYTHON_VERSION = 2.1 Your results should correspond to python locations on your system for your version of the Makefile. If PYTHON = /usr/bin/python is in the Makefile, but it doesn't correspond to anything on your system, then something is wrong with the automake macro AM_PATH_PYTHON which is supposed to generate the correct PYTHON string for your system (according to our experience on all other platforms we have tested and also the documentation available from info automake). 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-21 22:57:32
|
On Jan 21, 2004, at 12:02 AM, Alan W. Irwin wrote: > My conclusion is the Mac OS X problems with the java and python > examples are > extremely unlikely to be due to swig interface differences. > Should swig be installed on my system? - Koen. |
From: Rafael L. <rla...@us...> - 2004-01-21 23:22:26
|
* Koen van der Drift <kvd...@ea...> [2004-01-21 17:59]: > On Jan 21, 2004, at 12:02 AM, Alan W. Irwin wrote: > > >My conclusion is the Mac OS X problems with the java and python > >examples are > >extremely unlikely to be due to swig interface differences. > > > > Should swig be installed on my system? No, swig would only be needed if you changed the files bindings/python/*.i. The distribution tarball contains already all the swig-generated files. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-01-21 23:25:47
|
On 2004-01-21 17:59-0500 Koen van der Drift wrote: > > On Jan 21, 2004, at 12:02 AM, Alan W. Irwin wrote: > > > My conclusion is the Mac OS X problems with the java and python > > examples are > > extremely unlikely to be due to swig interface differences. > > > > Should swig be installed on my system? Short answer: no. Longer answer: It is necessary if you are using cvs. But Rafael's script for generating the tarball uses _his_ version of swig to pre-generate the python and java interfaces to PLplot. So if you use the tarball you don't need swig. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2004-01-21 23:57:51
|
On 2004-01-21 08:33+0100 Rafael Laboissiere wrote: > I have here, in both Debian testing (sarge) and unstable (sid): > > $ python -V > Python 2.3.3 > > Then I go to the installed tree (cd examples/python), type ./pythondemos.py > and everything works like a charm. Thanks very much for that important test, Rafael. That result along with my swig version and python and java experiments yesterday indicate we don't have a general problem with either the python or java interfaces. Also, we have now narrowed down the Mac OS X problem to not being able to find _numpy even though the appropriate _numpy.so file is clearly on Koen's system. If Koen can solve that we might be in python business again on Mac OS X. So here is the status of this release from my test coordinator perspective: Assuming the changes currently in CVS (excluding memory management) go into the next release candidate for 5.3.0 (which should be available at latest within a week according to Rafael) here is my assessment of what that next candidate will show on Mac OS X 10.3. * Everything default will build seamlessly (with various fortran workarounds required using the FLIBS environment variable). This includes the java examples which are built as part of the install. * The installed C, C++, f77, and tk examples will build seamlessly. * The C, C++, f77, and tcl examples will run and produce good-looking plots, but + anything to do with tk (e.g., -dev tk) will have run-time errors. + the java, python, and octave examples will have run-time errors. The tk problem is probably our own fault due to cross-platform problems with our tk support which can only be fixed substantially beyond the current release. I assume the rest of the java, python, and octave difficulties are due to Mac OS X/fink teething troubles with those packages. If that assumption is correct, then those problems may "automatically" disappear in the future as Mac OS X/fink matures (and it is also possible the python problem will disappear virtually immediately if Koen finds out how to make _numpy accessible). I hope that maturation happens fast since the java, python, and octave interfaces are so powerful and so useful, but that timing is out of our hands. Assuming my predictions are correct, then I think we are good for release as far as Mac OS X 10.3 is concerned. There are definitely problems for earlier Mac/Fink versions, however, and we should make it clear we don't support those earlier versions in the release announcement. Cygwin is probably a good new platform for us as well. Our tester for that platform, Ullal Devappa Kini, reported for an October PLplot version that certain devices had problems (notably the xterm device), but other devices like xwin worked fine. Static libraries worked fine, and so did shared libraries if dyn-drivers were disabled. I think that latter problem is probably now fixed due to Rafael's recent efforts on generalizing the linking of get-drv-info so I presume Cygwin will be on par with Mac OS X (except for the xterm device). Ullah, I have forwarded this report to you in hopes you will test RC1 now and RC2 when it becomes available in the next week. I think we are almost there as far as OSF1 is concerned as well. Thanks to Joao's feedback, I have fixed the fortran interface for OSF1 f90 and also the fortran examples, and I have just committed that change to CVS HEAD. As far as I know, the core of PLplot is fine on Linux (except for a slow memory leak) without the memory management fixes, and if somebody steps forward to deal with the segfault issue for the plend command from pltcl, then Rafael has expressed some willingness to include the memory management fixes in the release as well. Brian Wright has very recently been finding some octave interface problems on Linux, but it appears to me those are being fixed by Rafael as rapidly as Brian finds them. I also assume everything is release ready on sys/win32/msdev (Arjen), sys/win-tk (Vince), and sys/dos/djgpp (Andrew Roach). The one huge gap in our testing continues to be several major unices, e.g., HPUX, AIX, IRIX, and Solaris. I ask that everybody with access give RC1 a try on those unices and report back successes/failures. (RC2 will have a fix for linking get-drv-info when you are also building the tcl/tk interface to PLplot, but that is a fairly rare corner case for Unix. If it still turns out to be a problem for you for RC1, you can get around it by setting LD_LIBRARY_PATH appropriately. So don't wait for RC2 to do your Unix testing!) Apparently Don Spong tried PLplot (perhaps an old version) on AIX recently without much success. Don, if you also have troubles with RC1, could you please give all the gory details? RC1 is available for download at http://people.debian.org/~rafael/plplot.html. I do have access to a Source Forge compile farm solaris box with C, C++, and fortran on it which I will try today, but my testing will be quite limited there since java, python, tcl/tk, and octave are not available on that box. Unless some issue turns up on solaris or elsewhere that I can help fix, I don't anticipate I will be doing any more commits until this release is out the door. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2004-01-23 07:42:58
|
This report is for current CVS HEAD (which should be close to the same as the next release candidate except for the memory management fixes). I had to commit some changes for sysloc.in, and lib/*/nan.h to recognize the big endian case properly on solaris. Also, I committed a change to examples/f77/x18f.fm4 which needed a type change to compile under f95. Also, I have privately asked Rafael to fix one problem in examples/c++/Makefile.am that turned up during the install step. After those changes done, the short story is everything natively available on solaris (which isn't much in this case, just C and fortran) worked fine. But it took a lot of effort so here is the cookbook which should become part of the INSTALL file. * Platform (uname -a): SunOS sparc-solaris1 5.9 Generic_112233-03 sun4u sparc SUNW,Ultra-60 * Development environment: native cc, f95, and ld. * Environment variables that should be set _before_ ./configure is run: + export MYPREFIX=/whatever + export PATH='/opt/SUNWspro/bin:/usr/ccs/bin:'$PATH':$MYPREFIX/bin' /opt/SUNWspro/bin puts native cc and f95 on the path, /usr/ccs/bin puts native ld on the path, and $MYPREFIX/bin is there for when you want to execute some of those PLplot executables or scripts you have just installed. + export CC=cc Identify the native C compiler for ./configure + export F77=f95 Identify the native fortran compiler for ./configure Note, there is also a f77 script that invokes the f95 compiler with certain options. But use of F77=f77 confused libtool, and it was better to use F77=f95 directly (with no special options). This means our fortran code (interface and examples) is reasonably standards compliant because it all compiled under the native solaris f95 compiler with no special flags. Note, fortran command-line parsing worked on solaris so we are now three for three (g77, OSF1 f77, and solaris f95) on that score. + export FLIBS='-R/opt/SUNWspro/lib -L/opt/SUNWspro/lib -L/opt/SUNWspro/prod/lib -L/usr/ccs/lib -L/usr/lib -lf77compat -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai -lfminvai -lfmaxvai -lfsu -lsunmath -lm' Identify link flags required for mixed fortran/C libraries, i.e., libplplotf77. I am not sure all these complications are necessary for FLIBS, but this works and this FLIBS string is close to what the AC_F77_LIBRARY_LDFLAGS macro produces for this solaris system. (The FLIBS string produced by the macro had the -lf77compat option in the wrong place [before the corresponding -L option] and the -lompstubs option had to be eliminated because that library was causing trouble.) It is possible other solaris systems will be different so you may have to play some with FLIBS to get the right combination. * Remaining commands to configure, build, and install: + ./configure --prefix=$MYPREFIX --disable-cxx --without-gnu-ld --disable-cxx is required since native C++ is not available on this system (while g++ is, and that may confuse issues unless you turn it off). --without-gnu-ld is required so the native linker, /usr/ccs/bin is used rather than the Gnu linker in /usr/local/bin/ld. Note this is a "bare bones" sparcbox so absolutely nothing is available for development natively other than the cc C compiler, the g95 fortran compiler, and the ld linker. + make + make install Here is the configuration summary: command: ./configure --prefix=/home/users/a/ai/airwin/plplot_install_solaris_sparc/ --disable-cxx --without-gnu-ld system: sparc-sun-solaris2.9 have_x: yes prefix: /home/users/a/ai/airwin/plplot_install_solaris_sparc/ CC: cc F77: f95 LIB_TAG: d devices: dg300 hp7470 hp7580 lj_hpgl imp ljii ljiip mem null pbm plmeta ps psc pstex xterm tek4010 tek4107 mskermit versaterm vlt conex tek4010f tek4107f xfig xwin Available device drivers: static: dynamic: dg300.la hpgl.la impress.la ljii.la ljiip.la mem.la null.la pbm.la plmeta.la ps.la pstex.la tek.la xfig.la xwin.la Compilation options: with_debug: no with_opt: yes with_warn: no with_profile: no Library options: enable_shared: yes enable_static: yes with_rpath: yes with_double: yes Optional libraries: with_qhull: no with_csa: yes with_freetype: no with_pthreads: no Language Bindings: enable_tcl: no enable_itcl: no enable_cxx: no enable_f77: yes enable_java: no enable_python: no enable_octave: no As you can see a fair number of devices got built, although the only ones really useful on a remote machine like this without X client access are the psc and ps devices. make and make installed proceeded without errors. (Well, that will happen next time on the install once the examples/c++/Makefile.am issue is fixed.) After I installed (to a non-root MYPREFIX that was under my control as an ordinary user) I did the usual test: cd $MYPREFIX/share/plplot5.2.1.rc1.5.3.0/examples; make; ./plplot-test.sh and 34 postscript figures were produced. Roughly half were identical with Linux-produced figures, and the other half were only slightly distinguishable visually (slight changes in the rendering of some of the characters). Presumably these differences are due to our current 16-bit rendering. In sum, it should be a clean native (cc, f95, and ld) solaris test for the next release candidate. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-01-22 09:04:35
|
* Alan W. Irwin <ir...@be...> [2004-01-21 18:23]: > > One small addition - the file ./test_python.sh has a line > > /usr/bin/python, I had to change this to /sw/bin/python to get the > > batch script to work. > > That is most peculiar. That is a configured file (source > test/test_python.sh.in) where @PYTHON@ is changed to what should be the > correct python command on your system for test_python.sh. > > When Rafael creates the tarball he runs configure on his system so @PYTHON@ > gets replaced by his location for the python executable which I am sure is > /usr/bin/python. But then when you run configure on your system > test/test_python.sh should be completely overwritten corresponding to your > system. I hope this is true, but it may be false. I do not know very well the internals of AC_OUTPUT, but since *_both_* test_plplot.sh and test_plplot.sh.in are present in the tarball, things can get weird. The culprit is the following line in test/Makefile.am: EXTRA_DIST = test_*.sh This should read instead: EXTRA_DIST = test_c.sh \ test_cxx.sh \ test_java.sh \ test_octave.sh \ test_single_python.sh \ test_single_tcl.sh \ test_tcl.sh I.e., we should not distribute *.sh files for which there are *.sh.in. Alan, if you agree, I will make the changes in CVS. Koen, could you please do the following experiment: after detaring the tarball, cd test; rm -f test_python.sh. Then ./configure --enable-python. Which python path appears in the generated test_python.sh? -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-01-22 19:14:25
|
On 2004-01-22 10:03+0100 Rafael Laboissiere wrote: > I.e., we should not distribute *.sh files for which there are *.sh.in. > Alan, if you agree, I will make the changes in CVS. Yes, please! 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-22 23:00:50
|
On Jan 21, 2004, at 9:23 PM, Alan W. Irwin wrote: > That is most peculiar. That is a configured file (source > test/test_python.sh.in) where @PYTHON@ is changed to what should be the > correct python command on your system for test_python.sh. > Sorry, my mistake - I tested the examples I put in ~/tmp. I failed to update them after I rebuild plplot with the additional python package. I still cannot run ./test_python.sh directly, I get this error: can't open file '/pythondemos.py'. Using ./plplot_test.sh works fine. - Koen. |
From: Alan W. I. <ir...@be...> - 2004-01-23 02:19:13
|
On 2004-01-22 18:01-0500 Koen van der Drift wrote: > > On Jan 21, 2004, at 9:23 PM, Alan W. Irwin wrote: > > > That is most peculiar. That is a configured file (source > > test/test_python.sh.in) where @PYTHON@ is changed to what should be the > > correct python command on your system for test_python.sh. > > > > Sorry, my mistake - I tested the examples I put in ~/tmp. I failed to > update them after I rebuild plplot with the additional python package. No problem. > > I still cannot run ./test_python.sh directly, I get this error: can't > open file '/pythondemos.py'. ./test_python.sh should not be run standalone (as documented in that script and as you just found out). Instead, ./plplot_test.sh interprets its options, and sets environment variables appropriately before invoking ./test_python.sh. > Using ./plplot_test.sh works fine. Excellent. ==> Case closed (although I still think Rafael's proposed test/Makefile.am configuration change for test_python.sh is a good cleanup.) Note, if you just want to run the python examples alone with that script, try ./plplot-test.sh --front-end=python. Also, try ./plplot-test.sh --help to see other options. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |