gnuplot-beta — Developers and beta testers of new gnuplot code

Trial git repo is back up

[<es...@th...>]

Trial git repo is back up, with the conversion bug I previously noted fixed.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

In recent years it has been suggested that the Second Amendment
protects the "collective" right of states to maintain militias, while
it does not protect the right of "the people" to keep and bear arms.
If anyone entertained this notion in the period during which the
Constitution and the Bill of Rights were debated and ratified, it
remains one of the most closely guarded secrets of the eighteenth
century, for no known writing surviving from the period between 1787
and 1791 states such a thesis.
        -- Stephen P. Halbrook, "That Every Man Be Armed", 1984

Re: Trial git repository is up on SourceForge

[Eric S. R. <es...@th...>]

sfeam <sf...@us...>:
> Is it possible to see anything other than branch/tag identifiers
> through their interface?   
> Everything I click on just returns    
>   Error 404
>   We're sorry but we weren't able to process this request.

I wiped the repo so I could push a version with the most recent conversion
bug fixed.  As soon as I know what to do with the 1.1 code I'll push another
conversion.
-- 
		<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.

Re: Trial git repository is up on SourceForge

[Daniel J S. <dan...@ie...>]

On 10/16/2017 11:07 AM, sfeam via gnuplot-beta wrote:
> On Monday, 16 October 2017 08:21:40 Eric S. Raymond wrote:
>> A trial git repository is up on SourceForge.
>>
>> Now that I can look at it through their interface, I see it needs some
>> additional work.  Some files in the archaic releases have leaked into
>> the modern ones. I shall need to insert a shim commit that deletes
>> them.
>>
>> Everybody should eyeball this looking for other malformations -- wrong
>> authorship attributions, in particular.
>>
> 
> Is it possible to see anything other than branch/tag identifiers
> through their interface?
> Everything I click on just returns
>    Error 404
>    We're sorry but we weren't able to process this request.

That's all I'm seeing as well.  Is there restrictive access such that 
someone needs to login to access the repository?

Also, the html and git addresses for clone don't go anywhere:
sebald@ ~/sourceforge_test_1 $ git clone 
https://git.code.sf.net/p/gnuplot/git-main gnuplot-git-main
Cloning into 'gnuplot-git-main'...
fatal: repository 'https://git.code.sf.net/p/gnuplot/git-main/' not found

Dan

Re: Trial git repository is up on SourceForge

[sfeam <sf...@us...>]

On Monday, 16 October 2017 08:21:40 Eric S. Raymond wrote:
> A trial git repository is up on SourceForge.
> 
> Now that I can look at it through their interface, I see it needs some
> additional work.  Some files in the archaic releases have leaked into
> the modern ones. I shall need to insert a shim commit that deletes
> them.
> 
> Everybody should eyeball this looking for other malformations -- wrong
> authorship attributions, in particular.
> 

Is it possible to see anything other than branch/tag identifiers
through their interface?   
Everything I click on just returns    
  Error 404
  We're sorry but we weren't able to process this request.

	Ethan

Re: Release timestamps for archaic tarballs

[Eric S. R. <es...@th...>]

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.

Re: Release timestamps for archaic tarballs

