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