plplot-devel — Technical discussion about PLplot development

[Plplot-devel] plplot versus old JDK's

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

Turns out I have JDK 1.1.7 on my home machine (way old, RH60).  I have
been able to build plplot with java support, and run the demos.  I had
to make one tiddly change in sysloc.in to find the jni_md.h file,
which I will commit.  Beyond that, the only difficulty was that I had
to change from:
   java plplo/examples/x01
to
   java plplot.examples.x01

which I guessed my way into, based on the syntax of the Java language
package statement.  I dunno if this syntax (. versus /) is taken by
the newer JDK's.  Maybe we'll be lucky and this one way of doing
things will work with both old and new JDK's.  

Anyway, I see no problem with blackdown JDK 117.  

FYI.

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

Re: [Plplot-devel] cvs activity

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

Joao Cardoso writes:
 > On Friday 26 October 2001 18:59, Geoffrey Furnish wrote:
 > | Just to let you all know, I've done what I can do for a while.  I
 > | probably won't be able to respond to anything for 10 days or so.
 > |
 > | I've committed the minor mod to dyndrv.in which links all drivers
 > | against libplplot.so, needed to allow dynamic drivers to be used in
 > | the java binding. 
 > 
 > Geoffrey, it looks that you forgot to rebuild the drivers at  instalation 
 > time and user INSTALL_RPATH?

Mmm, probably true.  Thanks for noticing.  Can you enter a task
manager ticket on this so we don't forget it?

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

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

Can't you use plgpage or plgdidev (these routines along with plgchr are
badly documented so that is why I am guessing about the coordinates) to get
the plotting box size in the same coordinates as plgchr? If so, then the
ratio of results returned for character size and plotting box size can be
used to convert character size to world coordinates.  Once you have
character size in terms of world coordinates you have complete
driver-independent control of where the characters in your legend are
placed.

Alan

email: ir...@be...
phone: 250-727-2902=09FAX: 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, 26 Oct 2001, Joao Cardoso wrote:

> On Friday 26 October 2001 00:49, Alan W. Irwin wrote:
> | On Thu, 25 Oct 2001, Joao Cardoso wrote:
> | > 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:
> | >
> | > ...
> | >
> | > | FURTHER TESTS....
> | > |
> | > | I also ran the script for the png driver this morning, and there ar=
e
> | > | some problems (for real this time ....;-)) with the octave stuff in
> | > | that case. 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.
> |
> | Note my comment was for the png driver only.
>
> I have checked it, and the tk and ps drivers are OK (possibly others too)=
=2E
> The xwin and png drivers have the problem. Try the "p1" octave demo, and =
you
> will see it.
>
> As you say bellow, the problem is getting the correct character size. Oct=
ave
> just don't know what driver it is working on, it just looks at the value
> returned from plgchar():
>
> octave:1> fig(1,"xwin");
> octave:2> [a b]=3Dplgchr
> a =3D 2.0000
> b =3D 2.0000
> octave:3> fig(2,"tk");
> octave:4> [a b]=3Dplgchr
> a =3D 4.4449
> b =3D 4.4449
> octave:5> fig(3,"ps","po.ps");
> octave:6> [a b]=3Dplgchr
> a =3D 4.4436
> b =3D 4.4436
> octave:7> fig(4,"png","po.png");
> octave:8> [a b]=3Dplgchr
> a =3D 1.9950
> b =3D 1.9950
> octave:9>
>
> So, you see, the returned value is different for each driver. Octave has =
no
> other way to know the character size. There is no other API entry to know
> this, I think.
>
> What does others think? To summarize: the problem is to know the size of =
the
> bounding box of a plplot string, knowing the string length, to enclose it=
 in
> a box. This has to be done using the API calls.
>
> Joao
>
> PS-I will leave to a short holiday now, don't expect answers to the
> (eventual) thread.
>
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] cvs activity

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

On Friday 26 October 2001 18:59, Geoffrey Furnish wrote:
| Just to let you all know, I've done what I can do for a while.  I
| probably won't be able to respond to anything for 10 days or so.
|
| I've committed the minor mod to dyndrv.in which links all drivers
| against libplplot.so, needed to allow dynamic drivers to be used in
| the java binding.=20

Geoffrey, it looks that you forgot to rebuild the drivers at  instalation=
=20
time and user INSTALL_RPATH?

Joao

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

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

On Friday 26 October 2001 00:49, Alan W. Irwin wrote:
| On Thu, 25 Oct 2001, Joao Cardoso wrote:
| > 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:
| >
| > ...
| >
| > | FURTHER TESTS....
| > |
| > | I also ran the script for the png driver this morning, and there ar=
e
| > | some problems (for real this time ....;-)) with the octave stuff in
| > | that case. 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.
|
| Note my comment was for the png driver only.=20

I have checked it, and the tk and ps drivers are OK (possibly others too)=
=2E
The xwin and png drivers have the problem. Try the "p1" octave demo, and =
you=20
will see it.

As you say bellow, the problem is getting the correct character size. Oct=
ave=20
just don't know what driver it is working on, it just looks at the value=20
returned from plgchar():

octave:1> fig(1,"xwin");
octave:2> [a b]=3Dplgchr=20
a =3D 2.0000
b =3D 2.0000
octave:3> fig(2,"tk");
octave:4> [a b]=3Dplgchr=20
a =3D 4.4449
b =3D 4.4449
octave:5> fig(3,"ps","po.ps");
octave:6> [a b]=3Dplgchr=20
a =3D 4.4436
b =3D 4.4436
octave:7> fig(4,"png","po.png");
octave:8> [a b]=3Dplgchr=20
a =3D 1.9950
b =3D 1.9950
octave:9>=20

So, you see, the returned value is different for each driver. Octave has =
no=20
other way to know the character size. There is no other API entry to know=
=20
this, I think.

