Menu
▾
▴
gnuplot-beta
|
From: <es...@th...> - 2017-10-14 18:15:58
|
I'm making good progress on the git conversion procedure. I expect to have it wrapped up and ready to go tonight or tomorrow. All I will need to pull the trigger at that point is (a) Daniel Sebald's authorship map. (b) Push privileges on the git hosting site. Ethan, you sent me three tarballs of archaic releases: gnuplot-1.10A.tar.gz gnuplot-2.0.tar.gz gnuplot-3.5.tar.gz I have the machinery set up to graft these onto the front of the git repository, but I nees one piece of metadata for each: the release date. The timestamps in the tarballs seem to have been clobbered at some point. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> Don't think of it as `gun control', think of it as `victim disarmament'. If we make enough laws, we can all be criminals. |
|
From: sfeam <sf...@us...> - 2017-10-14 20:04:10
|
On Saturday, 14 October 2017 14:15:50 Eric S. Raymond wrote: > I'm making good progress on the git conversion procedure. I expect to > have it wrapped up and ready to go tonight or tomorrow. All I will > need to pull the trigger at that point is > > (a) Daniel Sebald's authorship map. > > (b) Push privileges on the git hosting site. I was thinking that you would create and populate the git repository somewhere convenient to you, where you have control over everything up to and including blowing it away and starting over. Then when it seems to be successfully set up we would clone it onto SourceForge. I can add you to the project "admin" or "developer" groups if you have a SourceForge user ID. More fine-grained management of privileges on the site is something I have never found proper documentation for. I created a placeholder by hitting a button "Add new git" on the admin tab https://sourceforge.net/p/gnuplot/git-main/ref/master/ but I don't know exactly which subset of users associated with the project can push to it. I am guessing it's everyone in the "developer" group. Please bear with me if I am misunderstanding what needs to be done. I have used git only to clone and use an existing repository; I've never set one up. > Ethan, you sent me three tarballs of archaic releases: > > gnuplot-1.10A.tar.gz > gnuplot-2.0.tar.gz > gnuplot-3.5.tar.gz > > I have the machinery set up to graft these onto the front of the git > repository, but I nees one piece of metadata for each: the release > date. The timestamps in the tarballs seem to have been clobbered > at some point. >From the self-reported date in the source file version.c gnuplot 1.1.0A "Thu May 18 21:57:24 MST 1989" gnuplot 2.0.0 "Wed Mar 7 22:18:59 EST 1990" gnuplot 3.5 "Fri Aug 27 05:21:33 GMT 1993" Yeah the timestamps probably don't mean much. I reconstructed the source trees from multipart shar archives originally posed to usenet group comp.sources.misc and stored in that form in the gnuplot-historical subdirectory on sf.net. I see there are also shar files there for "gnuplot-3.0", so I may try to unpack and put those in a tarball also. Ethan Ethan |
|
From: Eric S. R. <es...@th...> - 2017-10-14 20:48:04
|
sfeam <sf...@us...>: > On Saturday, 14 October 2017 14:15:50 Eric S. Raymond wrote: > > I'm making good progress on the git conversion procedure. I expect to > > have it wrapped up and ready to go tonight or tomorrow. All I will > > need to pull the trigger at that point is > > > > (a) Daniel Sebald's authorship map. > > > > (b) Push privileges on the git hosting site. > > I was thinking that you would create and populate the git repository > somewhere convenient to you, where you have control over everything > up to and including blowing it away and starting over. Then when it > seems to be successfully set up we would clone it onto SourceForge. That's what I'm doing now. > I can add you to the project "admin" or "developer" groups if you > have a SourceForge user ID. I do. I'm 'esr' there. > More fine-grained management of privileges > on the site is something I have never found proper documentation for. > I created a placeholder by hitting a button "Add new git" on the admin > tab > https://sourceforge.net/p/gnuplot/git-main/ref/master/ > but I don't know exactly which subset of users associated with the > project can push to it. I am guessing it's everyone in the "developer" > group. Yes, I believe that's correct. > >From the self-reported date in the source file version.c > gnuplot 1.1.0A "Thu May 18 21:57:24 MST 1989" > gnuplot 2.0.0 "Wed Mar 7 22:18:59 EST 1990" > gnuplot 3.5 "Fri Aug 27 05:21:33 GMT 1993" > > Yeah the timestamps probably don't mean much. I reconstructed the > source trees from multipart shar archives originally posed to usenet > group comp.sources.misc and stored in that form in the gnuplot-historical > subdirectory on sf.net. Better than nothing. I'll use those. > I see there are also shar files there for "gnuplot-3.0", so I may try to > unpack and put those in a tarball also. OK. It will be easy for me to incorporate that. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Pieter-Tjerk de B. <p.t...@ut...> - 2017-10-14 21:42:16
|
On Sat, Oct 14, 2017 at 01:03:55PM -0700, sfeam via gnuplot-beta wrote: > From the self-reported date in the source file version.c > gnuplot 1.1.0A "Thu May 18 21:57:24 MST 1989" > gnuplot 2.0.0 "Wed Mar 7 22:18:59 EST 1990" > gnuplot 3.5 "Fri Aug 27 05:21:33 GMT 1993" > > Yeah the timestamps probably don't mean much. For what it's worth, I happen to have a gnuplot-2.0.tar.gz containing source files all dated 1989-01-25 (and .o files from 1990). That .tar.gz itself is dated 1999-11-17, which presumably is when I downloaded this from "somewhere" on the Internet. I also have a companion (?) file called gnuplot-2.0-X11.tar.Z , containing apparently only the X11 terminal (which is not in the other tar file), with file dates between March 14 and 27, 1990. For any gnuplot archaeologist interested, I've put them temporarily at: http://wwwhome.ewi.utwente.nl/~ptdeboer/tmp/gnuplot-2.0.tar.gz http://wwwhome.ewi.utwente.nl/~ptdeboer/tmp/gnuplot-2.0-X11.tar.Z Regards, Pieter-Tjerk |
|
From: sfeam <sf...@us...> - 2017-10-14 22:32:14
|
On Saturday, 14 October 2017 23:28:27 Pieter-Tjerk de Boer wrote: > > On Sat, Oct 14, 2017 at 01:03:55PM -0700, sfeam via gnuplot-beta wrote: > > > From the self-reported date in the source file version.c > > gnuplot 1.1.0A "Thu May 18 21:57:24 MST 1989" > > gnuplot 2.0.0 "Wed Mar 7 22:18:59 EST 1990" > > gnuplot 3.5 "Fri Aug 27 05:21:33 GMT 1993" > > > > Yeah the timestamps probably don't mean much. > > For what it's worth, I happen to have a gnuplot-2.0.tar.gz containing > source files all dated 1989-01-25 (and .o files from 1990). > > That .tar.gz itself is dated 1999-11-17, which presumably is when I > downloaded this from "somewhere" on the Internet. > > I also have a companion (?) file called gnuplot-2.0-X11.tar.Z , containing > apparently only the X11 terminal (which is not in the other tar file), with > file dates between March 14 and 27, 1990. > > For any gnuplot archaeologist interested, I've put them temporarily at: > http://wwwhome.ewi.utwente.nl/~ptdeboer/tmp/gnuplot-2.0.tar.gz > http://wwwhome.ewi.utwente.nl/~ptdeboer/tmp/gnuplot-2.0-X11.tar.Z Those are interesting, but confusing. When I unpack the "gnuplot-2.0" tarball I find source that claims to be version 1.1 stonelion [2398] cat gnuplot-2.0/mainplot/version.c char version[] = "1.1.0"; char date[] = "Mon Jan 26 16:58:24 EST 1987"; The contents of the source files I looked at appear to be older than the corresponding files I have labeled "1.1.0A". So I think despite the name of the tarball and the directory it contains, you really have a tarball for the 1987 version 1.1 source. However the other one gnuplot-2.0-X11.tar.Z really does contain x11 terminal driver source for version 2.0 dated Mar 14 1990. As you note, the x11 terminal is missing from the gnuplot source prior to version 3 that I already have. So let's save that one file. thanks! Ethan > > Regards, > Pieter-Tjerk |
|
From: Daniel J S. <dan...@ie...> - 2017-10-16 03:38:46
|
On 10/14/2017 01:15 PM, Eric S. Raymond wrote: > I'm making good progress on the git conversion procedure. I expect to > have it wrapped up and ready to go tonight or tomorrow. All I will > need to pull the trigger at that point is > > (a) Daniel Sebald's authorship map. Eric, Generating the authorship map file requires a git repository (from the frozen CVS repository). If you are not using the map after the cvs-to-git conversion, but during the conversion, then there will be a three-step process: generating the git repository, generating the authorship map, and re-generating the git repository. If you provide the git repository from the frozen CVS repository, I can clone the repository and generate the authorship map then post that file somewhere. Alternatively, you can compile the utility and follow the directions described in "git_changelog_author --help". Let me describe the algorithm, for Ethan's benefit, then give an example. The utility is quite simple. It's main approach is: for each changeset where there is a modification to ChangeLog MAIN ALGORITHM: Search for the first change in ChangeLog diff-hunk. From that point search backward for the first authorship line (which typically is the current line because a new FSF entry is being added to the ChangeLog). EXCEPTIONS: 1) The authorship line cannot be a subtraction, i.e., can't have a minus sign as the first character. The reason is that is typically a scenario with a wholesale swap of the ChangeLog file, for example if ChangeLog is renamed ChangeLog.1 and a new blank ChangeLog is created, or it might be a corrected authorship line. Such situations are left attributed to the committer, usually Ethan (sfeam). 2) If the ChangeLog file is the *only* file that changes in the changeset, it is left out of the authorship map file. These are typically cases where Ethan goes back to clean up some comments. In such scenarios it is likely that the above algorithm searches backward to some FSF author line that really isn't pertinent. It might make sense in some cases because it goes back to the original author. But it could also be random. My thinking is that it is best to leave clean-up modifications attributed to the committer. To my way of thinking, the one problem this won't catch is where the original ChangeLog entry had an error in the authorship line itself and then Ethan went back and corrected the authorship line, because such a scenario will have '-' in the first column of the first changed line and a '+' in the first column of the second changed line. This is discarded, hence the original incorrect authorship (misspelled, wrong email, whatever) will remain in the authorship map. If such a scenario exists in the map and someone finds the uncorrected authorship in the future, as Mojca pointed out, that can be fixed by hand. An example with the test repository that Mojca generated. First step is create the lists from the "git log" command. Second step is process those lists to create the authorship map, in one case not extracting ChangeLog-only changeset and in another case extracting such changesets: sebald@ ~/test_repository $ git log --format='commit <%cE!%cIZ>' -p --unified=50 ChangeLog > CL.diff sebald@ ~/test_repository $ git log --format='commit <%cE!%cIZ>' --name-only > files.lst sebald@ ~/test_repository $ git_changelog_author CL.diff > author1.txt sebald@ ~/test_repository $ wc author1.txt 6037 32500 536364 author1.txt sebald@ ~/test_repository $ git_changelog_author CL.diff files.lst > author2.txt sebald@ ~/test_repository $ wc author2.txt 5632 30391 500619 author2.txt I used word-count utility to check how many lines are in each file. What the above is telling us is that there are 6037 changesets in which the ChangeLog was modified in which '-' was not in the first column of the authorship line. Of those, 405 (i.e., 6037 - 5632) changesets involved only the ChangeLog. Dan |
|
From: Eric S. R. <es...@th...> - 2017-10-16 05:03:31
|
Daniel J Sebald <dan...@ie...>: > If you provide the git repository from the frozen CVS repository, I can > clone the repository and generate the authorship map then post that file > somewhere. Alternatively, you can compile the utility and follow the > directions described in "git_changelog_author --help". It may be superfluous now. I started thinking about what you and broeker were telling me about analyzing diffs and ended up using a similar technique to implement parsing each ChangeLog blog for authorship info to apply to the clique it's in. I'll interleave a description of my algorithm with yours. > Let me describe the algorithm, for Ethan's benefit, then give an example. > > The utility is quite simple. It's main approach is: for each changeset > where there is a modification to ChangeLog > > MAIN ALGORITHM: > > Search for the first change in ChangeLog diff-hunk. From that point search > backward for the first authorship line (which typically is the current line > because a new FSF entry is being added to the ChangeLog). Yup, this is my first stage as well. Because I'm looking at the blob (the entire ChangeLog state associated with the changeset) rather than a diff, I can just grab the top (most recent) entry header > EXCEPTIONS: > > 1) The authorship line cannot be a subtraction, i.e., can't have a minus > sign as the first character. The reason is that is typically a scenario > with a wholesale swap of the ChangeLog file, for example if ChangeLog is > renamed ChangeLog.1 and a new blank ChangeLog is created, or it might be a > corrected authorship line. Such situations are left attributed to the > committer, usually Ethan (sfeam). I'm not checking for this case specially. Probably the right thing to do is not analyze if *all* the file paths in the commit are ChangeLogs. I just implemented this. > 2) If the ChangeLog file is the *only* file that changes in the changeset, > it is left out of the authorship map file. These are typically cases where > Ethan goes back to clean up some comments. In such scenarios it is likely > that the above algorithm searches backward to some FSF author line that > really isn't pertinent. It might make sense in some cases because it goes > back to the original author. But it could also be random. My thinking is > that it is best to leave clean-up modifications attributed to the committer. Above rule filters out these too. > To my way of thinking, the one problem this won't catch is where the > original ChangeLog entry had an error in the authorship line itself and then > Ethan went back and corrected the authorship line, because such a scenario > will have '-' in the first column of the first changed line and a '+' in the > first column of the second changed line. This is discarded, hence the > original incorrect authorship (misspelled, wrong email, whatever) will > remain in the authorship map. If such a scenario exists in the map and > someone finds the uncorrected authorship in the future, as Mojca pointed > out, that can be fixed by hand. Yeah, this can't realistically be detected in the metadata representation I'm traversing, either. > I used word-count utility to check how many lines are in each file. What the > above is telling us is that there are 6037 changesets in which the ChangeLog > was modified in which '-' was not in the first column of the authorship > line. Of those, 405 (i.e., 6037 - 5632) changesets involved only the > ChangeLog. In 13202 commits, my technique finds 8245 ChangeLog blobs of which it uses 8222. So all but 25 ChangeLogs yield usable attributions, and my method picks up about 1200 more attributions than yours. In 3137 cases the deduced author is different from the committer. That's 23% of commits, which is a completely reasonable density of patches contributed by non-devs. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Bastian M. <bma...@we...> - 2017-10-16 06:32:20
|
Dear Eric, dear Daniel, That sounds very promising! I am volunteering to inspect-by-eye (a subset) of the new attributions (but have only limited time). One thing I like to point out is that in some cases the ChangeLog entry was accidentally omitted (e.g. because the file changes were not saved). So it might have turned up in the follw-up checkin, which now may lead to incorrect attributions. Is it possible to check for such cases? Maybe for inspection by eye? Bastian > > I used word-count utility to check how many lines are in each file. > > What the above is telling us is that there are 6037 changesets in > > which the ChangeLog was modified in which '-' was not in the first > > column of the authorship line. Of those, 405 (i.e., 6037 - 5632) > > changesets involved only the ChangeLog. > > In 13202 commits, my technique finds 8245 ChangeLog blobs of which it uses > 8222. So all but 25 ChangeLogs yield usable attributions, and my method picks > up about 1200 more attributions than yours. > > In 3137 cases the deduced author is different from the committer. That's 23% > of commits, which is a completely reasonable density of patches contributed by > non-devs. > -- > <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> > > My work is funded by the Internet Civil Engineering Institute: https://icei.org > Please visit their site and donate: the civilization you save might be your own. > |
|
From: Daniel J S. <dan...@ie...> - 2017-10-16 06:52:52
|
On 10/16/2017 12:03 AM, Eric S. Raymond wrote: > Daniel J Sebald <dan...@ie...>: >> If you provide the git repository from the frozen CVS repository, I can >> clone the repository and generate the authorship map then post that file >> somewhere. Alternatively, you can compile the utility and follow the >> directions described in "git_changelog_author --help". > > It may be superfluous now. I started thinking about what you and > broeker were telling me about analyzing diffs and ended up using a similar > technique to implement parsing each ChangeLog blog for authorship info to > apply to the clique it's in. > > I'll interleave a description of my algorithm with yours. > >> Let me describe the algorithm, for Ethan's benefit, then give an example. >> >> The utility is quite simple. It's main approach is: for each changeset >> where there is a modification to ChangeLog >> >> MAIN ALGORITHM: >> >> Search for the first change in ChangeLog diff-hunk. From that point search >> backward for the first authorship line (which typically is the current line >> because a new FSF entry is being added to the ChangeLog). > > Yup, this is my first stage as well. Because I'm looking at the blob > (the entire ChangeLog state associated with the changeset) rather than > a diff, I can just grab the top (most recent) entry header > >> EXCEPTIONS: >> >> 1) The authorship line cannot be a subtraction, i.e., can't have a minus >> sign as the first character. The reason is that is typically a scenario >> with a wholesale swap of the ChangeLog file, for example if ChangeLog is >> renamed ChangeLog.1 and a new blank ChangeLog is created, or it might be a >> corrected authorship line. Such situations are left attributed to the >> committer, usually Ethan (sfeam). > > I'm not checking for this case specially. Probably the right thing to do > is not analyze if *all* the file paths in the commit are ChangeLogs. > > I just implemented this. > >> 2) If the ChangeLog file is the *only* file that changes in the changeset, >> it is left out of the authorship map file. These are typically cases where >> Ethan goes back to clean up some comments. In such scenarios it is likely >> that the above algorithm searches backward to some FSF author line that >> really isn't pertinent. It might make sense in some cases because it goes >> back to the original author. But it could also be random. My thinking is >> that it is best to leave clean-up modifications attributed to the committer. > > Above rule filters out these too. > >> To my way of thinking, the one problem this won't catch is where the >> original ChangeLog entry had an error in the authorship line itself and then >> Ethan went back and corrected the authorship line, because such a scenario >> will have '-' in the first column of the first changed line and a '+' in the >> first column of the second changed line. This is discarded, hence the >> original incorrect authorship (misspelled, wrong email, whatever) will >> remain in the authorship map. If such a scenario exists in the map and >> someone finds the uncorrected authorship in the future, as Mojca pointed >> out, that can be fixed by hand. > > Yeah, this can't realistically be detected in the metadata representation I'm > traversing, either. OK, we're on the same page. There are all sorts of conditions I could imagine having accounted for, but I think at some point its covering corner cases that become increasingly unlikely. We'll have opportunity to review how well the authorship has worked out. >> I used word-count utility to check how many lines are in each file. What the >> above is telling us is that there are 6037 changesets in which the ChangeLog >> was modified in which '-' was not in the first column of the authorship >> line. Of those, 405 (i.e., 6037 - 5632) changesets involved only the >> ChangeLog. > > In 13202 commits, my technique finds 8245 ChangeLog blobs of which it uses > 8222. So all but 25 ChangeLogs yield usable attributions, and my method > picks up about 1200 more attributions than yours. But I'm not using a good translation; it's Mojca's automated cvs-import repository which we know has issues. That repository is pretty far behind the current CVS repository, and doesn't pass its checks. I.e., sebald@ ~/test_repository $ git fsck Checking object directories: 100% (256/256), done. Checking objects: 100% (78081/78081), done. dangling blob e06a11799a6b06633e506611b184d15d31b71103 dangling blob 13ba2e4924d917df123084aa2ebb0931f9afd8b0 It's got dangling blobs; that can't be good. > In 3137 cases the deduced author is different from the committer. That's > 23% of commits, which is a completely reasonable density of patches > contributed by non-devs. I couldn't determine the percent without some extra effort because the committer (domain) here is sfeam, markisch, broeker, etc., while the author (range) is the full names of those individuals. Dan |
|
From: Daniel J S. <dan...@ie...> - 2017-10-16 07:01:17
|
On 10/16/2017 01:32 AM, Bastian Märkisch wrote: > Dear Eric, dear Daniel, > > That sounds very promising! I am volunteering to inspect-by-eye (a subset) > of the new attributions (but have only limited time). > > One thing I like to point out is that in some cases the ChangeLog entry was > accidentally omitted (e.g. because the file changes were not saved). So it > might have turned up in the follw-up checkin, which now may lead to > incorrect attributions. Some may turn out correct. Some may have the authorship associated with the clean up, i.e., off by one or two but still close to the original modification. > Is it possible to check for such cases? Maybe for > inspection by eye? I know with the utility I wrote it could be modified pretty easily to indicate the changesets where the ChangeLog didn't change. It might be a pretty long list though. It seems to me, based on the little bit I saw, that near the start of the project there were long strings of mods and the the ChangeLog was updated. This may be where Eric's approach has an advantage, that rather than the diff hunk it sounds like he's pulling out the actual snapshot of the ChangeLog at the time the changeset was made. That might sweep some more changesets under the same author. Dan |
|
From: Eric S. R. <es...@th...> - 2017-10-16 09:36:19
|
Daniel J Sebald <dan...@ie...>:
> This may be where Eric's approach has an advantage, that rather than the
> diff hunk it sounds like he's pulling out the actual snapshot of the
> ChangeLog at the time the changeset was made. That might sweep some more
> changesets under the same author.
That is correct. My code walks the commit list looking at the actual
blobs associated with each changeset. And those are whole-file
copies, not diffs.
This should not fail except in a couple of unlikely cases
(1) A malformed ChangeLog entry header (I've found two of those).
(2) Somebody tweaks the middle of a ChangeLog file (e.g. to fix a typo) without
adding a new top entry and it is *not* a changeset modifying only
ChangeLogs.
(3) Too-small fuzz (time window for CVS commits to be considered close
enough to coalesce into a changeset) results in a changest being
broken into pieces. It's hard to know how often this happens, but
I think it's pretty rare.
One of my metrics for a conversion that was worth doing is when I find a good
reason to write and field-test a new surgical primitive. GNUPLOT has, a bit
to my surprise, been interesting twice: one new primitive is the Changelog
miner, the other is a command to incorporate tarballs as new commits.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
|
|
From: Eric S. R. <es...@th...> - 2017-10-16 09:55:14
|
Daniel J Sebald <dan...@ie...>: > OK, we're on the same page. There are all sorts of conditions I could > imagine having accounted for, but I think at some point its covering corner > cases that become increasingly unlikely. We'll have opportunity to review > how well the authorship has worked out. Agreed. One of you guys should do an eyeball sanity check after I first push the repository. I'll probably do that later today. There is a sneaky way to force-push a surgically modified repo to SourceForge, but it relies on having ssh access to the repo directory. I'll have to check for that feature still being enabled before I push. BTW, I now have no fewer than 6 early releases in the repository tail: 1.10A, 2.0, 3.0, 3.1, 3.2, and 3.5. If any of you can turn up more ancient versions, now would be a good time for it. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Pieter-Tjerk de B. <p.t...@ut...> - 2017-10-16 12:07:36
|
On Mon, Oct 16, 2017 at 05:55:08AM -0400, Eric S. Raymond wrote: > BTW, I now have no fewer than 6 early releases in the repository tail: > 1.10A, 2.0, 3.0, 3.1, 3.2, and 3.5. If any of you can turn up more > ancient versions, now would be a good time for it. Well, as Ethan pointed out, the version I have at http://wwwhome.ewi.utwente.nl/~ptdeboer/tmp/gnuplot-2.0.tar.gz seems to be 1.1.0 from January 26, 1987, predating the others, so I guess including it would make sense. In the meantime I found out where I got it from, back in 1999: ftp://ftp.bu.edu/pub/mirrors/umich.edu/Public/html/apollo/gnuplot-2.0.tar.gz But that file is no longer there. B.t.w., with only a few trivial changes, this version still compiles on a modern Linux system, with working postscript and tek40xx output. Fun to see both how much and how little has changed in 30 years... Regards, Pieter-Tjerk |
|
From: Eric S. R. <es...@th...> - 2017-10-16 15:23:30
|
Pieter-Tjerk de Boer <p.t...@ut...>: > Well, as Ethan pointed out, the version I have at > http://wwwhome.ewi.utwente.nl/~ptdeboer/tmp/gnuplot-2.0.tar.gz > seems to be 1.1.0 from January 26, 1987, predating the others, so I guess > including it would make sense. The mainplot directory looks like a primitive GNUPLOT, all right. Do you have any idea what that stuff in the other two drectories is? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: sfeam <sf...@us...> - 2017-10-16 15:36:13
|
On Monday, 16 October 2017 11:23:22 Eric S. Raymond wrote: > Pieter-Tjerk de Boer <p.t...@ut...>: > > Well, as Ethan pointed out, the version I have at > > http://wwwhome.ewi.utwente.nl/~ptdeboer/tmp/gnuplot-2.0.tar.gz > > seems to be 1.1.0 from January 26, 1987, predating the others, so I guess > > including it would make sense. > > The mainplot directory looks like a primitive GNUPLOT, all right. Do you > have any idea what that stuff in the other two drectories is? The help directory contains a bunch of small files, each with text help on one topic. The gnuplot "help" command didn't exist yet. The plotdocs directory contains a utility and makefile that stitches those help files together into nroff format. Ethan |
|
From: Eric S. R. <es...@th...> - 2017-10-16 15:45:02
|
sfeam <sf...@us...>: > On Monday, 16 October 2017 11:23:22 Eric S. Raymond wrote: > > Pieter-Tjerk de Boer <p.t...@ut...>: > > > Well, as Ethan pointed out, the version I have at > > > http://wwwhome.ewi.utwente.nl/~ptdeboer/tmp/gnuplot-2.0.tar.gz > > > seems to be 1.1.0 from January 26, 1987, predating the others, so I guess > > > including it would make sense. > > > > The mainplot directory looks like a primitive GNUPLOT, all right. Do you > > have any idea what that stuff in the other two drectories is? > > The help directory contains a bunch of small files, each with text help > on one topic. The gnuplot "help" command didn't exist yet. > > The plotdocs directory contains a utility and makefile that stitches those help > files together into nroff format. How, if at all, do you want this included? The whole thing? The mainplot directory only? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
