Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2005-11-20 08:54:00
|
Perhaps it isn't a big deal, but I've noticed that the "last modified" date in the CVS version is not updated according to the last modification of the CVS source tree. Rather it refers to the date of the release, e.g.,
G N U P L O T
Version 4.1 patchlevel 0
last modified Sat Jul 3 00:04:32 CEST 2004
System: Linux 2.6.9-1.667
It would be nice if that could be updated via a CVS checkin script or something. (Not sure if CVS has that capability.) For example
G N U P L O T
CVS Post Version 4.1 patchlevel 0
last modified Tue Nov 13 11:06:27 CEST 2005
System: Linux 2.6.9-1.667
Dan
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-21 14:02:22
|
Daniel J Sebald wrote: > It would be nice if that could be updated via a CVS checkin script or > something. (Not sure if CVS has that capability.) I'm quite sure that CVS has that capability, but less than convinced that it would be a good idea to use it. A better alternative would be not to display the 'last modified' line at all, in non-release versions. Mechanisms for doing that already exist to switch between the -beta and the user mailing list addresses. Or we could exchange the 'last modified' time by a build time, for CVS builds. |
|
From: Daniel J S. <dan...@ie...> - 2005-11-21 18:07:54
|
Hans-Bernhard Broeker wrote: > Daniel J Sebald wrote: > >> It would be nice if that could be updated via a CVS checkin script or >> something. (Not sure if CVS has that capability.) > > > I'm quite sure that CVS has that capability, but less than convinced > that it would be a good idea to use it. > > A better alternative would be not to display the 'last modified' line at > all, in non-release versions. Mechanisms for doing that already exist > to switch between the -beta and the user mailing list addresses. > > Or we could exchange the 'last modified' time by a build time, for CVS > builds. Either of those would be better than a misleading 'last modified' date. Dan |
|
From: Harald H. <h.h...@tu...> - 2005-11-22 20:21:19
|
On Mon, 21 Nov 2005, Hans-Bernhard Broeker wrote: > Daniel J Sebald wrote: > > > It would be nice if that could be updated via a CVS checkin script or > > something. (Not sure if CVS has that capability.) > > I'm quite sure that CVS has that capability, but less than convinced > that it would be a good idea to use it. Why? I have often missed that information during runtime. Of course, the most recent checkin is important. And since ChangeLog is changed with every checkin, the version date of this file could be used. This could be found out using grep '/ChangeLog/' CVS/Entries | sed 's_/ChangeLog/[0-9.]*/\(.*\)//_\1_' during compiling or by ./configure or ./prepare. > A better alternative would be not to display the 'last modified' line at > all, in non-release versions. Mechanisms for doing that already exist > to switch between the -beta and the user mailing list addresses. > > Or we could exchange the 'last modified' time by a build time, for CVS > builds. Of all alternatives, I would prefer to show the CVS timestamp. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-22 20:35:49
|
Harald Harders wrote: > grep '/ChangeLog/' CVS/Entries | sed 's_/ChangeLog/[0-9.]*/\(.*\)//_\1_' > > during compiling or by ./configure or ./prepare. Please keep in mind that not all developers are on Unix ... If we want to put a 'last checkin' timestamp into the banner page of builds from CVS, the server is the place to implement such a scheme. The server would basically modify 'version.h' automatically, every single time anybody checks in anything. The date string could either be taken from the RCS $Id, or generated by a script on the server. |
|
From: Daniel J S. <dan...@ie...> - 2005-11-22 20:52:12
|
Hans-Bernhard Broeker wrote: > Harald Harders wrote: > >> grep '/ChangeLog/' CVS/Entries | sed 's_/ChangeLog/[0-9.]*/\(.*\)//_\1_' >> >> during compiling or by ./configure or ./prepare. > > > Please keep in mind that not all developers are on Unix ... > > If we want to put a 'last checkin' timestamp into the banner page of > builds from CVS, the server is the place to implement such a scheme. The > server would basically modify 'version.h' automatically, every single > time anybody checks in anything. The date string could either be taken > from the RCS $Id, or generated by a script on the server. Along the same line of reasoning, I think we wouldn't want to open the door for users or maintainers to easily, unintentionally modifying that date. In very few instances would that be useful, I think. Rather it would lead to more confusion where an older CVS version could appear to have a more recent date. I say we're stamping what's in CVS and if ever someone wants to change that date on a local copy, they have to go out of their way to do it. Dan |
|
From: Harald H. <h.h...@tu...> - 2005-11-22 21:23:39
|
On Tue, 22 Nov 2005, Hans-Bernhard Broeker wrote: > Harald Harders wrote: > > grep '/ChangeLog/' CVS/Entries | sed 's_/ChangeLog/[0-9.]*/\(.*\)//_\1_' > > > > during compiling or by ./configure or ./prepare. > > Please keep in mind that not all developers are on Unix ... Oh yes, I sometimes forget this. How do these people work? > If we want to put a 'last checkin' timestamp into the banner page of > builds from CVS, the server is the place to implement such a scheme. > The server would basically modify 'version.h' automatically, every > single time anybody checks in anything. The date string could either be > taken from the RCS $Id, or generated by a script on the server. This sounds good. The big advantage of being able to find out of which date a CVS version is, is comparability. Best regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-23 10:53:10
|
Harald Harders wrote: > On Tue, 22 Nov 2005, Hans-Bernhard Broeker wrote: >>Please keep in mind that not all developers are on Unix ... > Oh yes, I sometimes forget this. How do these people work? With difficulties, needing tools that emulate a Unix environment (Cygwin, DJGPP). I've been in that position myself for quite a while now --- the machine I spend my days sitting in front of runs Win98. And there's another gotcha of a client-side approach: not everybody runs 'prepare' all the time. On Linux, if your tools are recent, you generally can rely on a simple 'make' to get it all right by itself. > This sounds good. The big advantage of being able to find out of which > date a CVS version is, is comparability. On the other hand, any discussion of CVS versions older than 'today' is futile by definition. So we don't need a date stamp on the screen --- we only need to know that the binary is built from current sources. People who can't be bothered to cvs update and re-build before reporting a problem, shouldn't be building from CVS in the first place. If we were to actually care about behaviour of outdated CVS builds, having a public CVS becomes a useless exercise. |
|
From: Daniel J S. <dan...@ie...> - 2005-11-23 12:01:44
|
Hans-Bernhard Broeker wrote: > Harald Harders wrote: > >> On Tue, 22 Nov 2005, Hans-Bernhard Broeker wrote: > > >>> Please keep in mind that not all developers are on Unix ... > > >> Oh yes, I sometimes forget this. How do these people work? > > > With difficulties, needing tools that emulate a Unix environment > (Cygwin, DJGPP). I've been in that position myself for quite a while > now --- the machine I spend my days sitting in front of runs Win98. > > And there's another gotcha of a client-side approach: not everybody runs > 'prepare' all the time. On Linux, if your tools are recent, you > generally can rely on a simple 'make' to get it all right by itself. > >> This sounds good. The big advantage of being able to find out of which >> date a CVS version is, is comparability. > > > On the other hand, any discussion of CVS versions older than 'today' is > futile by definition. > So we don't need a date stamp on the screen --- > we only need to know that the binary is built from current sources. > People who can't be bothered to cvs update and re-build before reporting > a problem, shouldn't be building from CVS in the first place. That I don't know about. It's useful from the developers standpoint for the case where a bug finds its way into CVS. Say you're a developer and recognize your copy of gnuplot is a couple weeks old by looking on the screen. So, you update. You find a bug and can report back to the list what day it was last working. It may also be useful for referencing against the ChangeLog. For maintenance personel at universities and labs who might be used to working with bleeding edge releases, that date may be a reminder that gnuplot is long out of date. Removing the date would still be better, I think, than showing the code was last modified two years ago when it actually was modified two days ago. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-23 15:17:46
|
Daniel J Sebald wrote:
> Hans-Bernhard Broeker wrote:
>> On the other hand, any discussion of CVS versions older than 'today'
>> is futile by definition.
> That I don't know about. It's useful from the developers standpoint for
> the case where a bug finds its way into CVS.
Not necessarily. The primary information needed is: is it *still*
present in current CVS version? If not, case closed --- somebody
already fixed it in the meantime.
If a bug is found in current CVS, and you really need to know when it
got in there (e.g. because you can't figure out what causes it, so you
need to home in on the change that introduced it), you'll have to run
explicitly backdated checkouts anyway --- a time stamp in the executable
doesn't add any new information then. You know which date you just
checked out. But honestly, in all the years we have had a CVS source
tree, I don't recall having done that more than maybe once or twice.
> Say you're a developer and recognize your copy of gnuplot is a couple
> weeks old by looking on the screen. So, you update. You find a bug
> and can report back to the list what day it was last working.
No, you can't --- you can only report when it was still working. You
don't know if the _last_ working version was three weeks or three hours
ago, only that it's less than a couple weeks ago. To really nail down
the last working version, you still have to run a series of 'cvs update
-D <date>' test builds.
Anyway: if you're running the CVS version, you're supposed to have a
checked-out copy of the sources around, corresponding to the binary
being used. And even if you don't, you can still check the RCS $Id
strings embedded in the binary ('ident gnuplot') to find out.
So to sum it up, the only thing really likely to be achieved by putting
a CVS update time stamp into the banner printout is to encourage ab-use
of the CVS version.
|
|
From: Petr M. <mi...@ph...> - 2005-11-23 23:58:49
|
>> Harald Harders wrote:
>>> grep '/ChangeLog/' CVS/Entries | sed 's_/ChangeLog/[0-9.]*/\(.*\)//_\1_'
>>>
>>> during compiling or by ./configure or ./prepare.
>>
>> Please keep in mind that not all developers are on Unix ...
>
> Oh yes, I sometimes forget this. How do these people work?
Those people install such utilities from cygwin, mingw or gnuwin32 projects.
I propose that
./configure
gets the date from ChangeLong, and #defines it in config.h as
GNUPLOT_LAST_MODIFIED. Then the printing code of "show version" uses
#ifdef GNUPLOT_LAST_MODIFIED
fprintf last modified GNUPLOT_LAST_MODIFIED
#endif
For non-./configure platforms, makefile.os2, .cyg and .mgw can be updated to
gather the date from ChangeLog as on ./configure. Others won't see the
message.
---
PM
|
|
From: Lars H. <lhe...@us...> - 2005-11-23 15:26:05
|
> Anyway: if you're running the CVS version, you're supposed to have a
> checked-out copy of the sources around, corresponding to the binary
> being used. And even if you don't, you can still check the RCS $Id
> strings embedded in the binary ('ident gnuplot') to find out.
I think this (and "strings `which gnuplot` |grep '$Id:'") only works
with executables built without optimisation.
$ ident `which gnuplot`
/usr/local/bin/gnuplot:
$Header: /cvsroot/gnuplot/gnuplot/term/tgif.trm,v 1.36 2005/08/07 09:43:34 mikulik Exp $
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-23 15:42:31
|
Lars Hecking wrote:
>>Anyway: if you're running the CVS version, you're supposed to have a
>>checked-out copy of the sources around, corresponding to the binary
>>being used. And even if you don't, you can still check the RCS $Id
>>strings embedded in the binary ('ident gnuplot') to find out.
>
>
> I think this (and "strings `which gnuplot` |grep '$Id:'") only works
> with executables built without optimisation.
Optimization should have little to do with it --- I never build without
optimization, and ident always worked just fine.
Our source files go quite a bit out of their way to make sure those
ident strings are hard to optimize out, as a side effect of making them
acceptable to picky compilers. Well, at least I don't think I've seen
any optimizer yet that dared strip those things.
|
|
From: Lars H. <lhe...@us...> - 2005-11-23 16:27:14
|
> Optimization should have little to do with it --- I never build without > optimization, and ident always worked just fine. > > Our source files go quite a bit out of their way to make sure those > ident strings are hard to optimize out, as a side effect of making them > acceptable to picky compilers. Well, at least I don't think I've seen > any optimizer yet that dared strip those things. Argh, you're right - my meta-configure script uses -Dlint ... |
|
From: Petr M. <mi...@ph...> - 2005-11-24 10:48:09
|
> I think this (and "strings `which gnuplot` |grep '$Id:'") only works > with executables built without optimisation. > > $ ident `which gnuplot` > /usr/local/bin/gnuplot: > $Header: /cvsroot/gnuplot/gnuplot/term/tgif.trm,v 1.36 2005/08/07 09:43:34 mikulik Exp $ This looks to be a string printed in every output file of "set term tgif". This message makes no sense there. I propose it is replaced by the same message which appears in postscript files: fprintf(..., "Creator: gnuplot %s patchlevel %s\n", gnuplot_version, gnuplot_patchlevel) --- PM |
|
From: Petr M. <mi...@ph...> - 2005-11-25 18:45:44
|
>> $ ident `which gnuplot` >> /usr/local/bin/gnuplot: >> $Header: /cvsroot/gnuplot/gnuplot/term/tgif.trm,v 1.36 2005/08/07 >> 09:43:34 mikulik Exp $ > > This looks to be a string printed in every output file of "set term tgif". > This message makes no sense there. > > I propose it is replaced by the same message which appears in postscript > files: fprintf(..., > "Creator: gnuplot %s patchlevel %s\n", gnuplot_version, gnuplot_patchlevel) OK, I've changed that in cvs. --- PM |