What does others think? To summarize: the problem is to know the size of =
the=20
bounding box of a plplot string, knowing the string length, to enclose it=
 in=20
a box. This has to be done using the API calls.

Joao

PS-I will leave to a short holiday now, don't expect answers to the=20
(eventual) thread.

[Plplot-devel] quick bug fix for postscript driver?

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

BTW, for those who have not had a look, the patch Joao pointed out is just a
one-line change.  I am not a driver expert so I am hesitant to apply it.
But I feel it is important for the overall health of the plplot project and
our sanity to give small changes like this high priority because then our
ToDo lists don't get bogged down with zillions of petty details. Thus, would
some driver expert here take a quick look at this and either apply it or not
so we can close the bug?

Thanks.

Alan

Here is the full bug report from some anonymous plplot user:

It seems that the pladv() preserves the pen width.
However, the ps driver reset pen width to default
value.

The following patch is necessary?

diff -u -r plplot-5.0.4/drivers/ps.c
plplot-5.0.4.modified/drivers/ps.c
--- plplot-5.0.4/drivers/ps.c Wed Jun 6 05:01:39    2001
+++ plplot-5.0.4.modified/drivers/ps.c Mon Jul 2 14:52:21 2001
@@ -398,6 +398,7 @@
/* This ensures the color is set correctly at the
beginning of each page */

plD_state_ps(pls, PLSTATE_COLOR0);
+ plD_state_ps(pls, PLSTATE_WIDTH);
}

Re: [Plplot-devel] cvs activity

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

My java tests were with the static drivers so I guess I avoided the dyn
driver problem that you found with java.

I will look at the x08 examples in C and java and try to get them
to give identical results.  Same for x11.

Thanks for implementing the mesh API.

I will try to have at least one more java demo ready for you (except for
any required java API extensions) by the time you come back.

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, 26 Oct 2001, Geoffrey Furnish wrote:

> Just to let you all know, I've done what I can do for a while.  I
> probably won't be able to respond to anything for 10 days or so.
>
> I've committed the minor mod to dyndrv.in which links all drivers
> against libplplot.so, needed to allow dynamic drivers to be used in
> the java binding.  I was surprised Alan was able to work with the java
> binding without that patch.  Alan, did you use both
> --enable-dynamic-drivers, and --enable-java?  If so, maybe this more
> restrictive dlopen semantics was a JDK 1.3 innovation.  Anyway, that
> fix is in, shouldn't disrupt anything else, except that it brings back
> library/driver coupling we were hoping to avoid.
>
> Fixing that will require some work with one of these structs of
> function pointers ideas we've discussed before.  I entered a task on
> that in the java binding dev list.  I suppose it could be a dyndriver
> project tasklist, but since I found it in the context of java, I just
> put it there.
>
> It would be good to see task lists for other thrust areas, just so we
> can form a clearer picture of where we really stand.
>
> Anyway, I also knocked out a little more JNI work, real quick.
>
> And I've concluded that it looks to me like x11.java doesn't actually
> set up the data the same way as x11c.c.  I bet the same is happening
> in x08.java/x08c.c, which probably explains the slight discrepancy in
> the shade plots that I mumbled about before.  After a quick peek at
> the codes, I'm guessing it comes down to how x[] is initialized.
> Alan, if you look at this, you'll see I used "2." in the java demos,
> where the C demos used just "2".  :-).  I did the "2." thing in Java,
> as I recall, to supress a cast.  I confess to finding such matters
> confusing in the C case.  What does the C (double) cast do?  Is that
> an integer division the result of which is then cast to double?  In
> which case I wouldn't expect hte abscissa to be smooth. Or does it
> somehow make the seemingly integer division actually be performed in
> double?  Sheesh.  I should know C better, but anyway, I bet the
> problem has to do with this.  Think you can figure it out?  Or if you
> want to leave it to me, that's fine, but I don't promise to fix it
> soon :-).  I'd rather work on the JNI binding, than figure out these
> bizarrdoms of C/Java numerical experssion semantics.  (yeah, I know
> this sounds lame, sorry).
>
> I guess all I'm  saying is, I don't see anything wrong with the code
> per se, so it doesn't seem to me like something that necessarily /has/
> to be fixed before a release.  But someday, we should probably make
> sure the C/java demos actually display /exactly/ the same plots.  At
> least x08 and x11 are probably affected by the same bug, which is
> probably my fault.
>
> --
> Geoffrey Furnish         fu...@ga...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] cvs activity

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

Just to let you all know, I've done what I can do for a while.  I
probably won't be able to respond to anything for 10 days or so.

I've committed the minor mod to dyndrv.in which links all drivers
against libplplot.so, needed to allow dynamic drivers to be used in
the java binding.  I was surprised Alan was able to work with the java
binding without that patch.  Alan, did you use both
--enable-dynamic-drivers, and --enable-java?  If so, maybe this more
restrictive dlopen semantics was a JDK 1.3 innovation.  Anyway, that
fix is in, shouldn't disrupt anything else, except that it brings back
library/driver coupling we were hoping to avoid.  

Fixing that will require some work with one of these structs of
function pointers ideas we've discussed before.  I entered a task on
that in the java binding dev list.  I suppose it could be a dyndriver
project tasklist, but since I found it in the context of java, I just
put it there.

It would be good to see task lists for other thrust areas, just so we
can form a clearer picture of where we really stand.

Anyway, I also knocked out a little more JNI work, real quick.  

