plplot-devel — Technical discussion about PLplot development

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

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

Thanks, Maurice, for the symlink suggestion which I will use as an interim
measure.

It turns out this python2 name was an artifact of a license dispute that
forced the Debian packager to clearly distinguish between the python2
product (whose early version was not GPL compatible) and python-1.5 (which
was compatible).  Fortunately, that license dispute has been resolved for
later python 2 products.  Thus, the Debian python packager intends to
replace both the python2 and python (1.5) package by one updated python
package (python 2.1, IIRC).  At that point the name of the executable will
be python again.  It is possible the time scale for this change will be
short, but we will just have to wait and see.

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 Mon, 22 Oct 2001, Maurice LeBrun wrote:

> (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...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] Java examples work with jdk-1.2.2, but still one problem

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

I purged 1.1.8 from my Debian woody system and downloaded a private copy
of jdk 1.2.2 from Blackdown.

Following Geoffrey's recipe for working from plplot/tmp, I got further, but
ran into problems finding the plplot library. If I set up some symlinks from
files with the wrong name (libplplot.so, etc.,) to the existing files with
the correct name (libplplotd.so, etc.), I overcame this problem (at least to
the point of getting a menu to choose from.  I didn't pursue it further
because I immediately recognized it probably would work if I configured
without my usual --with-double). So I used single-precision next, and indeed
that worked, i.e., I got good results with java plplot/examples/x01, etc.

Geoffrey, have you implemented double precision?  If so, then this problem I
have found may simply be a forgotten LIB_TAG problem so that with double
configured, the libname is incorrectly referred to as libplplot rather than
the correct libplplot.  However, if you have an old single-precision
libplplot kicking around, everything will look rosy. To replicate the
double-precision name trouble I have found (if that is what it is) you have
to start with a clean slate.

I was most impressed with the substantial fraction of the single-precision
examples that have been implemented. Geoffrey, do you have the full PLplot
API accessible from java so the rest of the examples mimicking the x??c
examples would be straightforward to do? I can probably find the time to
fill out the remaining examples if the API is available.

The only other issue I can see is how far back we support java.  It would be
nice for Debian users (who I suspect are some of our keenest users due to
Rafael's packaging efforts) if we could support back to jdk-1.1.8, but that
depends on how difficult it is to drop the current requirement (incompatible
with jdk-1.1.8) that we must have a partial path as part of the class name.
If that is a simple change, Geoffrey, then I strongly encourage you to make
it, but if for some unknown reason it is complicated, then I am willing to
say we just support jdk-1.2.2 and above.

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] Java examples don't work for me

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

Geoffrey, you may have misunderstood me since you talk about eliminating
packages which is a phrase I certainly did not use.  I am actually asking
for something quite simple.

> Then you would run this (from anywhere) via "java x/y/z".
>
> I think you should be able to do things like that with simple java
> code in your jdk 118 without trouble.
>

That was one of my points.  I did such experiments with my hello_world
programme and it empirically appears that you cannot have slashes in the
name of the class file you invoke in java 1.1.8. For that version it appears
you *must*

setenv CLASSPATH x/y; java z

rather than

setenv CLASSPATH .; java x/y/z.

Why can't we set things up so our examples are invoked the first way (which
is also the way I have seen all classic java demo programmes invoked).

That is all I am asking.

Alan

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...

RE: [Plplot-devel] Java examples don't work for me

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

Alan W. Irwin writes:
 > Geoffrey, would you be willing to trim off the plplot/examples and plplot/core
 > from the internal names and see if the above CLASSPATH then works for you?

Alan, I think this is a bit more involved than you realize.  I don't
currently believe there is anything wrong with the code.  The
pathspecs you refer to are just a result of using packages in the Java
language, and there is nothing suspicious in that.  Java has used
packages since the very beginning.

I think what is at issue, is learning how to interract with the Java
run time environment for each version of Java.  Java has a very
stylized approach to software development, which I find very
frustrating to work with, and I did not choose to exactly emulate
typical Java software development systems in the way I set up the Java
plplot stuff.  With judicious use of javac -d, and reading the man
page, I got it to work with JDK 1.3, but the problems with JDK 1.1.x
are probably related to this, rather than to the appearance of
package-delimited name qualifiers in the .java source files.

I will admit to being a serious Java neophyte here, and I think you
are too.  So lets proceed methodically, rather than just trying things
willy nilly.

Typical java projects that I have to look at, do something like this:

dir x
subdir y
file   z.java

CLASSPATH points to x/..
z.java contains "package x.y;"
compilation occurs in x/y, using "javac z.java", resulting in x/y/z.class.

Then you would run this (from anywhere) via "java x/y/z".

I think you should be able to do things like that with simple java
code in your jdk 118 without trouble.

What I'm doing in PLplot, is softlinking all the source files to
plplot/tmp, and then attempting to use the -d flag to put the
compilation products in the expected place.  I think I've shown this
is working okay for JDK 13, but JDK 11x must not be so facile.

Rather than changing the code, I think what we may have to do to
support such systems, is investigate changign the /layout/ of the code
on disk, and futzing with the precise settings of CLASSPATH and what
not. 

