plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

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

On Sat, 9 Nov 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > I haven't looked at the code in detail, but I am just going on the
>  > documentation here.  All pltr2 seems to do is interpolate (with boundary
>  > checks).  So shouldn't it be straightforward to make variations on pltr2
>  > that accept and use a PLPointer which includes either the nx(j) information
>  > or ny(i) information?  I realize that such variations are not all that needs
>  > to be done by a long shot, but if these fundamental bits are possible, then
>  > I think the rest should be straightforward for all 3D API's that currently
>  > reference an interpolater such as pltr2.
>
> I don't think this belongs in pltr(), because it is called so deep in the
> loop.  You need something that can influence the control structure, so we're
> probably talking about function arguments e.g. (*fnx)(j) & (*fny)(i), for
> which the default is to return a constant (nx & ny, respectively).
>
> The bigger problem is reordering the loops in order to support *both* nx(j)
> and ny(i) -- the varying one needs to be in the inner loop of course.  So in
> general you'll need two versions of each plotter.  One of those will have the
> loop order swapped from what it is now, which means lots of logic changes in
> the interior of the loop (go look).  An additional complication is that the
> shade & contour plotters use different loop ordering already.  I haven't
> looked at the 3d plotters.
>
> Looks like an awful lot of work.

In my own case, the nx(y) and ny(x) limits are monotonic so my data can be
transformed from one form to the other.  Thus, I would need only one
choice implemented which would greatly simplify the change.  OTOH, this
would introduce a certain lack of generality which would disappoint other
users with irregularly defined regions which cannot be transformed from
the nx(y) form to the ny(x) form.

Perhaps the other idea of filling out the undefined region of the rectangle
with constant z(i,j), x(i,j), and y(i,j) from the last point on the boundary
would work instead.  Naively, I would think the contourer, shader, and other
3D routines would just keep hammering at the boundary values as it swept
through i,j of the extended region and thus produce acceptable results.

Alan

Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > Some proliferation of API like this at the C level is probably worth it. But
 > the interfaces also have a role that can be played.  For example, in my
 > user-friendly python interface, I define a lot of different simplified API's
 > for plcont, plshade, and plshades without having to use different names. It
 > is extremely easy to do this in python because it is an object-oriented
 > language.  Since C++, java, tcl (via itcl), and even perl have OO, then it
 > should be easy to translate what I have done in python to those other
 > languages as well.

Alas, but iTcl doesn't support method overloading by number of arguments (or
type, naturally, as Tcl's typeless).  The best you can do is use default args.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

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

On Sat, 9 Nov 2002, Joao Cardoso wrote:

> I agree. plshades() is a good direction. Dont' remove/redefine old API
entries, instead we must provide new/easier to use API entries. With time,
we can even put a plwarn() in the old API, saying that they can be replaced
with the new one, and will eventually be removed.

Some proliferation of API like this at the C level is probably worth it. But
the interfaces also have a role that can be played.  For example, in my
user-friendly python interface, I define a lot of different simplified API's
for plcont, plshade, and plshades without having to use different names. It
is extremely easy to do this in python because it is an object-oriented
language.  Since C++, java, tcl (via itcl), and even perl have OO, then it
should be easy to translate what I have done in python to those other
languages as well.

> > I understand your concerns here, but OTOH we shouldn't be afraid to change
> > if there are compelling reasons to do so and we give plenty of warning to
> > our users.
>
> warnings is not enought, if users have a big amount of software they must
> rewrite.

They also have the option of sticking with an old stable version such as
PLplot-5.1.0 so "must" is too strong a statement.  The exact same debate
often rages for the Linux kernel with e.g., binary module makers such as the
nvidia video card company wanting no change.  But Linus refuses to be
constrained by such arguments and suggests those who want the old stable
kernel API should stick with that old stable kernel version.  The result is
an evolving kernel that remains a lot cleaner and easier to maintain than it
otherwise would.

However, that said I do appreciate the concern expressed by you and Maurice
so *when the time comes* we should also discuss the option of adding a whole
new set of plplot 3D calls named the same way as the old-fashioned calls but
with a trailing "u" in the name standing for uniform 3d API.  But let's
bring up this "add API" versus "change API" discussion again only if/when
this becomes relevant.

For example, I am only interested in making this change if the new API
contains the possibility of nx(y) or ny(x) for *all* of our 3D calls.
That's the "killer app" feature for me.  This capability has long been a
standard feature of gnuplot.  It is needed for my equation of state data
at low temperatures and high densities where no equation of state results
can be calculated.  Right now for PLplot I am forced to extend the data into
this forbidden zone using a constant value, but the results look fairly
ugly and are a bad advertisement for PLplot.

Come to think of it, right now I guess it would be possible to extend the
x(ix,iy) and y(ix,iy) arrays with constant values as well.  I haven't tried
this, but it might give a nice looking result for plcont, plshade, and
plshades with the pltr2 interpolator (which deals well with x(ix,iy) and
y(ix,iy)) passed as an argument.  But if that worked, I would also need a
new API for plot3d, plmesh, and plsurf3d to allow them to accept a pltr
pointer and use it properly inside.

Of course that possibility is part of the "best API" discussion that I
hope we continue to have.

Alan

Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Sat, 9 Nov 2002, Maurice LeBrun wrote:
 > 
 > > p.s. as far as allowing a nx(j) or ny(i) dependence, I have no idea.  Never
 > > thought about it before, and after a quick look at the code I'm not hopeful
 > > that there's an easy way to support it.
 > 
 > I haven't looked at the code in detail, but I am just going on the
 > documentation here.  All pltr2 seems to do is interpolate (with boundary
 > checks).  So shouldn't it be straightforward to make variations on pltr2
 > that accept and use a PLPointer which includes either the nx(j) information
 > or ny(i) information?  I realize that such variations are not all that needs
 > to be done by a long shot, but if these fundamental bits are possible, then
 > I think the rest should be straightforward for all 3D API's that currently
 > reference an interpolater such as pltr2.

