plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] tk driver

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

The '-kb' thing appears to have fixed the checkout of the *.fnt files.
Thank you!

I've committed Alan's change to tclAPI.c (5.1.0/tcl instead of
tcl/plplot.tcl) so that should work for both installed and built versions
of pltcl etc.

I'll probably make some more minor changes over the coming weeks to tweak
the tcl<->plplot interactions, but only in a backwards compatible way.

I'd be interested if anyone has any success compiling pltcl with the
'tkwin' driver on Unix.  (makefile modifications will be needed, I assume)

cheers,

-- Vince

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

Re: [Plplot-devel] tk driver

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

On Tue, 2 Jul 2002, Vince Darley wrote:

> .... Also when I check out the two .fnt files they are
> corrupted and cause plplot to abort when trying to use them -- no error
> checking seems to be done! This seems to be because they are checked in as
> ascii, which is not a good thing.  They should use -kb so cvs treats them
> as binary files and doesn't destroy them on checkout to mac/win).

OK.  I sure hate to take responsibility for cvs administration because you
can really screw things up.  However, since Maurice was unavailable I read
up on this using cvs info.

Apparently the thing to do for binary files from a Unix/Linux system (windows
would be different!) is

cd plplot/lib
cvs admin -kb *.fnt

followed by

cvs update -A *.fnt

I have no understanding of why this is supposed to work, but that is what
I did.  The files are the same for me according to cksum.

Vince, please let me know whether this sorts out the problem for you.

Alan

Re: [Plplot-devel] tk driver

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

Alan W. Irwin writes:
 > Maurice, do you know how to make the administrative cvs changes to fix the
 > font file checkout problems?  I understand you are particularly time-pressed
 > at the moment so just let me know what to do, and I will do it (and test
 > the result to make sure it doesn't mess up the Linux/Unix side of things).

There's a cvs/rcs admin option to treat a file as "binary".  Check the man
pages as I forget, and am really low on time, sorry.

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

Re: [Plplot-devel] tk driver

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

On Tue, 2 Jul 2002, Vince Darley wrote:

> On Tue, 2 Jul 2002, Alan W. Irwin wrote:
>
> > application-specific initialization failed: Can't find a usable
> > tcl/plplot.tcl in the following directories:
> >     /usr/plplot5.1/library
> >
> > I have looked at your changes to tclAPI.h, and I believe they should be very
> > close to working for the installed version (in fact I got something similar
> > to this to work on install simply by modifying initScript, but you beat me
> > to check-in, and your solution is more sophisticated in that it is meant to
> > work both on windows and linux).
> >
> > The only question I have is your change to the treatment of libDir.  Is that
> > new treatment somehow limiting the search to just the one directory above
> > for the installed version?  If you go back to the old treatment, I think
> > that the installed version will work on Linux (but of course that might
> > blast the success you now have with plplot/tmp so I leave it to you to
> > figure this out in a general way).
>
> I don't think it should restrict the search to one directory, but it seems
> to be doing just that.  Perhaps your solution is better.  What were you
> going to change 'initScript' to?

I didn't do anything particularly sophisticated.  3 versions ago (i.e., for
version 1.32), this worked
fine for install (but not for built version in plplot/tmp).

static char initScript[] =
"tcl_findLibrary plplot 5.1.0/tcl \"\" plplot.tcl PL_LIBRARY pllibrary";

i.e., I just replaced 5.1 by 5.1.0/tcl for just this line in 1.32.  So I was
essentially just doing what you are now doing with initScriptExtended, and I
therefore think your current approach should work fine except for some
additional changes you made to libDir.  Here is the diff I am talking about
between version 1.32 and version 1.35.  I may have it wrong, but I think I
understand the initScriptExtended stuff so by elimination I think it is the
changed libDir stuff that is causing the trouble.

Alan

