plplot-devel

[Plplot-devel] New test run on Debian woody

[Alan W. I. <ir...@be...>]

Starting from scratch on a new disk (so I could preserve my old Debian
potato distribution) I have installed a Debian woody distribution including
all the development tools.  For those that don't know woody is the testing
distribution which should turn into the stable distribution within a few
months after all the major bugs have been squashed.  But it is stable enough
for my needs [in fact no obvious problems for a week now] so I am going with
it. I can now dual-boot between potato and woody, but it is so nice to work
with the most recent versions of everything that I haven't booted potato
for a week.  (Incidentally, anti-aliasing of fonts works essentially out of
the box with KDE-2.2.1 [which I compiled for myself] and xfree86-4.1.0.  I
simply changed one configuration parameter for the QT 2.3.1 library build in
expectation that a lot more would have to be done to get AA working, but
instead I got a most pleasant surprise the next time I opened up my KDE
desktop.  AA looks wonderful!)

To get to the plplot story, I bugfixed lib_sh_linux.in (the c++ example
could not possibly build without this fix), and also changed sysloc.in so
that tcl8.3 and python2.0 would be found easier.  python2.0 just made it
into woody last week so my earlier comments about being stuck with python1.5
for the forseeable future no longer apply.  Also, tcl8.3 is a considerable
advance on tcl8.1 that was available to me in potato.

After these changes

./configure --prefix=/usr/local/plplot --with-double

worked fine to give me everything except for only two configure "no" results
at the end; java (because I don't have it on my system, sorry Geoffrey) and
gnome (because it is not enabled by default and nobody has worked on it
recently).

make had some warnings (which may require further investigation) but no errors
and similarly for make install so I went ahead with running all the
non-interactive postscript examples in
/usr/local/plplot/lib/plplot5.0.4/examples/

Some problems did show up for my new woody environment:

(1) The python xw??.py scripts didn't work out of the box because Debian
woody calls the command python2 to distinguish it from the python-1.5
command which is still called python.  I tried alias so that executing
python interactively actually did execute python2, but /bin/env python
ignores the alias, and gets the old version.  (Numeric is not installed for
that old version so it makes a mess.) The only way out I could see was to
locally (not in cvs) edit all the xw??.py scripts to change the reference in
the first line from python to python2.  I don't see any easy way around this
name change. Unless somebody has a suggestion for an easy fix, I think we
should write this off as a temporary Debian woody peculiarity which will
eventually get fixed, and not make any changes to plplot.  This is
something, however, that Rafael will have to deal with as the woody packager
of plplot.

(2) Another python problem was that the plcont calls in xw09.py produce a
segfault. I doubt this is a Numeric problem since all my other high-level
Numeric code in the examples seems to work fine.  Also, getting plcont to
work at all under potato conditions was quite tricky (and perhaps even
magical since it seemed to start working for me after the most trivial
change way back when) so it might be true that there has always been a
problem with the plcont code in plmodules.so, and under the new woody
environment the problem is not covered up so well.

(3) All the octave colours were weak.  I did not notice that problem when I
last ran a test (under the old version of octave in potato).  Do you get
this problem also, Joao?  Note my version of octave is now 2.0.  octave 2.1
is currently in unstable and may get into woody soon.

(4) x19c continues not to work in the new plplot environment.  The 3rd map
page continues to be messed up.  Andrew, I am hoping that your map interest
will motivate you to squash this bug....;-)

The upside of this comprehensive test is every other non-interactive demo
(including the tcl ones and the remainder of the python ones, once I had
edited the scripts to call python2) worked fine and produced identical
results to before.  So fundamentally the new (to me) python2 and tcl8.3 are
working fine with the latest plplot.

So I am fairly happy both with the latest plplot from cvs HEAD and woody. I
intend to go back to potato only if there is some emergency.  Same is true
of plplot 5.0.4.

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
__________________________

Re: [Plplot-devel] New test run on Debian woody

[<jca...@in...>]