I don't think this belongs in pltr(), because it is called so deep in the
loop.  You need something that can influence the control structure, so we're
probably talking about function arguments e.g. (*fnx)(j) & (*fny)(i), for
which the default is to return a constant (nx & ny, respectively).

The bigger problem is reordering the loops in order to support *both* nx(j)
and ny(i) -- the varying one needs to be in the inner loop of course.  So in
general you'll need two versions of each plotter.  One of those will have the
loop order swapped from what it is now, which means lots of logic changes in
the interior of the loop (go look).  An additional complication is that the
shade & contour plotters use different loop ordering already.  I haven't
looked at the 3d plotters.

Looks like an awful lot of work.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

[Joao C. <jc...@fe...>]

On Saturday 09 November 2002 17:09, Alan W. Irwin wrote:
> On Sat, 9 Nov 2002, Maurice LeBrun wrote:
> > Alan W. Irwin writes:
> >  > Currently we have a nonuniform mixture of API's for the way we pas=
s 3D
> >  > information to our 3D routines.
> >
> > As for what an "uber-API" for these would look like, we can look at t=
he
> > API for the fattest plcont/plshade plot calls we have and go from the=
re.
> >
> > [...](gulp).  The shade plotter has the exclusion region that the con=
tour
> > plotter is missing, so if that capability were added to the contourer=
 the
> > two could share that in common.  Possibly with the (*defined) argumen=
t
> > changed to:
> >
> >         void (*defined) (PLFLT, PLFLT, PLINT *, PLPointer),
> >         PLPointer defined_data);
> >
> > as I mentioned some time back (but never got around to doing it).

As a matter of fact I prefer to have the possibility to exclude regions u=
sing=20
data instead of using a function, as seldon we have such function but we=20
might have the data where the data is invalid (say nan/inf/nd -- the ieee=
=20
standard does not define "nd", not defined, some software uses one of the=
=20
possible nan values to specify non-valid data).

> Thanks for these suggestions.
>
> > 'Course the real trick is to define simpler front-ends that do the jo=
b at
>
> hand 80%-95% of the time.  So plshades() is a step in the right directi=
on.
> Also the kx, lx, ky, ly args in the contour plotter are rarely exercise=
d so
> I'd personally leave them out of a simpler general-purpose API (they we=
re
> there in plplot 2.6 and I left them in).
>
> I never use those kx, lx, ky, ly limits so I also wouldn't mind persona=
lly
> if they went.
>
> > I also firmly believe that preserving the existing API should be a
> > priority,

I agree. plshades() is a good direction. Dont' remove/redefine old API=20
entries, instead we must provide new/easier to use API entries.
With time, we can even put a plwarn() in the old API, saying that they ca=
n be=20
replaced with the new one, and will eventually be removed.

> except when dealing with relatively newly-added calls for which
> > some period of flux is to be expected.  People use different versions=
 of
> > plplot on different machines; you don't want them to be *too* afraid =
to
> > upgrade.
>
> I understand your concerns here, but OTOH we shouldn't be afraid to cha=
nge
> if there are compelling reasons to do so and we give plenty of warning =
to
> our users.

warnings is not enought, if users have a big amount of software they must=
=20
rewrite. Remember, the Pentium 4 still executes instructions for the now =
more=20
then 10 years old i8086!

Joao

> Moving to a uniform API for passing 3D information to our 3D
> routines may already be compelling enough reason, but let's clinch the =
deal
> by making it the best API we can think of.
>
> So after the next release I will think hard about your suggestions, and
> also the nx(iy) or ny(ix) problem (see next post) to see what I can com=
e up
> with.
>
> Alan
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plenv() issues

[Joao C. <jc...@fe...>]

On Saturday 09 November 2002 07:54, Maurice LeBrun wrote:
> Joao Cardoso writes:
>  > On Wednesday 06 November 2002 06:17, Maurice LeBrun wrote:
>  > > Alan W. Irwin writes:
>  > >  > On Tue, 5 Nov 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
>  > >  > > What do you think of this problem? Is there a "cure" that doe=
s
>  > >  > > not influence other users?
>  > >  >
>  > >  > How about define plenv0 which does everything but the page adva=
nce?
>  > >  > Then define plenv as the combination of pladv and plenv0.
>  > >  >
>  > >  > I know this adds one more piece of public API that we have to
>  > >  > propagate to all the language interfaces *and* document, but th=
at
>  > >  > is pretty straightforward, and we currently have so many variat=
ions
>  > >  > on our startup commands (think of all the plstart variations), =
and
>  > >  > our advance page commands, that adding another convenient plenv
>  > >  > variation isn't that big a deal IMO.
>  > >  >
>  > >  > Geoffrey and Maurice, is such a solution OK with you?
>  > >
>  > > Sure.  I've never been completely happy with the behavior of plenv=
 in
>  > > this regard either.
>  >
>  > OK, I will work on it soon.
>  >
>  > Do you think that plenv0() should clear the page? I think it should!
>
> Seems reasonable.  There may be some cases where the user doesn't want =
it
> cleared but these are probably rare and not worth API support.
>
> Sigh.. I must admit to some dislike of the proliferation of API calls. =
 I

I agree!=20

> would greatly prefer we handle these kinds of cases through some sort o=
f
> option-setting procedure.  E.g. instead of calling plenv0(...), one wou=
ld
> do:
>
> plsopt("plenv_advance", "0");
> plenv(...)
>
> Then you never need to expand the API (complete with the myriad of lang=
uage
> bindings needed), just add a new option.