[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.

	Ethan

Re: Release timestamps for archaic tarballs

[Eric S. R. <es...@th...>]

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.

Trial git repository is up on SourceForge

[<es...@th...>]

A trial git repository is up on SourceForge.

Now that I can look at it through their interface, I see it needs some
additional work.  Some files in the archaic releases have leaked into
the modern ones. I shall need to insert a shim commit that deletes
them.

Everybody should eyeball this looking for other malformations -- wrong
authorship attributions, in particular.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The world is filled with violence. Because criminals carry guns, we
decent law-abiding citizens should also have guns. Otherwise they will
win and the decent people will lose.
        -- James Earl Jones

Re: Release timestamps for archaic tarballs

[Pieter-Tjerk de B. <p.t...@ut...>]

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

Re: Release timestamps for archaic tarballs

[Eric S. R. <es...@th...>]

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.

Re: AW: Release timestamps for archaic tarballs

[Eric S. R. <es...@th...>]

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.

Re: AW: Repo conversion procedure is basically done

[Daniel J S. <dan...@ie...>]

On 10/16/2017 01:42 AM, Bastian Märkisch wrote:
> To my knowledge there are a number of files in the CVS repository which are treated as text, but shouldn't be.  They either have to have a distinct end-of-line marker (like win/gnuplot.iss) or they really contain binary data (applies e.g. to some files in the demo directory).  That typically isn't a problem in *nix systems, but on Windows because some CVS programs try to be clever in adjusting the EOL marker.  Can that be taken care of?  If yes, I can come up with a list. Please excuse my ignorance if this isn't an issue with git at all.
> 
>    Bastian

git also tries to be clever by default (core.autocrlf).  The following 
sounds like what you are referring to:

https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git

Dan



>> -----Ursprüngliche Nachricht-----
>> Von: Eric S. Raymond [mailto:es...@th...]
>> Gesendet: Sonntag, 15. Oktober 2017 21:01
>> An: To...@th...:sfeam <sf...@us...>
>> Cc: gnu...@li...
>> Betreff: Repo conversion procedure is basically done
>>
>> I can now produce a git version of the GNUPLOT repository with the following
>> properties:
>>
>> (1) Content correctness, as previously discussed.
>>
>> (2) All committer fields are full DVCS-style IDs.
>>
>> (3) Over 3100 other authorship attributions are recovered from
>>      ChangeLog files.
>>
>> (3) The faq module contents is merged in.
>>
>> (4) Three very early releases that servived only as tarballs are
>>      glued to the tail of the repository.
>>
>> (5) An annotated tag marks the comversion point.
>>
>> I think this is basically done, unless Ethan wants me to glue more tarballs to its
>> tail.  It looks pretty good in gitk.
>>
> (snip)
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: AW: Release timestamps for archaic tarballs

[Daniel J S. <dan...@ie...>]

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

Re: Release timestamps for archaic tarballs

[Daniel J S. <dan...@ie...>]

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

AW: Repo conversion procedure is basically done

[Bastian M. <bma...@we...>]

To my knowledge there are a number of files in the CVS repository which are treated as text, but shouldn't be.  They either have to have a distinct end-of-line marker (like win/gnuplot.iss) or they really contain binary data (applies e.g. to some files in the demo directory).  That typically isn't a problem in *nix systems, but on Windows because some CVS programs try to be clever in adjusting the EOL marker.  Can that be taken care of?  If yes, I can come up with a list. Please excuse my ignorance if this isn't an issue with git at all.

  Bastian

> -----Ursprüngliche Nachricht-----
> Von: Eric S. Raymond [mailto:es...@th...]
> Gesendet: Sonntag, 15. Oktober 2017 21:01
> An: To...@th...:sfeam <sf...@us...>
> Cc: gnu...@li...
> Betreff: Repo conversion procedure is basically done
> 
> I can now produce a git version of the GNUPLOT repository with the following
> properties:
> 
> (1) Content correctness, as previously discussed.
> 
> (2) All committer fields are full DVCS-style IDs.
> 
> (3) Over 3100 other authorship attributions are recovered from
>     ChangeLog files.
> 
> (3) The faq module contents is merged in.
> 
> (4) Three very early releases that servived only as tarballs are
>     glued to the tail of the repository.
> 
> (5) An annotated tag marks the comversion point.
> 
> I think this is basically done, unless Ethan wants me to glue more tarballs to its
> tail.  It looks pretty good in gitk.
> 
(snip)

AW: Release timestamps for archaic tarballs

[Bastian M. <bma...@we...>]

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.
> 

Re: Release timestamps for archaic tarballs

[Eric S. R. <es...@th...>]

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.

Re: Release timestamps for archaic tarballs

[Daniel J S. <dan...@ie...>]

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

Repo conversion procedure is basically done

[<es...@th...>]

I can now produce a git version of the GNUPLOT repository with the
following properties:

(1) Content correctness, as previously discussed.

(2) All committer fields are full DVCS-style IDs.

(3) Over 3100 other authorship attributions are recovered from
    ChangeLog files.

(3) The faq module contents is merged in.

(4) Three very early releases that servived only as tarballs are
    glued to the tail of the repository.

(5) An annotated tag marks the comversion point.

I think this is basically done, unless Ethan wants me to glue more
tarballs to its tail.  It looks pretty good in gitk.

I'm appending the current version of my conversion script.
Stakeholders should read it carefully to check my assumptions.

#!/bin/sh
#
# Convert the gnuplot CVS repository.  Results go in gnuplot
#
# Requires the repository head version of reposurgeon.
# The following archaic release tarballs must also be present:
# gnuplot-1.10A.tar.gz
# gnuplot-2.0.tar.gz
# gnuplot-3.5.tar.gz
#
echo "Clear the decks: `date`"
rm -fr gnuplot gnuplot-cvs faq-cvs faq-cvs-git

echo "Resync the local repo copies: `date`"
cvssync gnuplot.cvs.sourceforge.net:/cvsroot/gnuplot gnuplot
mv gnuplot gnuplot-cvs
mkdir gnuplot-cvs/CVSROOT
cvssync gnuplot.cvs.sourceforge.net:/cvsroot/gnuplot faq
mv faq faq-cvs

cat >gnuplot.map <<EOF
amai = Alexander Mai <st0...@hr...>  Europe/Berlin
broeker =  Hans-Bernhard Broeker <br...@us...>  Europe/Berlin
cgaylord = Clark Gaylord <cga...@vt...>  US/Eastern
janert = Philipp K. Janert <ja...@ie...>  US/Pacific
joze = Johannes Zellner <joh...@ze...>
juhaszp = Peter Juhasz <ju...@us...>
hecking = Lars Hecking <lhe...@nm...>  Europe/Dublin
lhecking = Lars Hecking <lhe...@nm...>  Europe/Dublin
lodewyck =  Jérôme Lodewyck <lod...@us...>
markisch = Bastian Maerkisch <bma...@we...>  Europe/Berlin
mikulik = Petr Mikulik <mi...@ph...>  Europe/Prague
persquare = Per Persson <per...@ma...>
sfeam = Ethan A Merritt <merritt@u.washington.edu>  US/Pacific
tlecomte = Timothee Lecomte <tim...@en...>  Europe/Paris
vanzandt = James R. Van Zandt <jr...@va...>
#vanzandt = James R. Van Zandt <jr...@de...>
uid26705 = Petr Mikulik <mi...@ph...>  Europe/Prague
uid93776 = Ethan A Merritt <merritt@u.washington.edu>  US/Pacific
EOF

echo "Build a git repo with remapped committer IDs: `date`"
# gnuplot 1.1.0A	"Thu May 18 21:57:24 MST 1989" (UTC-7)
# gnuplot 2.0.0 	"Wed Mar  7 22:18:59 EST 1990" (UTC-5)
# gnuplot 3.5  		"Fri Aug 27 05:21:33 GMT 1993"
reposurgeon <<EOF
echo 1
prefer cvs
read gnuplot-cvs
authors read <gnuplot.map
prefer git
@min(=C) incorporate gnuplot-3.5.tar.gz
@min(=C) setfield commitdate 1993-08-27T05:21:33Z
@min(=C) incorporate gnuplot-2.0.tar.gz
@min(=C) setfield commitdate 1990-03-09T03:18:59Z
@min(=C) incorporate gnuplot-1.10A.tar.gz
@min(=C) setfield commitdate 1989-06-19T04:57:24Z
rebuild gnuplot
EOF

echo "Check in the FAQ and Makefile, then make a transition commit: `date`"
# Not worth trying to do more than this because the history of the FAQ
# doesn't seem to be recoverable due to Yet Another Wacky CVS Problem
cvsconvert faq-cvs
cd gnuplot
mkdir faq
cp ../faq-cvs-git/faq.tex faq
cp ../faq-cvs-git/Makefile faq
git add -f faq/faq.tex faq/Makefile
git commit -F - <<EOF
Check in faq.tex and Makefile from the old CVS faq module, in directory faq.
EOF
git tag -a -F - git-conversion <<EOF
Conversion to git.

Performed on `date --rfc-3339=date` by Eric S. Raymond <es...@th...>
using cvs-fast-export and reposurgeon.
EOF
cd ..

rm gnuplot.map
echo "Done: `date`"

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Government is not reason, it is not eloquence, it is force; like fire, a
troublesome servant and a fearful master. Never for a moment should it be left
to irresponsible action."
	-- George Washington, in a speech of January 7, 1790

Re: Block conditional expressions (was: Scoping of variables in block constructs)

[sfeam <sf...@us...>]

On Sunday, 15 October 2017 10:19:11 Achim Gratz wrote:
> Achim Gratz writes:
> > Ethan A Merritt via gnuplot-beta writes:
> >>> Also, why is there no block "else if" or maybe even "elsif"?
> >>
> >> No particular reason.  
> >> So far as I can see, all it would gain is to reduce the number of 
> >> required curly brackets by one pair.
> >> Is there something more subtle I'm missing?
> >
> > Maybe.  If the conditional expressions themselve need to be nested, you
> > will either end up with unwieldy formatting
> >
> > if (…) {
> > else {
> >   if (…) {
> >   else {
> >    if (…) {
> >    else {
> >     if (…) {
> >     else {
> >       if (…) {
> >       else {
> >         if (…) {
> >
> > or you'll need to explicitly repeat (and revert) the logical expression
> > from the former branches.
> 
[snip] 
> Example for that latter point:
> So with that hypothetical elsif keyword, things would look a lot saner
> and be less error-prone, I think:
> 
> --8<---------------cut here---------------start------------->8---
> if (days <= 1/24.) {
>   set xtics  15/60.
>   set mxtics 3
> } elsif (days <= 4/24.) {
>   set xtics  1
>   set mxtics 12
> } elsif (days <= 2) {
>   set xtics  1
>   set mxtics 4
> } elsif (days <= 2) {
>   set xtics  2
>   set mxtics 8
> } elsif (days <= 6) {
>   set xtics  6
>   set mxtics 12
> } elsif (days <= 13) {
>   set xtics  12
>   set mxtics 12
> } elsif (days <= 27) {
>   set xtics  24
>   set mxtics 8
> } elsif (days <= 41) {
>   set xtics  24
>   set mxtics 4
> } else {
>   set xtics  7*24
>   set mxtics 14
> }
> --8A<---------------cut here---------------end--------------->8---

There are other possibilities using the existing syntax elements.
For example:

do for [i=0:0] {

if (days <= 1/24.) {
  set xtics  15/60.
  set mxtics 3
  break
} 
if (days <= 4/24.) {
  set xtics  1
  set mxtics 12
 break
}
if (days <= 2) {
  set xtics  1
  set mxtics 4
  break
}
if (days <= 2) {
  set xtics  2
  set mxtics 8
  break
} 
if (days <= 6) {
  set xtics  6
  set mxtics 12
  break
} 
if (days <= 13) {
  set xtics  12
  set mxtics 12
  break
} 
if (days <= 27) {
  set xtics  24
  set mxtics 8
  break
} 
if (days <= 41) {
  set xtics  24
  set mxtics 4
  break
}
else {
  set xtics  7*24
  set mxtics 14
  break
}

}

Essentially a switch/case construct.

	Ethan


> Achim.
> 

[BUG] config.ac

[Achim G. <Str...@ne...>]

The configury supposedly tries to find TEXDIR via kpsexpand, but that
code never gets run if $prefix is set. I think the code should rather do
this:

--8<---------------cut here---------------start------------->8---
--- origsrc/gnuplot-branch-5-2-stable/configure.ac	2017-10-14 02:00:11.000000000 +0200
+++ src/gnuplot-branch-5-2-stable/configure.ac	2017-10-15 17:31:46.192683400 +0200
@@ -146,11 +146,11 @@ if test "$with_latex" = yes; then
     [texdir is not given and there is no kpsexpand, please tell where to install])
   dnl texdir has priority
   if test "$TEXDIR" = "no"; then
-    if test "x$prefix" != "xNONE"; then
-      TEXDIR=${prefix}/share/texmf
-    else
-      TEXDIR=`$KPSEXPAND '$TEXMFLOCAL'`
-      if test "x$TEXDIR" = "x" -o "$TEXDIR" = "\$TEXMFLOCAL"; then
+    TEXDIR=`$KPSEXPAND '$TEXMFLOCAL'`
+    if test "x$TEXDIR" = "x" -o "$TEXDIR" = "\$TEXMFLOCAL"; then
+      if test "x$prefix" != "xNONE"; then
+        TEXDIR=${prefix}/share/texmf
+      else
         TEXDIR=${ac_default_prefix}/share/texmf
       fi
     fi
--8<---------------cut here---------------end--------------->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Block conditional expressions (was: Scoping of variables in block constructs)

[Achim G. <Str...@ne...>]

Achim Gratz writes:
> Ethan A Merritt via gnuplot-beta writes:
>>> Also, why is there no block "else if" or maybe even "elsif"?
>>
>> No particular reason.  
>> So far as I can see, all it would gain is to reduce the number of 
>> required curly brackets by one pair.
>> Is there something more subtle I'm missing?
>
> Maybe.  If the conditional expressions themselve need to be nested, you
> will either end up with unwieldy formatting
>
> if (…) {
> else {
>   if (…) {
>   else {
>    if (…) {
>    else {
>     if (…) {
>     else {
>       if (…) {
>       else {
>         if (…) {
>
> or you'll need to explicitly repeat (and revert) the logical expression
> from the former branches.


Example for that latter point:

--8<---------------cut here---------------start------------->8---
if (days <= 1/24.) {
  set xtics  15/60.
  set mxtics 3
}
if (days > 1/24. && days <= 4/24.) {
  set xtics  1
  set mxtics 12
}
if (days > 4/24. && days <= 2) {
  set xtics  1
  set mxtics 4
}
if (days > 12/24. && days <= 2) {
  set xtics  2
  set mxtics 8
}
if (days > 2 && days <= 6) {
  set xtics  6
  set mxtics 12
}
if (days > 6 && days <= 13) {
  set xtics  12
  set mxtics 12
}
if (days > 13 && days <= 27) {
  set xtics  24
  set mxtics 8
}
if (days > 27 && days <= 41) {
  set xtics  24
  set mxtics 4
}
if (days > 41) {
  set xtics  7*24
  set mxtics 14
}
--8<---------------cut here---------------end--------------->8---

So with that hypothetical elsif keyword, things would look a lot saner
and be less error-prone, I think:

--8<---------------cut here---------------start------------->8---
if (days <= 1/24.) {
  set xtics  15/60.
  set mxtics 3
} elsif (days <= 4/24.) {
  set xtics  1
  set mxtics 12
} elsif (days <= 2) {
  set xtics  1
  set mxtics 4
} elsif (days <= 2) {
  set xtics  2
  set mxtics 8
} elsif (days <= 6) {
  set xtics  6
  set mxtics 12
} elsif (days <= 13) {
  set xtics  12
  set mxtics 12
} elsif (days <= 27) {
  set xtics  24
  set mxtics 8
} elsif (days <= 41) {
  set xtics  24
  set mxtics 4
} else {
  set xtics  7*24
  set mxtics 14
}
--8<---------------cut here---------------end--------------->8---


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Release timestamps for archaic tarballs

[sfeam <sf...@us...>]

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

Re: Release timestamps for archaic tarballs

[Pieter-Tjerk de B. <p.t...@ut...>]

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

Re: Release timestamps for archaic tarballs

[Eric S. R. <es...@th...>]

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.