We may also have to ultimately figure out how to product .jar files
from our compilation products.  I'm betting that if we produced a .jar
file from what we have now, and then you fixed CLASSPATH to reference
this .jar file, it would work fine even now.  But I can't quickly test
this theory because I don't know how to make well-formed .jar files.

The bottom line is I'm a java newbie, and I think you are too.  So
rather than thrashing over all the ways we could rewrite the code,
eliminating packages and all that, I think we should instead focus on
developing or acquiring the necessary sophistication with programming
the java envirionment, and figure out what changes are needed from
that.

Recruiting a java specialist through SF might be one way to go about
this.  

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

RE: [Plplot-devel] Java examples don't work for me

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

On Mon, 22 Oct 2001, Geoffrey Furnish wrote:

> Well, it sure looks to me like it built correctly, and put things in
> the right places.  Did you check that plplot/tmp/java/plplot/core has
> the PLStream.class file?

It is there.

> Anyway, try JDK 1.3, if you don't mind, and we'll take it from there.

I am willing to do that as a test, but we should also think hard about
compatibility with older jdk versions.  Our Debian users are not going to be
able to use your package (without a special download and possibly conflicts
between that download and the supported jdk-1.1.8 version). I guess I can
live with that because it might be a special case.  Also, I personally don't
have a problem with a conflict because I don't use any other Debian packages
that are related to jdk-1.1.8. But to ensure we don't make things too
impossible for our users, we should look at what other distributions do as
well.  Does anybody here know what jdk version is officially supported by
Redhat 7.1? (or 7.2 which is just out today?) Same question for SuSe and
Mandrake (latest versions only, please). If they all tend to be 1.2.x (or
even 1.1.8), I think we should support that version if at all possible.

Note this might be quite easy to do.  There was no trouble compiling any of
the applications under 1.1.8.  So there may be no fundamental inconsistency
between your work and jdk-1.1.8.  The symptoms I am getting are consistent
with the mental model that everything will work if the java invocation is
done without any path to the file name.  That is you just use "java x01"
rather than "java plplot/examples/x01". If that model is true, then the only
additional thing required to make it work is to change all internal
references to trim off plplot/examples and plplot/core from the names. (I
noticed with the strings command that there were such internal references.)
Then, if my model of what is going on is correct, then

setenv CLASSPATH java/plplot/examples:java/plplot/core

should work regardless of jdk version.

Geoffrey, would you be willing to trim off the plplot/examples and plplot/core
from the internal names and see if the above CLASSPATH then works for you?

Thanks.

Alan

RE: [Plplot-devel] Java examples don't work for me

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

Alan W. Irwin writes:
 > I tried plplot java with both the IBM jdk and Blackdown version.  (Both are
 > version 1.1.8.) (BTW, kaffe is not a complete JDK so it is out of the
 > running.) Both the IBM and Blackdown versions worked with no problems
 > up to and including make jdemos.  After that, however, no example
 > would work.
 > 
 > Here was my environment (for the Blackdown version.  The IBM version
 > was the same except for JAVA_HOME.)

Here is what I get when I run from my dev area.  This is the CVS head
for plplot, configured with --prefix=/home/furnish/j2.  After the
build, here is what I have, and I've run x01 to show that it does work:

plplot/tmp> pwd
/home/furnish/devel/plplot/tmp
plplot/tmp> echo $CLASSPATH
./java
plplot/tmp> echo $LD_LIBRARY_PATH 
.:/home/furnish/j2/lib/
plplot/tmp> ls java/plplot/examples/
x01.class  x01.java@  x02.class  x02.java@  x03.class  x03.java@  x04.class
x04.java@  x05.class  x05.java@  x06.class  x06.java@  x07.class  x07.java@
x08.class  x08.java@  x09.class  x09.java@  x10.class  x10.java@  x11.class
x11.java@  x12.class  x12.java@  x13.class  x13.java@  x14.class  x14.java@
x15.class  x15.java@  x16.class  x16.java@  x17.class  x17.java@  x18.class
x18.java@  x19.class  x19.java@
plplot/tmp> ls java/plplot/core
PLStream.class  PLStream.java@
plplot/tmp> java plplot/examples/x01

Plotting Options:
 < 1> xwin       X-Window (Xlib)
...

I also ran it with CLASSPATH java (instead of ./java), just to be sure
nothing so trivial could be at fault, but it behaves the same
(correctly) for me both ways.

 > pwd
 > /home/software/plplot_cvs/HEAD/plplot/tmp
 > 
 > printenv JAVA_HOME
 > /usr/lib/jdk1.1/
 > 
 > printenv CLASSPATH
 > java
 > 
 > Note I also tried this as an absolute path and it did not work.
 > 
 > printenv LD_LIBRARY_PATH
 > /home/software/plplot_cvs/HEAD/plplot/tmp
 > 
 > ls java/plplot/examples/
 > x01.class*  x04.java@   x08.class*  x11.java@   x15.class*  x18.java@
 > x01.java@   x05.class*  x08.java@   x12.class*  x15.java@   x19.class*
 > x02.class*  x05.java@   x09.class*  x12.java@   x16.class*  x19.java@
 > x02.java@   x06.class*  x09.java@   x13.class*  x16.java@
 > x03.class*  x06.java@   x10.class*  x13.java@   x17.class*
 > x03.java@   x07.class*  x10.java@   x14.class*  x17.java@
 > x04.class*  x07.java@   x11.class*  x14.java@   x18.class*
 > 
 > Here is the error message when I attempted to execute the first example.
 > 
 > java plplot/examples/x01
 > Invalid class name: plplot/examples/x01
 > Usage: java [-options] class
 > .
 > .
 > .