Good solution. Now is a bit too late, as I already implemented plenv0().
However, I think that if plsopt("plenv_advance", "0") becomes implemented=
=20
before the next release, then we can drop plenv0().

No user can complain by a feature introduced and removed but that never m=
ade=20
part of a release.=20

>
> I've actually implemented such a scheme for my own libraries, twice now=
,
> once in Fortran and more recently in iTcl.  Because there are times whe=
n
> you want the option to be set forever, I'd use plsdopt(...) to set an
> option permanently (default); plsopt would only take effect until the n=
ext
> new plot. That way you could avoid non-local effects.  It works great.

So lets wait for plsdopt() also. Your ToDo list?

Joao

> Anyway, I've got no time for any of this right now, so for now we're st=
uck
> with the usual addition to the API.
>
>  > As plclear() is not currently working (no driver but the gnome one
>  > supports it) I will also change it, issuing a solid fill with the
>  > background color when the driver does not support clear.
>
> Looks good.

Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

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

On Sat, 9 Nov 2002, Maurice LeBrun wrote:

> p.s. as far as allowing a nx(j) or ny(i) dependence, I have no idea.  Never
> thought about it before, and after a quick look at the code I'm not hopeful
> that there's an easy way to support it.

I haven't looked at the code in detail, but I am just going on the
documentation here.  All pltr2 seems to do is interpolate (with boundary
checks).  So shouldn't it be straightforward to make variations on pltr2
that accept and use a PLPointer which includes either the nx(j) information
or ny(i) information?  I realize that such variations are not all that needs
to be done by a long shot, but if these fundamental bits are possible, then
I think the rest should be straightforward for all 3D API's that currently
reference an interpolater such as pltr2.

Alan

Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

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

On Sat, 9 Nov 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Currently we have a nonuniform mixture of API's for the way we pass 3D
>  > information to our 3D routines.

> As for what an "uber-API" for these would look like, we can look at the API
> for the fattest plcont/plshade plot calls we have and go from there.

> [...](gulp).  The shade plotter has the exclusion region that the contour plotter
> is missing, so if that capability were added to the contourer the two could
> share that in common.  Possibly with the (*defined) argument changed to:
>
>         void (*defined) (PLFLT, PLFLT, PLINT *, PLPointer),
>         PLPointer defined_data);
>
> as I mentioned some time back (but never got around to doing it).

Thanks for these suggestions.

> 'Course the real trick is to define simpler front-ends that do the job at
hand 80%-95% of the time.  So plshades() is a step in the right direction.
Also the kx, lx, ky, ly args in the contour plotter are rarely exercised so
I'd personally leave them out of a simpler general-purpose API (they were
there in plplot 2.6 and I left them in).

I never use those kx, lx, ky, ly limits so I also wouldn't mind personally
if they went.

>
> I also firmly believe that preserving the existing API should be a priority,
> except when dealing with relatively newly-added calls for which some period
> of flux is to be expected.  People use different versions of plplot on
> different machines; you don't want them to be *too* afraid to upgrade.

I understand your concerns here, but OTOH we shouldn't be afraid to change
if there are compelling reasons to do so and we give plenty of warning to
our users. Moving to a uniform API for passing 3D information to our 3D
routines may already be compelling enough reason, but let's clinch the deal
by making it the best API we can think of.

So after the next release I will think hard about your suggestions, and also
the nx(iy) or ny(ix) problem (see next post) to see what I can come up with.

Alan

Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

[Maurice L. <mj...@ga...>]

p.s. as far as allowing a nx(j) or ny(i) dependence, I have no idea.  Never
thought about it before, and after a quick look at the code I'm not hopeful
that there's an easy way to support it.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > After this next release is out the door I hope to make some substantial
 > changes in how we call our current 3D routines, plot3d, plmesh, plsurf3d,
 > plcont, plshade, and plshades.
 > 
 > Currently we have a nonuniform mixture of API's for the way we pass 3D
 > information to our 3D routines. For example, many routines don't worry about
 > a defined region and plcont and plshade(s) have a generalized method of
 > passing z, x, y which allows using arbitrary methods (e.g., pltr0, pltr1,
 > pltr2, etc.) of evaluating the data while the rest of the routines (plot3d,
 > plmesh, plsurf3d) don't use a generalized method of passing 3D information
 > so their capabilities are much more limited as a result.
 > 
 > This lack of a generalized method of passing 3D information to plot3d,
 > plmesh, and plsurf3d has become a real problem for my own research work.
 > Typically my z arrays are defined with either fixed nx and ny a function of
 > x index or fixed ny with nx a function of y index.  It should not be a
 > problem for me to define more pltr variations that will handle these cases,
 > but the lack of a generalized method of passing information to plot3d,
 > plmesh, and plsurf3d also needs to be addressed as well.

I personally don't use surface plotting very often, as the data I deal with
tends to be a tad too noisy for it to be useful.  So I never got around to
generalizing these.

As for what an "uber-API" for these would look like, we can look at the API
for the fattest plcont/plshade plot calls we have and go from there.  For
contours:

plfcont(PLFLT (*f2eval) (PLINT, PLINT, PLPointer), 
        PLPointer f2eval_data, 
        PLINT nx, PLINT ny, PLINT kx, PLINT lx, 
        PLINT ky, PLINT ly, PLFLT *clevel, PLINT nlevel, 
        void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer), 
        PLPointer pltr_data);

and for shades:

plshade_int(PLFLT (*f2eval) (PLINT, PLINT, PLPointer), 
        PLPointer f2eval_data, 
        PLFLT (*c2eval) (PLINT, PLINT, PLPointer), 
        PLPointer c2eval_data,  
        PLINT (*defined) (PLFLT, PLFLT), 
        PLFLT missing_min, PLFLT missing_max, 
        PLINT nx, PLINT ny,  
        PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax, 
        PLFLT shade_min, PLFLT shade_max, 
        PLINT sh_cmap, PLFLT sh_color, PLINT sh_width, 
        PLINT min_color, PLINT min_width, 
        PLINT max_color, PLINT max_width, 
        void (*fill) (PLINT, PLFLT *, PLFLT *), PLINT rectangular, 
        void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer), 
        PLPointer pltr_data); 

(gulp).  The shade plotter has the exclusion region that the contour plotter
is missing, so if that capability were added to the contourer the two could
share that in common.  Possibly with the (*defined) argument changed to:

        void (*defined) (PLFLT, PLFLT, PLINT *, PLPointer), 
        PLPointer defined_data); 

as I mentioned some time back (but never got around to doing it).

'Course the real trick is to define simpler front-ends that do the job at hand
80%-95% of the time.  So plshades() is a step in the right direction.  Also
the kx, lx, ky, ly args in the contour plotter are rarely exercised so I'd
personally leave them out of a simpler general-purpose API (they were there in
plplot 2.6 and I left them in).  The way I look at it is: as long as you can
get at the "fat" API in C, someone facing a special need can always code up a
special interface routine for whatever binding they employ.

I also firmly believe that preserving the existing API should be a priority,
except when dealing with relatively newly-added calls for which some period
of flux is to be expected.  People use different versions of plplot on
different machines; you don't want them to be *too* afraid to upgrade.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] plenv() issues

[Maurice L. <mj...@ga...>]

Joao Cardoso writes:
 > On Wednesday 06 November 2002 06:17, Maurice LeBrun wrote:
 > > Alan W. Irwin writes:
 > >  > On Tue, 5 Nov 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
 > >  > > What do you think of this problem? Is there a "cure" that doe=
s not
 > >  > > influence other users?
 > >  >
 > >  > How about define plenv0 which does everything but the page adva=
nce?=20
 > >  > Then define plenv as the combination of pladv and plenv0.
 > >  >
 > >  > I know this adds one more piece of public API that we have to p=
ropagate
 > >  > to all the language interfaces *and* document, but that is pret=
ty
 > >  > straightforward, and we currently have so many variations on ou=
r startup
 > >  > commands (think of all the plstart variations), and our advance=
 page
 > >  > commands, that adding another convenient plenv variation isn't =
that big
 > >  > a deal IMO.
 > >  >
 > >  > Geoffrey and Maurice, is such a solution OK with you?
 > >
 > > Sure.  I've never been completely happy with the behavior of plenv=
 in this
 > > regard either.
 >=20
 > OK, I will work on it soon.
 >=20
 > Do you think that plenv0() should clear the page? I think it should!=


Seems reasonable.  There may be some cases where the user doesn't want =
it
cleared but these are probably rare and not worth API support. =20

Sigh.. I must admit to some dislike of the proliferation of API calls. =
 I
would greatly prefer we handle these kinds of cases through some sort o=
f
option-setting procedure.  E.g. instead of calling plenv0(...), one wou=
ld
do:

plsopt("plenv_advance", "0");
plenv(...)

Then you never need to expand the API (complete with the myriad of lang=
uage
bindings needed), just add a new option.

I've actually implemented such a scheme for my own libraries, twice now=
, once
in Fortran and more recently in iTcl.  Because there are times when you=
 want
the option to be set forever, I'd use plsdopt(...) to set an option
permanently (default); plsopt would only take effect until the next new=
 plot.
That way you could avoid non-local effects.  It works great.

Anyway, I've got no time for any of this right now, so for now we're st=
uck
with the usual addition to the API.

 > As plclear() is not currently working (no driver but the gnome one s=
upports=20
 > it) I will also change it, issuing a solid fill with the background =
color=20
 > when the driver does not support clear.=20

Looks good.

--=20
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (=
RIST)

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

On Thu, 7 Nov 2002, Geoffrey Furnish wrote:

> I think my app does not specifically have to do the Pltcl/Pltk tie-in
> during AppInit.  I don't have other init-time compiled code that needs
> plframe.  So, if we had it so that "package require Pltk" was
> serviceable, then maybe I wouldn't have to mimick pltcl's startup
> code.
>
> I haven't looked at this for a while.  My recollection was that pltcl
> was pretty sophisticated, and it paid to mimick it carefully.  I'm not
> sure we can really recover exactly what we need, using only a package
> based approach.  I hope so, but I would regard that as somewhat
> innovative, starting from where I think we are.  But maybe my memory
> on this paints the beast larger than life.  I'll have to go back and
> look at this, at some point.
>
> Anyway, my point is this.  For sure, apps need to be able to get
> plframe registered in their own custom Tcl_Interp *.  The way I have
> always done this, is to call Pltcl_init/Pltk_init, which requires
> plplot-config --libs to tell all that is required for that to work.
> That requirement could maybe be dropped, if there was a Tcl-level way
> to get plframe installed in the interpreter.  That's the TEA branch
> stuff.  I know its worked for Vince in that context, but I don't think
> we have this full capability on cvs head yet, do we?

I believe we already have the capability that you need. For example, right
now plframe is directly available from wish just like in the tea branch long
ago.  The recipe for setting that up is in
plplot/examples/tk/README.tkdemos.

But regardless of that issue plplot-config definitely needs options for any
user that develops apps that include reference to library symbols for some
of our additional libraries such as libplplottcltk. I have just put a note
to that effect in PROBLEMS so we will deal with this before the release.

Alan

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

