Menu
▾
▴
plplot-devel
|
From: Vince D. <vi...@sa...> - 2002-07-04 17:54:19
|
On Thu, 4 Jul 2002, Alan W. Irwin wrote: > ./plserver > source ../examples/tk/runAllDemos.tcl > > is almost entirely working now. Good! > Interestingly, for this environment I get the same first-page skip bug if a > multi-page demo (such as 8) is plotted first. Do you get that for your > non-plserver environment? If not, that will be another clue for Maurice when > he attempts to figure out this long-standing bug. If I understand what you're saying, then no, I don't see that bug. But I'm not 100% sure I know what you mean. > One glitch in runAllDemos.tcl is the page button does > not work. Here is the stack trace delivered by plserver Does hitting 'return' work? > % source ../examples/tk/runExtendedDemos.tcl > invalid command name "Plplotwin" The extended demo won't work. Sorry for the misleading cvs msg. > The other remaining issue I forgot to mention last time was the > bindings/tcl/pltclgen perl script that won't work for you because of > line-ending issues. I assume that should be straightforward since perl has > had to deal with these sorts of issues forever. However, that will probably > take somebody familiar with perl (Geoffrey?) to figure this out. Indeed! > Yes, the compile farm probably didn't have swig at all or swig-1.1 rather > than the required swig-1.3. Of course you could have worked around that by > the --disable-python configure option. The missing tk and tcl headers (which > I assume is what the problem is) on the compile farm are the real > showstoppers. But for unknown reasons SF have a long track record of > excluding essential developer packages from their compile-farm machines. I eventually found the disable-python flag, but there doesn't seem to be any workaround for tcl/tk missing... thanks! Vince. |
|
From: Alan W. I. <ir...@be...> - 2002-07-04 18:49:41
|
On Thu, 4 Jul 2002, Vince Darley wrote: > On Thu, 4 Jul 2002, Alan W. Irwin wrote: > > Interestingly, for this environment I get the same first-page skip bug if a > > multi-page demo (such as 8) is plotted first. Do you get that for your > > non-plserver environment? If not, that will be another clue for Maurice when > > he attempts to figure out this long-standing bug. > > If I understand what you're saying, then no, I don't see that bug. But > I'm not 100% sure I know what you mean. If example 8 (or any other multipage example) is the *first* button you press then the first page of example 8 is skipped and you start with the second page. The remainder of the pages are accessible with CR. If you press example 8 (or any other multi-page example) a *second* time the problem goes away, i.e., the first page is displayed properly and you have access to the rest with CR. Just to be clear here, the exact same symptoms occur for tkdemos.tcl under plserver but not for tcldemos.tcl under pltcl. So the common factor seems to be plserver. > > > One glitch in runAllDemos.tcl is the page button does > > not work. Here is the stack trace delivered by plserver > > Does hitting 'return' work? Yes. Alan |
|
From: Vince D. <vi...@sa...> - 2002-07-05 08:26:11
|
On Thu, 4 Jul 2002, Alan W. Irwin wrote: > If example 8 (or any other multipage example) is the *first* button you > press then the first page of example 8 is skipped and you start with the > second page. The remainder of the pages are accessible with CR. If you > press example 8 (or any other multi-page example) a *second* time the > problem goes away, i.e., the first page is displayed properly and you have > access to the rest with CR. Just to be clear here, the exact same symptoms > occur for tkdemos.tcl under plserver but not for tcldemos.tcl under pltcl. > So the common factor seems to be plserver. Ok, I definitely do not see that problem. This is likely a bug in either xwin.c or plframe.c (neither of which I am using with the new driver setup), or plserver itself. > > > One glitch in runAllDemos.tcl is the page button does > > > not work. Here is the stack trace delivered by plserver > > > > Does hitting 'return' work? > > Yes. Ok, I'll fix that soon. Vince. |
|
From: Geoffrey F. <fu...@ga...> - 2002-08-31 04:42:25
|
Alan W. Irwin writes: > The other remaining issue I forgot to mention last time was the > bindings/tcl/pltclgen perl script that won't work for you because of > line-ending issues. I assume that should be straightforward since perl has > had to deal with these sorts of issues forever. However, that will probably > take somebody familiar with perl (Geoffrey?) to figure this out. I am trying to get caught up after a looooooooooooooong diversion. Has this been fixed, or is it still waiting for me? Frankly, I don't know specifically what to do, and would be hunting at random. I agree that "surely Perl can handle this", but I never use Windows anymore, and have never even once run a perl script on Windows. The reason for my long silence is partly massive overload on my day job, and partly that I have just moved out of Silicon Valley, and relocated to Austin, Tx. Back to the old stomping grounds. Anyway, my computer books (perl included) haven't yet been seen since the move... -- Geoffrey Furnish fu...@ga... |
|
From: Maurice L. <mj...@ga...> - 2002-08-31 14:46:03
|
Geoffrey Furnish writes: > Alan W. Irwin writes: > > The other remaining issue I forgot to mention last time was the > > bindings/tcl/pltclgen perl script that won't work for you because of > > line-ending issues. I assume that should be straightforward since perl has > > had to deal with these sorts of issues forever. However, that will probably > > take somebody familiar with perl (Geoffrey?) to figure this out. > > I am trying to get caught up after a looooooooooooooong diversion. > Has this been fixed, or is it still waiting for me? I put in a fix for this, although haven't heard back whether it does the job or not. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Alan W. I. <ir...@be...> - 2002-07-03 15:02:50
|
Vince,
Sorry for another negative message, but it is part of my job to test your
changes to make sure all the details are right so that we present a polished
product for our next release. I am certainly willing to continue the Linux
testing of your changes, but you might be able to eliminate a lot of these
little problems (and achieve a lot better turnaround than when two of us are
involved) if you tested your changes on a Linux box (which I understand you
have access to) before committing them.
With your latest change I am still getting exactly the same error message
for the installed version:
application-specific initialization failed: Can't find a usable plplot.tcl
in the following directories:
/usr/plplot5.1/library
As I have said before, I believe the problem is one of your libDir changes
below (perhaps even initializing it to NULL?) is severely limiting the
directories that are being searched. For your latest change, I noticed you
switched to the "5.1.0/tcl" style which worked for me in the past, but the
point is no amount of fiddling with initScript or initScriptExtended is
going to work if your libDir changes makes sure those lines are completely
ignored. The error message above shows only one directory is being
searched. That never happened to me before your libDir changes. So I
suspect if you look carefully at everything you did with libDir, you will
find the reason why the directory search is now so limited.
I am going to quote my previous post on this (especially the diff) to help
you get to the bottom of this.
Alan
On Tue, 2 Jul 2002, Alan W. Irwin wrote:
> 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) {
> *******************
>
>
>
> -------------------------------------------------------
> 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
>
|
|
From: Vince D. <vi...@sa...> - 2002-07-03 15:19:31
|
Ok, I think I see the problem. It isn't anything to do with the 'libDir'
changes, but rather to calling tcl_findLibrary twice.
Use this:
if (Tcl_Eval(interp, initScript) != TCL_OK) {
#ifdef PLPLOT_EXTENDED_SEARCH
+ Tcl_UnsetVar(interp, "pllibrary", TCL_GLOBAL_ONLY);
if (Tcl_Eval(interp, initScriptExtended) != TCL_OK) {
(i.e. add the line with '+'), and all should work, I think... I only
rarely have access to a linux box (except perhaps through the sourceforge
compile farm), so it isn't that easy for me to test these things.
cheers,
-- Vince
<http://www.santafe.edu/~vince>
On Wed, 3 Jul 2002, Alan W. Irwin wrote:
> Vince,
>
> Sorry for another negative message, but it is part of my job to test your
> changes to make sure all the details are right so that we present a polished
> product for our next release. I am certainly willing to continue the Linux
> testing of your changes, but you might be able to eliminate a lot of these
> little problems (and achieve a lot better turnaround than when two of us are
> involved) if you tested your changes on a Linux box (which I understand you
> have access to) before committing them.
>
> With your latest change I am still getting exactly the same error message
> for the installed version:
>
> application-specific initialization failed: Can't find a usable plplot.tcl
> in the following directories:
> /usr/plplot5.1/library
>
> As I have said before, I believe the problem is one of your libDir changes
> below (perhaps even initializing it to NULL?) is severely limiting the
> directories that are being searched. For your latest change, I noticed you
> switched to the "5.1.0/tcl" style which worked for me in the past, but the
> point is no amount of fiddling with initScript or initScriptExtended is
> going to work if your libDir changes makes sure those lines are completely
> ignored. The error message above shows only one directory is being
> searched. That never happened to me before your libDir changes. So I
> suspect if you look carefully at everything you did with libDir, you will
> find the reason why the directory search is now so limited.
>
> I am going to quote my previous post on this (especially the diff) to help
> you get to the bottom of this.
>
> Alan
>
> On Tue, 2 Jul 2002, Alan W. Irwin wrote:
>
> > 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) {
> > *******************
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
>
>
|
|
From: Alan W. I. <ir...@be...> - 2002-07-03 16:22:21
|
Great. That one-line fix solved the problem, and I have committed it.
Thanks very much!
Now on to the last issue that arises from this. tclAPI.c has all sorts of
version information scattered throughout it now. The definitive place to
find out about version information is plplot/cf/version.in. On the Linux
side that is turned into PLPLOT_VERSION and automatically propagated to
plConfig.h via the magic of autoconf. I haven't paid attention to what
happens to the version on the windows side, but I think the windows guys
(Olof et al) simply edit plplot/sys/win32/msdev/makefile to change
PLPLOT_VERSION before each release.
PLPLOT_VERSION is already accessible from tclAPI.c via the plplot/plplotP.h
include which in turn includes plConfig.h. Can you parse out the parts
you need to replace 5.1 and 5.1.0 wherever they occur in tclAPI.c? That
would greatly simplify my life at release 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
__________________________
On Wed, 3 Jul 2002, Vince Darley wrote:
> Ok, I think I see the problem. It isn't anything to do with the 'libDir'
> changes, but rather to calling tcl_findLibrary twice.
>
> Use this:
>
> if (Tcl_Eval(interp, initScript) != TCL_OK) {
> #ifdef PLPLOT_EXTENDED_SEARCH
> + Tcl_UnsetVar(interp, "pllibrary", TCL_GLOBAL_ONLY);
> if (Tcl_Eval(interp, initScriptExtended) != TCL_OK) {
>
>
> (i.e. add the line with '+'), and all should work, I think... I only
> rarely have access to a linux box (except perhaps through the sourceforge
> compile farm), so it isn't that easy for me to test these things.
>
> cheers,
>
> -- Vince
>
> <http://www.santafe.edu/~vince>
>
>
> On Wed, 3 Jul 2002, Alan W. Irwin wrote:
>
> > Vince,
> >
> > Sorry for another negative message, but it is part of my job to test your
> > changes to make sure all the details are right so that we present a polished
> > product for our next release. I am certainly willing to continue the Linux
> > testing of your changes, but you might be able to eliminate a lot of these
> > little problems (and achieve a lot better turnaround than when two of us are
> > involved) if you tested your changes on a Linux box (which I understand you
> > have access to) before committing them.
> >
> > With your latest change I am still getting exactly the same error message
> > for the installed version:
> >
> > application-specific initialization failed: Can't find a usable plplot.tcl
> > in the following directories:
> > /usr/plplot5.1/library
> >
> > As I have said before, I believe the problem is one of your libDir changes
> > below (perhaps even initializing it to NULL?) is severely limiting the
> > directories that are being searched. For your latest change, I noticed you
> > switched to the "5.1.0/tcl" style which worked for me in the past, but the
> > point is no amount of fiddling with initScript or initScriptExtended is
> > going to work if your libDir changes makes sure those lines are completely
> > ignored. The error message above shows only one directory is being
> > searched. That never happened to me before your libDir changes. So I
> > suspect if you look carefully at everything you did with libDir, you will
> > find the reason why the directory search is now so limited.
> >
> > I am going to quote my previous post on this (especially the diff) to help
> > you get to the bottom of this.
> >
> > Alan
> >
> > On Tue, 2 Jul 2002, Alan W. Irwin wrote:
> >
> > > 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) {
> > > *******************
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > >
> >
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
|
|
From: Vince D. <vi...@sa...> - 2002-07-03 16:35:31
|
On Wed, 3 Jul 2002, Alan W. Irwin wrote: > PLPLOT_VERSION is already accessible from tclAPI.c via the plplot/plplotP.h > include which in turn includes plConfig.h. Can you parse out the parts > you need to replace 5.1 and 5.1.0 wherever they occur in tclAPI.c? That > would greatly simplify my life at release time. Ideally tclAPI.c needs both "5.1.0" and "5.1". But plConfig.h only provides "5.1.0" (in PLPLOT_VERSION). I don't know how to write a macro to extract the first bit of that string, and I certainly don't know anything about auto_conf. Perhaps best is to change tclAPI.c so that we use "5.1.0" everywhere. I can easily do that, but extracting "5.1" if it is possible, would be nicer... Vince. |
|
From: Alan W. I. <ir...@be...> - 2002-07-03 18:42:55
|
I am not too proficient in C so this took me a while, but I believe the
standard C function strncpy will do what you want. Here is a short example.
#include <stdio.h>
#include "plplot/plplotP.h"
main()
{
char short_version[]="x.x";
strncpy(short_version, PLPLOT_VERSION, 3);
printf("%s\n",PLPLOT_VERSION);
printf("%s\n",short_version);
}
The result of compiling and running this code was a printout of
5.1.0
5.1
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 Wed, 3 Jul 2002, Vince Darley wrote:
> On Wed, 3 Jul 2002, Alan W. Irwin wrote:
> > PLPLOT_VERSION is already accessible from tclAPI.c via the plplot/plplotP.h
> > include which in turn includes plConfig.h. Can you parse out the parts
> > you need to replace 5.1 and 5.1.0 wherever they occur in tclAPI.c? That
> > would greatly simplify my life at release time.
>
> Ideally tclAPI.c needs both "5.1.0" and "5.1". But plConfig.h only
> provides "5.1.0" (in PLPLOT_VERSION). I don't know how to write a macro
> to extract the first bit of that string, and I certainly don't know
> anything about auto_conf. Perhaps best is to change tclAPI.c so that we
> use "5.1.0" everywhere.
>
> I can easily do that, but extracting "5.1" if it is possible, would be
> nicer...
>
> Vince.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
|
|
From: Alan W. I. <ir...@be...> - 2002-07-03 23:58:11
|
Vince, I cannot get runAllDemos.tcl to work under plserver. Here is the error message when I click on demo1. ./plserver % source ../examples/tk/runAllDemos.tcl % plbox: Please set up window first, aborting operation Other demos either give no response at all or assorted error messages. In contrast ./plserver % source ../examples/tk/tkdemos.tcl % 1 % 2 % 3 etc. works well. Is there some change you can make to runAllDemos.tcl so it will work under plserver without compromising what you want to do with it on your own system? Clicking on buttons is a little nicer than typing in numbers.....;-) 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2002-07-04 00:30:53
|
Vince, The page control when running tkdemos.tcl under plserver, e.g., ./plserver source tkdemos.tcl 8 no longer works quite properly. If you start with a multipage demo such as 8, the first page is skipped, and then the rest of the pages of the multipage example are available with page control using CR. The second time you run a multipage demo (or if you run any other demo first) the first page is available and not skipped over. The problem does not occur when you run tcldemos.tcl under pltcl, e.g., ./pltcl -dev tk plinit source tcldemos.tcl 8 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 __________________________ |
|
From: Vince D. <vi...@sa...> - 2002-07-04 07:46:57
|
Hmm, I really don't see that I've modified any file which could have an effect on this demo at all. The 'plframe' and 'xwin' driver is completely untouched... However, I'll take a look. (My code uses a new tkwin driver which won't be used in your build). -- Vince <http://www.santafe.edu/~vince> On Wed, 3 Jul 2002, Alan W. Irwin wrote: > Vince, > > The page control when running tkdemos.tcl under plserver, e.g., > > ./plserver > source tkdemos.tcl > 8 > > no longer works quite properly. > > If you start with a multipage demo such as 8, the first page is skipped, and > then the rest of the pages of the multipage example are available with page > control using CR. The second time you run a multipage demo (or if you run > any other demo first) the first page is available and not skipped over. > > The problem does not occur when you run tcldemos.tcl under pltcl, e.g., > > ./pltcl -dev tk > plinit > source tcldemos.tcl > 8 > > 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 > __________________________ > > > |
|
From: Alan W. I. <ir...@be...> - 2002-07-04 14:49:45
|
On Thu, 4 Jul 2002, Vince Darley wrote: > Hmm, I really don't see that I've modified any file which could have an > effect on this demo at all. The 'plframe' and 'xwin' driver is completely > untouched... However, I'll take a look. (My code uses a new tkwin driver > which won't be used in your build). You are completely correct and my apologies for blaming the bug on your changes. Because of what you said above, I rebuilt a 21 June version of the code (long before any of your recent changes or Gary's), and the tkdemos.tcl page control bug was there. So this bug has been around for a while (and perhaps even before plplot-5.1.0 since my test scripts don't test multipage plots as the first example to be tried under plserver). That leaves two outstanding issues from your recent CVS changes that I am aware of. These are (1) finishing off the version stuff (using strncpy to get the first 3 characters of PLPLOT_VERSION), and (2) getting runAllDemos.tcl to work for both of our environments. Alan |
|
From: Alan W. I. <ir...@be...> - 2002-07-04 00:32:30
|
x19.tcl is looking good, and I have changed both tcldemos.tcl and tkdemos.tcl to run it. It is nice to deliver positive news for a change....;-) 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 __________________________ |
|
From: Vince D. <vi...@sa...> - 2002-07-02 09:46:40
|
>>> 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. |
|
From: Alan W. I. <ir...@be...> - 2002-07-02 15:06:45
|
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 |
|
From: Vince D. <vi...@sa...> - 2002-07-02 15:23:55
|
>>> 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> |
|
From: Alan W. I. <ir...@be...> - 2002-07-02 16:30:34
|
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 |
|
From: Maurice L. <mj...@ga...> - 2002-07-02 23:05:52
|
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) |
|
From: Alan W. I. <ir...@be...> - 2002-07-02 23:45:51
|
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 |
|
From: Vince D. <vi...@sa...> - 2002-07-03 09:09:25
|
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> |
|
From: Alan W. I. <ir...@be...> - 2002-07-05 15:34:58
|
On Wed, 3 Jul 2002, Vince Darley wrote: > I'd be interested if anyone has any success compiling pltcl with the > 'tkwin' driver on Unix. (makefile modifications will be needed, I assume). What is the difference between this driver, and say the tk one? I might even be interested in doing the configuration changes that would be required to get this driver to work under Linux simply as an alternative testbed to its normal windows environment. However, is there any other Linux motivation beyond that? Would we be able to run a wider variety of demos or a different style of demos? Also, on the other side of the coin would this driver require TEA to be working? Alan |
|
From: Vince D. <vi...@sa...> - 2002-07-05 16:12:17
|
On Fri, 5 Jul 2002, Alan W. Irwin wrote: > What is the difference between this driver, and say the tk one? I might > even be interested in doing the configuration changes that would be required > to get this driver to work under Linux simply as an alternative testbed to > its normal windows environment. However, is there any other Linux > motivation beyond that? Would we be able to run a wider variety of demos or > a different style of demos? Also, on the other side of the coin would this > driver require TEA to be working? On Unix the tkwin driver is, indeed, very similar to the tk one (since it is derived directly from it). Main differences are: (i) some bug fixes (particularly in initialisation, creation and destruction under a variety of circumstances). (ii) if you compile with 'USE_TCL_STUBS' and 'USE_TK_STUBS' defined, then the shared library you produce can be loaded into _any_ tk interpreter from 8.1 onwards (no recompilation necessary). (iii) you can then use the extended 'Plplotwin' widget (in bindings/tk-x-plat) which is quite nice. (iv) in principle 'plserver' and executables like that can be replaced by a simple script which is invoked by an ordinary 'wish' interpreter. (i.e. you don't need to compile a whole bunch of different executables for each different platform). However this bit would require a tcl script called 'plserver' which mimics plserver to be written. Depending on your usage, none of the above may be compelling. For people on Mac OS, Mac OS X, Windows, of course there is no other 'tk' option, so 'tkwin' provides something very valuable. The 'TEA' build process is not necessary for any of this. cheers, Vince. |
|
From: Vince D. <vi...@sa...> - 2002-07-03 10:05:39
|
On Tue, 2 Jul 2002, Alan W. Irwin wrote: > 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 It appears we need to do the same thing for the '*.map' files... Unfortunately, since I'm on a windows box, I can't do it here, I think. Vince. |
Thanks for helping keep SourceForge clean.
X