Well, it sure looks to me like it built correctly, and put things in
the right places.  Did you check that plplot/tmp/java/plplot/core has
the PLStream.class file?

 > To test that my jdk was working, I compiled the following incredibly
 > complicated programme:
 > **************
 > class HelloWorld
 > {
 > 
 >    public static void main(String args[])
 >      {
 > 
 > 	System.out.println("Hello World!");
 >      }
 > 
 > }
 > 
 > javac compiled it and java ran it without problems.  I also tried
 > appletview on several rather complicated examples such as molecule viewing,
 > etc.  They all worked.
 > 
 > Thus, I am stumped why plplot java does not work for me when I believe
 > I have followed Geoffrey's cookbook exactly.

Yes, it looks to me also that you have done it right.

 > But wait.... After thinking about that last sentence I tried moving my hello
 > world programme around.  If I execute it as java HelloWorld (i.e., no
 > partial path before HelloWorld and with CLASSPATH set to the *entire path*)
 > it works fine.  But any attempt to have a partial pathname with it, e.g.,
 > setenv CLASSPATH /home; java irwin/HelloWorld produces the same bad symptoms
 > as above. So for my version of java it seems no partial path can be part of
 > the class name when java executes a class.  Armed with that knowledge, I tried

Mmm, interesting.  Sounds like the whole package loading thing must
not work the same in JDK 1.1.x as it does now.

 > setenv CLASSPATH java/plplot/examples
 > java x03
 > Error loading class x03: Wrong name

Mmm.  Well, just for grins you could try java plplot/examples/x03,
since the x03.class file will show that its contained class x03 is in
the "java package" plplot/examples.

I dunno.  It seems like what you've done above should've worked.  I am
no Java expert by any means, and I especially don't know much about
how it has morphed with time and JDK (sun) version numbers.  I know
the 1.1.x -> 1.2.x transition was a Huge deal, at least in the minds
of Sun's marketting team.  The thing called "Java 2" is what was
labeled JDK 1.2.0.  So, you're not even using the Java 2 platform, but
just the Java 1 platform, which is archaic in the Java world.  

 > so clearly this "full CLASSPATH" strategy isn't the whole answer.
 > 
 > Do you have any ideas how to overcome these CLASSPATH problems, Geoffrey?
 > 
 > Does JDK-1.1.8 have a limitation that your JDK does not have?

I don't know specifically, but I do know that JDK 1.1.x are way way
way out of date in the Java world.  I would've been frankly more
worried aobut some part of my JNI coding having been tied to 1.3.x,
but maybe there were even changes in package identification and
loading, between 1.1.x and the 1.3.0 that we're using here:

/home/furnish> java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

I saw there were packages for JDK 1.3 up at blackdown.  I'd suggest,
if you don't mind the labor involved, just trying it out with a
vintage 1.3 jdk, and seeing how that goes.

I don't have specific knowledge of anything that should be pinning us
on a late model JDK, but I probably also don't know enough of the
history and culture of Java to recognize it even if there were,
sorry.  I did look at JNI a few years ago (pre Java 2), and I have the
vague impression that some things are different now, although my
memory isn't clear enough to know for sure.  Anyway, it wouldn't
surprise me if we are tied to Java 2 because of the C coupling, but
this trouble finding/loading packages does surprise me.

Anyway, try JDK 1.3, if you don't mind, and we'll take it from there.

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

[Plplot-devel] A report that native-compiled solaris xwin segfaults for both plplot-5.0.4 and plplot-cvs

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

I have received a yplot report that the xwin driver segfaults under
particular circumstances whether built on top of plplot-5.0.4 or
plplot-latest-cvs.  This is on a solaris box using the native compiler to
build both yplot and plplot.  This user apparently employed the -xCC option
of the native solaris compiler to get around the c++-style commentary
issues in plplot.

I believe there is an excellent chance the problem is some subtle gcc-ism in
the xwin driver (both in 5.0.4 and cvs HEAD) that the native solaris
compiler is misinterpreting.  After all, the yorick (yplot) front end has a
quite simple and clean interface to c code (much less baggage than in the
python case), and this guy (who is quite reliable by the way) apparently
gets good results with the postscript drivers for exactly the same yplot
commands that segfault for the xwin driver.

