plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

On Saturday 20 July 2002 00:40, Alan W. Irwin wrote:
=2E..
|
| I believe this new linking scheme should work for all modern Linux
| dynamic loaders.

This doesn't mean that others unices will be forgeted, does it?

|  (Just for the record, my dynamic loader
| /lib/ld-2.2.5.so from Debian woody is part of the libc6-2.2.5
| package.) However, if I recall correctly there was some evidence in
| the past that Joao's older patched SuSe distribution had different
| linking requirements.  So Joao and others, please test the latest CVS
| on your various Linux distributions starting from a fresh checkout
| from CVS.

As I told before, suse-7.2 don't have tkInt.h and other tkInt.h=20
dependent header files.
Copying those from the source tarball to /usr=09/include enables the=20
compilation of the tkwin driver, but not running it in plplot tmp dir:

[jcard@feup] ./x01c -dev tkwin
Plplot library version: 5.1.0
No tk plframe widget to connect to

[jcard@feup] ldd x01c
        libplplotd.so.5 =3D> /home/jcard/plplot-devel/tmp/libplplotd.so.5=
=20
        libtclmatrixd.so.5 =3D>=20
/home/jcard/plplot-devel/tmp/libtclmatrixd.so.5
        libpltcld.so.5 =3D> /home/jcard/plplot-devel/tmp/libpltcld.so.5=20
        libplplot_xwin_driverd.so =3D>=20
/home/jcard/plplot-devel/tmp/libplplot_xwin_driverd.so
        libplplot_tkwin_driverd.so =3D>=20
/home/jcard/plplot-devel/tmp/libplplot_tkwin_driverd.so
        libdl.so.2 =3D> /lib/libdl.so.2 (0x403d9000)
=2E..

Trying to follow the the tkwin receipt gives:

[jcard@feup] wish
% load libplplotd.so.5.1.0 Plplotter
couldn't load file "libplplotd.so.5.1.0": libplplotd.so.5.1.0: cannot=20
open shared object file: No such file or directory

% load libplplotd.so Plplotter
couldn't find procedure Plplotter_Init

It seems that some path is missing.
Coull you please send an updated receipt? I'm afraid that I have not=20
fully following the tkwin thread.

Also,=20
[jcard@feup] ./x01c -dev tk
Plplot library version: 5.1.0

gives the following error message in a tk window:
   Invalid command name "plw::create"
       while executing
   "plw::create .x01c tk"
       ("after" script)

This also appeared in some messages in the list, but I can't see how to=20
solve it.

Finally, the libplplot_tkwin_driverd.so and libplplot_xwin_driverd.so:=20
what are they for?
I think that they are there to help the unix loader to find the=20
xxx_drv.so files, but it does not look a clean approach to the=20
problem... perhaps the drivers that know that they will need another=20
driver should ldopen() them themselfs? E.g., if tkwin knows that it=20
needs the xwin driver, than at plD_init_tkwin() it should dlopen=20
drivers/xwind_drv.so?

Joao

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

Alan W. Irwin writes:
 > I don't have the problem here.
 > 
 > I am confused by your result since libplplot has no references (I believe,
 > although perhaps I am missing something here?) to libgd when dynamic drivers
 > are enabled.  Instead, the gd driver (which itself is linked to libgd et al)
 > is dlopened at run time.
 > 
 > Did you forget to configure --enable-dyndrivers?  The current CVS won't work
 > without it although I intend to address that issue once any problems with
 > the --enable-dyndrivers case are sorted out.

I was commenting on the disable-dyndrivers case.  Everything else seems ok so
far.

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

I don't have the problem here.

I am confused by your result since libplplot has no references (I believe,
although perhaps I am missing something here?) to libgd when dynamic drivers
are enabled.  Instead, the gd driver (which itself is linked to libgd et al)
is dlopened at run time.

Did you forget to configure --enable-dyndrivers?  The current CVS won't work
without it although I intend to address that issue once any problems with
the --enable-dyndrivers case are 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
__________________________

On Tue, 23 Jul 2002, Maurice LeBrun wrote:

> At least one problem so far.  If enable_png or enable_jpeg are set, nothing
> links because the -lgd flag is nowhere to be found.  Here's my output:
>
> cd shared; \
> gcc -shared -fPIC -o ../libplplot.so.5.1.0 \
>         -Wl,-soname -Wl,libplplot.so.5 \
>         pdfutils.o plargs.o plbox.o plbuf.o plcont.o plcore.o plctrl.o plcvt.o pldtik.o plfill.o plhist.o plline.o plmap.o plot3d.o plpage.o plsdef.o plshade.o plsym.o pltick.o plvpor.o plwind.o plstripc.o plimage.o plmeta.o null.o gd.o ps.o tk.o pbm.o pstex.o    -L.. -ltclmatrix -lpltcl
> ln -sf libplplot.so.5.1.0 libplplot.so.5
> ln -sf libplplot.so.5 libplplot.so
>
> gcc -g   plrender.o -L. -lplplot -o plrender \
>          -Wl,-rpath -Wl,/home/mjl/dev/plplot/latest/tmp
> ./libplplot.so: undefined reference to `gdImageColorAllocate'
> ./libplplot.so: undefined reference to `gdImageColorDeallocate'
> ./libplplot.so: undefined reference to `gdImageDestroy'
> ./libplplot.so: undefined reference to `gdImageLine'
> ./libplplot.so: undefined reference to `gdImagePng'
> ./libplplot.so: undefined reference to `gdImageJpeg'
> ./libplplot.so: undefined reference to `gdImageCreate'
> ./libplplot.so: undefined reference to `gdImageFilledPolygon'
> collect2: ld returned 1 exit status
> make: *** [plrender] Error 1
>
> and ditto for x01c, etc.  I suppose it's an easy fix but I don't see it.
> Since you did the change maybe you'll find it quicker than I..
>
> Will let you know if any other problems arise.
>
> --
> Maurice LeBrun    mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
>

Re: [Plplot-devel] Are there any other issues before we start more changes?

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

Alan W. Irwin writes:
 > For example, one issue Vince mentioned before was the bindings/tcl/pltclgen
 > perl script did not handle line endings in a proper cross-platform way.  I
 > am still hoping that Maurice or Geoffrey will be able to fix that.

The change I just made *might* do the job, please give it a try.  If not,
there may not be much I can do about it, without access to a test system.

 > Maurice, do any of the many recent changes adversely impact you?  Once you
 > are reasonably satisfied with the present version, I understand there are
 > some more changes that Vince would like to make.

Working on it.

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

Alan W. Irwin writes:
 > I have just committed my changes to split out the pltcl library and I
 > also greatly simplified the linking flags.  The old model for linking flags
 > was to "throw in everything but the kitchen sink until the sucker worked".
 > The new model is to attempt to link just what is required and nothing more.
 > 
 > With the new model, applications only link libplplot (which is quite
 > convenient); libplplot only links libpltcl, the normal list of dynamic
 > drivers, and libg2c (the library required in Linux for fortran); and finally
 > libpltcl links the tcl, itcl, tk, itk, xwin, libtclmatrix, and the special
 > dynamic drivers.
 > 
 > These changes have been tested (my usual interactive and non-interactive
 > tests) in the plplot/tmp location and also in an arbitrary location with the
 > result installed with prefix = /usr/local/plplot.  I used the configure
 > options --with-double --enable-dyndrivers --enable-java --enable-gnome
 > --enable-ntk --enable-tkwin
 > ...
 > I believe the current scheme will work also for --disable-dyndrivers.  The
 > idea there is the special drivers get absorbed into libpltcl and the rest
 > get absorbed into libplplot.  But I haven't tested this at all.

At least one problem so far.  If enable_png or enable_jpeg are set, nothing
links because the -lgd flag is nowhere to be found.  Here's my output:

cd shared; \
gcc -shared -fPIC -o ../libplplot.so.5.1.0 \
        -Wl,-soname -Wl,libplplot.so.5 \
        pdfutils.o plargs.o plbox.o plbuf.o plcont.o plcore.o plctrl.o plcvt.o pldtik.o plfill.o plhist.o plline.o plmap.o plot3d.o plpage.o plsdef.o plshade.o plsym.o pltick.o plvpor.o plwind.o plstripc.o plimage.o plmeta.o null.o gd.o ps.o tk.o pbm.o pstex.o    -L.. -ltclmatrix -lpltcl 