And I've concluded that it looks to me like x11.java doesn't actually
set up the data the same way as x11c.c.  I bet the same is happening
in x08.java/x08c.c, which probably explains the slight discrepancy in
the shade plots that I mumbled about before.  After a quick peek at
the codes, I'm guessing it comes down to how x[] is initialized.
Alan, if you look at this, you'll see I used "2." in the java demos,
where the C demos used just "2".  :-).  I did the "2." thing in Java,
as I recall, to supress a cast.  I confess to finding such matters
confusing in the C case.  What does the C (double) cast do?  Is that
an integer division the result of which is then cast to double?  In
which case I wouldn't expect hte abscissa to be smooth. Or does it
somehow make the seemingly integer division actually be performed in
double?  Sheesh.  I should know C better, but anyway, I bet the
problem has to do with this.  Think you can figure it out?  Or if you
want to leave it to me, that's fine, but I don't promise to fix it
soon :-).  I'd rather work on the JNI binding, than figure out these
bizarrdoms of C/Java numerical experssion semantics.  (yeah, I know
this sounds lame, sorry).

I guess all I'm  saying is, I don't see anything wrong with the code
per se, so it doesn't seem to me like something that necessarily /has/
to be fixed before a release.  But someday, we should probably make
sure the C/java demos actually display /exactly/ the same plots.  At
least x08 and x11 are probably affected by the same bug, which is
probably my fault.

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

[Plplot-devel] RE: [Plplot-cvs] CVS update notice (plplot/examples/java)

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

Alan W. Irwin writes:
 > Update of /cvsroot/plplot/plplot/examples/java
 > In directory usw-pr-cvs1:/tmp/cvs-serv20021
 > 
 > Modified Files:
 > 	x11.java 
 > Log Message:
 > Implemented x11 example with plot3d temporarily replacing mesh until that
 > API is completed.

Hi Alan,

I just took a look at this one.  The java demo looked so much like
what I remembered, that I had to look at the output of x11c to
remember what was different.  Okay, so yes, mesh needs to be
implemented.

However, in comparing x11.java (currently using plot3d instead of
mesh) versus x11c.c (using mesh), there was an interesting
difference.  Look at the right edge, near x=1.  You'll see that
x11c.c, using mesh, goes up to the z=1 value, but in the x11.java,
using plot3d, that function doesn't go up that high.  In fact,
studying each of the plots, it looks like that last data point in x is
missing in all the plots.

I haven't compared the source, but am presuming the data was
calculated right.  Do you think this is a problem with plot3d dropping
a data point, or is it something with how the data is set up in the
java demo?

I'll work on the mesh api.

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

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

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

On Thu, 25 Oct 2001, Joao Cardoso wrote:

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

Note my comment was for the png driver only.  Not the postscript one. Do yo=
u
really have a clean checkout of latest CVS with no local changes? If you
cannot confirm the octave legend problem for png, then that is really
strange because it is quite obvious on my system for a clean checkout (i.e.=
,
"mv plplot plplot_old; cvs checkout plplot").  I cannot remember very well,
but I think this png driver legend problem for all the octave examples has
been there from the first day I tested it long ago (probably even before I
did the aspect ratio stuff), but to be sure we would have to review my old
e-mail to you.

> But the other day I start octave with the xwin driver, and I noticed the
> problems.

> ....Hummm, can't this be related with your changes related with the aspec=
t-ratio
> problem?

I doubt it.  My changes prior to 5.0.4 should have no effect unless you are
reorienting (-ori option with -freeaspect) or changing the overall aspect
ratio (-a option). The -portrait option is also available for the postscrip=
t
driver, but I assume you are not using that.  All these character aspect
ratio changes are central to plplot and have nothing to do with individual
drivers (except the simple -portrait option which is available as a
convenience for the ps driver, but which just combines other options that
are implemented centrally and not in the individual drivers.)

I noticed that the legend problem was much less severe for ps as well. Your
legend placements should look identical for all drivers, and they don't.
From=20the overall plotting perspective the only real difference between
drivers is their pixel units, but I don't think you should be using those
unless you scale them to the pixel size of the plotting area, for example.
If you did that you would know a character height is some fraction of the
plotting area, and your results would be identical regardless of the number
of pixels assigned by each driver to the plotting area and to the
character area.

>
> |  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
> dimension, knowing the string size and the number of lines, and I use the
> returned height from plgchr(). As plplot fonts are proportional, the widt=
h of
> the box will be wrong some times, but the height should be OK. If plgchr(=
)
> returns a wrong height, everything gets messed.
> Could your changes related with fonts and aspect-ratio have some impact o=
n
> this?

Answered above.  I have never tried to make multi-line legends like in your
examples, but certainly for single-line legends I believe there is a way
to do it in a pixel-independent way, and I have outlined above a way to
do that for multi-lined legends as well.

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

Yes, use plplot-test.sh. If you cannot replicate this default colour proble=
m
with a clean checkout, then we will have to look deeper at the differences
between our two machines.

>
> | All png results differed from previous which is expected because I am n=
ow
> ...
>
> | 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?
>
> Thats OK to release often, but call it 5.1.0 is too much, as there are st=
ill
> many loose things to fix.

I don't intend to bring it out until you and everybody else here feels it i=
s
ready for release that is as stable as 5.0.4. However, I start thinking
about stable releases when I can do all my research plots from CVS HEAD
without serious bugs showing up, and that is certainly the case now.  We do
have the segfault problem to clear up and the map problem for the test
examples, but those are the only two serious bugs I know about that have
been introduced since 5.0.4.

For now, let's concentrate on the next step between us which is to find out
why we are getting different octave results (png legend size, default
colours, etc.) If you cannot see the problems I have found with running
plplot-test.sh with png driver for a fresh checkout of plplot, then it migh=
t
have something to do with our different octave versions.

Alan

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 problems

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

Joao Cardoso writes:
 > | I'm not defending the JVM behavior, I'm just reporting it.
 > |
 > | 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.
 > 
 > Hi, it looks like you have not yet commited that change. Have you found a 
 > work-around for this issue?

No, I implmeneted 1) in my working set, but haven't checked it in
yet.  I'll try to do that today or tomorrow.