Below, I have given this guy's words about the yplot code fragments that
bomb for him and work for him. I cannot pursue this further because I have
no access to a solaris box with X on it.  (The compile farm boxes at
sourceforge don't give access to X headers.) But if anybody else is
interested, I think the first step would be to attempt to replicate the
problem using the obvious C equivalent of the yplot commands below using the
native solaris compiler with -xCC option.  If the problem is found, then the
next step would be to see if it disappears if you use the gcc compiler under
solaris.

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
__________________________

**************************
---------- Forwarded message ----------
Date: Sun, 21 Oct 2001 10:38:12 +0530 (IST)
From: V.V.Pipin <vp...@ii...>
To: Alan W. Irwin <ir...@be...>
Subject: Re: [Plplot-general] compiling yplot on the SunOS

....Besides this big success with installation yplot on the Sun mashine I
found that not all of plplot routines work correctly there.
Certainly there is a problem to put plot on xwin drive with combination
(only!, ps-drive and others work well)
plinit;
pladv,0;
plstick,1,1,1,1,4.,0.,2,0.;
plwind,0,1,0,1;

Though there was no problem to put plot on xwin with this
plinit;
pladv,0;
plenv,0,1,0,1, 0, 0;

In the first case I have
Enter device number or keyword: 1
ERROR (plinit) Segmentation violation interrupt (SIGSEGV)
  LINE: 61  FILE: /home/vpip/yorick/share/yorick/1.5/i0/yplot.i
yorick: quitting on error in batch mode.
The ps drive work well in this case, as I noted before.
**************************

[Plplot-devel] Java examples don't work for me

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

I tried plplot java with both the IBM jdk and Blackdown version.  (Both are
version 1.1.8.) (BTW, kaffe is not a complete JDK so it is out of the
running.) Both the IBM and Blackdown versions worked with no problems
up to and including make jdemos.  After that, however, no example
would work.

Here was my environment (for the Blackdown version.  The IBM version
was the same except for JAVA_HOME.)

pwd
/home/software/plplot_cvs/HEAD/plplot/tmp

printenv JAVA_HOME
/usr/lib/jdk1.1/

printenv CLASSPATH
java

Note I also tried this as an absolute path and it did not work.

printenv LD_LIBRARY_PATH
/home/software/plplot_cvs/HEAD/plplot/tmp

ls java/plplot/examples/
x01.class*  x04.java@   x08.class*  x11.java@   x15.class*  x18.java@
x01.java@   x05.class*  x08.java@   x12.class*  x15.java@   x19.class*
x02.class*  x05.java@   x09.class*  x12.java@   x16.class*  x19.java@
x02.java@   x06.class*  x09.java@   x13.class*  x16.java@
x03.class*  x06.java@   x10.class*  x13.java@   x17.class*
x03.java@   x07.class*  x10.java@   x14.class*  x17.java@
x04.class*  x07.java@   x11.class*  x14.java@   x18.class*

Here is the error message when I attempted to execute the first example.

java plplot/examples/x01
Invalid class name: plplot/examples/x01
Usage: java [-options] class
.
.
.

To test that my jdk was working, I compiled the following incredibly
complicated programme:
**************
class HelloWorld
{

   public static void main(String args[])
     {

	System.out.println("Hello World!");
     }

}

javac compiled it and java ran it without problems.  I also tried
appletview on several rather complicated examples such as molecule viewing,
etc.  They all worked.

Thus, I am stumped why plplot java does not work for me when I believe
I have followed Geoffrey's cookbook exactly.

But wait.... After thinking about that last sentence I tried moving my hello
world programme around.  If I execute it as java HelloWorld (i.e., no
partial path before HelloWorld and with CLASSPATH set to the *entire path*)
it works fine.  But any attempt to have a partial pathname with it, e.g.,
setenv CLASSPATH /home; java irwin/HelloWorld produces the same bad symptoms
as above. So for my version of java it seems no partial path can be part of
the class name when java executes a class.  Armed with that knowledge, I tried

setenv CLASSPATH java/plplot/examples
java x03
Error loading class x03: Wrong name

so clearly this "full CLASSPATH" strategy isn't the whole answer.

Do you have any ideas how to overcome these CLASSPATH problems, Geoffrey?

Does JDK-1.1.8 have a limitation that your JDK does not have?

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 RELEASE?

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

On Sat, 20 Oct 2001, Rafael Laboissiere wrote:

> * 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.

No problem.  I am beginning to figure it out.  The dummy packages are for
the situation where you have to satisfy Debian dependencies, but you have
installed Java completely independently.  But it appears there is no need t=
o
do that; there are real Debian packages for the java implementation from
kaffe, IBM, and Blackdown.

I will probably try them in that order since kaffe is a clean-room GPLed
version and thus completely out of the control of Sun, and I feel the IBM
version has a better chance than the Blackdown version of surviving the
idiotic Sun policies for Java.  It's amazing to me that (a) Sun is treating
the Blackdown volunteers in such a shabby manner since, after all,
Blackdown's Linux porting efforts have substantially increased the number o=
f
Java users, and (b) that any Blackdown volunteers are left after that shabb=
y
treatment. I well remember the first Sun Java for Linux announcement that
made no mention of the years of hard effort put into the product by
Blackdown volunteers (and which Sun could grab off without credit to
Blackdown because of the Java license).  Also, from the Blackdown web site,
Sun still apparently does all sorts of control freak stuff about giving
Blackdown developers needed information in a timely manner, and I wouldn't
put up with such nonsense for a minute.

> You may try :
>
>     http://people.debian.org/=F5pal/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).

Thanks for these suggestions.

Alan

[Plplot-devel] "State of our Statistics" Address or Lies, Damned Lies, and Statistics

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

Our statistics area at sourceforge shows there were supposedly 1200
downloads of plplot on October 16th.  I am frankly at a loss to explain this
huge number (10-20 downloads per day is more normal), and there doesn't seem
to be any abnormality in the file download area statistics that is
consistent with 1200 extra downloads of one of the files there.  At one
point I went into paranoid mode and checked out other sourceforge projects
to see whether SF had been subject to a denial-of-service attack.  But no
other project I have looked at has such a huge one-day spike in their
download numbers.

Anyhow, if you see these pumped up download numbers for plplot in October, I
suspect they are not real.  We typically get about 70 downloads/month for
yplot and 600 downloads per month (ignoring October) for plplot.  An
interesting comparison is that gnuplot also gets about 600 downloads per
month.  Of course it is two years since they have made an official release.
Their cvs is reasonably active so I wouldn't be surprised to see another
gnuplot release soon, and a corresponding surge in their monthly download
rate.

Of course I am hoping for a surge in our download rates when 5.1.0 comes
out.  Ain't competition fun?  ;-)

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 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 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?

[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...>]

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 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 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

[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 problems

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

On Friday 12 October 2001 17:08, Geoffrey Furnish wrote:
| Jo=E3o Cardoso writes:
=2E..

| Here's what you haven't yet grasped.
|
| When running a /Java/ program, the PLplot binding is accomplished by
| asking the JVM to "load" libplplot.  Evidently it does this by dlopen,
| but not using RTLD_GLOBAL.  Then, when libplplot dlopen's
| driver/xyz.drv, the driver doesn't have access to libplpot's symbols
| because libplplot itself wasn't loaded with RTLD_GLOBAL.

Yes, I wasn't aware of that.

| To live with it, we need to either
|
| 1) link drivers against libplplot, or
| 2) break the symbol resolution requirement.
|
| I'll /probably/ check in 1) soon.