On Thursday 18 October 2001 01:32, Alan W. Irwin wrote:
=2E..
| (3) All the octave colours were weak.  I did not notice that
| problem when I last ran a test (under the old version of octave in
| potato).  Do you get this problem also, Joao?  Note my version of
| octave is now 2.0.  octave 2.1 is currently in unstable and may get
| into woody soon.

What do you mean with "weak"? the colors got faded? pastel? gone? :)
I work with octave-2.1.34, xfree-4.1.0, tcltk-8.3...=20

Joao

Re: [Plplot-devel] New test run on Debian woody + FURTHER TESTS + NEW RELEASE?

[Alan W. I. <ir...@be...>]

On Thu, 18 Oct 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Thursday 18 October 2001 01:32, Alan W. Irwin wrote:
> ...
> | (3) All the octave colours were weak.  I did not notice that
> | problem when I last ran a test (under the old version of octave in
> | potato).  Do you get this problem also, Joao?  Note my version of
> | octave is now 2.0.  octave 2.1 is currently in unstable and may get
> | into woody soon.
>
> What do you mean with "weak"? the colors got faded? pastel? gone? :)
> I work with octave-2.1.34, xfree-4.1.0, tcltk-8.3...

Sorry.  False alarm.  I only looked at the octave plots yesterday because
they were the only ones different from previous (presumably because of
legend changes). This morning I investigated further and it turns out the
effect is in all our plots and is caused by antialiasing in gv and has
nothing to do with actual plplot file results.  With the new gv,
antialiasing is on by default which causes the colours of the sharp lines
in our plots to look horrible. gv -noantialiasing solves the problem.

So discounting the python2 name change, that only leaves the xw09.py
segfault, and the continuing problem with the 3rd map in x19c.ps as the onl=
y
obvious errors left in the non-interactive postscript tests.

FURTHER TESTS....

I also ran the script for the png driver this morning, and there are some
problems (for real this time ....;-)) with the octave stuff in that case.
There are severe size problems with the legends for all plots.  This does
not happen for the postscript results although the sizing of the legends
needs work there as well.  I think the problem is that pixel units are bein=
g
used rather than coordinates that will give the same result for every
driver. Also, page 1 of the p15 plot and page 1 of the p7 plot are missing =
a
lot of the plot that is visible with the postscript driver.  I think it is =
a
colour initialization problem in both cases that might be fixed by setting
the colour at the start of each octave example rather than relying on
default values.  (I have run into this problem before with the octave
examples; the colour results depend on the order you run the plots, and the
driver.)

All png results differed from previous which is expected because I am now
using libgd-2.0.1 rather than the old libgd-1.7.3 that was available for
potato.  However, visual inspection showed nothing obviously wrong except
for the remarks I made above about the octave results for the png driver.
In particular Andrew's png driver changes he made some time ago to rescale
the size seemed to fix some line hiding problems that appeared in the
old results.  (The only thing I can think of that would explain that
result is that we were subject to rounding errors before with the small
number of pixels.)

I also exercised all the tk interactive examples, and they seem to work
fine.

Geoffrey, I would be happy to add java to the testing, but I would need a
short cookbook from you on exactly what software to get and what commands
to run to exercise your examples.  I probably also need advice from Rafael
about how to implement java on Debian.  For example, I looked for java
packages, and there is dummy java virtual machine and dummy java compiler.
The advice for these packages is to install them if you have a "real" java
compiler and java virtual machine.  Huh?

NEW RELEASE?

If somebody is willing to fix the two mentioned postscript problems, and
Joao sorts out the legend coordinate and colour initialization problems for
the octave examples, I think that would put us in good position to release
5.1.0 as a stable release in the near future featuring the dynamic drivers
and the new java stuff (if I can figure out how to test it).  This
presupposes that it will be some time (because of his new job pressures)
beofe Rafael can start integrating his AM/LT changes.

What do the rest of you think of this release strategy?  My motivation is t=
o
continue to release often so that users have something definite they can
rely on rather than the moving target that is CVS HEAD.  Also our ~1500 use=
rs
(as judged from the download numbers) seem quite willing to download and
try out each new version, and this diverse testing is quite a help for
improving our product.