Just FYI, there is a good chance I'll be incommunicado next week, due
to circumstances beyond my control.  So if I don't answer email for a
while, don't be surprised.

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

Re: [Plplot-devel] New problems

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

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

|  > The dlopen() man page says:
|  >
|  >        External  references in the library [jc: the dlopened program=
]
|  >        are resolved using the libraries in that library's dependency
|  >        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
|  > executable was linked against, with RTLD_GLOBAL, and
|  > as such their symbols are available to the dlopened program].
|  >
|  >        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.
|
| 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.
|
| I'm not defending the JVM behavior, I'm just reporting it.
|
| 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.

Hi, it looks like you have not yet commited that change. Have you found a=
=20
work-around for this issue?

Joao

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

Re: [Plplot-devel] Task manager

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

Jo=E3o Cardoso writes:
 > On Thursday 25 October 2001 00:42, Geoffrey Furnish wrote:
 > | I've added a task in the SF project page, for the Java binding
 > | development, and dumped a few items into it which I think capture
 > | the spirit of some of the recent discussion.
 >=20
 > Nice. But how can one add tasks or add items to a task? Only=20
 > administrators can do it?

Looks like only admins can add a new sub project.  I /assume/,
although I have not tested, that any logged-in developer can add a
task to a sub project (topical task list).  Click on the "java binding
development" task list, and you should see a way to add a new task.
If you want me to make you a new sub project to which you can
associate tasks, let me know.  If developers who are not admins want
admin privilege in order to reach some of this project tracking
machinery, let me know.

 > Other usefull think is the "bugs" entry. One should use it! Most of=20=


Mmm.  Thanks for pointing this out too.

 > the time I forget to annotate bugs when I detect them, and then I=20=

 > just forget them. By the way, we have a patch there!

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

Re: [Plplot-devel] Task manager

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

On Thursday 25 October 2001 00:42, Geoffrey Furnish wrote:
| I've added a task in the SF project page, for the Java binding
| development, and dumped a few items into it which I think capture
| the spirit of some of the recent discussion.

Nice. But how can one add tasks or add items to a task? Only=20
administrators can do it?

Other usefull think is the "bugs" entry. One should use it! Most of=20
the time I forget to annotate bugs when I detect them, and then I=20
just forget them. By the way, we have a patch there!

Joao

[Plplot-devel] Task manager

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

I've added a task in the SF project page, for the Java binding
development, and dumped a few items into it which I think capture the
spirit of some of the recent discussion.

I wonder if I could persuade other team members to start documenting
with the task manager, at least your views of what /needs/ to be done,
inv arious areas.

I don't view this as a life-or-death thing, but I'm trying to get more
organized here at work, and was thinking about how we could be
similarly more coordianted with PLplot development.  Since SF has some
facilities for at least low-grade ambition tracking, why don't we see
if we can put it to use.  I for one feel that a lot of ideas get lost
by virtue of being discussed almost to death, then forgotten.  How
about people start recording work tasks in the task manager, and lets
see if that helps us be a little more disciplined.

Not obligatory by any means, but hopefully people will find some value
in this.

Cheers to all,

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

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

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

Alan W. Irwin writes:
 > On Wed, 24 Oct 2001, Geoffrey Furnish wrote:
 > 
 > > ....thanks for offering.  If you would Java-ize the
 > > remaining unimplemented C examples, perhaps just leaving the
 > > unimplemented PLplot calls commented out, and check them in, then I
 > > could just focus on implementing the needed API functions, uncomment
 > > one or two lines, and see the examples fully implemented.  That would
 > > definitely be a big help.
 > 
 > OK.
 > 
 > Geoffrey, while looking at the current java examples to see what I could do,
 > I noticed a lot of floats. Won't those give us intermachine comparison
 > trouble unless they are all changed to double?

I plead ignorance.  If you think they should be doubles, feel free to
make them doubles.  That would certainly allow elilmination of some
hideous casts, which is why some of the later examples have things in
double instead of float.

I'm just blundering along on this one.

 > I looked at x09.java, but it is currently too tough for me to infer
 > what to do.  That may change as I gain a bit more experience with other,
 > hopefully easier examples.
 > 
 > Finally, I did find an easy one I could do; x11.java was just a
 > straightforward modification of x08.java.  Note, I know virtually nothing
 > about java programming (total programming time in java is now up to one half
 > hour...;-)), but I inferred what had to be done from x08.java and a context
 > diff between x08c.c and x11c.c, and the x11.java result I just checked in
 > seems to work well.  To finish it, you only need to define the pls.mesh API
 > and change x11.java to replace the temporary use of pls.plot3d with
 > pls.mesh.

It's easy going.  Think of C++-- and you'll get the basic idea.

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

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

On Wed, 24 Oct 2001, Geoffrey Furnish wrote:

> ....thanks for offering.  If you would Java-ize the
> remaining unimplemented C examples, perhaps just leaving the
> unimplemented PLplot calls commented out, and check them in, then I
> could just focus on implementing the needed API functions, uncomment
> one or two lines, and see the examples fully implemented.  That would
> definitely be a big help.

OK.

Geoffrey, while looking at the current java examples to see what I could do,
I noticed a lot of floats. Won't those give us intermachine comparison
trouble unless they are all changed to double?

I looked at x09.java, but it is currently too tough for me to infer
what to do.  That may change as I gain a bit more experience with other,
hopefully easier examples.

Finally, I did find an easy one I could do; x11.java was just a
straightforward modification of x08.java.  Note, I know virtually nothing
about java programming (total programming time in java is now up to one half
hour...;-)), but I inferred what had to be done from x08.java and a context
diff between x08c.c and x11c.c, and the x11.java result I just checked in
seems to work well.  To finish it, you only need to define the pls.mesh API
and change x11.java to replace the temporary use of pls.plot3d with
pls.mesh.