ln -sf libplplot.so.5.1.0 libplplot.so.5
ln -sf libplplot.so.5 libplplot.so

gcc -g   plrender.o -L. -lplplot -o plrender \
         -Wl,-rpath -Wl,/home/mjl/dev/plplot/latest/tmp
./libplplot.so: undefined reference to `gdImageColorAllocate'
./libplplot.so: undefined reference to `gdImageColorDeallocate'
./libplplot.so: undefined reference to `gdImageDestroy'
./libplplot.so: undefined reference to `gdImageLine'
./libplplot.so: undefined reference to `gdImagePng'
./libplplot.so: undefined reference to `gdImageJpeg'
./libplplot.so: undefined reference to `gdImageCreate'
./libplplot.so: undefined reference to `gdImageFilledPolygon'
collect2: ld returned 1 exit status
make: *** [plrender] Error 1

and ditto for x01c, etc.  I suppose it's an easy fix but I don't see it.
Since you did the change maybe you'll find it quicker than I..

Will let you know if any other problems arise.

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

On Sat, 20 Jul 2002, Vince Darley wrote:

> A few thoughts,
>
> On Fri, 19 Jul 2002, Alan W. Irwin wrote:
> > convenient); libplplot only links libpltcl, the normal list of dynamic
>
> This seesm the wrong way around.  Wouldn't libpltcl link to libplplot?

It works now as I have described.  I think what is going on is that the
Linux dynamic loader makes available all symbols of the preceding libraries
in the chain to the linked libraries.  So libpltcl does have symbols it
needs from libplplot, but the dynloader makes those accessible even though
libplplot is linked to libpltcl in the present scheme rather than vice
versa.  So the way I have set it up makes for the most compact link line for
applications.  But you are right it makes no logical sense to humans who
are used to the old static linking, and on that basis it may make sense
to link the other way, and accept a less compact link line which mentions
both libplplot and libpltcl.  Anybody else have thoughts on this issue?

Alan

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

A few thoughts,

On Fri, 19 Jul 2002, Alan W. Irwin wrote:
> convenient); libplplot only links libpltcl, the normal list of dynamic

This seesm the wrong way around.  Wouldn't libpltcl link to libplplot?

> I haven't yet thought much about the static library case.  For Linux
> shouldn't we just drop that altogether?  Alternatively, we could make it a
> non-default configuration item for Linux if there are still some important
> Linux distributions that do not support shared libraries.

It would be nice to still allow someone to compile one executable which
contains everything they need (to pass between machines, etc) rather than
needing a dozen different files.

this new build structure should, I hope, smooth things for integration of
the last parts of what I want to do: enable the 'USE_TCL_STUBS' and
'USE_TK_STUBS' flags.  Doing this effectively removes the linkage between
libpltcl and tcl/tk, so allowing the same libpltcl to be used with any
version of Tcl/Tk since 8.1 without recompilation.  This makes
distributing a binary much more useful!

If you'd like, try turning on those flags and see if the 'load libpltcl
Plplotter' still works.  (I'm pretty sure plrender, pltcl etc would break
with this change as they stand, however, but the 'load' bit might work)

good work!

Vince.

[Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

I have just committed my changes to split out the pltcl library and I
also greatly simplified the linking flags.  The old model for linking flags
was to "throw in everything but the kitchen sink until the sucker worked".
The new model is to attempt to link just what is required and nothing more.

With the new model, applications only link libplplot (which is quite
convenient); libplplot only links libpltcl, the normal list of dynamic
drivers, and libg2c (the library required in Linux for fortran); and finally
libpltcl links the tcl, itcl, tk, itk, xwin, libtclmatrix, and the special
dynamic drivers.

These changes have been tested (my usual interactive and non-interactive
tests) in the plplot/tmp location and also in an arbitrary location with the
result installed with prefix = /usr/local/plplot.  I used the configure
options --with-double --enable-dyndrivers --enable-java --enable-gnome
--enable-ntk --enable-tkwin

I believe this new linking scheme should work for all modern Linux dynamic
loaders.  (Just for the record, my dynamic loader /lib/ld-2.2.5.so from
Debian woody is part of the libc6-2.2.5 package.) However, if I
recall correctly there was some evidence in the past that Joao's older
patched SuSe distribution had different linking requirements.  So Joao and
others, please test the latest CVS on your various Linux distributions
starting from a fresh checkout from CVS.  Note with the new model @LIBS@
(the combination of a zillion different linking flags) is no longer used,
but it is still defined in case we need it to support older dynamic loaders.

Maurice, I think if you followed what I did for libpltcl, you could also
easily split out the fortran interface from libplplot.

And similar remarks to Geoffrey about splitting out the java interface from
libplplot.

Other notes:

I believe the current scheme will work also for --disable-dyndrivers.  The
idea there is the special drivers get absorbed into libpltcl and the rest
get absorbed into libplplot.  But I haven't tested this at all.

I haven't yet thought much about the static library case.  For Linux
shouldn't we just drop that altogether?  Alternatively, we could make it a
non-default configuration item for Linux if there are still some important
Linux distributions that do not support shared libraries.

I haven't thought at all about our other platforms, but I will address that
issue once we are completely satisfied about the linking behaviour on Linux.

So please test the current CVS hard on as wide a variety of Linux platforms
as possible using --enable-dyndrivers.  If you want to try it without that
flag, I would also be interested in the results, but no guarantees it would
work!

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] Are there any other issues before we start more changes?

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