OK.

|  I will /possibly/ do 2) sooner than
| sometime in the indefinite future.  How's that for a vague statement
| of my intentions?  :-).

Fine, I got it. :)

Joao

Re: [Plplot-devel] New problems

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

Jo=E3o Cardoso writes:
 >=20
 > The mailing list "reply" is again broken. Just leave it that way, we=
=20
 > will get used to it this way.

The option is gone, I literally can't put it back.  Grrrr.

If anybody comes up with an elisp "list-reply" function that works
with VM, please let me know...  :-).

 > | Thus, the tk problem is another problem. Or maybe not?
 >=20
 > By the way, Geoffrey, you are not working in linux, are you?

Yes, I am on Linux.  I haven't used anything but Linux since joining
Lightspeed.  (Although today I'm gonna have to actually log onto a
Slowaris machine to run some EDA tool that's only provided by the
vendor on Slowaris, but that's just a one time thing.  I live on
Linux).=20

 > The dlopen() man page says:
 >=20
 >        External  references in the library [jc: the dlopened program=
]=20
 >        are resolved using the libraries in that library's dependency=
 =20
 >        list [jc: I (we?) don't want that] and any  other
 >        libraries previously opened with the RTLD_GLOBAL flag
 >=20
 > [jc: so I guess that in linux the loader opens the libraries the=20
 > executable was linked against, with RTLD_GLOBAL, and=20
 > as such their symbols are available to the dlopened program].
 >  =20
 >        If the executable was linked with the flag "-rdynamic",  then=

 >        the  global symbols in the executable will also be used to
 >        resolve references in a dynamically loaded library.

Right.  I believe you understand correctly, everything that relates to
understanding how our C programs, like the PLplot C demos, our own
programs, etc, all work when linked against libplplot, and then using
PLplot's dynamic drivers.=20

Here's what you haven't yet grasped.

When running a /Java/ program, the PLplot binding is accomplished by
asking the JVM to "load" libplplot.  Evidently it does this by dlopen,
but not using RTLD_GLOBAL.  Then, when libplplot dlopen's
driver/xyz.drv, the driver doesn't have access to libplpot's symbols
because libplplot itself wasn't loaded with RTLD_GLOBAL. =20

I'm not defending the JVM behavior, I'm just reporting it.=20

To live with it, we need to either

1) link drivers against libplplot, or
2) break the symbol resolution requirement.

I'll /probably/ check in 1) soon.  I will /possibly/ do 2) sooner than
sometime in the indefinite future.  How's that for a vague statement
of my intentions?  :-).

--=20
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] New problems

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

Jo=E3o Cardoso writes:
 > OK, if you can't, you can't. But I can. I configure/installed in=20
 > /usr/local/test, then, as another user, compiled x01x.c:
 >=20
 > > gcc x01c.c -o x01c -L/usr/local/test/lib -I/usr/local/test/include=
=20
 > -lplplot -Wl,-rpath -Wl,/usr/local/test/lib
 >=20
 > then,
 >=20
 > > ./x01c -dev ntk=20
 > Plplot library version: 5.0.4
 >=20
 > Cannot open library file: drivers/drivers.db
 > lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
 > Device not loaded!
 > tag=3Dntk, drvidx=3D12
 > Trying to load ntk.drv on ./drivers/ntk.drv
 > Trying to load at /usr/local/test/lib/drivers/ntk.drv
 >=20
 > and it work. Also for tk (that is static, not dyndrv).

