From: Joao C. <jc...@fe...> - 2002-03-14 21:17:57
|
On Thursday 14 March 2002 8:59 pm, Joao Cardoso wrote: | Update of /cvsroot/plplot/plplot/src | In directory usw-pr-cvs1:/tmp/cvs-serv19126/src | | Modified Files: | =09plstripc.c | Log Message: | Solve out of bonds bug, Bonds... I corrected it! Joao | "For the first call to the c_plstripa function, stripc->npts[p]-2 | value is -1 and generates an out of bound access in table | stripc->x[p]." | | _______________________________________________ | Plplot-cvs mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-cvs |
From: Rafael L. <lab...@ps...> - 2003-02-20 16:13:09
|
[ Moving to plplot-devel. ] * João Cardoso <jc...@fe...> [2003-02-20 15:40]: > In my sources, I use a PLplot global variable called build_tree that > says if the program being run was invoked inside the build tree(*); if > it was , then the path of the searched file in the build tree is used, > else the usual search path is used. This works fine for most drivers, > fonts and map files. > The tk driver is an exception, as it needs to find plserver, and tcl/tk > also needs its auto_path to be setup; in my sources this is also > working fine. > However, I don't like the (tk) solution, as it is not general. > There is also the problem of having a global variable, build_tree, which > is ugly. If your solution works and does not interfere with the normal mode of operation why don't you commit the changes? -- Rafael |
From: <jc...@fe...> - 2003-02-20 18:47:59
|
On Thursday 20 February 2003 16:00, Rafael Laboissiere wrote: | [ Moving to plplot-devel. ] | | * Jo=E3o Cardoso <jc...@fe...> [2003-02-20 15:40]: | > In my sources, I use a PLplot global variable called build_tree | > that says if the program being run was invoked inside the build | > tree(*); if it was , then the path of the searched file in the | > build tree is used, else the usual search path is used. This works | > fine for most drivers, fonts and map files. | > The tk driver is an exception, as it needs to find plserver, and | > tcl/tk also needs its auto_path to be setup; in my sources this is | > also working fine. | > However, I don't like the (tk) solution, as it is not general. | > There is also the problem of having a global variable, build_tree, | > which is ugly. | | If your solution works and does not interfere with the normal mode of | operation why don't you commit the changes? As I say above, the tk special case makes me believe that other similar=20 situations (tkwin?) can appear, creating yet another special case. I=20 don't like more than one special case :) I also don't like to have a global variable, even if only one -- aside=20 from plsc in plcore.c, of course. At last, Alan has been my only interlocutor in this issue, and he does=20 not seems sensible to this "make install" problem. Joao |
From: Alan W. I. <ir...@be...> - 2003-02-20 20:19:30
|
On Thu, 20 Feb 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > At last, Alan has been my only interlocutor in this issue, and he does > not seems sensible to this "make install" problem. Joao, you should know from my previous posts on this matter that this assertion is false. On the contrary, I understand how the make install latency could be annoying, and I will support any "make check" solution that does not have any confusion/ambiguity between the build and install locations. For older versions of plplot with this ambiguity we wasted many man-hours trying to confirm tmp-area bugs which turned out to be caused by (or hidden by) prior buggy installs. All I want to do is avoid this bad situation in the future. The configuration process already has all the required information on the various build locations of everything required for PLplot to run so in principle it is entirely possible to support "make check" without any build/install location ambiguity, but it will take a fair amount of thought about the design. There is absolutely nothing stopping you from designing and implementing such a solution if you are willing to be careful of this one build/install ambiguity issue. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting softwar= e package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-04-11 18:05:24
|
On Friday 11 April 2003 17:00, Joao Cardoso wrote: | Update of /cvsroot/plplot/plplot/src | In directory sc8-pr-cvs1:/tmp/cvs-serv14724/src | | Modified Files: | plmap.c | Log Message: | Use fabs() instead of abs(), as the native OSF1/alpha cc compiler should be C compiler, not cc, although cc could be Compaq C Compiler, ccc :) Joao |
From: Rafael L. <lab...@ps...> - 2003-10-09 22:22:35
|
* Joao Cardoso <jc...@us...> [2003-10-09 14:00]: > Update of /cvsroot/plplot/plplot/src > In directory sc8-pr-cvs1:/tmp/cvs-serv22829/src > > Modified Files: > plcore.c plctrl.c > Log Message: > If the current directory is in the build tree, change files search order so > as to load them locally. > > [...] I am very pleased that you finally cvs committed this code. Congratulations for avoiding the use of a global variable (a liked the static variables in plInBuildTree). However, I am just wondering: * Joao Cardoso <jc...@us...> [2003-10-09 14:02]: > Update of /cvsroot/plplot/plplot/include > In directory sc8-pr-cvs1:/tmp/cvs-serv23141/include > > Modified Files: > plConfig.h.in > Log Message: > Create and set BUILD_DIR. Is it really necessary to have the #define BUILD_DIR in plConfig.h? Remember that this file is included in user's programs and I do not see the interest of having BUILD_DIR defined in this case. At any rate, #define BUILD_DIR is already included in config.h, thanks to the call to AC_DEFINE_UNQUOTED in configure.ac. By the way, I think that the same arguments would apply for other #define's included in plConfig.h ( LIB_DIR, DATA_DIR, BIN_DIR, and TCL_DIR). Does anybody object to removing these #define's from plConfig.h.in? -- Rafael |
From: Alan W. I. <ai...@us...> - 2003-10-09 23:04:50
|
On 2003-10-10 00:19+0200 Rafael Laboissiere wrote: > By the way, I think that the same arguments would apply for other #define's > included in plConfig.h ( LIB_DIR, DATA_DIR, BIN_DIR, and TCL_DIR). > > Does anybody object to removing these #define's from plConfig.h.in? I can find no trace of them in the examples so your change seems okay to me, but you had probably better talk to Geoffrey and Maurice to make sure some of their more exotic applications that use PLplot would not be broken by this. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-10-10 06:25:29
|
* Alan W. Irwin <ai...@us...> [2003-10-09 16:04]: > I can find no trace of them in the examples so your change seems okay to me, > [...] My understanding is that the *_DIR #defines are only used in the core code of the PLplot library. I cannot see why a regular user would need to access them. I am so happy when I can remove cruft from code... > [...] but you had probably better talk to Geoffrey and Maurice to make sure > some of their more exotic applications that use PLplot would not be broken > by this. I guess that Maurice and Geoffrey are still subscribed to this mailing list, aren't they? -- Rafael |
From: Maurice L. <mj...@ga...> - 2003-10-10 06:43:27
|
Rafael Laboissiere writes: > * Alan W. Irwin <ai...@us...> [2003-10-09 16:04]: > > > I can find no trace of them in the examples so your change seems okay to me, > > [...] > > My understanding is that the *_DIR #defines are only used in the core code > of the PLplot library. I cannot see why a regular user would need to access > them. > > I am so happy when I can remove cruft from code... I see no reason why they cannot be taken out. > > [...] but you had probably better talk to Geoffrey and Maurice to make sure > > some of their more exotic applications that use PLplot would not be broken > > by this. > > I guess that Maurice and Geoffrey are still subscribed to this mailing list, > aren't they? One would hope. :) -- Maurice LeBrun Lightspeed Semiconductor Corp |
From: Maurice L. <mj...@ga...> - 2003-10-10 06:48:52
|
Maurice LeBrun writes: > Rafael Laboissiere writes: > > * Alan W. Irwin <ai...@us...> [2003-10-09 16:04]: > > > > > I can find no trace of them in the examples so your change seems okay to me, > > > [...] > > > > My understanding is that the *_DIR #defines are only used in the core code > > of the PLplot library. I cannot see why a regular user would need to access > > them. > > > > I am so happy when I can remove cruft from code... > > I see no reason why they cannot be taken out. A qualification: I meant as regards user code. As far as the core is concerned, they are used in plctrl.c and plcore.c to establish the install locations, and this use needs to be retained. -- Maurice LeBrun Lightspeed Semiconductor Corp |
From: Rafael L. <lab...@ps...> - 2003-10-10 08:36:40
|
* Maurice LeBrun <mj...@ga...> [2003-10-10 01:48]: > A qualification: I meant as regards user code. As far as the core is > concerned, they are used in plctrl.c and plcore.c to establish the install > locations, and this use needs to be retained. As mentioned before in this thread, the *_DIR #define's are included in config.h by the AC_DEFINE_UNQUOTED calls in configure.ac. plConfig.h includes config.h at build time, so we are in business. -- Rafael |
From: <jc...@fe...> - 2003-10-10 01:54:02
|
On Thursday 09 October 2003 23:19, Rafael Laboissiere wrote: | * Joao Cardoso <jc...@us...> [2003-10-09 14:00]: | > Update of /cvsroot/plplot/plplot/src | > In directory sc8-pr-cvs1:/tmp/cvs-serv22829/src | > | > Modified Files: | > plcore.c plctrl.c | > Log Message: | > If the current directory is in the build tree, change files search order | > so as to load them locally. | > | > [...] | | I am very pleased that you finally cvs committed this code. | Congratulations for avoiding the use of a global variable (a liked the | static variables in plInBuildTree). | | However, I am just wondering: | | * Joao Cardoso <jc...@us...> [2003-10-09 14:02]: | > Update of /cvsroot/plplot/plplot/include | > In directory sc8-pr-cvs1:/tmp/cvs-serv23141/include | > | > Modified Files: | > plConfig.h.in | > Log Message: | > Create and set BUILD_DIR. | | Is it really necessary to have the #define BUILD_DIR in plConfig.h? I followed the other *_DIR receipt. Feel free to make with it "The Right Thing". And yes, config.h is include by plConfig.h, I should have checked that myself. Joao PS: I forgot to tell in the cvs commit message that no environment variables are honored while in the build tree. If we are running plplot in the build tree we don't want to be fooled by any other instalation. That's the purpose of a build tree. | Remember that this file is included in user's programs and I do not see the | interest of having BUILD_DIR defined in this case. At any rate, #define | BUILD_DIR is already included in config.h, thanks to the call to | AC_DEFINE_UNQUOTED in configure.ac. | | By the way, I think that the same arguments would apply for other | #define's included in plConfig.h ( LIB_DIR, DATA_DIR, BIN_DIR, and | TCL_DIR). | | Does anybody object to removing these #define's from plConfig.h.in? |
From: Rafael L. <lab...@ps...> - 2003-10-10 06:25:52
|
* João Cardoso <jc...@fe...> [2003-10-10 02:53]: > I followed the other *_DIR receipt. Feel free to make with it "The Right > Thing". And yes, config.h is include by plConfig.h, I should have checked > that myself. No problem. > I forgot to tell in the cvs commit message that no environment variables > are honored while in the build tree. If we are running plplot in the build > tree we don't want to be fooled by any other instalation. That's the > purpose of a build tree. Yes, this is "The Right Thing" to do. -- Rafael |