Alan W. Irwin writes:
 > On Thu, 7 Nov 2002, Geoffrey Furnish wrote:
 > 
 > > I know people are real hip on splitting all the language bindings out
 > > of libplplot proper, but those language bindings are there because
 > > applications use them.  So if we're going to go this route, then
 > > plplot-config needs to keep pace, and I guess, grow options so it can
 > > spit out all the binding-specific drivel that has to be done just
 > > right.
 > 
 > I have already answered you privately, but I made mistakes in my response so
 > please forget it.
 > 
 > First, I just checked and plplot-config has been kept up to date with the
 > linking simplification that occurred in July, and I don't think much has
 > changed since.
 > 
 > Secondly, I cannot confirm your problem with plplot-config.  

Hmm.  I've blown away that config by now, so I can't check without
redoing it all, but I'm thinking now that it is possible that I may
have used the wrong plplot-config.  I thought I was doing it right at
the time, but maybe I biffed this part of it.  So, don't sweat that
unless I write back to confirm.

 > Would you please confirm that you can build the installed examples on your
 > system with the latest PLplot cvs and tcl-8.3?

Not today, but I'll do this exercise again and let you know.

 > If that is the case, then the obvious next question is what are you doing
 > differently for your own toolchain so that plplot-config does not work for
 > that specific case? One possibility is your toolchain may *directly* refer
 > to tcl/tk symbols.  If that is the case then you have to link those
 > libraries in, independently of plplot-config.  I am sorry if that is the
 > case. However, remember the function of plplot-config is to link in the
 > libplplot library.  

Right.  My app does do that, but I wasn't blaming plplot-config for
not (any longer) including -ltk and all that.  I completely agree,
plplot-config --libs is only there to tell you how to link PLplot, so
the behavior you describe is correct.

 > It does that job well, and that is all most applications
 > (e.g., plrender, x??c) need.  Recall that with the current linking scheme,
 > linking to the tcl/tk libraries is necessary only for the drivers that
 > explicitly reference tcl/tk symbols (e.g., tkd_drv.so) and for the
 > libplplottcltk library.  The present scheme does that linking automatically
 > when you you build those drivers or the libplplottcltk library.  Even pltcl
 > and plserver don't refer to tcl/tk symbols directly so their linking only
 > involves the libplplottcltk library.
 > 
 > Another possibility is your toolchain refers to symbols in libplplottcltk.

Yes, that's me.  By building a PLplot-enhanced Tcl shell, I am
effectively a glorified pltcl or plserver.  So my app calls
Pltcl_init, Pltk_init, etc.

 > Currently, we don't have an option for that case in plplot-config because it
 > is not needed in the install, but we should develop such an option as a
 > convenience for our users. Volunteers?

Anyone building a PLplot-enhanced Tcl shell, will need this.  I think
this is what triggered my first email on this point, although I'll
still try to run the experiment again at some point, and confirm.

I think my app does not specifically have to do the Pltcl/Pltk tie-in
during AppInit.  I don't have other init-time compiled code that needs
plframe.  So, if we had it so that "package require Pltk" was
serviceable, then maybe I wouldn't have to mimick pltcl's startup
code.

I haven't looked at this for a while.  My recollection was that pltcl
was pretty sophisticated, and it paid to mimick it carefully.  I'm not
sure we can really recover exactly what we need, using only a package
based approach.  I hope so, but I would regard that as somewhat
innovative, starting from where I think we are.  But maybe my memory
on this paints the beast larger than life.  I'll have to go back and
look at this, at some point.

Anyway, my point is this.  For sure, apps need to be able to get
plframe registered in their own custom Tcl_Interp *.  The way I have
always done this, is to call Pltcl_init/Pltk_init, which requires
plplot-config --libs to tell all that is required for that to work.
That requirement could maybe be dropped, if there was a Tcl-level way
to get plframe installed in the interpreter.  That's the TEA branch
stuff.  I know its worked for Vince in that context, but I don't think
we have this full capability on cvs head yet, do we?

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

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

On Thu, 7 Nov 2002, Geoffrey Furnish wrote:

> I know people are real hip on splitting all the language bindings out
> of libplplot proper, but those language bindings are there because
> applications use them.  So if we're going to go this route, then
> plplot-config needs to keep pace, and I guess, grow options so it can
> spit out all the binding-specific drivel that has to be done just
> right.

I have already answered you privately, but I made mistakes in my response so
please forget it.

First, I just checked and plplot-config has been kept up to date with the
linking simplification that occurred in July, and I don't think much has
changed since.

Secondly, I cannot confirm your problem with plplot-config.  For example,
plrender and all the x??c examples are linking well for me now using it.
This happens automatically if you build the installed examples, see
Makedemo.

Would you please confirm that you can build the installed examples on your
system with the latest PLplot cvs and tcl-8.3?

If that is the case, then the obvious next question is what are you doing
differently for your own toolchain so that plplot-config does not work for
that specific case? One possibility is your toolchain may *directly* refer
to tcl/tk symbols.  If that is the case then you have to link those
libraries in, independently of plplot-config.  I am sorry if that is the
case. However, remember the function of plplot-config is to link in the
libplplot library.  It does that job well, and that is all most applications
(e.g., plrender, x??c) need.  Recall that with the current linking scheme,
linking to the tcl/tk libraries is necessary only for the drivers that
explicitly reference tcl/tk symbols (e.g., tkd_drv.so) and for the
libplplottcltk library.  The present scheme does that linking automatically
when you you build those drivers or the libplplottcltk library.  Even pltcl
and plserver don't refer to tcl/tk symbols directly so their linking only
involves the libplplottcltk library.

Another possibility is your toolchain refers to symbols in libplplottcltk.
Currently, we don't have an option for that case in plplot-config because it
is not needed in the install, but we should develop such an option as a
convenience for our users. Volunteers?

Alan

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