Right, that's because the way /we/ do dlopen in libplplot, allows the
resolution of symbols in the loaded module, against the symbols in
libplplot.  So, for an app linked to libplplot, the use of a dynamic
driver is easy.

But that's not the only usage model...

 > My understanding of dlopen() is that the libraries that the opening=20=

 > program was linked with are available to the dlopened code, so there=
=20
 > is no need to link it again with the same libraries. This works for=20=

 > other programs also:
 >=20
 > > ldd /usr/X11R6/lib/modules/xie.so=20
 >         libm.so.6 =3D> /lib/libm.so.6 (0x4008b000)
 >         libc.so.6 =3D> /lib/libc.so.6 (0x400a8000)
 >         /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)

Your statement is true some of the time.  It depends on the flags used
in all the dlopen calls.  The way /we/ do it, makes the above
statement true.  The way the JVM does it, as one notable
counterexample, does not allow this.

 > | BTW, just in case there is any skepticism about this, here is how
 > | you can see for sure that every driver depends on libplplot:
 > |
 > | plplot/tmp> nm drivers/pbm.drv | grep " U "
 > |          U ___brk_addr@@GLIBC_2.0
 > |          U __curbrk@@GLIBC_2.0
 > |          U __environ@@GLIBC_2.0
 > |          U atexit@@GLIBC_2.0
 > |          U fclose@@GLIBC_2.1
 > |          U fprintf@@GLIBC_2.0
 > |          U fwrite@@GLIBC_2.0
 > |          U pdf_finit
 > |          U plFamInit
 > |          U plOpenFile
 > |          U plP_setphy
 > |          U plP_setpxl
 >=20
 > Those are resolved at *load* time, and as the "calling" program has=20=

 > "loaded" the libraries (libplplot, etc), everything is OK.
 > This is how I understand it, and it works for me.

Correct.  This is the way /we/ do it.  When /we/ load the driver into
libplplot.so, we allow it to do the run-time symbol resolution agsint
symbols already in our address space.

But not all users of dlopen are so permissive.  In my opinion, we need
to do one of two things:

1) bind the symbols so that non-permisive dlopen contexts will still
support use of PLplot with dynamic drivers, or

2) break the symbol resolution requirement.

Last night I was thinking more about this, after my mail yesterday,
and I am starting to feel some resolve for just doing 2) now.  I have
done the 1) thing in my makefiles (cf stuff), and am prepared to
commit that now, just to relieve the immediate pressure.  But I forsee
this thorn sticking us in the rump a few more times before we die of
old age, so I am starting to think that introducing a structure
dereferencing thing to break this symbol resolution requirement, may
be the best alternative, even if I didn't really want to be driven
into this so early in the game.

Thinking, thinking, thinking...

 > The plrender problem, is also not completely reprodutible for me:
 >=20
 > > ./x01c -dev plmeta -o po.plm
 > Plplot library version: 5.0.4
 >=20
 > Cannot open library file: drivers/drivers.db
 > lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
 > Device not loaded!
 > tag=3Dplm, drvidx=3D0
 > Trying to load plmeta.drv on ./drivers/plmeta.drv
 > Trying to load at /usr/local/test/lib/drivers/plmeta.drv
 > Opened po.plm
 >=20
 > > /usr/local/test/bin/plrender po.plm -dev xwin
 >=20
 > Cannot open library file: drivers/drivers.db
 > lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
 >=20
 > That's OK. Also for ntk and gnome, but there seems to be a problem,=20=

 > they quickly render the page and quit after that.

Umm, haven't noticed this.  Hmm.  I just ran x07c, directed to a
plmeta file, then ran my installed $prefix/bin/plrender on the
resulting multi-page plmeta file, and it renders fine with xwin,
pausing between each page as usual, etc.  But when I try to render
with the tk driver, it fails, even though if I run x-7c -dev tk, it
works fine.  So there is some problem with the Tk driver when it is
installed, or with plrender, or something.  Not sure which.

 > There is really a problem with the tk driver, as you said:
 >=20
 > > /usr/local/test/bin/plrender po.plm -dev tk
 >=20
 > Cannot open library file: drivers/drivers.db
 > lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
 > TCL command "/usr/local/plplot/lib/drivers/drivers.db" failed:
 >          invalid command name=20
 > "/usr/local/plplot/lib/drivers/drivers.db"
 > Program aborted
 >=20
 > But, given that the others run OK, I am inclined to another problem.=

 > tk is static, dont work,
 > xwin is static, works,
 > ntk, gnome are dynamic, work.
 > ps, psc, etc are dynamic also work OK.
 >=20
 > Thus, the tk problem is another problem. Or maybe not?

Yes, I believe the problem with the Tk driver is likely unrelated to
the issue with the semantics of linking the dynamic drivers.  BTW,
I've fixed the driver linking thing in my local copy, but the Tk
driver from plrender, is still nonfunctional.  So I believe this is a
separate problem, which I think I have not induced through my own
blunders in my own working copy.

--=20
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] New problems

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