This seems like a good time to consolidate what we have so are there any
issues with the present CVS that anybody would like to see addressed?

For example, one issue Vince mentioned before was the bindings/tcl/pltclgen
perl script did not handle line endings in a proper cross-platform way.  I
am still hoping that Maurice or Geoffrey will be able to fix that.

Vince, let us know if there is anything else on your core PLplot wish list
that would make your life easier.

Maurice, do any of the many recent changes adversely impact you?  Once you
are reasonably satisfied with the present version, I understand there are
some more changes that Vince would like to make.

Also, I do plan to split off all the tk and tcl stuff from libplplot, and
the first commits concerning that change may start happening 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
__________________________

[Plplot-devel] Current CVS passes my tests

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

I just finished my standard extensive tests (both non-interactive and
interactive) from the plplot/tmp location with nothing installed, and also
from an arbitrary location for an installed version of plplot.

Everything works well except for one glitch when using the
installed version from the arbitrary directory /tmp/examples/tk:

./xtk01 -f tk01
(*AppInit) failed: Can't find a usable plplot.tcl in the following
directories:
    /usr/lib/plplot5.1.0/tcl /tmp/examples/lib/plplot5.1.0/tcl
/tmp/lib/plplot5.1.0/tcl /tmp/examples/library /tmp/library
/tmp/plplot5.1.0/tcl/library /plplot5.1.0/tcl/library

etc.

The problem is the xtk?? example C programmes are compiled right in the
arbitary directory and not installed in /usr/local/plplot/bin.  Since
tcl_findLibrary pays attention to the location of the executable it looks in
the wrong places for plplot.tcl.

Note, that if the install $prefix had been /usr rather than
/usr/local/plplot, then the above search by tcl_findLibrary would have
worked.  Furthermore, there is a simple workaround for these particular
interactive examples, when you have a prefix other than /usr, namely,

setenv PL_LIBRARY $prefix/lib/plplot5.1.0/tcl
(or export equivalent in bash)

For real C code following the xtk?? examples, the choices are to install
plplot with a prefix of /usr, install your executables in $prefix/bin or
else set the environment variable.

Are these options OK with everybody?

Maurice, will you give this current CVS version a spin (and perhaps even tag
it so we can get back to it) before Vince makes his next round of changes?

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] recent plwidget.tcl changes break -dev tk again

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

On Wed, 17 Jul 2002, Vince Darley wrote:

> The plwidget stuff should now work again...

Sorry, Vince, but there are still some problems.  There is a missing brace
somewhere in one of your changes. Here are the variety of bad results you
get from that.

I executed

cvs update

in plplot to get all your changes, then ran make
(which gave me a new plrender and tk driver to accompany your *.tcl file
changes).

Afterwards, when I executed

./x01c -dev tk

from plplot/tmp, here is the error message that was generated.

./x01c -dev tk
Plplot library version: 5.1.0
TCL command "plclient_init" failed:
         can't access "plw::create_proc": parent namespace doesn't exist
TCL command "plclient_link_end" failed:
         can't access "plw::end_proc": parent namespace doesn't exist
Program aborted

Another showstopper error I get is