Geoffrey Furnish writes:
 > Grrrr.  I was able, with lots of recompiling the universe, to get as
 > far as stepping through plserver, to find that the source of the
 > trouble is that the call to Itcl_Init in tkMain.c, fails, which causes
 > plserver to exit straight away.
 > 
 > I cannot see why this fails.  But for whatever reason, Itcl 3.2.1,
 > appears to be incompatible with Tcl 8.4.1.  

Well, I don't understand what could've caused this change, but the
bottom line is that you have to set ITCL_LIBRARY to
$prefix/lib/itcl3.2, and similarly for ITK_LIBRARY, in order for
plserver to run. Setting these environment variables is not necessary
when using itcl3.2.1 over tcl/tk 8.3.x.  Bizarre.  With that, plserver
works fine.

But I face more impediments to using plplot cvs head in my day job.
plplot-config --libs no longer reports something that works.  

I know people are real hip on splitting all the language bindings out
of libplplot proper, but those language bindings are there because
applications use them.  So if we're going to go this route, then
plplot-config needs to keep pace, and I guess, grow options so it can
spit out all the binding-specific drivel that has to be done just
right. 

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

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

[Vince D. <vi...@sa...>]

>>
Vince, you reported success with Tcl/Tk 8.4.1.  Was that with
Itcl/Itk, or not?  If so, what itcl are you using?  There has been no
Itcl release since the release of Tcl/Tk 8.4.1.
>>

I've only used itcl/itk via "package require" (and indeed, only use Plplot
via that route as well), so I'm not sure what the Itcl issue is. (Also on
Windows only at present).

sorry not to be more helpful,

-- Vince

<http://www.santafe.edu/~vince>

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

On Thu, 7 Nov 2002, Geoffrey Furnish wrote:

> Geoffrey Furnish writes:
>  > I'll try to make a detailed post tomorrow on what I'm having trouble
>  > with.
>
> Okay.  Here's the deal.  cvs head static driver builds are busted.
> Everybody seems to have known that but I had forgotten.
>
> Using --enable-dyndrivers, I can get a build, but only if I have
> LD_LIBRARY_PATH set to .:$prefix.  I don't think we should leave it
> like that.  Specification of correct -rpaths can alleviate that, and
> we should eventuall fix the build system to supply them in all the
> right places.  I ordinarily in my professional development activities,
> do not ever need to set LD_L_P.

Some time ago I complained bitterly that the java interface to PLplot
requires setting LD_LIBRARY_PATH.  Despite much reading of java manuals we
couldn't find any way to wiggle out of it.  Since I always routinely include
java in my PLplot builds, I also routinely set LD_LIBRARY_PATH. Like
you, I would prefer not to set LD_LIBRARY_PATH at all, but I would be a lot
more sensitive to the issue for non-java parts of PLplot, if we could find a
solution for the java part.

**I need some clarification from you**.  Do you get good results for tcl-8.3
with LD_LIBRARY_PATH set? If so, then that settles my principal concern that
we were getting different results.

It sounds from your other preliminary results that there will be some
substantial effort required to get PLplot to work with later versions of
tcl/tk on Linux.  I am glad you are working on that.  Although, tcl-8.3 is
the version used in my current distribution (Debian stable), I notice
tcl-8.4 is already in Debian testing, and I assume it is the version of
choice (or soon will be the version of choice) for other distributions as
well.

Alan

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

Geoffrey Furnish writes:
 > But, the Tk driver only works if I build against an old Tcl/Tk.  cvs
 > head's Tk driver does not work when built against Tcl/Tk 8.4.1.  If
 > you type x01c, tk, it just hangs.  If you try to run plserver
 > directly, it exits immediately with error code 1.
 > [...]
 > With cvs head built against Tcl/Tk 8.3.3, ./plserver pops up a top
 > level and gives you a prompt.
 > 
 > So, something is wrong with that.  

Grrrr.  I was able, with lots of recompiling the universe, to get as
far as stepping through plserver, to find that the source of the
trouble is that the call to Itcl_Init in tkMain.c, fails, which causes
plserver to exit straight away.

I cannot see why this fails.  But for whatever reason, Itcl 3.2.1,
appears to be incompatible with Tcl 8.4.1.  I tried to debug inside
the Itcl_Init call, but alas, the itcl 3.2.1 configure script emits a
bogus makefile if you configure --enable-symbols, and so you can't
build a debuggable itcl 3.2.1.  I guess one could hack the makefile
after configuring, but I'm getting winded after all this skulldugery. 

Vince, you reported success with Tcl/Tk 8.4.1.  Was that with
Itcl/Itk, or not?  If so, what itcl are you using?  There has been no
Itcl release since the release of Tcl/Tk 8.4.1.

I should add, if you build Itcl/Itk 3.2.1 against Tcl/Tk 8.4.1, you
/can/ get an itk wish, just by going into tclsh and saying package
require Itk.  So that works fine.  But the tkMain.c call to Itcl_Init,
fails, but it worked with itcl 3.2.1 built against Tcl/Tk 8.3.x.

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

Re: [Plplot-devel] Autotools (AT)

[Rafael L. <lab...@ps...>]

[Sorry for this belated reply.]

* Alan W. Irwin <ir...@be...> [2002-10-31 17:58]:

> Today I started my effort on what we used to call the automake/libtools
> project (AM/LT), but I will call it autotools (AT) for short since autoconf
> is involved as well.

I named it AM/LT because autoconf was already used in the PLplot project.

> These 3 tools are collectively called autotools in an excellent on-line
> book I just discovered entitled "Gnu Autoconf, Automake, and Libtool". (I
> am not sure whether Rafael referred to this book before, but I found it
> with a google search for libtool tutorial.) 

I probably did.  If not, I should have done.  And yes, it is a excellent
reference.