*******************
Index: tclAPI.c
===================================================================
RCS file: /cvsroot/plplot/plplot/bindings/tcl/tclAPI.c,v
retrieving revision 1.32
retrieving revision 1.35
diff -u -3 -p -r1.32 -r1.35
--- tclAPI.c	2 Jul 2002 11:30:36 -0000	1.32
+++ tclAPI.c	2 Jul 2002 16:44:25 -0000	1.35
@@ -1,4 +1,4 @@
-/* $Id: tclAPI.c,v 1.32 2002/07/02 11:30:36 vincentdarley Exp $
+/* $Id: tclAPI.c,v 1.35 2002/07/02 16:44:25 vincentdarley Exp $

     Copyright 1994, 1995
     Maurice LeBrun			mj...@di...
@@ -313,6 +313,15 @@ loopbackCmd(ClientData clientData, Tcl_I
 static char defaultLibraryDir[200] = PL_LIBRARY;
 extern char* plplotLibDir;

+#if (!defined(MAC_TCL) && !defined(__WIN32__))
+/*
+ * Use an extended search for installations on Unix where we
+ * have very likely installed plplot so that plplot.tcl is
+ * in  /usr/local/plplot/lib/plplot5.1.0/tcl
+ */
+#define PLPLOT_EXTENDED_SEARCH
+#endif
+
 /*
  * PlbasicInit
  *
@@ -326,7 +335,11 @@ PlbasicInit( Tcl_Interp *interp )
 {
     static char initScript[] =
     "tcl_findLibrary plplot 5.1 \"\" plplot.tcl PL_LIBRARY pllibrary";
-    char *libDir;
+#ifdef PLPLOT_EXTENDED_SEARCH
+    static char initScriptExtended[] =
+    "tcl_findLibrary plplot 5.1.0 \"\" tcl/plplot.tcl PL_LIBRARY pllibrary";
+#endif
+    char *libDir = NULL;
 #ifdef USE_TCL_STUBS
     /*
      * We hard-wire 8.1 here, rather than TCL_VERSION, TK_VERSION because
@@ -359,16 +372,48 @@ PlbasicInit( Tcl_Interp *interp )
 #endif

     Tcl_SetVar(interp, "plversion", "5.1", TCL_GLOBAL_ONLY);
-    if(Tcl_Eval(interp, initScript))
+    if (Tcl_Eval(interp, initScript) != TCL_OK) {
+#ifdef PLPLOT_EXTENDED_SEARCH
+	if (Tcl_Eval(interp, initScriptExtended) != TCL_OK) {
+	    /* Last chance, look in '.' */
+	    Tcl_DString ds;
+	    if (Tcl_Access("plplot.tcl", 0) != 0) {
+		return TCL_ERROR;
+	    }
+	    if (Tcl_EvalFile(interp, "plplot.tcl") != TCL_OK) {
+		return TCL_ERROR;
+	    }
+	    /* It is in the current directory */
+	    libDir = Tcl_GetCwd(interp, &ds);
+	    if (libDir == NULL) {
+		return TCL_ERROR;
+	    }
+	    libDir = strdup(libDir);
+	    Tcl_DStringFree(&ds);
+	}
+	/*
+	 * Clear the result so the user isn't confused by an error
+	 * message from the previous failed search
+	 */
+	Tcl_ResetResult(interp);
+#else
 	return TCL_ERROR;
+#endif
+    }

-    libDir = Tcl_GetVar(interp, "pllibrary", TCL_GLOBAL_ONLY);
     if (libDir == NULL) {
-	Tcl_SetVar(interp, "pllibrary", defaultLibraryDir, TCL_GLOBAL_ONLY);
+	libDir = Tcl_GetVar(interp, "pllibrary", TCL_GLOBAL_ONLY);
+	if (libDir == NULL) {
+	    /* I don't believe this path can ever be reached now */
+	    Tcl_SetVar(interp, "pllibrary", defaultLibraryDir, TCL_GLOBAL_ONLY);
+	    libDir = defaultLibraryDir;
+	}
     } else {
-	/* Used by init code in plctrl.c */
-	plplotLibDir = strdup(libDir);
+	Tcl_SetVar(interp, "pllibrary", libDir, TCL_GLOBAL_ONLY);
     }
