Re: [Plplot-devel] decoupling drivers from libplplot

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

Alan W. Irwin writes:
 > On Mon, 2 Sep 2002, Geoffrey Furnish wrote:
 > 
 > > Okay, well, I bit the bullet, and implemented a large part of the env
 > > handle object thing that I've discussed recently, and previously.
 > >
 > > So I went to test it, and as the first step, I tried to run the ps
 > > driver inside a java example (this is with dyn drivers), but without
 > > first changing ps.c to eliminate the direct linkage to plPhyRot.
 > >
 > > Curiously, it ran without difficulty.
 > 
 > I just tried replacing
 > 
 > gcc -shared -fPIC -o drivers/psd_drv.so shared/ps.o shared/pstex.o -L. -lplplotd
 > 
 > with
 > 
 > gcc -shared -fPIC -o drivers/psd_drv.so shared/ps.o shared/pstex.o
 > 
 > and it didn't generate any errors at all from either python or java.  But
 > then I recalled the dlopen code tries both the plplot/tmp/drivers location
 > and installed location for something valid.  So I removed my installed
 > version (you should do this as well), and then both python and java fail to
 > work with the second form, but work fine with the first form.

Oh, duh, I shouldda thot o' that.   Okay, I'll try again tonight when
I get back to the machine with that dev strain on it.

 > > Just to confirm:  Alan, you're using a JDK less than 1.4.0, and if you
 > > drop the -lplplot when linking psd_drv.so, then you can't run the ps
 > > driver inside a java example, right?
 > 
 > Yep, I was using jdk1.2.2 with the above example.  But I think that might be
 > a red herring.  Try again with the above shortened link line with no
 > installed version of plplot, and I suspect you will also see errors with
 > both java and python.

Yeah, probably.  And if so, that will provide the test environment I
need for making sure the plenv thing is really working right.

 > BTW, I thought your "possible security reasons" explanation for why both
 > java and python were forcing -L. -lplplot[d] on the gcc line above was a
 > reasonable explanation.  Which begs the question should we be doing extra
 > coding ourselves simply to avoid putting -L. -lplplot[d] on the gcc line? By
 > reading through the posts in historical order, you may have gotten the
 > impression this was still unsolved, but the configuration has long been
 > changed so that -L. -lplplot[d] or -L. -lplplottcltk[d] is done
 > appropriately for all drivers.

Well, okay, there's a lot of history here, and I am coming back into
it after an absence, so perhaps I'm detuned.

I had dyndrivers working long before your recent flurry, and the way I
did it before, was to link them to -lplplot.  Now, there were some
iterations of that as well.  There were times when cvs head didn't
link the drivers to libplplot, and I didn't notice it to be a problem
because I didn't test with the drivers that actually called functions
in libplplot.  And then sometimes also I was running in x01c and
friends, and failed to notice that running dyndrivers inside x01.java
was different than running them in x01c.  So, the code fluctuated a
few times, but in the end (before your recent activity), the drivers
were linked to libplplot.  So, yes, I knew that that was a "solution",
of sorts.

And sure, you could say, if there is a solution of sorts, why mess
with any more swdev intensive approach?

My feeling is that the JNI env handle model, is actually really a good
idea.  Not just a dumb hack.  

For one thing, it makes the drivers more transportable.  By not being
specifically linked to libplplot, but just being truly dynloadable
modules, it means people will be able to cart them around without
worrying specifically which version of the library they were compiled
for.  Do I expect people to be trafficking in illegally imported
plplot dynamic drivers?  Of course not :-).  But the point is, it is
one more type of coupling removed, and intrinsically valuable from
that standpoint.

Another aspect of it is that it formalizes the notion of support
services that PLplot provides to drivers.  There are several functions
already, but it looks like kind of a strange collection of API's.  By
calling attention to it in the code, and collecting the provisioning
of these services into one place, it should make it easier to reason
about how to better organize what's there, as well as to flesh it out.

I think there's stuff, especially related to coordinate
transformations, that could probably be usefully pulled out from the
interactive drivers, and moved into an area where they can be more
easily shared by all the drivers.

Noel Gorelick once ruefully noted on the list, that way too much
effort had been dumped into the plframe interface, and too little
effort dumped into constructing reusable services for implementing
widgets.  Although I didn't share his antipathy for plframe, I
certainly do share his view of vision of infrastructure development to
promote the construction of disparate intractive widgets for PLplot to
play in multiple toolkit environments.

I think the move to the concept of a handle for reaching a family of
driver support functions, can be a useful approach to this.  It
certainly works handsomely well in the Java Native Interface world.

The linkage thing is just one piece of the pie.

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