plplot-devel — Technical discussion about PLplot development

[Plplot-devel] I need some cvs advice

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

I am trying to track down a bug by seeing when it first occurred in CVS.

So I naively tried the following:

cvs checkout -D '15 days ago' plplot

The command did get the version from 15 days ago, but in addition grabbed
all the old removed files as well which makes the local tree unusable. For
example, I now have plstream.h in two separate directories and our
configuration uses the bad (removed) version.

The documentation under info cvs implied that cvs kept track of removed
files, so why is the above command putting them into my tree?  Is this a bug
in the CVS server at sourceforge?

Anyhow, if anybody knows how to get a clean snapshot from n days ago (where
I will probably be doing a binary search on n), please let me know.

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
__________________________

[Plplot-devel] Problem solved! (Was: Help needed for dynamic linking problem on linux)

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

On Sun, 14 Jul 2002, Alan W. Irwin wrote:

> ==17017== discard syms in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/drivers/psd_drv.so due to munmap()
> ==17017== discard 0 (0 -> 0) translations in range 0x43ADB000 .. 0x43AE1FFF
> Unable to load driver: psd_drv.so.
> Reason: /usr/local/plplot/lib/plplot5.1.0/data/../drivers/psd_drv.so: cannot open shared object file: No such file or directory


Update: The discard sysm and discard 0 messages are legit, but the reason is
wrong.  What's going on here is ./drivers/psd_drv.so fails in plplot/tmp so
the plcore code tries a second time in the install location which I had
cleaned out so that fails as well with that resulting error message.  If I
simply copy ./drivers/psd_drv.so to the install location, I get the correct
error message:

Unable to load driver: psd_drv.so.
Reason: /usr/local/plplot/lib/plplot5.1.0/data/../drivers/psd_drv.so: undefined symbol: plRotPhy

What's going on is that psd_drv.so has some undefined symbols (presumably
plRotPhy is the first of these to be encountered) from libplplot that cannot
be resolved by the dynamic loader despite the fact that libplplot has
already been dynamically loaded.  My best guess for the cause of this is
that python (and java) use dlopen to load libplplot in the first place, and
they do not use the RTLD_GLOBAL flag which can be ORed with the RTLD_NOW or
RTLD_LAZY options for dlopen.  The point of RTLD_GLOBAL is "the external
symbols defined in the library will be made available to subsequently loaded
libraries" according to the excellent documentation I found at
http://www.tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html.
Presumably, the dynamic loader invoked when libplplot is simply used as a
shared library (i.e., when x??c is invoked) effectively sets this flag so
that libplplot symbols such as plRotPhy can be resolved in psd_drv.so.

So my tentative conclusion is that the dlopen calls in the python extension
interface (and the java equivalent) forgot to OR in RTLD_GLOBAL with their
dlopen flag (since dlopening a library which in turn dlopens another library
depending on the symbols of the first library is a scenario they probably
didn't think about).

Bottom line: gotta work around this problem myself.  The solution which I
have just committed is to have libplplot link to the "special" drivers tk,
xwin, and tkwin and all other "ordinary" drivers link the other way to
plplot.  My spot checks indicated everything works with this solution.

Status: there are still some things to clean up.  For example, I just
committed a bugfix for plplot.h which solves one bug and also now allows (at
least from my preliminary tests) tk to be moved from the special to the
ordinary list.  Also, the install has to be fixed up to deal with the
special dynamic drivers.  But fundamentally, I think I have the dynamic
driver linking problems whipped.

Alan

[Plplot-devel] Help needed for dynamic linking problem on linux

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

For reasons explained in the recent commit messages I have stopped linking
the dynamic drivers to libplplot (although I link libplplot to tk, xwin, and
tkwin).  The resulting C examples work fine, but the resulting python and
java examples do not.  (This is an old issue which we have discussed before
which I am forced to revisit now.) Also, with this change valgrind starting
complaining about the lack of an ".so" on the ends of the dynamic driver
names and then aborted with an internal error.  I got around that problem by
changing all our dynamic driver dll file names so they had a ".so" suffix.

With that change

valgrind --num-callers=50 -v ./x01c -dev psc -o test.ps

worked fine, but

valgrind --num-callers=50 -v python ./test.py -dev psc -o test.ps

did not.  test.py is a modified version of pythondemos.py which
executes just the first example.

Here are the relevant valgrind messages:

==17017== Reading syms from /home/software/plplot_cvs/HEAD/plplot_working3/tmp/drivers/psd_drv.so
==17017==    object doesn't have any debug info
==17017== discard syms in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/drivers/psd_drv.so due to munmap()
==17017== discard 0 (0 -> 0) translations in range 0x43ADB000 .. 0x43AE1FFF
Unable to load driver: psd_drv.so.
Reason: /usr/local/plplot/lib/plplot5.1.0/data/../drivers/psd_drv.so: cannot open shared object file: No such file or directory
==17017==
==17017== Jump to the invalid address stated on the next line
==17017==    at 0x0: ???
==17017==    by 0x43054483: c_plinit (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/libplplotd.so.5.1.0)
==17017==    by 0x4300FBC9: _wrap_plinit (plplotcmodule.c:2636)
==17017==    by 0x8058BFA: (within /usr/bin/python2.1)
==17017==    by 0x8057699: (within /usr/bin/python2.1)
==17017==    by 0x8054DD9: (within /usr/bin/python2.1)
==17017==    by 0x806C933: (within /usr/bin/python2.1)
==17017==    by 0x806C8EA: (within /usr/bin/python2.1)
==17017==    by 0x806C8BE: (within /usr/bin/python2.1)
==17017==    by 0x806BCD1: (within /usr/bin/python2.1)
==17017==    by 0x806B82C: (within /usr/bin/python2.1)
==17017==    by 0x8051EA0: (within /usr/bin/python2.1)
==17017==    by 0x8051954: (within /usr/bin/python2.1)
==17017==    by 0x4029B14F: (within /lib/libc-2.2.5.so)
==17017==    by 0x8051881: (within /usr/bin/python2.1)
==17017==    Address 0x0 is not stack'd, malloc'd or free'd

Anybody got any clue why the syms are being discarded (presumably
by the dynamic loader using munmap) from psd_drv.so above?

If I link psd_drv.so to libplplot, that line and all subsequent error
messages disappear from the valgrind output, psd_drv.so is loaded properly
(presumably since there are no error messages saying anything is wrong about
the load), and test.ps is generated without any further errors.

There is no change in size of drivers/psd_drv.so whether it was linked
to libplplot or not.

I also used nm (with and without --dynamic) on psd_drv.so either linked with
libplplot or not.  There was no change in the number of symbols or their
status flags.  The offsets were changed by small amounts (variable, but
usually 16 bytes) so some internal rearrangement was going on, but the
changes apparently have nothing to do with the number of symbols or their
status flags.

I wouldn't be surprised if this issue (the dynamic loader [presumably]
discarding symbols with munmap when psd_drv.so is not linked with libplplot)
could be resolved by a ld option, but the question is which one?