./plserver
% source tkdemos.tcl
missing close-brace: possible unbalanced brace in comment

I then thought perhaps I had better start from a clean start in case there
was some dependency screwup.  It turns out it doesn't build at all from
a clean start.  Here is
the error message.

 Entering directory `/home/software/plplot_cvs/HEAD/plplot_working3/tmp'
missing close-brace: possible unbalanced brace in comment
    while compiling
"proc plw_create {args}"
    invoked from within
"$parser eval $contents"
    (procedure "auto_mkindex_parser::mkindex" line 28)
    invoked from within
"auto_mkindex_parser::mkindex $file"
    (procedure "auto_mkindex" line 25)
    invoked from within
"auto_mkindex . *.tcl *.itcl *.itk *.ith *.itm"
    invoked from within
"if {[catch {package require Itcl}]} {

# Error including Itcl -- only include tcl files
    auto_mkindex . *.tcl

} else {

# Package require succeede..."
    (file "/home/software/plplot_cvs/HEAD/plplot_working3/scripts/mktclIndex" line 14)
make[1]: *** [tclIndex] Error 1
make[1]: Leaving directory `/home/software/plplot_cvs/HEAD/plplot_working3/tmp'
make: *** [all] Error 2

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] I need some cvs advice

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

Alan W. Irwin writes:
 > Note, by chance I had some snapshots lying around that gave me the clues
 > I needed for the debugging.  But I am still quite interested in why
 > 
 > cvs checkout -D '15 days ago' plplot
 > 
 > doesn't give me a clean snapshot for the date specified since it is likely
 > I would like to get date-specified snapshots from CVS in the future.

I'm not really sure, but I've seen something like it before.  The best
explanation I can think of is that some cvs versions don't handle file
deletion correctly.  I had a similar problem in a different cvs repository
some time ago.  There were some very old files in a repository I use that were
in the cvs Attic and clearly removed (from the log entries) but that showed up
on a -D style extraction.  When I looked at the files in the repository, they
showed 'state Exp' instead of "state dead" like they should have.  After
changing the most recent state entry to "dead" like they should have been,
the -D option worked fine.

We really need direct access to the repository. :(

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

Re: [Plplot-devel] New threat to our computer freedom

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

Alan W. Irwin writes:
 > Most all of us on this list buy PC's from time to time so I think this
 > post is appropriate for this list even though it is not related directly
 > to PLplot.
 > 
 > Microsoft and computer manufacturers have gotten together to try once again
 > to limit computer freedom.  The only way to fight it is for people to be
 > educated about the threat so they can assert mass economic pressure (via
 > buying decisions) against the companies involved.
 > 
 > How to get educated?  Well, the 3 links below are a good start.
 > 
 > http://www.pbs.org/cringely/pulpit/pulpit20020627.html
 > http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html
 > http://www.theregus.com/content/4/25378.html

Thanks, Alan, these look interesting.  Only read the first so far, and
although I agree on the negative statements re: M$, I'd have to disagree with
Cringely's assessment that "The End is Near".  I think a more accurate &
productive assessment would be "The Enemy is Engaged".  M$ is finally waking
up to how serious a threat the open source movement is (esp. Linux) and is
moving to counter it.  But M$'s recent moves AFAIAC have all been kind of
stupid in this regard, and this is just another one.  A company that is truly
successful over the long term needs to offer a choice (maybe a compelling
one), but not cause large numbers of people to truly loathe them.  But they
keep doing it, over and over again etc.  Given the strength of the open source
movement, and how difficult it is to combat (especially outside the US), I
think M$ has reached it's zenith.. all downhill from here, Billgatus of Borg.

BTW my household is 100% Linux.  My wife, daughters, and many guests to the
house use it.  Everyone seems very happy with it.  In fact often people don't
know they're running Linux, they just think it's some unfamiliar strain of
windows. :) As for the Windows experts I meet, they are usually interested in
Linux to some degree.

Oh yeah, I'm back. :)

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

[Plplot-devel] recent plwidget.tcl changes break -dev tk again

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

Vince,