The mailing list "reply" is again broken. Just leave it that way, we=20
will get used to it this way.

=2E..

| OK, if you can't, you can't. But I can. I configure/installed in
|
| /usr/local/test, then, as another user, compiled x01x.c:

I forgot to say, in other then the plplot tmp dir=20

| > gcc x01c.c -o x01c -L/usr/local/test/lib
| > -I/usr/local/test/include
=2E..

| But, given that the others run OK, I am inclined to another
| problem. tk is static, dont work,
| xwin is static, works,
| ntk, gnome are dynamic, work.
| ps, psc, etc are dynamic also work OK.

As a matter of fact the pstex driver is not working after install,=20
but I already was expecting that, as you can see in the relevant=20
comments in dyndrv.in.

| Thus, the tk problem is another problem. Or maybe not?

By the way, Geoffrey, you are not working in linux, are you?

The dlopen() man page says:

       External  references in the library [jc: the dlopened program]=20
       are resolved using the libraries in that library's dependency =20
       list [jc: I (we?) don't want that] and any  other
       libraries previously opened with the RTLD_GLOBAL flag

[jc: so I guess that in linux the loader opens the libraries the=20
executable was linked against, with RTLD_GLOBAL, and=20
as such their symbols are available to the dlopened program].
 =20
       If the executable was linked with the flag "-rdynamic",  then
       the  global symbols in the executable will also be used to
       resolve references in a dynamically loaded library.


Joao

Re: [Plplot-devel] New problems

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

On Thursday 11 October 2001 21:34, Geoffrey Furnish wrote:
| Geoffrey Furnish writes:
|  > I'm having some problems with the source after a recent update.
|  >
|  > 1) The dynamic drivers don't work inside Java anymore.  I traced
|  > this down to a recent change in drivers.in which removed
|  > libplplot from the driver linking step.  The reason this was
|  > there was explained in dyndrv.in, commit for version 1.3.=20
|  > Basically the issue is that there are multiple ways dlopen can
|  > be used (this panoply of RTLD_* flags), and the way we do it in
|  > libplplot when opening the drivers is more lenient than how the
|  > JVM does it when loading libplplot.  So, the drivers need to be
|  > linked against libplplot.  Maybe they don't have to be linked
|  > against all the other libs, if libplplot is now free of them,
|  > but the drivers still make some calls into the core of
|  > libplplot, so they have to be linked against at least that.=20
|  > I'll take care of this (again).

OK, if you can't, you can't. But I can. I configure/installed in=20
/usr/local/test, then, as another user, compiled x01x.c:

> gcc x01c.c -o x01c -L/usr/local/test/lib -I/usr/local/test/include=20
-lplplot -Wl,-rpath -Wl,/usr/local/test/lib

then,

> ./x01c -dev ntk=20
Plplot library version: 5.0.4

Cannot open library file: drivers/drivers.db
lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
Device not loaded!
tag=3Dntk, drvidx=3D12
Trying to load ntk.drv on ./drivers/ntk.drv
Trying to load at /usr/local/test/lib/drivers/ntk.drv

and it work. Also for tk (that is static, not dyndrv).

My understanding of dlopen() is that the libraries that the opening=20
program was linked with are available to the dlopened code, so there=20
is no need to link it again with the same libraries. This works for=20
other programs also:

> ldd /usr/X11R6/lib/modules/xie.so=20
        libm.so.6 =3D> /lib/libm.so.6 (0x4008b000)
        libc.so.6 =3D> /lib/libc.so.6 (0x400a8000)
        /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)


| BTW, just in case there is any skepticism about this, here is how
| you can see for sure that every driver depends on libplplot:
|
| plplot/tmp> nm drivers/pbm.drv | grep " U "
|          U ___brk_addr@@GLIBC_2.0
|          U __curbrk@@GLIBC_2.0
|          U __environ@@GLIBC_2.0
|          U atexit@@GLIBC_2.0
|          U fclose@@GLIBC_2.1
|          U fprintf@@GLIBC_2.0
|          U fwrite@@GLIBC_2.0
|          U pdf_finit
|          U plFamInit
|          U plOpenFile
|          U plP_setphy
|          U plP_setpxl

Those are resolved at *load* time, and as the "calling" program has=20
"loaded" the libraries (libplplot, etc), everything is OK.
This is how I understand it, and it works for me.

The plrender problem, is also not completely reprodutible for me:

> ./x01c -dev plmeta -o po.plm
Plplot library version: 5.0.4

Cannot open library file: drivers/drivers.db
lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
Device not loaded!
tag=3Dplm, drvidx=3D0
Trying to load plmeta.drv on ./drivers/plmeta.drv
Trying to load at /usr/local/test/lib/drivers/plmeta.drv
Opened po.plm

> /usr/local/test/bin/plrender po.plm -dev xwin

Cannot open library file: drivers/drivers.db
lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"

That's OK. Also for ntk and gnome, but there seems to be a problem,=20
they quickly render the page and quit after that.

There is really a problem with the tk driver, as you said:

> /usr/local/test/bin/plrender po.plm -dev tk

Cannot open library file: drivers/drivers.db
lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
TCL command "/usr/local/plplot/lib/drivers/drivers.db" failed:
         invalid command name=20
