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.
phone: 250-727-2902 FAX: 250-721-7715
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
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 furnish@...
> Plplot-devel mailing list