> The book's website is at http://sources.redhat.com/autobook/ where you can
> get access to the on-line version (with all errata applied), a download
> version, or the publisher's page where you could buy the print edition.

Or just "apt-get install autobook" in Debian.

> I have already read the first 4 introductory chapters in detail, and now
> that I am beginning to get into the hard part, I think I will try to follow
> along with our already existing AT approach for building the documentation
> in plplot/doc/docbook.  Once I thoroughly understand what was done there,
> then I may be able to understand what Rafael attempted to do on the AM-LT
> branch.

Unfortunately, what I did is not really documented in the sources.  However,
you might come back to my messages to plplot-devel between April and May
last year, when I actively worked on the project.  This is at least what I
will do if/when I resume my work.

> So obviously I am still very much just getting started with learning about
> AT, but at least that start has been made.

Good luck.  I am sure you are not loosing your time.

-- 
Rafael

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

Geoffrey Furnish writes:
 > I'll try to make a detailed post tomorrow on what I'm having trouble
 > with.

Okay.  Here's the deal.  cvs head static driver builds are busted.
Everybody seems to have known that but I had forgotten.

Using --enable-dyndrivers, I can get a build, but only if I have
LD_LIBRARY_PATH set to .:$prefix.  I don't think we should leave it
like that.  Specification of correct -rpaths can alleviate that, and
we should eventuall fix the build system to supply them in all the
right places.  I ordinarily in my professional development activities,
do not ever need to set LD_L_P.

But, the Tk driver only works if I build against an old Tcl/Tk.  cvs
head's Tk driver does not work when built against Tcl/Tk 8.4.1.  If
you type x01c, tk, it just hangs.  If you try to run plserver
directly, it exits immediately with error code 1.

[furnish@xiphi tmp]$ ldd plserver
        libplplottcltk.so.5 =>