> [referring to fixing up library name problem with double] I'll try to do
this soon

Great!

Alan

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

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

Alan W. Irwin writes:
 > On Tue, 23 Oct 2001, Geoffrey Furnish wrote:
 > > [Referring to implementing the remainder of the plplot API]
 > > It's dirty work, but sombody's gotta do it :-).
 > 
 > Thanks for doing so much already.  With nine demos implemented, you probably
 > already have a large majority of the API implemented so you might be closer
 > to the end than you think.  

Well, a perusal of plplot.h shows the depressing amount of work left
to be done.  PLplot has a /lot/ of API calls.

 > The easiest thing would probably be just for you
 > to carry on with your present work style (API and examples simultaneously)
 > as you have time.  Often, it is counterproductive to throw in new resources
 > near the end of a project. However, I would be willing to do the grunt work
 > on the examples side (but not on the API side since I don't feel competent
 > there) if that would be a help.

That would be great, thanks for offering.  If you would Java-ize the
remaining unimplemented C examples, perhaps just leaving the
unimplemented PLplot calls commented out, and check them in, then I
could just focus on implementing the needed API functions, uncomment
one or two lines, and see the examples fully implemented.  That would
definitely be a big help.

 > > 4.  I think configure support is still poor.
 > 
 > Probably, but I wouldn't want overall concern for the whole configuration to
 > divert attention from the relatively simple task of fixing up the library
 > name configuration.  Even if you solve that simple issue in a temporary way,
 > it gives us the chance to make valuable tests of the java front end using
 > double precision for the first time.

I'll try to do this soon.

 > > 6. I think we should regard the current java suport as alpha or early
 > > beta level stuff, and advertise it only as functional with JDK 1.3.
 > 
 > I agree with the alpha designation since some of the API is still missing.
 > All my testing so far has been with JDK-1.2.2, and the current java front
 > end to plplot does fine in that environment.  Thus, I would rephrase your
 > wording to "functional with JDK 1.2.2 and higher".

Great.

 > > 7. I remain willing, in principle, to attempt to support older JDK's,
 > > but I can't commit to investigate this prior to an imminent release.
 > > If Alan wants to do a release soon, which I support, then I think we
 > > should leave --enable-java off by default, and only represent it as
 > > working with JDK 1.3.
 > 
 > With regard to supporting 1.1.8, I think that is a dead duck now or very low
 > priority (see below).  With regard to the potential release, if the
 > configuration change for the library name reveals some other double-java
 > problems for the examples that now work in single, I would simply note it
 > and not let that hold back a release. OTOH, double and java might work well
 > (once that library name configure issue is solved) for the limited API of
 > the current examples that work with single.  That would be nice to be able
 > to state for the new release so let's find how far we can go with just that
 > library name configuration change.  Same comment as previous about JDK
 > version.

Agree.

 > > 8.  The pathway to supporting older JDK's, seems to me to involve
 > > better understanding of how to set up source structures for older
 > > javac's, and learning how to build/use JAR's, etc.  I could forsee
 > > that this might ultimately mean substantially reworking the way
 > > configure sets up softlinks, but I am optimisitic that it would not
 > > change the way the Java package structure of the PLplot classes, is
 > > presented.
 > 
 > It seems to work fine for 1.2.2, and I wouldn't worry about anything older
 > for some time to come if ever (see dead duck comment above...;-)) I brought
 > up 1.1.8 originally, but as I have gotten more experience with java, my
 > interest in 1.1.8 has waned considerably.  We are not really penalizing
 > users much to demand they use 1.2.2 or above.  It looks like users tend to
 > download whatever jdk they want.  For example, I had a chance to look at RH
 > 7.1 yesterday, and there is no jdk in it, and I assume that continues for RH
 > 7.2.  I think the Sun License is essentially forcing everybody to make
 > individual downloads, and those downloads tend to be the latest/greatest
 > version.  Debian does have one old example (Blackdown jdk-1.1.8) that is
 > thoroughly integrated into their packaging system, but there may be a
 > license relaxation for such an old jdk version that allows this. My guess it
 > that most Debian Java users may simply ignore that old version, download the
 > latest JDK, and use the dummy packages to help integrate it.

I have also been frustrated by the lack of Java rpms in the major
distros, although I haven't actually studied the licensing correlation
factor.  

 > So to summarize, please give the highest priority to finding at least a
 > temporary solution to the library name problem so I can test other aspects
 > of double (and perhaps brag about it in the new release if double works as
 > well as single does now).  1.2.2 is fine as far as I am concerned so don't
 > worry about 1.1.8.  Leave the java packaging of the examples as is if nobody
 > else complains about this additional complexity (or Java style) like I have
 > done....;-)

Great, thanks for the feedback, and offer of help with implementing
the rest of the examples.

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

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

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

On Tue, 23 Oct 2001, Geoffrey Furnish wrote:

> Maybe we can split the System.loadLibrary call out to another small
> .java file which only does this one thing, and then have that one be
> sed'd by configure.  I guess we should add this task to "the list".

That sounds like a reasonable solution to me.  Another alternative, of
course, would be to read (at run time) the library name from a special
one-line file.

> [Referring to implementing the remainder of the plplot API]
> It's dirty work, but sombody's gotta do it :-).

Thanks for doing so much already.  With nine demos implemented, you probably
already have a large majority of the API implemented so you might be closer
to the end than you think.  The easiest thing would probably be just for you
to carry on with your present work style (API and examples simultaneously)
as you have time.  Often, it is counterproductive to throw in new resources
near the end of a project. However, I would be willing to do the grunt work
on the examples side (but not on the API side since I don't feel competent
there) if that would be a help.

> ....feedback desired.
>
> 1.  I think the structure of this langauge binding is pretty good.  I
> like the package structure, plplot.core and plplot.examples.  I think
> it makes sense, presents the right "package interface" to the
> stylistic Java user.  I think PLStream "just feels right".