The other possibility is to resort to some Makefile trickery so that first
libplplot is linked without the link to the tk, xwin, and tkwin dynamic
drivers, then the dynamic drivers are linked to that libplplot, then
libplplot is relinked with the proper links to the tk, xwin, and tkwin
dynamic drivers.  But if there is some other easy way around this problem,
I would prefer to take it.

Thus any help to sort out this problem would be most appreciated.

Current status after recent round of commits.  x??c examples work, and I
also checked that plserver (either tkdemos.tcl or runAllDemos.tcl) works as
well.  python and java examples do not work because of the above problem.

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
__________________________

[Plplot-devel] Status of tk, xwin, and tkwin

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

I have just completed a round of cvs commits that should substantially
improve the Unix configuration control over the tkwin driver.  There are
also some incomplete changes to allow tk, xwin, and tkwin to be dynamic
drivers.  These won't work without hand intervention at the moment
so to avoid them, turn off dynamic drivers.

Note the tkwin driver requires access to functions in plplotter.c. According
to Vince) plplotter.c absolutely depends on internal tcl/tk functions which
are declared in private tcl and tk headers (i.e. tkInt.h which in turn
indirectly includes all sorts of other private headers including tclInt.h).
Thus, to use tkwin, you will have to have access to a tcl/tk tarball or
private build or else your devel packages for tcl/tk must include access to
the internal tcl/tk headers.  The only distribution I am aware of that gives
access to the internal headers is Debian so I have set up the search patch
for tkInt.h and tclInt.h which includes the Debian location.  But if you
have your own special location for those headers, then you will have to
specify the environment variables TKPRIVATEINCDIR and TCLPRIVATEINCDIR
before you run configure in order to get plplotter.c built.