I am hoping to release say two weeks from now, but that timing depends
critically on people stepping forward to fix the bugs I mentioned and on
whether other bugs are there which I an unaware of.  Also it depends
critically on whether there are plans to add important new functionality
such as the tea-based stuff to the HEAD in the near future. So let me know
your thoughts.

Alan

Re: [Plplot-devel] NEW RELEASE?

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > Geoffrey, I would be happy to add java to the testing, but I would need a
 > short cookbook from you on exactly what software to get and what commands
 > to run to exercise your examples.  I probably also need advice from Rafael
 > about how to implement java on Debian.  For example, I looked for java
 > packages, and there is dummy java virtual machine and dummy java compiler.
 > The advice for these packages is to install them if you have a "real" java
 > compiler and java virtual machine.  Huh?

In order to compile the Java binding, you'll need a full JDK
installed.  Our sysop did it here, so I haven't been through this
personally for a while.  The definitive site for Java Linux, is
blackdown.org, which ports Sun's JDK's to Linux.  There are some
alternatives: IBM's JIKES compiler, Guavac, gcj, kaffe, but I haven't
personally tried any of them.  I've only used the blackdown.org
stuff. 

Once you fetch/install a JDK for your system, you'll need to set
JAVA_HOME to point to it.  For instance, I have here:

src/ds++> echo $JAVA_HOME/
/usr/local/jdk1.3/

I think the PLplot configure script keys of that, if I remember
right.  Then you need to set your CLASSPATH to "java" (if you're
operating from plplot/tmp), or even a fully qualified path if you
prefer.  Finally, make sure you have LD_LIBRARY_PATH set to . (during
development) or $prefix/lib (after installing).

configure --enable-java and make will then build javabind.c, and stuff
it into libplplot.so, and build the java PLStream.java file which
forms the core of the Java-side interface.  Then "make jdemos" to
build the java demos.  Then to run them, do:
      java plplot/examples/x01
for example.  

Undestanding that last line takes just a little bit of orientation.
The whole thing hangs on the setting of this CLASSPATH variable, which
effectively tells java where its universe lives.  So what happens is
that compiling tmp/x01.java results in a file
tmp/java/plplot/examples/x01.class, and when you say java
plplot/examples/x01, it looks basically for
$CLASSPATH/plplot/examples/x01.class ==
tmp/java/plplot/examples/x01.class.

So, post install, you set CLASSPATH to $prefix/lib/java, and then from
anywhere, you can just say java plplot/examples/x01, and it (the JVM)
will just run directly $prefix/lib/java/plplot/examples/x01.class.
Everything keys off CLASSPATH.

Just be aware that $CLASSPATH/plplot/core/PLStream.class (compiled
from PLStream.java) itself actually dynamically loads libplplot.so, so
LD_LIBRARY_PATH has to be set to find the one of those that you want.
Again, post-install, LD_LIBRARY_PATH = $prefix/lib does the job.  Then
you'll be able to run the java demos, or java application code, from
anywhere, just as long as CLASSPATH and LD_LIBRARY_PATH are set
right. 

I know it sounds like kind of a lot, but it isn't bad with a few
aliases.  

 > NEW RELEASE?
 > 
 > If somebody is willing to fix the two mentioned postscript problems, and
 > Joao sorts out the legend coordinate and colour initialization problems for
 > the octave examples, I think that would put us in good position to release
 > 5.1.0 as a stable release in the near future featuring the dynamic drivers
 > and the new java stuff (if I can figure out how to test it).  This
 > presupposes that it will be some time (because of his new job pressures)
 > beofe Rafael can start integrating his AM/LT changes.
 > 
 > What do the rest of you think of this release strategy?  

I am totally swamped at work right now, so I don't expect to do
anything major new anytime soon.  I may do some bug fixes here and
there.  I'll have to check in that change we discussed recently so the
java stuff will work with dynamic drivers again.  That should be in
before the release, but anything else you need will need to come from
others.

