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,
+ 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
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
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 W. Irwin
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