My configuration changes also include allowing the possibility of xwin, tk,
and tkwin to be dynamic drivers.  This should have no effect and everything
should work (including allowing you to play with the tkwin driver to your
heart's content) if you do not enable dynamic drivers.

However, if you do enable dynamic drivers, then the current status is you
will have to hand-link libplplot so that it links to tkd.drv, xwind.drv and
tkwind.drv. After that, everything should just work (yesterday's
breakthrough).

BTW, my style is to cvs commit many small separate changes with a relevant
log message for each rather than one huge commit with a log message that
necessarily must deal only in generalities.  So please bear with this work
in progress!  I plan to put off detailed testing until the end of this
series of changes, but at this stage the static driver builds should be fine
so let me know if you find any problems in that case.

The next item on the agenda is to automate the additional linking required
for the tk, xwin, and tkwin dynamic drivers.  After that, I plan to
implement splitting of the tcl/tk stuff from libplplot into libtclplplot.

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
__________________________

[Plplot-devel] xwin, tk, and tkwin now all work fine as dynamic drivers

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

To get this "historic breakthrough" to work, all you have to do is make the
changes to configure.in and dyndrv.in similar to what I indicated before for
the tkwin case, and link the current libplplot against tkwind.drv,
xwind.drv, and tkwind.drv.

Then x01c worked fine with -dev xwin and -dev tk, plserver and wish
worked fine for runAllDemos.tcl, and plserver worked fine for tkdemos.tcl

I thank Vince for a key sentence in his last email that greatly improved my
understanding of linking and which made this breakthrough possible.

I haven't committed the configure.in and dyndrv.in changes since those
changes require hand intervention on the link step to get everything to work
in plplot/tmp. I am not even sure of how to link libplplot so that
plplot/tmp/drivers/*.drv can be found by the dynamic linker from plplot/tmp
before install and $prefix/lib/plplot5.1.0/drivers/*.drv can be found from
anywhere by the dynamic linker after install.  Probably I will have to fool
around with rpath and soname.  Right now I am using symlinks such as

ln -s drivers/tkd.drv libtkd.so

and the -L option and the -ltkd option (which needs that lib prefix and .so
suffix to work) to get libplplot linked properly.

Anybody got a better idea for the proper way to link a library against 3 of
our dynamic drivers?  Ultimately it will do this for the split-out
libtclplplot, instead, but I might as well get it right for libplplot for
now.

I could definitely use some active help here with sorting out the
configuration issues so please let me know if you are interested in
participating in this work.

But the most important news I have to report here is that tk, xwin, and
tkwin can straightforwardly be made dynamic devices contrary to our previous
conclusions on this issue.

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
__________________________

Re: [Plplot-devel] runAllDemos.tcl background colour issue under wish

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

Thanks, Vince!  Without those checkin's I got a change to grey (but not black)
background.  With those checkin's the problem was solved (i.e. black
background at last!)

Here is the cookbook that results in a black background now:

wish
% source pldefaults.tcl
% load libplplotd.so Plplotter
% package provide Plplotter 5.1.0
% source runAllDemos.tcl

N.B. it is essential that source pldefaults.tcl occurs first in this
sequence. Otherwise, I get the beige background.

From my previous tests the command pldefaults is just not defined at the
time you execute it in plplot.tcl so I changed that (locally) to source
pldefaults.tcl.  However, that gives the beige background result (without
any error messages), and in fact source pldefaults.tcl interactively on the
wish command line as above no longer works if you make that change to
plplot.tcl.  So invoking source pldefaults.tcl from plplot.tcl seems to be
equivalent to invoking it on the wish command line above after the load and
with the same beige result.  So far, the only thing that works is to have
the source before the load with no source pldefaults.tcl afterward (on the
command line or in plplot.tcl).

So I suggest you look carefully at the order in which source pldefaults.tcl
is invoked for plserver, and copy that for the present case (assuming it
works for you as well.)

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, 12 Jul 2002, Vince Darley wrote:

> I've checked in those changes, since they are clear fixes.  We do need to
> work out how to ensure pldefaults is called on your machine, but that
> shouldn't be too hard.
>
> -- Vince
>
> <http://www.santafe.edu/~vince>
>
>
>
>

Re: [Plplot-devel] tkwin doesn't work as dynamic driver :(

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

On Fri, 12 Jul 2002, Vince Darley wrote:

> Just build a shared library and off you go.

The light dawns....  Before I thought dll's and shared libraries were
structurally different (i.e., compiled with different flags).  However, a
google search on the phrase "linux dll" turned up an article which said they
were the same, and a look at the flags for creating, e.g., the ntk device
dll, ntkd.drv, confirm this.

So I guess the only remaining distinction to make in Linux is whether the
dll is loaded under your code's direct control by a call to dlopen (as
occurs in plcore.c, for example with the device dll's) or whether it is
loaded automatically when your programme is first loaded (or as an indirect
result of calling dlopen for a library that is linked against another
library).

That suggests an easy solution for the problems I was having with making
tkwin a dll.  As an experiment I will link libplplot against tkwind.drv.
I believe that will resolve the symbols that were unresolved before.

If/when that part of the mental model is confirmed, then I will look at
splitting off the tcl/tk stuff (as libtclplplot, say) from libplplot.  This
will mean I will drop the experiment, e.g., libplplot will no longer be
linked against tkwind.drv.  Instead, libtclplplot will be linked against
tkwind.drv and libplplot.  Then applications will only be linked against
libtclplplot in special cases (such as pltcl and plserver) where tcl/tk is
actually being used.  And if the mental model is correct, then simply
loading libtclplplot from wish is all that will be required to automatically
load every dll that will be needed.

Let me know if there are any problems with the revised mental model of
the dynamic linking process.

Assuming there are no such problems I will go ahead with the experiment and
if that works the splitting, and if that also works under Linux I will
commit the results to CVS HEAD so others will be able try it out.

Alan

Re: [Plplot-devel] runAllDemos.tcl background colour issue under wish

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

Actually, looking more closely, this is probably due to a combination of
things in plplot's tcl/tk interaction.  First of all, both plframe.c and
plplotter.c should have:

Tk_SetClass("Plframe")

not

Tk_SetClass("plframe")

and 'pldefaults.tcl' should replace:

	if {[winfo depth .] == 1} {
	    option add *plwin.background		white
	} else {
	    option add *plwin.background		black
	}

with

	if {[winfo depth .] == 1} {
	    option add *Plframe.background		white
	} else {
	    option add *Plframe.background		black
	}

and then, if you ensure pldefaults is called, you should get what you
want.


-- Vince

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

Re: [Plplot-devel] runAllDemos.tcl background colour issue under wish

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

I don't see this problem.  I can see two reasons:

(i) the code is different (#ifdef) or behaves differently (Tk 'issues'
perhaps) on the two platforms.
(ii) you don't seem to be loading 'pldefaults.tcl' (since you got an
error on that before), and that could account for the difference.

To see if (ii) is true, try:

wish
% cd /location/of/pldefaults
% source pldefaults.tcl
% pldefaults

then do what you did before (source runAllDemos.tcl, etc)

If that doesn't resolve the problem, then it is, I believe, (i), but that
is going to be very tricky to solve -- probably have to wait till one of
the experts in Tcl/Tk _and_ unix takes the time to look into it.

cheers,

-- Vince

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


On Fri, 12 Jul 2002, Alan W. Irwin wrote:

> Vince,
> 
> BTW since you made some changes during the night, I have rebuilt plplot from
> scratch.  However, everything works identically (as far as I can see) to
> before including the background colour problem.
> 
> When wish and plserver are first started a tiny GUI comes up that is
> essentially completely blank and beige-coloured in my case.  I think that in
> both cases it is picking up the default GUI background colour from my KDE
> environment.  However, once you source runAllDemos.tcl, then the background
> in the plotting area for plserver is black (just as in the standalone demos)
> while for wish it continues to be beige.  So somehow the plplot default
> background of black is not overriding the wish default background of beige.
> I can send you some ugly (;-)) screenshots of this, but probably the word
> picture is enough.
> 
> You may have the same thing, but may not recognize it if you are starting
> with a default wish background of black.  Start wish with some other default
> background colour to see if plplot can override it.  If you do get a change
> in background colour from when wish starts to when you source
> runAllDemos.tcl, then perhaps the #ifed windows version of the plplot code
> is handling the background colour in a different way?
> 
> 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, 12 Jul 2002, Vince Darley wrote:
> 
> > I haven't noticed this problem, or at least haven't been able to run the
> > demos under plserver anyway to know what they are supposed to look like!
> > Therefore it is going to be very hard for me to track down any problem
> > here without a lot more information...  All my demos have a black
> > background, I think.  Are some supposed not to?
> >
> > This could potentially be a synchronisation issue between the widget's
> > background colour:
> >
> > plframe .p
> > .p cget -bg
> >
> > and the '0' colour used by plplot.  But really I don't know
> >
> > To get further on this you need to describe to me a very simple example
> > and what you expect to see and what you do see.
> >
> > -- Vince
> >
> 
> 

Re: [Plplot-devel] runAllDemos.tcl background colour issue under wish

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

Vince,

BTW since you made some changes during the night, I have rebuilt plplot from
scratch.  However, everything works identically (as far as I can see) to
before including the background colour problem.

When wish and plserver are first started a tiny GUI comes up that is
essentially completely blank and beige-coloured in my case.  I think that in
both cases it is picking up the default GUI background colour from my KDE
environment.  However, once you source runAllDemos.tcl, then the background
in the plotting area for plserver is black (just as in the standalone demos)
while for wish it continues to be beige.  So somehow the plplot default
background of black is not overriding the wish default background of beige.
I can send you some ugly (;-)) screenshots of this, but probably the word
picture is enough.

You may have the same thing, but may not recognize it if you are starting
with a default wish background of black.  Start wish with some other default
background colour to see if plplot can override it.  If you do get a change
in background colour from when wish starts to when you source
runAllDemos.tcl, then perhaps the #ifed windows version of the plplot code
is handling the background colour in a different way?

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, 12 Jul 2002, Vince Darley wrote:

> I haven't noticed this problem, or at least haven't been able to run the
> demos under plserver anyway to know what they are supposed to look like!
> Therefore it is going to be very hard for me to track down any problem
> here without a lot more information...  All my demos have a black
> background, I think.  Are some supposed not to?
>
> This could potentially be a synchronisation issue between the widget's
> background colour:
>
> plframe .p
> .p cget -bg
>
> and the '0' colour used by plplot.  But really I don't know
>
> To get further on this you need to describe to me a very simple example
> and what you expect to see and what you do see.
>
> -- Vince
>

Re: [Plplot-devel] tkwin doesn't work as dynamic driver :(

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

I agree with all the below, except that 'TEA' is misleading.  All TEA is
is a collection fof stuff: a suggested way of building, installing, a
suggested directory structure, code conventions, etc.  None of it is
necessary.

Now that we have built a shared library with all of this, and it works, we
are "done".  Obviously there is cleanup that can happen, but TEA isn't
going to give us anything else (Ok: this isn't quite true, I mentioned
that we should ultimately compile with USE_TCL_STUBS and USE_TK_STUBS so
that we don't care what version of Tcl/Tk we load into, but again that can
wait).

So: to do what you want, you just need to build two separate dlls.  As you
say, there should be a base plplot dll and a separate tk-plplot shared
library with all the tcl-tk related stuff (in the future we might want
several of these, but lets ignore that for the moment).

On Fri, 12 Jul 2002, Alan W. Irwin wrote:
> (a) You would need some tcl/tk mechanism to dlopen that combined dll.  I
> assume that would be where TEA came in.

That will happen automatically.  No tea.

> (b) the dll itself would be linked to libplplot as a shared library so that
> library gets automatically loaded as well.  (At least that is what seems
> to happen for the python plplot extension module which is a dll that calls
> libplplot functions).

Exactly the same for Tcl.

> (c) libplplot has calls to tkwin.o itself which it would dlopen according to
> the dynamic driver mechanism in plcore.c.  Under python this just works, and
> I assume the same would be true under tcl/tk except the dlopen would
> automatically turn into an effective no-op since that dll would have already
> been loaded by the tcl dlopen.

Yup.

> However, IMO a much better idea is to split off everything (not just
> plplotter.o) concerning tcl/tk helper functions from libplplot and put that
> into a dll.  The upside of that for other front ends such as python is it
> makes libplplot substantially smaller.  Also, I think reserving libplplot
> strictly for plotting functions is just good organization that makes
> everything much easier to maintain.  Splitting off the tcl/tk helper
> functions would be a great step in the right direction, and I know Maurice
> intends to split off the fortran stuff as well for similar organizational
> reasons.

Yes!

> There is another less important issue.  It would probably be worthwhile to
> keep the tkwin dll separate just to be in conformity with the way the rest
> of the device dll's are treated.  So with these two changes (a) gets changed
> to

I don't see the need to complicate things this much, but feel free ;-)

> So the next question in my mind is how do you implement (a')?  In analogy
> with the setup.py way of building the python interface dll, should the
> tcl/tk helper function dll (and tkwin dll) be built under TEA control?  If
> so, and given that I collect a list of tcl/tk helper C source files that
> should be compiled and put into the tcl/tk helper dll rather than libplplot,
> what is the cookbook?

You don't need any helper functions at all.  Just build a shared library
and off you go.

cheers,

Vince.

Re: [Plplot-devel] tkwin doesn't work as dynamic driver :(

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

On Fri, 12 Jul 2002, Vince Darley wrote:

> Try putting plplotter.c in the tiny dll with tkwin.c...
>

I think that might work. Here is my best guess at the mental model of the
linking, subject to correction by the experts here.

(a) You would need some tcl/tk mechanism to dlopen that combined dll.  I
assume that would be where TEA came in.

(b) the dll itself would be linked to libplplot as a shared library so that
library gets automatically loaded as well.  (At least that is what seems
to happen for the python plplot extension module which is a dll that calls
libplplot functions).

(c) libplplot has calls to tkwin.o itself which it would dlopen according to
the dynamic driver mechanism in plcore.c.  Under python this just works, and
I assume the same would be true under tcl/tk except the dlopen would
automatically turn into an effective no-op since that dll would have already
been loaded by the tcl dlopen.

(d) libplplot is currently linked against the shared libtclmatrix library.
From our recent experience with "load libplplotd.so Plplotter" under wish
that linking against libtclmatrix is all that is required to make the
libtclmatrix functions available to the tcl examples that were run under
wish with runAllDemos.tcl.

So I think this linking scenario you suggest would work.

However, IMO a much better idea is to split off everything (not just
plplotter.o) concerning tcl/tk helper functions from libplplot and put that
into a dll.  The upside of that for other front ends such as python is it
makes libplplot substantially smaller.  Also, I think reserving libplplot
strictly for plotting functions is just good organization that makes
everything much easier to maintain.  Splitting off the tcl/tk helper
functions would be a great step in the right direction, and I know Maurice
intends to split off the fortran stuff as well for similar organizational
reasons.

There is another less important issue.  It would probably be worthwhile to
keep the tkwin dll separate just to be in conformity with the way the rest
of the device dll's are treated.  So with these two changes (a) gets changed
to

(a') tcl dlopens tcl/tk helper function dll *and* tkwin dll under TEA

and (c) gets changed to

(c') the *tkwin* dll gets dlopened by plcore which would effectively be a
no-op.

Vince (or anybody else here), don't hesitate to comment on list about
refinements of this mental model of the way the linking happens if I was
unclear or got something wrong.  Of course our understanding of what goes on
in (b) and (c') and (d) doesn't really matter (so long as they work) because
those parts are all done automatically.

So the next question in my mind is how do you implement (a')?  In analogy
with the setup.py way of building the python interface dll, should the
tcl/tk helper function dll (and tkwin dll) be built under TEA control?  If
so, and given that I collect a list of tcl/tk helper C source files that
should be compiled and put into the tcl/tk helper dll rather than libplplot,
what is the cookbook?

Alan

Re: [Plplot-devel] runAllDemos.tcl background colour issue under wish

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

I haven't noticed this problem, or at least haven't been able to run the
demos under plserver anyway to know what they are supposed to look like!
Therefore it is going to be very hard for me to track down any problem
here without a lot more information...  All my demos have a black
background, I think.  Are some supposed not to?

This could potentially be a synchronisation issue between the widget's
background colour:

plframe .p
.p cget -bg

and the '0' colour used by plplot.  But really I don't know

To get further on this you need to describe to me a very simple example
and what you expect to see and what you do see.

-- Vince

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


On Thu, 11 Jul 2002, Alan W. Irwin wrote:

> Vince,
> 
> I have noticed when comparing runAllDemos.tcl under plserver and under wish
> that the background colour is not set properly under wish.  I assume this is
> a bug.  With the background so different it is difficult to tell whether the
> other cmap0 and cmap1 colours have a problem or not, but I think (from
> looking closely at examples 12 and 16) that they are probably the same.
> 
> Anyhow, I will have a closer look at this once the background problem is
> sorted out.
> 
> 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
> __________________________
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

Re: [Plplot-devel] tkwin doesn't work as dynamic driver :(

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

Try putting plplotter.c in the tiny dll with tkwin.c...

-- Vince

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


On Thu, 11 Jul 2002, Alan W. Irwin wrote:

> As an experiment I tried the following local changes to turn tkwin into
> a dynamic driver (i.e., a tiny dll that is loaded as needed by the core
> plplot routines):
> 
> cvs diff
> Index: configure.in
> ===================================================================
> RCS file: /cvsroot/plplot/plplot/cf/configure.in,v
> retrieving revision 1.134
> diff -u -3 -p -r1.134 configure.in
> --- configure.in        11 Jul 2002 20:05:52 -0000      1.134
> +++ configure.in        12 Jul 2002 00:47:18 -0000
> @@ -133,12 +133,12 @@ hp7470, hp7580, lj_hpgl, ljiip, imp, xwi
>  # Note specifically which drivers are known to be loadable.  Eventually,
>  # hopefully, every driver will show up on this list.  However, we add them one
>  # at a time since each will have its own peculiarities in the build process
> -# (only ones missing at present: xwin and tk and tkwin).
> +# (only ones missing at present: xwin and tk).
> 
>  define([PL_DYNAMIC_DRIVER_LIST],
>  [plmeta null xterm tek4010 tek4010f tek4107 tek4107f mskermit \
>  conex linuxvga vlt versaterm dg300 png jpeg cgm ps psc xfig ljii \
> -hp7470 hp7580 lj_hpgl ljiip imp pbm gnome pstex ntk])
> +hp7470 hp7580 lj_hpgl ljiip imp pbm gnome pstex ntk tkwin])
> 
>  # We think of a "device" as the output medium.  Could be a machine
>  # style (Tektronix, X11), or a file format (Postscript).
> Index: dyndrv.in
> ===================================================================
> RCS file: /cvsroot/plplot/plplot/cf/dyndrv.in,v
> retrieving revision 1.24
> diff -u -3 -p -r1.24 dyndrv.in
> --- dyndrv.in   9 Jul 2002 19:52:58 -0000       1.24
> +++ dyndrv.in   12 Jul 2002 00:47:18 -0000
> @@ -61,8 +61,8 @@ drivers/impress$(LIB_TAG).drv : shared/i
>  drivers/gnome$(LIB_TAG).drv : shared/gnome$O $(PLLIBS)
>         $(SHLIB_BUILD) $@ $< @GNOMELIBS@ $(driverlibs)
> 
> -#drivers/tkwin$(LIB_TAG).drv : shared/tkwin$O $(PLLIBS)
> -#      $(SHLIB_BUILD) $@ $< @TKLIBS@ $(driverlibs)
> +drivers/tkwin$(LIB_TAG).drv : shared/tkwin$O $(PLLIBS)
> +       $(SHLIB_BUILD) $@ $< @TKLIBS@ $(driverlibs)
> 
>  drivers/ntk$(LIB_TAG).drv : shared/ntk$O $(PLLIBS)
>         $(SHLIB_BUILD) $@ $< @TKLIBS@ $(driverlibs)
> 
> However, these changes do not work (so I won't commit them).
> 
> The problem is that the link step for applications shows undefined symbols:
> 
> make
> gcc -g   plrender.o -L. -lplplotd -ltclmatrixd -o plrender \
>          -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm
> -lg2c -Wl,-rpath -Wl,/home/software/plplot_cvs/HEAD/plplot_working3/tmp
> ./libplplotd.so: undefined reference to PLColor_from_TkColor_Changed'
> ./libplplotd.so: undefined reference to plplot_tkwin_ccmap'
> ./libplplotd.so: undefined reference to plD_dispatch_init_tkwin'
> ./libplplotd.so: undefined reference to plD_open_tkwin'
> ./libplplotd.so: undefined reference to pltkwin_setBGFG'
> collect2: ld returned 1 exit status
> make: *** [plrender] Error 1
> 
> These symbols are referred to by plplotter.c, and putting plplotter.o into
> libplplot is causing the problem.
> 
> My understanding is that similar problems (Tcl/Tk stuff integrated into
> libplplot) keep the tk driver (and therefore xwin) from being dynamic.
> 
> I think it is crazy to have Tcl/Tk stuff (or code from any other front end)
> inside libplplot so I hope we can rationalize this situation.  Of course,
> once the Tcl/Tk front end code is in its own separate library, then the next
> step is to turn that into a dll which could be dynamically loaded into wish
> or tclsh (using the TEA-based approach, I presume). Separating out the
> python front-end stuff into dll's is exactly the python approach we have
> used both with the old and present python interfaces.  That idea works very
> well so I am anxious to see it tried for the Tcl/Tk case, and a side benefit
> I understand is it allows us to convert our remaining static drivers (tk,
> xwin, and tkxwin) optionally into dynamic drivers as well.
> 
> I believe we have concluded previously that a separate Tcl/Tk library and
> ultimately dll was the way to go. I don't have the expertise to do this
> myself, but if somebody is inspired to take responsibility for this change,
> I will certainly cheer from the sidelines, and also I will be more than
> happy to help with the configuration and testing of the result!
> 
> 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
> __________________________
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

[Plplot-devel] tkwin doesn't work as dynamic driver :(

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

As an experiment I tried the following local changes to turn tkwin into
a dynamic driver (i.e., a tiny dll that is loaded as needed by the core
plplot routines):

cvs diff
Index: configure.in
===================================================================
RCS file: /cvsroot/plplot/plplot/cf/configure.in,v
retrieving revision 1.134
diff -u -3 -p -r1.134 configure.in
--- configure.in        11 Jul 2002 20:05:52 -0000      1.134
+++ configure.in        12 Jul 2002 00:47:18 -0000
@@ -133,12 +133,12 @@ hp7470, hp7580, lj_hpgl, ljiip, imp, xwi
 # Note specifically which drivers are known to be loadable.  Eventually,
 # hopefully, every driver will show up on this list.  However, we add them one
 # at a time since each will have its own peculiarities in the build process
-# (only ones missing at present: xwin and tk and tkwin).
+# (only ones missing at present: xwin and tk).

 define([PL_DYNAMIC_DRIVER_LIST],
 [plmeta null xterm tek4010 tek4010f tek4107 tek4107f mskermit \
 conex linuxvga vlt versaterm dg300 png jpeg cgm ps psc xfig ljii \
-hp7470 hp7580 lj_hpgl ljiip imp pbm gnome pstex ntk])
+hp7470 hp7580 lj_hpgl ljiip imp pbm gnome pstex ntk tkwin])

 # We think of a "device" as the output medium.  Could be a machine
 # style (Tektronix, X11), or a file format (Postscript).
Index: dyndrv.in
===================================================================
RCS file: /cvsroot/plplot/plplot/cf/dyndrv.in,v
retrieving revision 1.24
diff -u -3 -p -r1.24 dyndrv.in
--- dyndrv.in   9 Jul 2002 19:52:58 -0000       1.24
+++ dyndrv.in   12 Jul 2002 00:47:18 -0000
@@ -61,8 +61,8 @@ drivers/impress$(LIB_TAG).drv : shared/i
 drivers/gnome$(LIB_TAG).drv : shared/gnome$O $(PLLIBS)
        $(SHLIB_BUILD) $@ $< @GNOMELIBS@ $(driverlibs)

-#drivers/tkwin$(LIB_TAG).drv : shared/tkwin$O $(PLLIBS)
-#      $(SHLIB_BUILD) $@ $< @TKLIBS@ $(driverlibs)
+drivers/tkwin$(LIB_TAG).drv : shared/tkwin$O $(PLLIBS)
+       $(SHLIB_BUILD) $@ $< @TKLIBS@ $(driverlibs)

 drivers/ntk$(LIB_TAG).drv : shared/ntk$O $(PLLIBS)
        $(SHLIB_BUILD) $@ $< @TKLIBS@ $(driverlibs)

However, these changes do not work (so I won't commit them).

The problem is that the link step for applications shows undefined symbols:

make
gcc -g   plrender.o -L. -lplplotd -ltclmatrixd -o plrender \
         -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm
-lg2c -Wl,-rpath -Wl,/home/software/plplot_cvs/HEAD/plplot_working3/tmp
./libplplotd.so: undefined reference to PLColor_from_TkColor_Changed'
./libplplotd.so: undefined reference to plplot_tkwin_ccmap'
./libplplotd.so: undefined reference to plD_dispatch_init_tkwin'
./libplplotd.so: undefined reference to plD_open_tkwin'
./libplplotd.so: undefined reference to pltkwin_setBGFG'
collect2: ld returned 1 exit status
make: *** [plrender] Error 1

These symbols are referred to by plplotter.c, and putting plplotter.o into
libplplot is causing the problem.

My understanding is that similar problems (Tcl/Tk stuff integrated into
libplplot) keep the tk driver (and therefore xwin) from being dynamic.

I think it is crazy to have Tcl/Tk stuff (or code from any other front end)
inside libplplot so I hope we can rationalize this situation.  Of course,
once the Tcl/Tk front end code is in its own separate library, then the next
step is to turn that into a dll which could be dynamically loaded into wish
or tclsh (using the TEA-based approach, I presume). Separating out the
python front-end stuff into dll's is exactly the python approach we have
used both with the old and present python interfaces.  That idea works very
well so I am anxious to see it tried for the Tcl/Tk case, and a side benefit
I understand is it allows us to convert our remaining static drivers (tk,
xwin, and tkxwin) optionally into dynamic drivers as well.

I believe we have concluded previously that a separate Tcl/Tk library and
ultimately dll was the way to go. I don't have the expertise to do this
myself, but if somebody is inspired to take responsibility for this change,
I will certainly cheer from the sidelines, and also I will be more than
happy to help with the configuration and testing of the result!

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
__________________________

[Plplot-devel] runAllDemos.tcl background colour issue under wish

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

Vince,

I have noticed when comparing runAllDemos.tcl under plserver and under wish
that the background colour is not set properly under wish.  I assume this is
a bug.  With the background so different it is difficult to tell whether the
other cmap0 and cmap1 colours have a problem or not, but I think (from
looking closely at examples 12 and 16) that they are probably the same.

Anyhow, I will have a closer look at this once the background problem is
sorted out.

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
__________________________

[Plplot-devel] runAllDemos.tcl had problem for plserver which I just fixed

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

Vince,

Here is the error message I got:

./plserver
% source ../examples/tk/runAllDemos.tcl
Can't open drivers/driversd.db

This sequence of commands used to work fine.

This problem was caused by the cd command in runAllDemos.tcl that you put in
recently.  Once out of the plplot/tmp directory, then ./drivers/driversd.db
(presumably used by some of the plserver boiler plate although in this case
tk is a static device) could no longer be found.  I don't think this would
have been a problem, if I had already installed plplot, but to keep issues
as simple as possible I always clean out the installed version of plplot
before my plplot/tmp testing.

In this case the fix was simple, and I don't think there are any side
effects.  I have just committed a change that replaces the unnecessary cd
command in runAllDemos.tcl.  This works for me for both plserver and wish.
Does it cause any problems for you?

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
__________________________

Re: [Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

Well, that fixed the problem, and everything works fine in the resulting GUI
from plplot/tmp with no error/warning messages at all!

So please commit that change *assuming there is no impact on the tk or ntk
drivers.*  (I held back on that commit because I didn't know the meaning
of catch....)

I have just committed a small configuration tweak that should set up the
r*.tcl symlinks properly for plplot/tmp.

So for the others here who want to try this here is the cookbook:

(1) configure --with-tkwin

(2) In the make step you currently need to hand-configure the appropriate
additional options for the compile step for plplotter.c  On my system the
additional options that work for me are

-I/usr/include/tcl8.3/tk-private/generic/ -DHAVE_LIMITS_H
-I/usr/include/tcl8.3/tcl-private/generic/

Then in plplot/tmp

wish
% load libplplotd.so.5.1.0 Plplotter
% package provide Plplotter 5.1.0
% source runAllDemos.tcl

and enjoy the new GUI.

Thanks Vince for being willing to work with me to shake out all the
showstopper problems with tkwin on linux.  I am especially impressed that it
works directly under wish.  I always thought you needed the TEA-based
approach for that.

The next item on my agenda is to put some rudimentary configuration stuff
in for the extra compile flags that you need.  Then I will look at what
you have to do for the install (probably tomorrow).

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 Thu, 11 Jul 2002, Vince Darley wrote:

> I have one more suggestion.  The error you are getting is because of the
> call to 'pldefaults' in plplot.tcl (whichever version of plplot.tcl is
> being picked up load; I'm not sure if that will be the one in pwd or in
> /usr/..).  Replace the single line with 'pldefaults' with:
>
> catch {pldefaults}
>
> and see if that helps.  At the very least you should not get the same
> error message!
>
> -- Vince
>
> <http://www.santafe.edu/~vince>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

I have one more suggestion.  The error you are getting is because of the
call to 'pldefaults' in plplot.tcl (whichever version of plplot.tcl is
being picked up load; I'm not sure if that will be the one in pwd or in
/usr/..).  Replace the single line with 'pldefaults' with:

catch {pldefaults}

and see if that helps.  At the very least you should not get the same
error message!

-- Vince

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

Re: [Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

On Thu, 11 Jul 2002, Vince Darley wrote:

> It could be that the error message is important, if Tcl aborts the load
> when an error is received.
>
> After 'load' when you do:
>
> % info commands pl*
>
> is 'plframe' listed?

no.

% info commands p*
pwd package proc puts pid pack place
%

BTW, I have done a cvs update to get your latest fixes which do solve the
symlink problem I was having before. But the showstopper is the pl* commands
are not available.

>
> Best approach is probably to do what I described in my following mail and
> install everything where Tcl expects to find it (tcl/lib/plplot5.1.0 or
> whatever), and use 'package require Plplotter'.

I have also read your further messages on this subject.  Nevertheless, I am
leary of jumping that far ahead with the tiny tcl expertise that I have. I
would like to get it working properly in plplot/tmp first, and once we
understand that, then move on to the installation problem.  I don't want
tkwin to be the only driver that doesn't work in plplot/tmp, and also the
final installed location for the plplot library will not be in the tcl tree
(instead it will be located at $prefix/lib/libplplotd.so or
$prefix/lib/libplplot.so) so we will have to deal with that issue in any
case.

>
> Note: there is no 'plinit' command with the tkwin driver -- all plplot
> interaction happens through a plframe widget.

Sorry I picked such a bad example.  But the above info commands results show
no plplot command is available so the load of libplplotd.so is not working
properly from its plplot/tmp location.

I would appreciate it if you tried making the same experiment from windows,
i.e. attempted to load the plplot library (or a copy of it) from the current
directory to get to the root of the problem of why the pl* commands are
not available after the load.

But if you don't want to go further with that, then it is probably time for
me to hand this over to the real tcl/linux experts here. Geoffrey is not
available for several weeks, but I am hoping Maurice is back now.  Maurice,
can you see any reason why the pl* commands are not available after the load
from the current directory?  All the tkwin stuff should build out of the box
now for you except for the hand intervention I described to add the
appropriate -I flags to compile plplotter.c.  Ultimately, I intend to put
in all the configuration necessary so that hand intervention is not required,
but it is good enough for testing purposes for now.

Alan

Re: [Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

On Thu, 11 Jul 2002, Alan W. Irwin wrote:
> Later, we install many of our files including the tk/tcl ones into the
> $prefix/lib/plplot5.1.0 tree.  In my case prefix is /usr/local/plplot so
> that is not compatible with the above result.  But that is a separate issue
> which we will have to sort out eventually.

That shouldn't matter, really, I think.  As long as 

% set auto_path

in wish contains the directory above where you have plplot installed.
i.e. as long as the file 'pkgIndex.tcl' (from tk-x-plat) matches this
pattern:

$dir/*/pkgIndex.tcl

for some $dir in auto_path.

As long as this is true, then 'package require Plplotter' will
automatically find the pkgIndex.tcl and you'll be set.

Vince.

[Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

On Thu, 11 Jul 2002, Alan W. Irwin wrote:
> For now, the question is how to get everything to work in plplot/tmp.

I thought the question was how to get everything to work.

Afterwards we can address how to get it to work in some particular
setup...?

Vince.

[Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

On my current system under wish and after
load libplplotd.so.5.1.0 Plplotter

% file join [file dirname [info library]] plplot5.1.0
/usr/lib/plplot5.1.0

Later, we install many of our files including the tk/tcl ones into the
$prefix/lib/plplot5.1.0 tree.  In my case prefix is /usr/local/plplot so
that is not compatible with the above result.  But that is a separate issue
which we will have to sort out eventually.

For now, the question is how to get everything to work in plplot/tmp. If
wish is looking for stuff in /usr/lib/plplot5.1.0, then it is not going to
find anything.  Like before, I believe it is a question of somehow putting
the current directory "." on the list of directories that it searches.

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 Thu, 11 Jul 2002, Vince Darley wrote:

> What you need to do to make this all seamless now is install everything
> that Plplot wants in a place where Tcl can see it through its normal
> package mechanism.
>
> This means you want to install a bunch of stuff into the directory
> returned by:
>
> wish
> % file join [file dirname [info library]] plplot5.1.0
>
> perhaps /usr/local/tcl/lib/plplot5.1.0 or something like that?
>
> Anyway, the stuff that goes in there is:  (see sys/win-tk/makefile.vc's
> 'install' target for details):
>
> *.map
> *.fnt
> tk/plcolor.tcl
> tk/plplot.tcl
> tk/pldefaults.tcl
> tk/pltools.tcl
> tk/plwidget.tcl
> tk-x-plat/*.tcl
> tk-x-plat/tclIndex
>
> as well as the shared library you have created.
>
> You may also need to edit 'pkgIndex.tcl' so that this stuff:
>
> if {[info exists tcl_platform(debug)]} {
>     set file [file join $dir plplot510d[info sharedlibextension]]
> } else {
>     set file [file join $dir plplot510[info sharedlibextension]]
> }
>
> Assuming you install all of this, then you should just be able to do:
>
> wish
> % package require Plplotter
> 5.1.0
> % plframe .p
> .p
> % pack .p
>
> or simply:
>
> wish runAllDemos.tcl
>
> cheers,
>
> Vince.
>
>
>
>
>
>

Re: [Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

It could be that the error message is important, if Tcl aborts the load
when an error is received.

After 'load' when you do:

% info commands pl*

is 'plframe' listed?

Best approach is probably to do what I described in my following mail and
install everything where Tcl expects to find it (tcl/lib/plplot5.1.0 or
whatever), and use 'package require Plplotter'.

Note: there is no 'plinit' command with the tkwin driver -- all plplot
interaction happens through a plframe widget.

-- Vince

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

[Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

> Ok, that basically means it worked.  Ignore that error and continue with
> the source runAllDemos.tcl...

Here are the symlinks in plplot/tmp
ls -l run*.tcl
lrwxrwxrwx    1 software software       30 Jul 11 10:06 runAllDemos.tcl -> ../examples/tk/runAllDemos.tcl
lrwxrwxrwx    1 software software       35 Jul 11 10:07 runExtendedDemos.tcl -> ../examples/tk/runExtendedDemos.tcl

Here is my wish results from that same directory:

wish
% load libplplotd.so Plplotter
invalid command name "pldefaults"
% package provide Plplotter 5.1.0
% pwd
/home/software/plplot_cvs/HEAD/plplot_working3/tmp
% source runAllDemos.tcl
couldn't change working directory to "./../tcl": no such file or directory

somehow your scripts aren't handling the symlinks correctly so I tried
directly accessing the file:

% pwd
/home/software/plplot_cvs/HEAD/plplot_working3/tmp
% source ../examples/tk/runAllDemos.tcl
invalid command name "plframe"
% pwd
/home/software/plplot_cvs/HEAD/plplot_working3/examples/tcl

So the script in examples/tk was found and it changed the working directory
to examples/tcl, but it cannot seem to find plframe, and presumably that is
why there is still a blank wish gui being displayed.

Note I also tried ? and no command name starting with pl is accessible
including plframe.  So I am beginning to think the first error message:

invalid command name "pldefaults"

is more meaningful than you thought.  My guess is the load command above
is not working at all since no pl* commands are available after that load.
If you don't trust the ? results, I also tried

% plinit
invalid command name "plinit"

and surely that should be accessible after "load libplplotd.so Plplotter"?

I have a strong sense of deja vu.  It's been a couple of years, but didn't
we go through this for my attempts to Linux-test the TEA-based branch?

Alan