WRT python and plcont:  I remember that being a trouble spot.  I think
if you read the plmodule.c code, you'll probably see the evidence of
confused thrashing and milling about.  Sorry.  I thought I had left it
in a useable state, but maybe not.  I /know/ that when I last ran
pytkdemo, all the plots looked fine to me, but that's been a number of
years/jobs ago, so my memory isn't 100%.  I hope I didn't have some
uncommitted change/fix that got left on some disk N employers ago
without ever getting check in...

I thought the prospects for using PLplot+Python here were good as
recently as a month ago, but recently those hopes were dashed.  We'll
still use PLplot here, but it will be with the Tcl/Tk front end, since
the whole EDA industry has basically adopted Tcl as its scripting
language.  Better than nothing, but I'd hoped to raise the bar a bit..
Oh well.

 > I am hoping to release say two weeks from now, but that timing depends
 > critically on people stepping forward to fix the bugs I mentioned and on
 > whether other bugs are there which I an unaware of.  

I'll check in the raparation for the Java+dyndrivers, but I can't
commit to looking at the other stuff.

-- 
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] NEW RELEASE?

[Alan W. I. <ir...@be...>]

Thanks, Geoffrey, for that java cookbook.  Rafael, if you cannot advise me
due to lack of java-Debian experience, the first thing I will try is to
install the dummy java Debian packages, and see what the documentation of
them says for making Debian work with the Blackdown version of the JDK.

As far as the python xw09.py segfault error, I know this did not occur for
my last tests in September.  But a lot has changed since then on my system
and also for plplot.  To help distinguish these two possibilities, can
anybody else replicate the bug for plplot HEAD and either or both of
python-1.5 and python-2.0?

Thanks.

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
__________________________

On Fri, 19 Oct 2001, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > Geoffrey, I would be happy to add java to the testing, but I would need a
>  > short cookbook from you on exactly what software to get and what commands
>  > to run to exercise your examples.  I probably also need advice from Rafael
>  > about how to implement java on Debian.  For example, I looked for java
>  > packages, and there is dummy java virtual machine and dummy java compiler.
>  > The advice for these packages is to install them if you have a "real" java
>  > compiler and java virtual machine.  Huh?
>
> In order to compile the Java binding, you'll need a full JDK
> installed.  Our sysop did it here, so I haven't been through this
> personally for a while.  The definitive site for Java Linux, is
> blackdown.org, which ports Sun's JDK's to Linux.
.
.
.

> WRT python and plcont:  I remember that being a trouble spot.  I think
> if you read the plmodule.c code, you'll probably see the evidence of
> confused thrashing and milling about.  Sorry.  I thought I had left it
> in a useable state, but maybe not.  I /know/ that when I last ran
> pytkdemo, all the plots looked fine to me, but that's been a number of
> years/jobs ago, so my memory isn't 100%.  I hope I didn't have some
> uncommitted change/fix that got left on some disk N employers ago
> without ever getting check in...
>

Re: [Plplot-devel] NEW RELEASE?

[Geoffrey F. <fu...@ga...>]

BTW, I thought I saw a link for deb packages at blackdown.

Alan W. Irwin writes:
 > Thanks, Geoffrey, for that java cookbook.  Rafael, if you cannot advise me
 > due to lack of java-Debian experience, the first thing I will try is to
 > install the dummy java Debian packages, and see what the documentation of
 > them says for making Debian work with the Blackdown version of the JDK.

-- 
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] NEW RELEASE?

[Rafael L. <ra...@ic...>]

* Alan W. Irwin <ir...@be...> [2001-10-19 11:29]:

> Rafael, if you cannot advise me due to lack of java-Debian experience,
> [...]

Sorry, Alan, I am completely ignorant on java-Debian matters.  You may try :

    http://people.debian.org/õpal/java/policy.html

> [...] the first thing I will try is to install the dummy java Debian
> packages, and see what the documentation of them says for making Debian
> work with the Blackdown version of the JDK.