Your recent changes to bindings/tk/plwidget.tcl broke -dev tk
again (and perhaps more, I haven't checked).

I notice most of the changes consist of replacing "plw_" with "plw::"
(something to do with namespaces?).  There are lots of "plw_" references in
other files in bindings/tk/ and also in drivers/tk.c.  So I guess there is
still a lot to do to complete the change so that -dev tk (and other tk
stuff?) works again.

Let me know when you are ready for me to test it.

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] installed plserver problems are now fixed

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

On Tue, 16 Jul 2002, Alan W. Irwin wrote:

> BTW, this fix does not solve the remaining similar problem with installed
> -dev tk, but I notice tk.c has the same problem that occurred for tkMain.c;
> tk.c calls Tcl_CreateInterp without a prior call to Tcl_FindExecutable.  At
> that point in the code argv is not available so I have to think a bit about
> the appropriate way to put in the required Tcl_FindExecutable call, but I am
> sure when I do so the -dev tk problem will be fixed.

ntk also does not call Tcl_FindExecutable, but it works fine.  So that is
not the whole story with my -dev tk problems.  However, Tcl_FindExecutable
only works if you have the executable on your path (recall I have not
bothered with that and was using the full file name for the executable). So
I tried putting /usr/local/plplot/bin on my path, and all the -dev tk
problems disappeared without having to fiddle with Tcl_FindExecutable in
tk.c.

I expect most users will have all the plplot executables on their path so
I am going to leave this situation as is.

So as far as I am concerned everything worked at that point both for the
plplot/tmp location and also when installed so that is pretty good
verification that the new way of linking libraries and establishing dynamic
drivers for xwin, tk, and tkwin is fine which was my principal concern.

More comments on your plwidget.tcl changes shortly.

Alan

[Plplot-devel] installed plserver problems are now fixed

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

On Tue, 16 Jul 2002, Vince Darley wrote:

> Ok, I think I might know the problem: plserver's main starts messing with
> Tcl before calling 'Tcl_FindExecutable'.  This is bad (or at least
> potentially bad).
>
> pltclMain has:
>
>     Tcl_FindExecutable(argv[0]);
>     interp = Tcl_CreateInterp();
>
> plserver's 'main' has:
>
>     interp = Tcl_CreateInterp();
>
> so try adding the appropriate call...

Yes, that fixes it!  The installed plserver now works fine, and I have
committed the fixed tkMain.c to CVS.

Thanks very much for getting this straightened out!

BTW, this fix does not solve the remaining similar problem with installed
-dev tk, but I notice tk.c has the same problem that occurred for tkMain.c;
tk.c calls Tcl_CreateInterp without a prior call to Tcl_FindExecutable.  At
that point in the code argv is not available so I have to think a bit about
the appropriate way to put in the required Tcl_FindExecutable call, but I am
sure when I do so the -dev tk problem will be fixed.

Alan

Re: [Plplot-devel] Problems with installed plserver

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

On Tue, 16 Jul 2002, Alan W. Irwin wrote:

> I expect the problem is caused because pltcl is set up correctly to do the
> tcl_findLibrary search and plserver not.

They both should pass through the 'PlbasicInit' command, so both should
have exactly the same init behaviour!  But perhaps I'm missing
something...

plserver calls pltkMain calls AppInit calls Pltk_Init calls PlbasicInit...

> Could you please try similar temporary tclAPI.c coding tricks there so that
> both searches fail, and we can look at the tcl_findLibrary error messages
> from both plserver and pltcl? Are they the same or fundamentally different
> as in the case on Linux?

I don't have plserver or pltcl compiled on my machine.  I've only set up
compilation for the shared library...  It would involve a fair amount of
effort to ensure plserver and pltcl also compiled, which seems rather
unnecessary, sadly.

Vince.

Re: [Plplot-devel] Problems with installed plserver

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

On Tue, 16 Jul 2002, Vince Darley wrote:

> Actually I can't really see what could be going wrong... may have to leave
> this up to Geoff etc to look at.  However I will continue to think.
>
> I the long term it would be much better to get rid of the compiled
> executable that is plserver and replace it with an executable Tcl script
> which simply loads dlls etc.

We'll cross that bridge when we come to it.  But the flip side of this is
that on any time scale less than long term we have to continue to support
plserver and pltcl.

I expect the problem is caused because pltcl is set up correctly to do the
tcl_findLibrary search and plserver not.