OK.  I have already posted on this question, and you have recently replied.
You also pointed out in your replay that I had more of a C stylistic
perspective, but that probably flatters me.  More likely its a Fortran
stylistic perspective....;-) Obviously I am less comfortable with java
package style for the examples than you are. However, I respect "just feels
right". Anybody else?

> 4.  I think configure support is still poor.

Probably, but I wouldn't want overall concern for the whole configuration to
divert attention from the relatively simple task of fixing up the library
name configuration.  Even if you solve that simple issue in a temporary way,
it gives us the chance to make valuable tests of the java front end using
double precision for the first time.

>
> 6. I think we should regard the current java suport as alpha or early
> beta level stuff, and advertise it only as functional with JDK 1.3.

I agree with the alpha designation since some of the API is still missing.
All my testing so far has been with JDK-1.2.2, and the current java front
end to plplot does fine in that environment.  Thus, I would rephrase your
wording to "functional with JDK 1.2.2 and higher".

>
> 7. I remain willing, in principle, to attempt to support older JDK's,
> but I can't commit to investigate this prior to an imminent release.
> If Alan wants to do a release soon, which I support, then I think we
> should leave --enable-java off by default, and only represent it as
> working with JDK 1.3.

With regard to supporting 1.1.8, I think that is a dead duck now or very low
priority (see below).  With regard to the potential release, if the
configuration change for the library name reveals some other double-java
problems for the examples that now work in single, I would simply note it
and not let that hold back a release. OTOH, double and java might work well
(once that library name configure issue is solved) for the limited API of
the current examples that work with single.  That would be nice to be able
to state for the new release so let's find how far we can go with just that
library name configuration change.  Same comment as previous about JDK
version.


>
> 8.  The pathway to supporting older JDK's, seems to me to involve
> better understanding of how to set up source structures for older
> javac's, and learning how to build/use JAR's, etc.  I could forsee
> that this might ultimately mean substantially reworking the way
> configure sets up softlinks, but I am optimisitic that it would not
> change the way the Java package structure of the PLplot classes, is
> presented.

It seems to work fine for 1.2.2, and I wouldn't worry about anything older
for some time to come if ever (see dead duck comment above...;-)) I brought
up 1.1.8 originally, but as I have gotten more experience with java, my
interest in 1.1.8 has waned considerably.  We are not really penalizing
users much to demand they use 1.2.2 or above.  It looks like users tend to
download whatever jdk they want.  For example, I had a chance to look at RH
7.1 yesterday, and there is no jdk in it, and I assume that continues for RH
7.2.  I think the Sun License is essentially forcing everybody to make
individual downloads, and those downloads tend to be the latest/greatest
version.  Debian does have one old example (Blackdown jdk-1.1.8) that is
thoroughly integrated into their packaging system, but there may be a
license relaxation for such an old jdk version that allows this. My guess it
that most Debian Java users may simply ignore that old version, download the
latest JDK, and use the dummy packages to help integrate it.

So to summarize, please give the highest priority to finding at least a
temporary solution to the library name problem so I can test other aspects
of double (and perhaps brag about it in the new release if double works as
well as single does now).  1.2.2 is fine as far as I am concerned so don't
worry about 1.1.8.  Leave the java packaging of the examples as is if nobody
else complains about this additional complexity (or Java style) like I have
done....;-)

Alan

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

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

Alan W. Irwin writes:
 > I agree that what I was asking for before was to eliminate the
 > package structure, but I now refine that request, see below.
 > 
 > > In other words, I'd rather do the experiments with HelloWorld class
 > > things, than with PLplot.
 > 
 > I have done those tests which I believe can be summarized as package
 > structure does not work for 1.1.8.  Nevertheless, it does work for 1.2.2 and
 > above as my further tests last night proved.  So I don't mind if you put
 > PLStream.class in its own package.  I like that because the extra
 > plplot.core helps to identify it and also eliminates name clashes, and I
 > also think it is acceptable to say we don't support anything before
 > jdk-1.2.2.
 > 
 > I guess my only remaining objection is having the examples in a package
 > structure.  To me that seems like unnecessary complexity. It gives the
 > mistaken impression to the java newbie like me that my own java code for
 > plotting must be in a complicated directory structure.  Thus, I believe you
 > should remove the package command from all the examples so the resulting
 > class files appear right in tmp and are part of no formal java
 > package.

I thought about this.  If the examples were just free standing
programs, this would make a certain amount of sense.  The C demos, for
example, are kind of like this.  Just independent programs that link
against plplot, but are otherwise independent.

In Java, I am imagining that the installation article, is a JAR file.
plplot-config --java-classpath will return something like:
	      $prefix/lib/java/plplot.jar
or some such.  With this class path, and with LD_LIBRARY_PATH set to
include $prefix/lib, they will "run" the demos via java
plplot/examples/x??.  The thing is that Java's CLASSPATH centric view
of the software world, means that all these things sort of "live in
the same space".  Speaking anthropomorphically here, but hopefully you
understand what I mean.

My feeling was that for things delivered in a JAR, leaving them at
global scope would be bad, because the class names "x01", etc, would
interfere with the ability of clients to have similar names in their
global scope.  So, because of Java's propensity for gang bundling
software, I decided that what made the most sense to me, was to bundle
the plplot java examples together, but drop them in a namespace
(woops, dropping into C++ parlance there), a Java package, that
wouldn't collide with users.  So, plplot.examples.*, gets them
delivered to the JAR that winds up in their CLASSPATH, without dumping
junk into the global scope.

I think if you want to strip the examples out of 
  package plplot.examples;
then we need to also not deliver them in the JAR file (or hierarchical
.class collection) at install time.  We could still upload them to the
install tree somewhere, but not under the same CLASSPATH as the
plplot.core goods.  They would still be able to run them, but they'd
have to cd to the java demo dir, and run them as you've shown.  That
works, I agree, but just doesn't seem as stylistically or
idiomatically java, as the choice I made.  