/home/furnish/devel/tcl/841/plplot/tmp/libplplottcltk.so.5
(0x40014000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        libtcl.so.0 => /usr/lib/libtcl.so.0 (0x4004f000)
        libtk.so.0 => /usr/lib/libtk.so.0 (0x400cf000)
        libplplot.so.5 =>
/home/furnish/devel/tcl/841/plplot/tmp/libplplot.so.5 (0x4017b000)
        libtclmatrix.so.5 =>
/home/furnish/devel/tcl/841/plplot/tmp/libtclmatrix.so.5 (0x401ae000)
        libitcl3.2.so =>
/home/furnish/fastflow/tcl-841/lib/libitcl3.2.so (0x401b3000)
        libitk3.2.so =>
/home/furnish/fastflow/tcl-841/lib/libitk3.2.so (0x401cd000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401d7000)
        libdl.so.2 => /lib/libdl.so.2 (0x402ac000)
        libm.so.6 => /lib/i686/libm.so.6 (0x402af000)
        libgcc_s.so.1 => /opt/gcc-3.2/lib/libgcc_s.so.1 (0x402d1000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[furnish@xiphi tmp]$ ./plserver
[furnish@xiphi tmp]$ echo $?
1
[furnish@xiphi tmp]$ 

With cvs head built against Tcl/Tk 8.3.3, ./plserver pops up a top
level and gives you a prompt.

So, something is wrong with that.  

BTW, the build is almost clean when we build against Tcl/Tk 8.3.3, but
there are oodles of warnings in the build against Tcl/Tk 8.4.1.
Evidently they changed some const qualifiers on some of the publi Tcl
API functions.  I don't know if we can solve these interface binding
issues in plplot with casts.  I do know that in one of my C++
projects, it is illegal to make the casts needed, so the Tcl client
code actually has to be changed to support the new const qualifiers on
the Tcl API functions.  Sheesh, this is awfully late in the game for
the Tcl guys to discover const.  Maybe C will be more permissive.
grrr. 

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

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

On Wed, 6 Nov 2002, Geoffrey Furnish wrote:

> I am ambivalent to which is the default, but I do feel strongly that
> sstatic builds should work.

Agreed.  But all in good time for the release.  However, because the current
cvs head works (at least for particular combinations of configuration
options under linux) static drivers are somewhat down the list of my
priorities at the moment.

Here is my "library" issue list prioritized from high to low.

(1) AT (autotools).  This is going to take some time for me to learn plus
some time for me to implement.  But once Linux with shared libraries and
dynamic drivers works with AT to everybody's satisfaction, then the changes
to make static drivers work, static libraries work, and to support other
Unix platforms should be quite straightforward compared to the current
configuration system.

(2) I think some more work simplifying libplplottcltk may be in order. If I
recall correctly, Joao mentioned some modules that were simply used for one
executable so he advocated keeping those *.o files outside of any library
and simply linking them on the command line.  I don't know whether that is a
bad or good idea, but it needs more discussion.  I am looking for a
volunteer to implement it if the consensus is this is a good idea.  This
can be done with the present shared library, dyn driver system or it can
wait until after AT.

(3) Separate out the language interface stuff (e.g., java, fortran) that
currently is is mixed in with the plotting API in libplplot.  Again I need a
volunteer, and this can be done before or after AT.

For production use before the next release, 5.1.0 is quite capable, and CVS
HEAD does work under Linux (I hope to prove that tomorrow for
Geoffrey....;-)).  Thus, I have felt fairly relaxed about not being able to
contribute much in the last two months to make some progress on the above
library issues.  And I realize the rest of you are under time constraints as
well.  But the goal before the next release is library linking that works
much better than any previous release.  I think we are already pretty much
there on Linux for the specific case of shared libraries and dynamic
devices.  But to add all the bells and whistles like static devices or
libraries and to make it work cross platform is going to take quite an
additional effort.  We will get there sooner or later depending on how many
volunteers help, and at that point we will release.

Alan

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > On Wed, 6 Nov 2002, Geoffrey Furnish wrote:
 >  > > I cannot configure plplot cvs head against a prefix with installations
 >  > > of either Tcl/Tk 8.4.1, or for that matter, Tcl/Tk 8.3.4, and have the
 >  > > build complete successfully.  Looking at the link lines that fail, it
 >  > > is clear that libraries are being dropped, which contain needed
 >  > > symbols.
 >  > 
 >  > Library dropping is unlikely to be the cause of your problem.  As far as I
 >  > know the present linking scheme works fine for everybody else using tcl/tk
 >  > on Linux (Maurice, Joao, and me) so long as we use dynamic drivers.  Since I
 >  > cannot confirm your problem, we need to get together off list to make more
 >  > exact comparisons, and in fact I have just initiated that process.
 > 
 > I think it may be due to not including --enable-dyndrivers, which is required
 > at present.  Hmm.. mayhaps a change to the configure default is warranted?
 > I mean, if the default doesn't build.. that doesn't make sense.

Well, the network demons conspired against me tonight, so I won't be
able to read my work email till tomorrow, where I suppose some of
Alan's response went.  Following up only on this part:

Yes, I did do a static drivers config, and no it won't build, and no
I'm not imagining things, but no I also didn't know that it was known
that it didn't work, although now that you say it, it does ring a
distant bell.

I am ambivalent to which is the default, but I do feel strongly that
sstatic builds should work.

However, I also should say here, that I did a dyndrivers config first,
and that didn't build for me either, also failing during a link.  But
in subsequent consideration, I realized that might have been at least
partially attributable to not having had LD_LIBRARY_PATH set right.  I
had one bug report on the non functioning dyndrivers config composed,
but I deleted it without sending it, after I reran the build with
LD_L_P set.  

I'll try to make a detailed post tomorrow on what I'm having trouble
with.  My problems today were discovered only shortly before I had to
leave work, so I didn't have time for a totally detailed analysis.

I spent some time tonight reviewing the email traffic during my
hibernation.  I'm really amazed at how much cool stuff has been going
on.  Great job everybody.

On the subject of linking and all that, I found some emails from a
couple months back, indicating that it was all still under
discussion.  And the last thing I was working on, was a "struct of
function pointers" abstraction to decouple drivers from libplplot
proper.  I had made some real headway on that, but got distracted
before a commit.  I'll try to resurrect this stuff over the next few
days and get it in.  I really believe this will have a substantial
positive effect on decoupling things in a way that is robust, and
comprehensible. 

More later, cheers,

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

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Wed, 6 Nov 2002, Geoffrey Furnish wrote:
 > 
 > > Vince Darley writes:
 > >  > The tkwin driver works fine for me with 8.4.1.  Beyond that, "isn't
 > >  > working" doesn't shed too much light on your problem ;-)
 > >
 > > I cannot configure plplot cvs head against a prefix with installations
 > > of either Tcl/Tk 8.4.1, or for that matter, Tcl/Tk 8.3.4, and have the
 > > build complete successfully.  Looking at the link lines that fail, it
 > > is clear that libraries are being dropped, which contain needed
 > > symbols.
 > 
 > Library dropping is unlikely to be the cause of your problem.  As far as I
 > know the present linking scheme works fine for everybody else using tcl/tk
 > on Linux (Maurice, Joao, and me) so long as we use dynamic drivers.  Since I
 > cannot confirm your problem, we need to get together off list to make more
 > exact comparisons, and in fact I have just initiated that process.

I think it may be due to not including --enable-dyndrivers, which is required
at present.  Hmm.. mayhaps a change to the configure default is warranted?
I mean, if the default doesn't build.. that doesn't make sense.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

On Wed, 6 Nov 2002, Geoffrey Furnish wrote:

> Vince Darley writes:
>  > The tkwin driver works fine for me with 8.4.1.  Beyond that, "isn't
>  > working" doesn't shed too much light on your problem ;-)
>
> I cannot configure plplot cvs head against a prefix with installations
> of either Tcl/Tk 8.4.1, or for that matter, Tcl/Tk 8.3.4, and have the
> build complete successfully.  Looking at the link lines that fail, it
> is clear that libraries are being dropped, which contain needed
> symbols.

Library dropping is unlikely to be the cause of your problem.  As far as I
know the present linking scheme works fine for everybody else using tcl/tk
on Linux (Maurice, Joao, and me) so long as we use dynamic drivers.  Since I
cannot confirm your problem, we need to get together off list to make more
exact comparisons, and in fact I have just initiated that process.

Alan

Re: [Plplot-devel] plenv() issues

[Joao C. <jc...@fe...>]

On Wednesday 06 November 2002 06:17, Maurice LeBrun wrote:
> Alan W. Irwin writes:
>  > On Tue, 5 Nov 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
>  > > What do you think of this problem? Is there a "cure" that does not
>  > > influence other users?
>  >
>  > How about define plenv0 which does everything but the page advance?=20
>  > Then define plenv as the combination of pladv and plenv0.
>  >
>  > I know this adds one more piece of public API that we have to propag=
ate
>  > to all the language interfaces *and* document, but that is pretty
>  > straightforward, and we currently have so many variations on our sta=
rtup
>  > commands (think of all the plstart variations), and our advance page
>  > commands, that adding another convenient plenv variation isn't that =
big
>  > a deal IMO.
>  >
>  > Geoffrey and Maurice, is such a solution OK with you?
>
> Sure.  I've never been completely happy with the behavior of plenv in t=
his
> regard either.

OK, I will work on it soon.

Do you think that plenv0() should clear the page? I think it should!

As plclear() is not currently working (no driver but the gnome one suppor=
ts=20
it) I will also change it, issuing a solid fill with the background color=
=20
when the driver does not support clear.=20

Joao