Could you please try similar temporary tclAPI.c coding tricks there so that
both searches fail, and we can look at the tcl_findLibrary error messages
from both plserver and pltcl? Are they the same or fundamentally different
as in the case on Linux?

Alan

Re: [Plplot-devel] Problems with installed plserver

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

Actually I can't really see what could be going wrong... may have to leave
this up to Geoff etc to look at.  However I will continue to think.

I the long term it would be much better to get rid of the compiled
executable that is plserver and replace it with an executable Tcl script
which simply loads dlls etc.

-- Vince

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


On Mon, 15 Jul 2002, Alan W. Irwin wrote:

> On Mon, 15 Jul 2002, Alan W. Irwin wrote:
> 
> > Vince,
> >
> > For installed versions of plserver I get the following error now if I
> > attempt to execute it from an arbitrary directory.
> > ********
> > /usr/local/plplot/bin/plserver
> > (*AppInit) failed: Can't find a usable plplot.tcl in the following
> > directories:
> >     /usr/lib/plplot5.1.0/tcl ./lib/plplot5.1.0/tcl ./lib/plplot5.1.0/tcl
> > ./library ./library ./plplot5.1.0/tcl/library ./plplot5.1.0/tcl/library
> >
> >
> >
> > This probably means that plplot wasn't installed properly.
> > ********
> 
> Hello Vince,
> 
> I have done one additional interesting experiment with pltcl.  I forced it
> to *not* work by temporarily changing the /tcl string to /tclx in tclAPI.c.
> Here is the resulting error message:
> 
> /usr/local/plplot/bin/pltcl
> application-specific initialization failed: Can't find a usable plplot.tcl
> in the following directories:
>     /usr/lib/plplot5.1.0/tclx /usr/local/plplot/lib/plplot5.1.0/tclx
> /usr/local/lib/plplot5.1.0/tclx /usr/local/plplot/library /usr/local/library
> /usr/local/plplot5.1.0/tclx/library /usr/plplot5.1.0/tclx/library
> 
> If I change tclx back to tcl, then this works because the required file
> is in  /usr/local/plplot/lib/plplot5.1.0/tcl.
> 
> However, you will note the interesting difference with the previous error
> message. Instead of looking in /usr/local/plplot/lib/plplot5.1.0/tcl like
> pltcl, plserver is looking in ./lib/plplot5.1.0/tcl.  Howcum?  It's
> executing in the /usr/local/plplot tree not the . directory, and one of the
> clues tcl_findLibrary is supposed to use to get the tree prefix is the
> location of the executable.  Also, one error message starts with a different
> header "(*AppInit)" rather than "application-specific initialization failed".
> Is that significant?
> 
> Hope this extra information helps you get this straightened out.
> 
> Alan
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber - The world's fastest growing 
> real-time communications platform! Don't just IM. Build it in! 
> http://www.jabber.com/osdn/xim
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

Re: [Plplot-devel] Problems with installed plserver

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

On Mon, 15 Jul 2002, Alan W. Irwin wrote:

> Vince,
>
> For installed versions of plserver I get the following error now if I
> attempt to execute it from an arbitrary directory.
> ********
> /usr/local/plplot/bin/plserver
> (*AppInit) failed: Can't find a usable plplot.tcl in the following
> directories:
>     /usr/lib/plplot5.1.0/tcl ./lib/plplot5.1.0/tcl ./lib/plplot5.1.0/tcl
> ./library ./library ./plplot5.1.0/tcl/library ./plplot5.1.0/tcl/library
>
>
>
> This probably means that plplot wasn't installed properly.
> ********

Hello Vince,

I have done one additional interesting experiment with pltcl.  I forced it
to *not* work by temporarily changing the /tcl string to /tclx in tclAPI.c.
Here is the resulting error message:

/usr/local/plplot/bin/pltcl
application-specific initialization failed: Can't find a usable plplot.tcl
in the following directories:
    /usr/lib/plplot5.1.0/tclx /usr/local/plplot/lib/plplot5.1.0/tclx
/usr/local/lib/plplot5.1.0/tclx /usr/local/plplot/library /usr/local/library
/usr/local/plplot5.1.0/tclx/library /usr/plplot5.1.0/tclx/library

If I change tclx back to tcl, then this works because the required file
is in  /usr/local/plplot/lib/plplot5.1.0/tcl.