I guess my position can be sumarized by saying that the scheme you are
advocating looks to me very natural from a C mindset.  But the scheme
I chose seems more natural to a Java mindset.  I believe this, but I
realize I am a small sample :-).  Studying how other packaged/released
java ware is done obviously presents one way to attempt to tune into
the frequency of the Java community, but I guess I'd be wary of
relying too heavily on the example of things that date from the
pre-Java 2 days.  

 (I
 > have just done this on my own and it works fine so long as you have your
 > CLASSPATH set up as
 > 
 > echo $CLASSPATH
 > .:/home/software/plplot_cvs/HEAD/plplot/tmp/java/
 > 
 > The initial . finds any class file you have compiled into the local
 > directory wherever that may be, and the /home/etc.... finds the
 > PLStream.class.  That latter directory would be changed if PLStreams.class
 > was installed, of course.  Also note for all user examples, that at least
 > two paths will always be required of CLASSPATH unless PLStreams.class is
 > installed in a java default location.) In my view compiling into the local
 > directory will be more representative of the way that most java users will
 > be using plplot. All java examples I have seen recently (and I have seen
 > quite a few) compile their class files right into the current directory, and
 > I think that keeping things simple this way is an excellent choice for our
 > examples as well.

The extended Java framework that Lightspeed has, also has files
distributed over a hierarchy on disk, with the package assocations
matching the disk layout identically.  Then we point CLASSPATH to the
root of this tree, but also to any other Java ware that we use which
is not part of the local source set.  By just including the PLplot
classpath as one component in the classpath, we can run local code,
including local code that uses the PLplot Java API, or
the PLplot examples, without tampering with the CLASSPATH.  Others
could do the same.  This seems like a very free-playing way to go, to
me. 

 > However, that is just my $0.02 Canadian from my java newbie
 > perspective, and if you feel it is necessary to keep the package
 > complexity for the examples, I would be willing to accept that
 > (albeit somewhat reluctantly) as well.

I don't view the "package plplot.examples;" as complexity, but rather
as idiomatic Java style.  

We should consider this topic open for further discussion.

Gotta run.

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

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

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

Alan W. Irwin writes:
 > 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.

Mmm, wow, thanks for uncovering this.  I certainly did not know about
this problem yet.

I haven't been configuring with --with-double, so I guess I haven't
gone through the issues of setting up the configure support for mixing
double with java.  However, I don't really see exactly how to do what
we need.  The reference to "libplplot" is found in PLStream.java, line
235:

// Static code block to get the PLplot dynamic library loaded in.
    static {
        System.loadLibrary( "plplot" );
    }

which would need to be, I guess, plplotd, for the double case.  What I
don't know, is how we're gonna make this configure-time change
accessible to the code.  Java doesn't have header files,
preprocessors, anything like CPP, etc.  I don't really like the idea
of making PLStream.java into PLStream.java.in, to be converted to
PLStream.java by configure, because it's a substantial heavyweight
source file, which I am actively editing, now, and will continue to be
in flux for some time to come (see below).

Maybe we can split the System.loadLibrary call out to another small
.java file which only does this one thing, and then have that one be
sed'd by configure.  I guess we should add this task to "the list".

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

Thanks.  

What's done (speaking of the API), can be seen in PLStream.java.  All
the decls that say "public native void xyz(...);" are the API entry
points that are implemented.  You can see with a quick perusal, that
this set is far short of the full set.  On the other hand, the ones
that are implemented, are mostly done in duplicate for float and
double, where there are FP arguments.  (Looks like I mised poin on
double[], gotta go back and do that at some point.)

There are many many PLplot api calls that haven't been implemented
yet.  Basically what I've been doing is implementing the examples, one
by one.  I pull in the x??c.c code to x??.java, comment it all out,
and then go through it line by line, converting the C code to Java,
leaving the plplot api calls still commented out.  Once I think I have
the data for the plot computed properly, then I go through and
uncomment the PLplot calls.  At this point most of the calls for
setting up the plots are done, so you can at least get the labels,
viewports, etc, showing.  Then I go through and implement the api's
for the drawing functions, one by one, until the whole demo is
displaying.  Then I check that in, and move to the next plot.

As time allows.

So, there's lots still left to do.  It's mostly make work.  You can
read javabind.c and see that the most of the wrapper functions are
trivially constructed.  The only really tricky part, is the business
of setting up the function names, which you have to get by putting the
decls in PLStream.java, and then running javah, and pasting the output
from that into javabind.c.  And javah sometimes lies, producing
function names with funny octal codes (I guess) burried in them, which
the JVM does /not/ use when it references the names through JNI.  So I
had to learn to chop out the bizarre octal chars, leaving the parts of
the name that look vaguely like C++ mangled linker function names.

It's dirty work, but sombody's gotta do it :-).

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

Here's my take on it, feedback desired.

1.  I think the structure of this langauge binding is pretty good.  I
like the package structure, plplot.core and plplot.examples.  I think
it makes sense, presents the right "package interface" to the
stylistic Java user.  I think PLStream "just feels right".

2.  I think the overloading of float and double args in the Java api
is good.  People can write Java code with either float or double
types, and the plots will "just work", whichever way they configured
plplot when they built it.  That is, they can use float and float[],
and still plot to a double plplot config, and vice versa.  I think
that's good.  It decouples the client's .java source files from the
config time issue of the PLplot build.

3.  I think the under-the-hood implementation of the JNI wrappers is
good.  We are efficient when the user type maps to PLFLT, and we incur
only reasonable overhead when conversions have to be performed.  I
think this style can be extended to cover the as yet unimplemented
APIs. 