+
+    /* Used by init code in plctrl.c */
+    plplotLibDir = strdup(libDir);

 #ifdef TCL_DIR
     if (libDir == NULL) {
*******************

Re: [Plplot-devel] tk driver

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

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

> application-specific initialization failed: Can't find a usable
> tcl/plplot.tcl in the following directories:
>     /usr/plplot5.1/library
> 
> I have looked at your changes to tclAPI.h, and I believe they should be very
> close to working for the installed version (in fact I got something similar
> to this to work on install simply by modifying initScript, but you beat me
> to check-in, and your solution is more sophisticated in that it is meant to
> work both on windows and linux).
> 
> The only question I have is your change to the treatment of libDir.  Is that
> new treatment somehow limiting the search to just the one directory above
> for the installed version?  If you go back to the old treatment, I think
> that the installed version will work on Linux (but of course that might
> blast the success you now have with plplot/tmp so I leave it to you to
> figure this out in a general way).

I don't think it should restrict the search to one directory, but it seems
to be doing just that.  Perhaps your solution is better.  What were you
going to change 'initScript' to?

cheers,

Vince.

Re: [Plplot-devel] tk driver

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

On Tue, 2 Jul 2002, Vince Darley wrote:

> I've committed a minor change to tclAPI.c to try to get it to look both in
> '.' (should solve the build test problem) and to look for tcl/plplot.tcl
> (should solve the default install problem).
>
> hope that helps,

That certainly works now in plplot/tmp.

But the installed version still does not work.

Here is the message.

application-specific initialization failed: Can't find a usable
tcl/plplot.tcl in the following directories:
    /usr/plplot5.1/library

I have looked at your changes to tclAPI.h, and I believe they should be very
close to working for the installed version (in fact I got something similar
to this to work on install simply by modifying initScript, but you beat me
to check-in, and your solution is more sophisticated in that it is meant to
work both on windows and linux).

The only question I have is your change to the treatment of libDir.  Is that
new treatment somehow limiting the search to just the one directory above
for the installed version?  If you go back to the old treatment, I think
that the installed version will work on Linux (but of course that might
blast the success you now have with plplot/tmp so I leave it to you to
figure this out in a general way).

Alan

Re: [Plplot-devel] tk driver

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

I've committed a minor change to tclAPI.c to try to get it to look both in
'.' (should solve the build test problem) and to look for tcl/plplot.tcl
(should solve the default install problem).

hope that helps,

-- Vince

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

Re: [Plplot-devel] tk driver

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

On Tue, 2 Jul 2002, Vince Darley wrote:

> >>>
> Under Linux/Unix whatever line-ending style is in cvs is checked out that
> way and not converted and similarly on check-in.  I wasn't sure what
> happened
> on windows, but I noticed in the past that some of the files in the
> windows
> area were a horrible mixture of the two styles so I made the decision to
> convert them to a consistent (windows) style.
>
> I notice on all your many recent check-ins that you are using a Linux line
> ending style.  I really appreciate that for the core parts, but you don't
> need to extend that to sys/win-tk/ if it is an extra burden for you there.
> >>>
>
> No extra burden at all.  In fact it would be a burden (and a bad idea, I
> _think_) to do differently.
>
> All the text files (including all of those ones which you see as '\n')
> have \r\n on my machine, so when I checked everything in, I didn't have to
> do anything special at all, because cvs converted that to \n on the fly.

You are the first on the plplot core team to actually have CVS access from
windows.  (Andrew Roach could never find a CVS client for his DOS system so
he just used the Linux SF client at shell1.sf.net.) so the line-ending results
are most interesting.  I agree, just go ahead with what you are doing now.

>
> The only problems arise because:
>
> (i) processing of files (e.g. by perl) assumes a particular line-ending
> style.  (I would call this a bug in the perl script)
> (ii) files aren't binary when they should be (e.g. lib/*.fnt)
>
> Anyway, these are the lessons I've picked up from developing Tcl, which I
> think should also apply to plplot, but also feel free to ignore them if
> they seem wrong. The most important one is (ii) because plplot will 100%
> guaranteed segfault at the moment, which isn't very helpful!

Agreed.  I don't have the expertise to fix either of these issues, but
hopefully others here will be able to give you some quick help.

Alan

Re: [Plplot-devel] tk driver

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

Vince, I won't be able to test the package you mention below because I don't
have access to a windows machine.

However, I did make a fresh checkout/configure/build, and there were no
obvious problems with your recent round of changes from the Linux
perspective.  I do still have to

setenv PL_LIBRARY .

in the plplot/tmp directory to get the tcl stuff to work there.  I must say
I didn't understand the discussion between Maurice and you on this issue.

I would be perfectly happy to use the above command in the tmp area so long
as the installed version that most of our users will be using does not
require setting an environment variable.

For an installation prefix of /usr/local/plplot the plplot.tcl is installed
in

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

on Linux systems.  However, the *installed version* of pltcl now gives the
following error:

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



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

This error goes away if you

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

BTW, I also tried

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

but the tcl on the end is necessary.

From the above error message pltcl automatically searchs
$prefix/lib/plplot5.1 now.  Vince, how can that be changed to
$prefix/lib/plplot5.1.0/tcl, instead so setting the environment variable
is not necessary on the installed version.

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

> Note: If desired I can upload a simple binary .zip archive of a package
> which should be loadable into a standard Tk interpreter (i.e. drop
> unzipped directory into your Tcl tree on any windows machine, ....

Re: [Plplot-devel] tk driver

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

>>>
Under Linux/Unix whatever line-ending style is in cvs is checked out that
way and not converted and similarly on check-in.  I wasn't sure what
happened
on windows, but I noticed in the past that some of the files in the
windows
area were a horrible mixture of the two styles so I made the decision to
convert them to a consistent (windows) style.

I notice on all your many recent check-ins that you are using a Linux line
ending style.  I really appreciate that for the core parts, but you don't
need to extend that to sys/win-tk/ if it is an extra burden for you there.
>>>

No extra burden at all.  In fact it would be a burden (and a bad idea, I
_think_) to do differently.

All the text files (including all of those ones which you see as '\n')
have \r\n on my machine, so when I checked everything in, I didn't have to
do anything special at all, because cvs converted that to \n on the fly.

The only problems arise because:

(i) processing of files (e.g. by perl) assumes a particular line-ending
style.  (I would call this a bug in the perl script)
(ii) files aren't binary when they should be (e.g. lib/*.fnt)

Anyway, these are the lessons I've picked up from developing Tcl, which I
think should also apply to plplot, but also feel free to ignore them if
they seem wrong. The most important one is (ii) because plplot will 100%
guaranteed segfault at the moment, which isn't very helpful!

cheers,

-- Vince

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

Re: [Plplot-devel] tk driver

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

On Tue, 2 Jul 2002, Vince Darley wrote:

> >>>
> Note the informal rule on file line endings is Linux/Unix line endings
> "nl"
> everywhere in the tree except the windows specific part of the tree such
> as
> sys/win32/msdev/ where windows line endings "cr nl" should be used.
> >>>
>
> I don't believe this really works like that at all.  All 'cvs' clients I
> know of on Windows will convert line-endings on the fly when you checkout
> unless the file is marked as binary in cvs.  This means all of the cvs
> tree that I checkout uses 'cr nl'.  When committing, cvs compares but
> ignoring line-ending differences.

Under Linux/Unix whatever line-ending style is in cvs is checked out that
way and not converted and similarly on check-in.  I wasn't sure what happened
on windows, but I noticed in the past that some of the files in the windows
area were a horrible mixture of the two styles so I made the decision to
convert them to a consistent (windows) style.

I notice on all your many recent check-ins that you are using a Linux line
ending style.  I really appreciate that for the core parts, but you don't
need to extend that to sys/win-tk/ if it is an extra burden for you there.

>
> (note: this causes a problem because the perl script pltclgen assumes the
> files it is looking at have '\n' lineendings and so fails to generate
> anything useful.  Also when I check out the two .fnt files they are
> corrupted and cause plplot to abort when trying to use them -- no error
> checking seems to be done! This seems to be because they are checked in as
> ascii, which is not a good thing.  They should use -kb so cvs treats them
> as binary files and doesn't destroy them on checkout to mac/win).

Ahhh, the joys of cross-platform development....

The obvious solution to these problems is to find a line ending switch on
your cvs client so it doesn't mess with the files on check-out and check-in.
However, I assume you have looked long and hard for such a switch, and there
isn't one so we will have to find some other solution.

Geoffrey, perl is supposed to work cross-platform so this line ending
situation must have come up again and again.  Is there an easy fix for
this?

Maurice, do you know how to make the administrative cvs changes to fix the
font file checkout problems?  I understand you are particularly time-pressed
at the moment so just let me know what to do, and I will do it (and test
the result to make sure it doesn't mess up the Linux/Unix side of things).

Alan

Re: [Plplot-devel] tk driver

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

Note: If desired I can upload a simple binary .zip archive of a package
which should be loadable into a standard Tk interpreter (i.e. drop
unzipped directory into your Tcl tree on any windows machine, and
'package require Plplotter' will work). However, I don't currently have
appropriate permissions on the plplot project.

You can grab it from

ftp://ftp.ucsd.edu/pub/alpha/tcl/extensions/plplot5.1a.zip

if you'd like to test/upload/whatever.

-- Vince

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

Re: [Plplot-devel] tk driver

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

Vince Darley writes:
 > >>>
 > Setting PL_LIBRARY is the best solution but I think "." should be
 > searched
 > last, as a last-ditch effort to find plplot.tcl.  Just so that you don't
 > ever
 > have to set PL_LIBRARY if all you're doing is building/testing.
 > >>>
 > 
 > Unfortunately, the nice function we're using (tcl_findLibrary) is a
 > standard Tcl library function which doesn't search '.'.  All I can think
 > of that we add a check just before that initScript to check if PL_LIBRARY
 > is set, and if not, then to set it to '.'.

OK, sure.

 > What is 'pltcl' supposed to do, from the build directory, if 'PL_LIBRARY'
 > is set?  Presumably it should use that and ignore what is in '.' anyway.

Right.

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

Re: [Plplot-devel] tk driver

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

>>>
Note the informal rule on file line endings is Linux/Unix line endings
"nl"
everywhere in the tree except the windows specific part of the tree such
as
sys/win32/msdev/ where windows line endings "cr nl" should be used. 
>>>

I don't believe this really works like that at all.  All 'cvs' clients I
know of on Windows will convert line-endings on the fly when you checkout
unless the file is marked as binary in cvs.  This means all of the cvs
tree that I checkout uses 'cr nl'.  When committing, cvs compares but
ignoring line-ending differences.

(note: this causes a problem because the perl script pltclgen assumes the
files it is looking at have '\n' lineendings and so fails to generate
anything useful.  Also when I check out the two .fnt files they are
corrupted and cause plplot to abort when trying to use them -- no error
checking seems to be done! This seems to be because they are checked in as
ascii, which is not a good thing.  They should use -kb so cvs treats them
as binary files and doesn't destroy them on checkout to mac/win).

I've now checked in all my first set of changes.  People with windows
machines and VC++ installed should be able to test (the source code itself
that I have checked in will of course work on win/unix/mac with gcc or
whatever, BUT there is no build system for it at present).

cheers,

Vince.

Re: [Plplot-devel] tk driver

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

>>>
Setting PL_LIBRARY is the best solution but I think "." should be
searched
last, as a last-ditch effort to find plplot.tcl.  Just so that you don't
ever
have to set PL_LIBRARY if all you're doing is building/testing.
>>>

Unfortunately, the nice function we're using (tcl_findLibrary) is a
standard Tcl library function which doesn't search '.'.  All I can think
of that we add a check just before that initScript to check if PL_LIBRARY
is set, and if not, then to set it to '.'.  Either that, or running
'pltcl' from the build directory should simply require you to set
PL_LIBRARY to . first.  (You can even add make targets to do that).

What is 'pltcl' supposed to do, from the build directory, if 'PL_LIBRARY'
is set?  Presumably it should use that and ignore what is in '.' anyway.

I'm in the middle of committing the other parts of the first set of
changes, in small pieces.

cheers,

-- Vince

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

Re: [Plplot-devel] tk driver

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

Alan W. Irwin writes:
 > On Mon, 1 Jul 2002, Maurice LeBrun wrote:
 > 
 > > Alan W. Irwin writes:
 > >  > On Mon, 1 Jul 2002, Vince Darley wrote:
 > >  >
 > >  > > PL_LIBRARY is the environment variable you can set (see tclAPI.c:
 > >  > >     static char initScript[] =
 > >  > >     "tcl_findLibrary plplot 5.1 \"\" plplot.tcl PL_LIBRARY pllibrary";
 > >  > > ).  Alternatively the 'pllibrary' Tcl variable can be set.
 > >  > >
 > >  >
 > >  > OK.
 > >  >
 > >  > setenv PL_LIBRARY .
 > >  >
 > >  > made everything work fine in plplot/tmp.  You will probably have to set that
 > >  > environment variable to something else for the installed version to work on
 > >  > Linux if you use a non-standard prefix.
 > >
 > > I don't like this at all.  Why isn't the current directory being searched?
 > 
 > I agree it is slightly inconvenient for users to set an environment variable
 > so this should ultimately be fixed.
 > 
 > What specifically do you suggest?  I was tempted to put a "." in the list
 > that Vince mentioned above, but I wasn't sure that was the right syntax to
 > use or even if tcl experts such as yourself really did want the local
 > directory always searched for this file or if so, in what order? For
 > example, there might be security implications in always automatically
 > searching the current directory first (or at all) since it is a very similar
 > situation to putting "." in your path.  Anyhow, I would appreciate you and
 > Vince thinking about all this and making the final decision.

Setting PL_LIBRARY is the best solution but I think "." should be searched
last, as a last-ditch effort to find plplot.tcl.  Just so that you don't ever
have to set PL_LIBRARY if all you're doing is building/testing.

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

[Plplot-devel] New python plplot "user-friendly" API completed.

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

I have just completed my work on plplot.py which implements the
user-friendly plplot python module, and this should complete my python work
for a while.  This user-friendly plplot module is identical to the "raw"
plplotc python extension module built using swig-1.3 except that the
argument lists for plcont, plshades, and plshade are allowed some additional
useful variations and simplifications beyond the vanilla argument lists
provided by plplotc. Note this API is much more extensive than the prior
"user-friendly" API for plcont, plshade, and plshades that was implemented
with the old plmodule.c approach.  Presumably, there are also corner cases
which now act differently than before for these 3 functions.

The user-friendly module works well with xw09.py, xw15.py, and xw16.py (I
didn't modify xw15.py which already uses a simplified form of plshade, but
xw09.py and xw16.py have been modified to take advantage of some of the
simplifications to plcont and plshades.)

I have also tried the installed version (after making the small but
important fix to copy plplot.py to the python installation directory), and
all python examples work in that case also.

Anyhow, now that everything seems to be working for the examples, I would
appreciate those of you with a python interest to give this user-friendly
module a lot more thorough testing with your own favorite plcont, plshade,
and plshades examples.

Also, a general testing of the new python plplot API is in order with your
favorite python plots which will inevitably test more of the new API than
the examples.

Unless further testing finds some issues, my work on python should be
essentially done for a while.  I would like to thank Gary once again for
creating the new python interface, for the important plotsh3d bug fix in the
PLplot library, and for friendly e-conversations as we sorted out some new
python interface issues.

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] tk driver

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

On Mon, 1 Jul 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > On Mon, 1 Jul 2002, Vince Darley wrote:
>  >
>  > > PL_LIBRARY is the environment variable you can set (see tclAPI.c:
>  > >     static char initScript[] =
>  > >     "tcl_findLibrary plplot 5.1 \"\" plplot.tcl PL_LIBRARY pllibrary";
>  > > ).  Alternatively the 'pllibrary' Tcl variable can be set.
>  > >
>  >
>  > OK.
>  >
>  > setenv PL_LIBRARY .
>  >
>  > made everything work fine in plplot/tmp.  You will probably have to set that
>  > environment variable to something else for the installed version to work on
>  > Linux if you use a non-standard prefix.
>
> I don't like this at all.  Why isn't the current directory being searched?

I agree it is slightly inconvenient for users to set an environment variable
so this should ultimately be fixed.

What specifically do you suggest?  I was tempted to put a "." in the list
that Vince mentioned above, but I wasn't sure that was the right syntax to
use or even if tcl experts such as yourself really did want the local
directory always searched for this file or if so, in what order? For
example, there might be security implications in always automatically
searching the current directory first (or at all) since it is a very similar
situation to putting "." in your path.  Anyhow, I would appreciate you and
Vince thinking about all this and making the final decision.

Until this minor fix is finalized, setting the environment variable should
be okay for testing purposes on CVS.

When you actually try the latest CVS version are there any other concerns
that need to be addressed?

Alan

Re: [Plplot-devel] tk driver

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

Alan W. Irwin writes:
 > On Mon, 1 Jul 2002, Vince Darley wrote:
 > 
 > > PL_LIBRARY is the environment variable you can set (see tclAPI.c:
 > >     static char initScript[] =
 > >     "tcl_findLibrary plplot 5.1 \"\" plplot.tcl PL_LIBRARY pllibrary";
 > > ).  Alternatively the 'pllibrary' Tcl variable can be set.
 > >
 > 
 > OK.
 > 
 > setenv PL_LIBRARY .
 > 
 > made everything work fine in plplot/tmp.  You will probably have to set that
 > environment variable to something else for the installed version to work on
 > Linux if you use a non-standard prefix.

I don't like this at all.  Why isn't the current directory being searched?

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

Re: [Plplot-devel] tk driver

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

On Mon, 1 Jul 2002, Vince Darley wrote:

> PL_LIBRARY is the environment variable you can set (see tclAPI.c:
>     static char initScript[] =
>     "tcl_findLibrary plplot 5.1 \"\" plplot.tcl PL_LIBRARY pllibrary";
> ).  Alternatively the 'pllibrary' Tcl variable can be set.
>

OK.

setenv PL_LIBRARY .

made everything work fine in plplot/tmp.  You will probably have to set that
environment variable to something else for the installed version to work on
Linux if you use a non-standard prefix.  Anyhow, because everything is
working I committed your 11 file changes to CVS.  I am afraid I used one
giant commit with a rather generic commit message for all 11 files because I
didn't follow the details of your changes, but in future to make it easier
for all of us to follow the changes it would be better to have more
fine-grained commit messages appropriate to much smaller groups of files
that were being committed at one time.

Vince, you are a full member of the core developer team for plplot so I
assume you have full access to cvs.  I was glad to help in this case to get
the line-endings right, but I assume you can do that for yourself from now
on.  Therefore I am going to ignore your subsequent patch since you can put
that into cvs yourself.

Note the informal rule on file line endings is Linux/Unix line endings "nl"
everywhere in the tree except the windows specific part of the tree such as
sys/win32/msdev/ where windows line endings "cr nl" should be used.  I
have Linux programmes that change Linux line endings to windows line endings
and I use the tr command to go from windows line endings to Linux line
endings.  Here is the c code for Linux to windows, and I am sure you
can adapt it to go the other way (or use the tr command if that is available
on your system).

#include <stdio.h>
/* copy input to output exactly except for translating \n to \r\n.
 * Thus, this code is a utility for translating a file from unix line
 * termination to windows line termination.
 */

main()
{
   int c;
   int cr = '\r';
   while ((c = getchar()) != EOF)
   {
     if (c == '\n') putchar(cr);
     putchar(c);
   }
}


Happy Canada Day!

Alan

[Plplot-devel] x09c.m problems

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

During the course of running plplot-test.sh *from a completely fresh tree
checked out from cvs* I found the following problem with the octave
interface to plplot.

error: plclabel_param' undefined near line 73 column 3
error: evaluating index expression near line 73, column 3
error: called from ix09c'
error: near line 167 of file
/home/software/plplot_cvs/HEAD/plplot_darley/bindings/octave/demos/x09c.m'

I cannot find plclabel_param defined anywhere in the octave tree.

Joao, this problem has been introduced sometime since 5.1.0 when the
plplot-test.sh script ran fine.  I suspect there is an additional file
you need to commit to cvs to make sure plclabel_param is defined.

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] tk driver

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

Alan,

I've updated the patch with a few changes from some deeper testing today.
When it works for you, I'll also commit the additional files (which won't
affect the existing build, at present).

cheers,

-- Vince

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

Re: [Plplot-devel] tk driver

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

On Mon, 1 Jul 2002, Alan W. Irwin wrote:
> Note, there is a plplot.tcl in the current directory,
> /home/software/plplot_cvs/HEAD/plplot_darley/tmp.
> Vince, what environment variable do I need to set (or what change to source
> files) to put the current directory on the list of directories to be
> searched for plplot.tcl?  Once this is sorted out so I can successfully
> run pltcl, then that will complete my tests, and I intend to commit
> your patch to cvs so others can give it a try.

Thanks for trying this Alan.

PL_LIBRARY is the environment variable you can set (see tclAPI.c:
    static char initScript[] = 
    "tcl_findLibrary plplot 5.1 \"\" plplot.tcl PL_LIBRARY pllibrary";
).  Alternatively the 'pllibrary' Tcl variable can be set.

Basically 'PlbasicInit' needs to be able to find 'plplot.tcl' and source
it.  'tcl_findLibrary' is a standard Tcl command which simplifies this
task.

cheers,

Vince.

Re: [Plplot-devel] tk driver

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

On Mon, 1 Jul 2002, Vince Darley wrote:

> I've uploaded a patch to sourceforge which contains the first set of
> changes needed to cvs head.  Assuming that doesn't break anything, then
> that patch, plus a few new files, will allow a first build of plplot
> against Windows Tk.
>
> I'd appreciate it if someone could check whether that patch breaks
> anything (note: the patch has windows eols (\r\n) so care is needed to
> apply it correctly on Unix).

The line endings problem was easily fixed using the

tr -d '\r' <file.in >file.out

command.

Once that change was made, the patch applied cleanly, and plplot was
configured and built without errors and similarly for

make cdemos fdemos cxxdemos tkdemos

Furthermore, all my tk interactive tests worked fine (and I liked the page
control you now have for the tkdemos.tcl demos).

However, pltcl no longer works.

./pltcl -dev xwin
application-specific initialization failed: Can't find a usable plplot.tcl
in the following directories:
    /usr/lib/plplot5.1
/home/software/plplot_cvs/HEAD/plplot_darley/lib/plplot5.1
/home/software/plplot_cvs/HEAD/lib/plplot5.1
/home/software/plplot_cvs/HEAD/plplot_darley/library
/home/software/plplot_cvs/HEAD/library
/home/software/plplot_cvs/HEAD/plplot5.1/library
/home/software/plplot_cvs/plplot5.1/library



This probably means that plplot wasn't installed properly.

This is undoubtedly a configuration issue.  The point is that stuff built in
plplot_darley/tmp should just work without installation so long as you stay
in that directory.  (Once plplot is installed, that should work as well with
whatever install location prefix is used, but I haven't gotten that far,
yet.)

Note, there is a plplot.tcl in the current directory,
/home/software/plplot_cvs/HEAD/plplot_darley/tmp.
Vince, what environment variable do I need to set (or what change to source
files) to put the current directory on the list of directories to be
searched for plplot.tcl?  Once this is sorted out so I can successfully
run pltcl, then that will complete my tests, and I intend to commit
your patch to cvs so others can give it a try.

Alan

Re: [Plplot-devel] tk driver

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

On Fri, 28 Jun 2002, Geoffrey Furnish wrote:
> Vince Darley writes:
>  > Can the current plplot be compiled as one or more Tcl extensions on Unix?
>  > (i.e. so 'package require plplot' does something useful in a standard Tk
>  > shell)?  If so, then at least integrating the first two items below should
>  > be relatively easy.
> No one has done TEA yet (on the main branch), if that's what you're
> asking.

That's not exactly what I was asking, but I think you've answered the
question anyway.  There are many parts to TEA: a particular way of
building, the use of Tcl/Tk's 'stubs' tables, etc.

> The details are foggy in my brain at this point.  I remember looking
> in some detail at the TEA branch a year or so ago, and being concerned
> about some aspect of how the TEA branch interacted with device
> selection.  I remember there was discussion about it at the time, and
> I remember being personally convinced that a better solution was
> possible, but by now it has been so long since the discussion that I
> cannot remember the details of the problem or of the discussed
> solutions.  

I must say I don't remember anything about device selection, but this was
a long time ago...

> I have some TEA work ahead of me in my day job, so it is possible that
> I will become engrossed in the whole thing sometime this summer/fall,
> but it hasn't percolated to "top priority" quite yet.
> 
> BTW, you are welcome to selectively integrate things from your list
> below, into the main branch yourself, if you wish.  IMHO, part of the
> problem with the TEA branch is that too much happened on it.
> Reviewing the changes between TEA and main, is too big a task.  If
> the first two items depend on the TEA integration, perhaps you could
> just take the bottom three, and move that out of the TEA branch and
> into main (assuming they are suitably mature for production use by the
> wide world of PLplot folk).

I've uploaded a patch to sourceforge which contains the first set of
changes needed to cvs head.  Assuming that doesn't break anything, then
that patch, plus a few new files, will allow a first build of plplot
against Windows Tk.

I'd appreciate it if someone could check whether that patch breaks
anything (note: the patch has windows eols (\r\n) so care is needed to
apply it correctly on Unix).

> I'm a big fan of named branches, for focused work.  But if the TEA
> branch has roughly 5 major tasks all within it, I think that results,
> on a purely human level, in an impediment to getting it merged.
> Especially if the merge is left to others than the developer(s) on the
> branch.  It seems to me that perhaps some of this could've been done
> directly on main, or that perhaps a few named branches, each with more
> limited scope, could've been employed.

It really has two major tasks in it: new build technique, and addition of
support for Tk cross platform.  In my mind the latter is far more
important than the former.

cheers,

Vince.