However, you will note the interesting difference with the previous error
message. Instead of looking in /usr/local/plplot/lib/plplot5.1.0/tcl like
pltcl, plserver is looking in ./lib/plplot5.1.0/tcl.  Howcum?  It's
executing in the /usr/local/plplot tree not the . directory, and one of the
clues tcl_findLibrary is supposed to use to get the tree prefix is the
location of the executable.  Also, one error message starts with a different
header "(*AppInit)" rather than "application-specific initialization failed".
Is that significant?

Hope this extra information helps you get this straightened out.

Alan

Re: [Plplot-devel] Problems with installed plserver

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

P.S.  I just reviewed my old messages about this problem, and it turns
out the original problem was for pltcl, and we solved it for that executable.
I just checked, and both ways (local and installed) of running pltcl
still work fine.  But at the time I never tested plserver, and its that
executable that is now giving trouble (but was not giving trouble
on the July 4 snapshot.)

So I think the key question is how come the tcl_findLibrary logic works fine
now for the pltcl case, but not for the plserver case?

Vince, could you please have a look at this question?

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] Problems with installed plserver

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

We did introduce this problem and fix a very similar one.  I don't believe
we ever made Tcl look in the directory your are now asking for, however.
The problematic code is that 'tcl_findLibrary' stuff...

cheers,

-- Vince

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


On Mon, 15 Jul 2002, Alan W. Irwin wrote:

> Vince,
> 
> For installed versions of plserver I get the following error now if I
> attempt to execute it from an arbitrary directory.
> ********
> /usr/local/plplot/bin/plserver
> (*AppInit) failed: Can't find a usable plplot.tcl in the following
> directories:
>     /usr/lib/plplot5.1.0/tcl ./lib/plplot5.1.0/tcl ./lib/plplot5.1.0/tcl
> ./library ./library ./plplot5.1.0/tcl/library ./plplot5.1.0/tcl/library
> 
> 
> 
> This probably means that plplot wasn't installed properly.
> ********
> 
> If I
> 
> setenv PL_LIBRARY /usr/local/plplot/lib/plplot5.1.0/tcl
> 
> the problem disappears.
> 
> I happened to have a plplot version lying around from 4 July, and it does
> not have this problem.
> 
> There has been all sorts of changes in the last 11 days so things are
> blurring together, but didn't you introduce this problem and didn't we
> subsequently sort it out (or one very similar to it) during that time?
> 
> 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
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

[Plplot-devel] New threat to our computer freedom

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

Most all of us on this list buy PC's from time to time so I think this
post is appropriate for this list even though it is not related directly
to PLplot.

Microsoft and computer manufacturers have gotten together to try once again
to limit computer freedom.  The only way to fight it is for people to be
educated about the threat so they can assert mass economic pressure (via
buying decisions) against the companies involved.

How to get educated?  Well, the 3 links below are a good start.

http://www.pbs.org/cringely/pulpit/pulpit20020627.html
http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html
http://www.theregus.com/content/4/25378.html

If you like these links be sure and tell your friends about them 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
__________________________

Re: [Plplot-devel] I need some cvs advice

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

Note, by chance I had some snapshots lying around that gave me the clues
I needed for the debugging.  But I am still quite interested in why

cvs checkout -D '15 days ago' plplot

doesn't give me a clean snapshot for the date specified since it is likely
I would like to get date-specified snapshots from CVS in the future.

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] Problems with installed plserver

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

Vince,

For installed versions of plserver I get the following error now if I
attempt to execute it from an arbitrary directory.
********
/usr/local/plplot/bin/plserver
(*AppInit) failed: Can't find a usable plplot.tcl in the following
directories:
    /usr/lib/plplot5.1.0/tcl ./lib/plplot5.1.0/tcl ./lib/plplot5.1.0/tcl
./library ./library ./plplot5.1.0/tcl/library ./plplot5.1.0/tcl/library



This probably means that plplot wasn't installed properly.
********

If I

setenv PL_LIBRARY /usr/local/plplot/lib/plplot5.1.0/tcl

the problem disappears.

I happened to have a plplot version lying around from 4 July, and it does
not have this problem.

There has been all sorts of changes in the last 11 days so things are
blurring together, but didn't you introduce this problem and didn't we
subsequently sort it out (or one very similar to it) during that time?

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
__________________________