4.  I think configure support is still poor.  I didn't even know about
the float/double library config bug that Alan discovered.  There's
probably other issues neither of us knows about.  Some issues I do
know about, relate to the difficulty of mapping PLplot's "flat tmpdir"
build paradigm, to Java, and comparatively lame implemenation of the
install target (for Java components).  There's a lot of issues here.
Idiomatic Java usage seems to couple package structure to disk
hierarchy inseparably.  I've rigged the plplot build system with javac
invocation well enoguh to work for JDK 1.3, but it seems clear there
are issue with other JDK's and other vendor implementations.  Users
aren't gonna like the way the install works right now.  We should be
building a JAR for the install.  plplot-config needs to be expanded to
cover coughing up java classpaths for clients, etc.

5.  Timelines are totally unclear.  I cannot commit to specific
functionality by any particular date.  

6. I think we should regard the current java suport as alpha or early
beta level stuff, and advertise it only as functional with JDK 1.3.  

7. I remain willing, in principle, to attempt to support older JDK's,
but I can't commit to investigate this prior to an imminent release.
If Alan wants to do a release soon, which I support, then I think we
should leave --enable-java off by default, and only represent it as
working with JDK 1.3.  

8.  The pathway to supporting older JDK's, seems to me to involve
better understanding of how to set up source structures for older
javac's, and learning how to build/use JAR's, etc.  I could forsee
that this might ultimately mean substantially reworking the way
configure sets up softlinks, but I am optimisitic that it would not
change the way the Java package structure of the PLplot classes, is
presented. 

9.  I could be wrong in 8. above.  If it is conclusively determined
that the current package structure won't work in old JDK's, I suppose
more deep thinking will be required.

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

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

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

On Tue, 23 Oct 2001, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > Geoffrey, you may have misunderstood me since you talk about eliminating
>  > packages which is a phrase I certainly did not use.
>
> My point is that I believe your request is synonymous with eliminating
> packages.  Perhaps I am mistaken, but I don't have information to
> persuade me otherwise at this time.
>
> CLASSPATH is supposed to point to the /root/ of your java package
> system.  If a Java class file lives in package x.y, then you point
> CLASSPATH to the parent of x, and reference the class as x/y/z.  If
> you want to eliminate the string "x/y/z", I believe this effectively
> means eliminating the package structure.

Thanks for that clarification.  I had no clue what you meant by packages
before, and I have to confess I interpreted the phrase "eliminating packages"
as something to do with eliminating software packages. But now I understand
what you are talking about, I agree that what I was asking for before was to
eliminate the package structure, but I now refine that request, see below.

> In other words, I'd rather do the experiments with HelloWorld class
> things, than with PLplot.

I have done those tests which I believe can be summarized as package
structure does not work for 1.1.8.  Nevertheless, it does work for 1.2.2 and
above as my further tests last night proved.  So I don't mind if you put
PLStream.class in its own package.  I like that because the extra
plplot.core helps to identify it and also eliminates name clashes, and I
also think it is acceptable to say we don't support anything before
jdk-1.2.2.

I guess my only remaining objection is having the examples in a package
structure.  To me that seems like unnecessary complexity. It gives the
mistaken impression to the java newbie like me that my own java code for
plotting must be in a complicated directory structure.  Thus, I believe you
should remove the package command from all the examples so the resulting
class files appear right in tmp and are part of no formal java package. (I
have just done this on my own and it works fine so long as you have your
CLASSPATH set up as

echo $CLASSPATH
.:/home/software/plplot_cvs/HEAD/plplot/tmp/java/

The initial . finds any class file you have compiled into the local
directory wherever that may be, and the /home/etc.... finds the
PLStream.class.  That latter directory would be changed if PLStreams.class
was installed, of course.  Also note for all user examples, that at least
two paths will always be required of CLASSPATH unless PLStreams.class is
installed in a java default location.) In my view compiling into the local
directory will be more representative of the way that most java users will
be using plplot. All java examples I have seen recently (and I have seen
quite a few) compile their class files right into the current directory, and
I think that keeping things simple this way is an excellent choice for our
examples as well.

However, that is just my $0.02 Canadian from my java newbie perspective, and
if you feel it is necessary to keep the package complexity for the examples,
I would be willing to accept that (albeit somewhat reluctantly) as well.

Alan

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

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

Alan W. Irwin writes:
 > 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.

My point is that I believe your request is synonymous with eliminating
packages.  Perhaps I am mistaken, but I don't have information to
persuade me otherwise at this time.

CLASSPATH is supposed to point to the /root/ of your java package
system.  If a Java class file lives in package x.y, then you point
CLASSPATH to the parent of x, and reference the class as x/y/z.  If
you want to eliminate the string "x/y/z", I believe this effectively
means eliminating the package structure.  

I admit the conceivability that I may be wrong.  But I haven't seen
the evidence yet.  I realize you've done some tests, but I'm saying
they don't convince me, at least not yet.  The package system has been
in Java since the beginning.  My active Java programming status has
been only for two months, using JDK 1.3.  So yes, it is possible that
my assumptions about how Java used to work may be wrong.  It is also
possible that there are some nuances of precise techniques for working
with older JDK's, that both you and me, don't know.  Before I agree to
some substantial restructuring of the code, which I believe is well
structured now, I want to be certain that I understand the true and
complete semantics of class usage in older JDK's.  Right now I don't
have this clear understanding.  Right now the only thing I feel I know
clearly, is that "it don't work".  But I don't feel we've identified
/why/ it doesn't work, or /how/ things do work in the old JDK's.  I
want to get through that clearly, rather than just initating reactive
efforts at restructuring the PLplot code.

In other words, I'd rather do the experiments with HelloWorld class
things, than with PLplot.  

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

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

On Mon, 22 Oct 2001, Alan W. Irwin wrote:

> 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
TYPO should read:
> the correct libplplotd.  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.