Look at the archives of the debian-java mailing list
(http://lists.debian.org/devel.html).

--
Rafael

Re: [Plplot-devel] New test run on Debian woody + FURTHER TESTS + NEW RELEASE?

[Joao C. <jca...@in...>]

On Thursday 18 October 2001 18:14, Alan W. Irwin wrote:
| On Thu, 18 Oct 2001, [iso-8859-1] Jo=E3o Cardoso wrote:
| > On Thursday 18 October 2001 01:32, Alan W. Irwin wrote:
=2E..

| FURTHER TESTS....
|
| I also ran the script for the png driver this morning, and there are so=
me
| problems (for real this time ....;-)) with the octave stuff in that cas=
e.
| There are severe size problems with the legends for all plots.

As it didn't happen for me, I was assuming that the fault was yours.
But the other day I start octave with the xwin driver, and I noticed the=20
problems.

The problem does not occur for the tk or ps drivers!
Hummm, can't this be related with your changes related with the aspect-ra=
tio=20
problem?

|  This does
| not happen for the postscript results although the sizing of the legend=
s
| needs work there as well.  I think the problem is that pixel units are
| being used rather than coordinates that will give the same result for e=
very
| driver.

The problem with the legend box, is that I need to calculated the box=20
dimension, knowing the string size and the number of lines, and I use the=
=20
returned height from plgchr(). As plplot fonts are proportional, the widt=
h of=20
the box will be wrong some times, but the height should be OK. If plgchr(=
)=20
returns a wrong height, everything gets messed.
Could your changes related with fonts and aspect-ratio have some impact o=
n=20
this?

Joao


| Also, page 1 of the p15 plot and page 1 of the p7 plot are missing
| a lot of the plot that is visible with the postscript driver.  I think =
it
| is a colour initialization problem in both cases that might be fixed by
| setting the colour at the start of each octave example rather than rely=
ing
| on default values.  (I have run into this problem before with the octav=
e
| examples; the colour results depend on the order you run the plots, and=
 the
| driver.)

Could you give a recipe to make it fail?

| All png results differed from previous which is expected because I am n=
ow
=2E..

| NEW RELEASE?
|
| If somebody is willing to fix the two mentioned postscript problems, an=
d
| Joao sorts out the legend coordinate and colour initialization problems=
 for
| the octave examples, I think that would put us in good position to rele=
ase
| 5.1.0 as a stable release in the near future featuring the dynamic driv=
ers
| and the new java stuff (if I can figure out how to test it).  This
| presupposes that it will be some time (because of his new job pressures=
)
| beofe Rafael can start integrating his AM/LT changes.
|
| What do the rest of you think of this release strategy?=20

Thats OK to release often, but call it 5.1.0 is too much, as there are st=
ill=20
many loose things to fix.

Joao

Re: [Plplot-devel] New test run on Debian woody

[Maurice L. <mj...@ga...>]

(I just returned from vacation)

Alan W. Irwin writes:
 > Some problems did show up for my new woody environment:
 > 
 > (1) The python xw??.py scripts didn't work out of the box because Debian
 > woody calls the command python2 to distinguish it from the python-1.5
 > command which is still called python.  I tried alias so that executing
 > python interactively actually did execute python2, but /bin/env python
 > ignores the alias, and gets the old version.  (Numeric is not installed for
 > that old version so it makes a mess.) The only way out I could see was to
 > locally (not in cvs) edit all the xw??.py scripts to change the reference in
 > the first line from python to python2.  I don't see any easy way around this
 > name change. Unless somebody has a suggestion for an easy fix, I think we
 > should write this off as a temporary Debian woody peculiarity which will
 > eventually get fixed, and not make any changes to plplot.  This is
 > something, however, that Rafael will have to deal with as the woody packager
 > of plplot.

I always use softlinks for this kind of thing.  Link `which python2` to
~/bin/python or even /usr/local/bin/python and make sure they come in your
path before the old python and you're set.

-- 
Maurice LeBrun    mj...@ga...