"/usr/local/plplot/lib/drivers/drivers.db"
Program aborted

But, given that the others run OK, I am inclined to another problem.
tk is static, dont work,
xwin is static, works,
ntk, gnome are dynamic, work.
ps, psc, etc are dynamic also work OK.

Thus, the tk problem is another problem. Or maybe not?

Joao

|
| That's just one example, but there is some set of external PLplot
| API symbols showing up in every one I've checked.  So libplplot.so
| really can't be remvoed from the list of dependencies for drivers.
|
| BTW, it would be /possible/ to break this dependency, if we
| introduced one of these cute structure dereferencing tricks like
| they do in the Java Native Interface (and I think someone was
| saying the TEA stubs thing is similar, though I haven't
| investigated that myself yet).
|
| Anyway, my point is just that there does exist a known technique
| for defeating this linker-visible symbol coupling, if it is
| sufficiently disturbing to justify the effort.  Right now, I'm not
| sufficiently disturbed by the coupling to do this work, I'm just
| gonna augment the driver production rules so they are fully linked.
|  But if in the future anyone /really really really/ wants this
| broken, then we should do it the right way, with one of these
| structure pointer tricks.

RE: [Plplot-devel] New problems

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

Geoffrey Furnish writes:
 > I'm having some problems with the source after a recent update.  
 > 
 > 1) The dynamic drivers don't work inside Java anymore.  I traced this
 > down to a recent change in drivers.in which removed libplplot from the
 > driver linking step.  The reason this was there was explained in
 > dyndrv.in, commit for version 1.3.  Basically the issue is that there
 > are multiple ways dlopen can be used (this panoply of RTLD_* flags),
 > and the way we do it in libplplot when opening the drivers is more
 > lenient than how the JVM does it when loading libplplot.  So, the
 > drivers need to be linked against libplplot.  Maybe they don't have to
 > be linked against all the other libs, if libplplot is now free of
 > them, but the drivers still make some calls into the core of
 > libplplot, so they have to be linked against at least that.  I'll take
 > care of this (again).

BTW, just in case there is any skepticism about this, here is how you
can see for sure that every driver depends on libplplot:

plplot/tmp> nm drivers/pbm.drv | grep " U "
         U ___brk_addr@@GLIBC_2.0
         U __curbrk@@GLIBC_2.0
         U __environ@@GLIBC_2.0
         U atexit@@GLIBC_2.0
         U fclose@@GLIBC_2.1
         U fprintf@@GLIBC_2.0
         U fwrite@@GLIBC_2.0
         U pdf_finit
         U plFamInit
         U plOpenFile
         U plP_setphy
         U plP_setpxl

That's just one example, but there is some set of external PLplot API
symbols showing up in every one I've checked.  So libplplot.so really
can't be remvoed from the list of dependencies for drivers.

BTW, it would be /possible/ to break this dependency, if we introduced
one of these cute structure dereferencing tricks like they do in the
Java Native Interface (and I think someone was saying the TEA stubs
thing is similar, though I haven't investigated that myself yet).

Anyway, my point is just that there does exist a known technique for
defeating this linker-visible symbol coupling, if it is sufficiently
disturbing to justify the effort.  Right now, I'm not sufficiently
disturbed by the coupling to do this work, I'm just gonna augment the
driver production rules so they are fully linked.  But if in the
future anyone /really really really/ wants this broken, then we should
do it the right way, with one of these structure pointer tricks.

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

[Plplot-devel] New problems

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

I'm having some problems with the source after a recent update.  

1) The dynamic drivers don't work inside Java anymore.  I traced this
down to a recent change in drivers.in which removed libplplot from the
driver linking step.  The reason this was there was explained in
dyndrv.in, commit for version 1.3.  Basically the issue is that there
are multiple ways dlopen can be used (this panoply of RTLD_* flags),
and the way we do it in libplplot when opening the drivers is more
lenient than how the JVM does it when loading libplplot.  So, the
drivers need to be linked against libplplot.  Maybe they don't have to
be linked against all the other libs, if libplplot is now free of
them, but the drivers still make some calls into the core of
libplplot, so they have to be linked against at least that.  I'll take
care of this (again).

2) The Tk driver doesn't work other than in the tmp directory
anymore.  I can't for example, get the /installed/ plrender to use the
Tk driver anymore.  For example:

plplot/tmp> x01c -dev plmeta -o x1.plm
Plplot library version: 5.0.4
Opened x1.plm
plplot/tmp> ~/j2/bin/plrender x1.plm -dev tk
TCL command "
         invalid command name "
Program aborted

Here I ran x01c in plplot/tmp, produced a .plm file, but then ran the
installed plrender from $prefix/bin, and it won't run the tk driver.
But I can run the tk driver from x01c directly (if LD_LIBRARY_PATH
includes both . and $prefix/lib).

But the local plrender won't correctly invoke the tk driver even then,
even though x01c will.

Does anyone else see this with a current checked out tree?  I'm
guessing this comes from Joao's recent changes to cf stuff, but I'm
not sure.  I know this stuff worked /before/ I updated...  But I have
some other uncommitted changes right now, so I'm wondering if the tk
driver works in plrender for other developers at this point in time.

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