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

Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

sfeam <sf...@us...>:
> It looks to me that there is general consensus that 
> 
> - we should move to git,
> 
> - that Eric Raymond's toolset is the best way to do that, and that 
> 
> - if Eric himself is willing to guide the conversion it has the greatest chance of success.
> 
> So let's do that.

This is a good time for me to do it.  NTPsec 1.0 just shipped and our PM said
he didn't want to see any commits for a week. :-)

> Eric - several people responded with bits and pieces of meta-info that
> you asked for.   Do you have everything you need?

Not yet.

1. Here's the committer map:

janert = Philipp K. Janert <ja...@us...>
uid225733 = Ethan Merritt <merritt@u.washington.edu>
uid93776 = Ethan Merritt <merritt@u.washington.edu>
mikulik = Petr Mikulik <mi...@ph...>
markisch = Bastian Maerkisch  <bma...@we...>
tlecomte = Timothee Lecomte <tim...@en...>
persquare = Per Persson <per...@us...>
amai = Alexander Mai <am...@us...>
lhecking = Lars Hecking <lhe...@us...>
cgaylord = Clark Gaylord <cga...@vt...>
uid26705 = Petr Mikulik <mi...@ph...>
juhaszp = Peter Juhasz  <ju...@us...>
vanzandt = James R. Van Zandt <van...@us...>
sfeam = Ethan Merritt <merritt@u.washington.edu>
lodewyck = J´erˆome Lodewyck <lod...@us...>
joze = Joze Duhovnik <jo...@us...>

   Ideally, we'd enhance this in two ways.  First, those of you with preferred
   email addresses should make sure this points at the one you want. Second,
   we'd add timezone offsets.

2. If you want the authorship data to be right, somebody's going to have to
   write code to grovel through the ChangeLog(s) and generate
   date/author/filelist triples. (Then I'll have to write some custom Python
   to use those.) Though maybe this isn't worth it - the only
   ChangeLog I can see only seems to cover 1998-2000.

3. There was some talk of gluing to the history old releases that only
   exist as tarballs.  That can be done, but I need those tarballs.

3. I'm not clear on what ought to be excised from the repo. HBBroeker
   mentions dropping the faq module.  Someone else (I think Mojca) had
   a pre-conversion sript that stripped out some stuff.  A set of excisions
   you guys agree on - ideally expressed as a pre-conversion script modifying
   the repo - is one thing we need.

4. The following paragraph from HBBroeker worries me a little:

   > I've tried out reposurgen on our repository (with the "faq" module 
   > removed), and it seems to work almost perfectly.  "make allcompare" 
   > showed nothing missing from the git version.  The original import 
   > pseudo-branch GNUPLOT_BETA is, correctly, dropped, all other tags and 
   > branch tips compare equal, and .cvsignore files are also taken care of.

   I didn't use reposurgeon, I used cvsconvert.  This is a wrapper script 
   in the reposurgeon distribution that also uses cvs-fast-export as an
   engine,  but is specialized for CVS and does more detailed correctness
   checking than allcompare.  What worries me is that *my* conversion didn't
   look quite so smooth - it was not clear that GNUPLOT_BETA was dropped, and
   there were some files on ther gitspace side that weren't in CVS (probably
   due to a botched CVS delete).  This needs to be further investigated.

> Do I understand correctly that the git repository can be created 
> initially anywhere that you find convenient  and then replicated to 
> SourceForge afterwards?

That understanding is correct.

> Should we set a freeze date for the existing CVS source [*]?

That's not important yet.  Once I have the conversion process
scripted, you can basically choose any time to cut over and it
will all get done in a time on the close order of two hours.

> Anything else that needs to be done in preparation?

For the conversion itself, no.  You guys need to make a hosting site
decision, then I need to have push and force-push privileges so I can drop
the git repo in place.
-- 
		<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: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

[Clark G. <cga...@vt...>]

I agree with freeze. I suggest that if Eric is willing to perform the final
production migration then he should control that timing (else Mojca,
probably best for you to take the helm?) We may have a few days where the
change is happening, etc that we're frozen (could be just one day, but
giving a little buffer).

After the migration I'll plan to grab a final CVS copy to put into
historical.

Yes one of the really great things about git/if is that repo clone is a
first class citizen, so we can (indeed *will*) have several places the repo
resides. So yes the conversion could happen anywhere. Similarly, merge is
not nearly the horror you would probably associate it with if you've ever
done it with CVS or svn; I still feel my stomach knot up thinking of the
pain unborking a CVS repo following a merge attempt gone bad many years ago.

I'm a little concerned with the longevity of SourceForge, but from our
original discussion of the matter I'll recall the critical decision rule:
support what Ethan wants to work with. :-) Certainly keeping the
environment on SF is the easiest option for me.

[Btw Eric: I *loved* your article on heirloom software and ADVENT last
month in Linux Journal! Thanks for that.]

Regards
Clark

--
Clark Gaylord
cga...@vt...
... Autocorrect may have improved this message
    Brevity should not be interpreted as curtness ...

On Oct 10, 2017 23:57, "sfeam" <sf...@us...> wrote:

> On Monday, 09 October 2017 21:54:42 Hans-Bernhard Bröker wrote:
> >
> > ESR's tool, cvs-fast-import, which "man git-cvsimport" itself recommends
> > to be used instead, shows none of those messages, so I believe that
> > these can be fixed by a change towards cvs-fast-import.
> >
> > I've tried out reposurgen on our repository (with the "faq" module
> > removed), and it seems to work almost perfectly.  "make allcompare"
> > showed nothing missing from the git version.  The original import
> > pseudo-branch GNUPLOT_BETA is, correctly, dropped, all other tags and
> > branch tips compare equal, and .cvsignore files are also taken care of.
> >
> > All in all, I'm quite impressed by this tool.
>
> It looks to me that there is general consensus that
>
> - we should move to git,
>
> - that Eric Raymond's toolset is the best way to do that, and that
>
> - if Eric himself is willing to guide the conversion it has the greatest
> chance of success.
>
> So let's do that.
>
> There is no obvious consensus on where the repository should live.
> I'm going to step in and vote to stay with SourceForge for now
> because I know how to manage their infrastructure for issue trackers and
> putting out a release.
>
> Eric - several people responded with bits and pieces of meta-info that
> you asked for.   Do you have everything you need?
>
> Do I understand correctly that the git repository can be created
> initially anywhere that you find convenient  and then replicated to
> SourceForge afterwards?  If not then maybe we do need additional
> discussion about where to do this.
>
> Should we set a freeze date for the existing CVS source [*]?
> Anything else that needs to be done in preparation?
>
>         Ethan
>
>
> [*] freeze concerns -
>
> 5.2:  I want to package up the current 5.2 branch as an incremental
> release, just so that's out of the way and there is no time pressure after
> the conversion while we deal with any cleanup or fallout.  That takes
> very little time, but I need to know when to do it.
>
> 5.3:  So far as I know this is as good a time as any to freeze.
> The current build is usable as it stands.
>
> Older branches:  There should not be any activity there anyhow.
>
>

Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On Monday, 09 October 2017 21:54:42 Hans-Bernhard Bröker wrote:
> 
> ESR's tool, cvs-fast-import, which "man git-cvsimport" itself recommends 
> to be used instead, shows none of those messages, so I believe that 
> these can be fixed by a change towards cvs-fast-import.
> 
> I've tried out reposurgen on our repository (with the "faq" module 
> removed), and it seems to work almost perfectly.  "make allcompare" 
> showed nothing missing from the git version.  The original import 
> pseudo-branch GNUPLOT_BETA is, correctly, dropped, all other tags and 
> branch tips compare equal, and .cvsignore files are also taken care of.
> 
> All in all, I'm quite impressed by this tool.

It looks to me that there is general consensus that 

- we should move to git,

- that Eric Raymond's toolset is the best way to do that, and that 

- if Eric himself is willing to guide the conversion it has the greatest chance of success.

So let's do that.

There is no obvious consensus on where the repository should live.
I'm going to step in and vote to stay with SourceForge for now 
because I know how to manage their infrastructure for issue trackers and
putting out a release.   

Eric - several people responded with bits and pieces of meta-info that
you asked for.   Do you have everything you need?

Do I understand correctly that the git repository can be created 
initially anywhere that you find convenient  and then replicated to 
SourceForge afterwards?  If not then maybe we do need additional
discussion about where to do this.

Should we set a freeze date for the existing CVS source [*]?
Anything else that needs to be done in preparation?

	Ethan


[*] freeze concerns -

5.2:  I want to package up the current 5.2 branch as an incremental
release, just so that's out of the way and there is no time pressure after
the conversion while we deal with any cleanup or fallout.  That takes
very little time, but I need to know when to do it.

5.3:  So far as I know this is as good a time as any to freeze.
The current build is usable as it stands.

Older branches:  There should not be any activity there anyhow.

Re: Scoping of variables in block constructs

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

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

--8<---------------cut here---------------start------------->8---
if (…) {
else {
  if (…) {
  else {
   if (…) {
   else {
    if (…) {
    else {
      if (…) {
      else {
        if (…) {
--8<---------------cut here---------------end--------------->8---

or you'll need to explicitly repeat (and revert) the logical expression
from the former branches.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Scoping of variables in block constructs

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

Hans-Bernhard Bröker writes:
>> This seems all unnecessarily involved, so maybe I should rather ask if
>> there's a way to build up an explicit tics list piece by piece rather
>> than having to feed everyting as one single giant string?
>
> You're looking for "set xtics add ..."

Indeed.  Thanks.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On 10/09/2017 04:14 PM, Daniel J Sebald wrote:

> BUT, I may have hit upon a more reliable and straightforward approach 
> from an automated script standpoint.  It's based on what I pointed out 
> about the ChangeLog file typically being listed in the diff hunks. 
> Experiment with the following git command:
> 
> git log -p --unified=20 ChangeLog
> 
> That gives us the log record for the ChangeLog, printing out the diff 
> hunks in the ChangeLog and with enough context lines such that it 
> displays back to the Date/Contributor/Address line.  (Use --unified=30 
> if one thinks there could be that length of comment.)
> 
> With such a record, the script can search for the changes in the file 
> (i.e., "+" as character in the first location of the line), and then 
> search backward for the Date/Contributor/Address info.  With a few 
> heuristic rules, this might be rather accurate, in theory.
Mojca, HBB,

I've written a short C++ utility to extract the authorship info from the 
ChangeLog diff hunks per changeset and posted the code here:

https://sourceforge.net/p/gnuplot/patches/763/

along with a file containing the g++ command to compile it.  Once built, 
type

git_changelog_author --help

for a description of how to use it.  Basically

git log -p --unified=50 ChangeLog > ChangeLog.diff
git_changelog_author ChangeLog.diff > author.txt

will give a condensed list of git ID and authorship information, 
whitespace reduce to a single character and no whitespace within the 
email address.

Give it a try.  It's very fast.  Commit the program to the repository in 
some utility directory, if you like, then we can tweak the code for your 
use.  Or, just post new versions to the patch report.

Dan

Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On 10/09/2017 03:05 PM, Hans-Bernhard Bröker wrote:
> Am 09.10.2017 um 20:08 schrieb Daniel J Sebald:
> 
> 
>> The above is a good match in terms of files that changed and the 
>> change log for that day.  Hence, in this case we would substitute 
>> Author hhhh bbbbbb  <xxxxxx@xxxxxx> for bbbbbb <bbbbbb>
> 
> It's also kind of a non-example, given that with an authormap file in 
> place, there would be nothing left to substitute: i.e. my full name and 
> address would already be in git log.

Yes, in this case the Author info is replace with the same exact info. 
But I was thinking generally.  I.e., most non-maintainer contributions 
would also be a group of files.  Ethan would have the most insight on 
how this is characterized.  The problem is that contributions which only 
change a single file could, with higher probability, be on a day when 
someone else made a modification to the same file.

BUT, I may have hit upon a more reliable and straightforward approach 
from an automated script standpoint.  It's based on what I pointed out 
about the ChangeLog file typically being listed in the diff hunks. 
Experiment with the following git command:

git log -p --unified=20 ChangeLog

That gives us the log record for the ChangeLog, printing out the diff 
hunks in the ChangeLog and with enough context lines such that it 
displays back to the Date/Contributor/Address line.  (Use --unified=30 
if one thinks there could be that length of comment.)

With such a record, the script can search for the changes in the file 
(i.e., "+" as character in the first location of the line), and then 
search backward for the Date/Contributor/Address info.  With a few 
heuristic rules, this might be rather accurate, in theory.  Let's look 
at some examples.

Here's one that's pretty simple, the Author info is the first modified line:

-------------------------
commit 87ca52fd56cf60be023642ad2664390affd5d896
Author: sfsfsf <sfsfsf>
Date:   Mon Sep 4 05:57:37 2017 +0000

     Use AC_MSG_RESULT rather than AC_MSG_WARN

diff --git a/ChangeLog b/ChangeLog
index f771b54..8cc8ab9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,20 +1,25 @@
+2017-09-03  Daniel J Sebald <xxxxxx@xxxxxx>
+
+	* configure.ac:  Use AC_MSG_RESULT rather than AC_MSG_WARN to report
+	which Qt version will be used.
+
  2017-09-03  Ethan Mmmm  <xxxxxx@xxxxxx>

  	* src/time.c (xstrftime):  The variant format specs for time
  	%tH %tM did not behave as documented in that hours wrapped at 24 and
  	minutes at 60 if the decimal precision modifier was missing.

  2017-09-02  Ethan Mmmm  <xxxxxx@xxxxxx>

  	* src/axis.c (parse_range eval_link_function) docs/gnuplot.doc:
  	Attempt to handle the case of linked axes (x+x2 or y+y2) and an in-line
  	range specifier in the plot statement.  This fix only addresses simple
  	cases, such as
  	    set link x2;  plot [x=min:max] something-using-x2 axes x2y1
  	Recommend to use separate "set xrange ... set yrange ..." instead.

  2017-09-01  Bastian Mmmm  <xxxxxx@xxxxxx>

  	* src/win/winmain.c (ConsoleHandler):  Install the console handler
  	also for wgnuplot and wgnuplot_pipes.  Avoids segfaults when closing
  	the wgnuplot_pipes console window or the caca terminal console window.
-------------------------

How about the scenario of my previous post where the commits are a 
series of small changes where the ChangeLog entry is gradually assembled 
piecemeal?

-------------------------
commit 1455f9768f84f061aade6a9d52c29dfd92f621db
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:52:24 2017 +0000

     Add menu items to edit gnuplot.ini and wgnuplot.ini

diff --git a/ChangeLog b/ChangeLog
index 9fe292c..45b8ac3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,32 +1,38 @@
  2017-10-06  Bastian Mmmm  <xxxxxx@xxxxxx>

  	* config/mingw/Makefile:  Add helpfiles to "all" target, including
  	the japanese version.  Remove helpfile from default target.

  	* config/mingw/Makefile:  Default to Mingw-w64 and Direct2D v1.1.
  	Note that building using Mingw32 currently does not work anyway
  	due to missing headers libraries for newer Windows APIs.

  	* config/mingw/Makefile:  Add a note that secure APIs are required
  	(pointed out by Allin Cottrell on the mailing list).

+	* config/msvc/Makefile:  Build and install support files for the
+	lua/tikz terminal.
+
+	src/win/wgnuplot.mnu:  Add menu items to edit gnuplot.ini and
+	wgnuplot.ini to 'Help' menu.
+
  2017-10-05  Bastian Mmmm  <xxxxxx@xxxxxx>

  	* src/win/wd2d.cpp:  Enable color font support.  This enables colored
  	emojis, which can be used e.g. as point symbols.  Due to the default
  	font-fallback to "Segoe UI Emoji", this might lead to unexpected
  	results if a plot relied on non-colored character fallbacks.

  2017-10-03  Ethan Mmmm  <xxxxxx@xxxxxx>

  	* term/gd.trm:  Report number of frames in completed animation sequence.

  2017-10-01  Bastian Mmmm  <xxxxxx@xxxxxx>

  	* src/win/winmain.c|h src/command.c:  For wgnuplot, open or attach to a
  	console when executing system commands so we can its the output.  That
  	in my option eliminates the last benefit of wgnuplot_pipes over
  	wgnuplot.  Note that the process terminates if the new console is
  	closed, just as is the case with wgnuplot_pipes, but the console is
  	only opened when actually required.

-------------------------

Notice in the above how having enough context lines shows us the Author 
information (searching backward from the first changed line in the 
ChangeLog file) even though Bastian appended to the end of the previous 
ChangeLog entry.

Does that approach seem fairly reliable and easy to automate?


>> I think doing a parallel reconstruction of a tagged version in both 
>> CVS and git (or SVN) with the idea in mind of making them file-by-file 
>> exact could lead to the most insight as far as alignment.  Those tags 
>> being correct is actually a little higher priority than having the 
>> exact contribution attributes by user per commit.
> 
> reposurgeon will do these checks automatically, and in my trial run 
> there were essentially no differences found.

That's good.  To me, this seemed like the most "surgical" work.

Dan

Re: Aw: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

[Petr M. <mi...@ph...>]

> As much automation as possible is preferred.

Few impressions:

If someone wants to look to a patch description of the (current) cvs period, 
then just look into the ChangeLog, thus slight misalignments in local 
description is not a big issue.

Thanks for explaing why it is desperate to search for ChangeLog's in some 
non-cvs projects :-)

I see there is no cvs command to list all available branches; it is necessary 
to look into version.c,h, for example.
That's nice that git has such a command.

Looking to a calendar, 2017-10-17 may be a nice date for the switch :-)

Getting the cvs repository backup, it has "just" 183 MB complete and 18 MB 
compressed, with the oldiest entry in April 1998 (import from beta340).
Good job for 20 years, right?

---
Petr Mikulik

Re: Scoping of variables in block constructs

[Ethan A M. <sf...@us...>]

On Monday, 09 October, 2017 20:19:43 Achim Gratz wrote:
> sfeam via gnuplot-beta writes:
> > Too complicated for me to work through in detail but one line
> > is waving a red flag.   This line
> >      set ytics @ticdef
> > is almost certainly not what you want to do.
> 
> Ah, OK.
> 
> > The macro expansion operator @ is like a #define statement in C.
> > It causes a substitution at the time the file/block/clause/program unit
> > is read in.  It is _not_ reevaluated at run time.
> 
> I still can't quite figure out the consitions under which this was and
> wasn't working for my example in various stages of its development, but
> I think that must be the right explanation.
> 
> > An example of evaluation at run time would be:
> >
> >    ... loop that constructs ticdef ...
> >    eval "set ytics " . ticdef
> 
> This seems all unnecessarily involved, so maybe I should rather ask if
> there's a way to build up an explicit tics list piece by piece rather
> than having to feed everyting as one single giant string?

Yes.   The keyword "add" does what you want.

	# x labels at 1 2 3 ... and also at certain interesting values
	array label[4] = ["sqrt(2)", "sqrt(3)", "e", "pi"]
	array value[4] = [1.414, 1.732, exp(1), pi]
	set xtics 1.0
    do for [i=1:4] {
		set xtics add (label[i] value[i])
    }
	
> 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?

	Ethan

> 
> Regards,
> Achim.
> 

Re: Scoping of variables in block constructs

[Hans-Bernhard B. <HBB...@t-...>]

Am 09.10.2017 um 20:19 schrieb Achim Gratz:

> This seems all unnecessarily involved, so maybe I should rather ask if
> there's a way to build up an explicit tics list piece by piece rather
> than having to feed everyting as one single giant string?

You're looking for "set xtics add ..."

Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

[Hans-Bernhard B. <HBB...@t-...>]

Am 09.10.2017 um 20:08 schrieb Daniel J Sebald:


> The above is a good match in terms of files that changed and the change 
> log for that day.  Hence, in this case we would substitute Author hhhh 
> bbbbbb  <xxxxxx@xxxxxx> for bbbbbb <bbbbbb>

It's also kind of a non-example, given that with an authormap file in 
place, there would be nothing left to substitute: i.e. my full name and 
address would already be in git log.

[...]

> I think doing a parallel reconstruction of a tagged version in both CVS 
> and git (or SVN) with the idea in mind of making them file-by-file exact 
> could lead to the most insight as far as alignment.  Those tags being 
> correct is actually a little higher priority than having the exact 
> contribution attributes by user per commit.

reposurgeon will do these checks automatically, and in my trial run 
there were essentially no differences found.

> So, when a release is done currently, are a collection of files grouped 
> into an archive file and that's the official release, sitting on a 
> server somewhere?  It's not the tagged files in the repository that is 
> considered the release?

They both are.  It's basically a required step while making a release to

1) check in what needs to be,
1a) repeat 1) until "make distcheck" finishes without errors
2) tag that state from your local working copy
3) check out a clean copy at that tag
4) "make dist" in there, too
5) verify that both tarballs are effectively identical.

Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

[Hans-Bernhard B. <HBB...@t-...>]

Am 09.10.2017 um 07:15 schrieb Mojca Miklavec:
> PS: w.r.t. the question of what could go wrong with my conversion,
> this is what the "git cvsimport" complains about:
> 
[...]

ESR's tool, cvs-fast-import, which "man git-cvsimport" itself recommends 
to be used instead, shows none of those messages, so I believe that 
these can be fixed by a change towards cvs-fast-import.

I've tried out reposurgen on our repository (with the "faq" module 
removed), and it seems to work almost perfectly.  "make allcompare" 
showed nothing missing from the git version.  The original import 
pseudo-branch GNUPLOT_BETA is, correctly, dropped, all other tags and 
branch tips compare equal, and .cvsignore files are also taken care of.

All in all, I'm quite impressed by this tool.

Re: Scoping of variables in block constructs

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

sfeam via gnuplot-beta writes:
> Too complicated for me to work through in detail but one line
> is waving a red flag.   This line
>      set ytics @ticdef
> is almost certainly not what you want to do.

Ah, OK.

> The macro expansion operator @ is like a #define statement in C.
> It causes a substitution at the time the file/block/clause/program unit
> is read in.  It is _not_ reevaluated at run time.

I still can't quite figure out the consitions under which this was and
wasn't working for my example in various stages of its development, but
I think that must be the right explanation.

> An example of evaluation at run time would be:
>
>    ... loop that constructs ticdef ...
>    eval "set ytics " . ticdef

This seems all unnecessarily involved, so maybe I should rather ask if
there's a way to build up an explicit tics list piece by piece rather
than having to feed everyting as one single giant string?

Also, why is there no block "else if" or maybe even "elsif"?


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Aw: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On 10/09/2017 02:12 AM, Mojca Miklavec wrote:
> On 9 October 2017 at 08:30, Daniel J Sebald wrote:
>> On 10/09/2017 12:15 AM, Mojca Miklavec wrote:
>>>
>>> They are actually "lost" is CVS already, while they are (and will)
>>> still (be) in ChangeLog.
>>>
>>> What one *can* do with cvs2git conversion is to start with something
>>> that looks like a reasonable conversion already and then make a map
>>>
>>>       <commit-shasum> <author>
>>>
>>> for all commits where the author doesn't match the committer. Then one
>>> can run a script that changes the author of each individual commit.
>>
>> This is what I was wondering about, i.e., an iterative approach where it
>> might not be correct on the first pass but then somehow run a script or
>> program that cross-references comments and adds or removes author info to
>> keep everything in sync.
>>
>> I thought that the git database was encoded such that changing authorship
>> wouldn't be so easy unless there is a git command that does so.
> 
> This is one of the reasons why I like git a lot. You can basically do
> whatever you please with a git repository. In contrast to subversion
> (and also mercurial ot a large extent), changing the history of a git
> repository is considered "normal" and there's built-in support to do
> very strange things. Or, if the support is not built-in, it's "easy"
> to write a python/perl/bash script to achieve what you want.
> 
> The main "problem" with assigning the correct author is getting the
> mapping right. That requires quite some man-hours, I guess. Doing the
> change on the git end is more or less straightforward.

As much automation as possible is preferred.  A script file to sort 
through the changed files and ChangeLog entry might give reasonably good 
alignment.  Consider the first two examples from the test repository. 
The "git log --stat" tells us what files have changed with each changeset:

GIT LOG
-------
commit 0a3035e39a1f9402a474d0ea9300deac4cd9ef33
Author: bbbbbb <bbbbbb>
Date:   Fri Oct 6 18:35:09 2017 +0000

     Use <sys/wait.h> if available.
     Provide centralized fall-back of WEXITSTATUS if <sys/wait.h> does 
not supply it.

  ChangeLog     | 15 +++++++++++++--
  configure.ac  |  4 +++-
  src/command.c |  6 +-----
  src/syscfg.h  | 20 ++++++++++++++++----
  4 files changed, 33 insertions(+), 12 deletions(-)

CHANGELOG
---------
2017-10-06  hhhh bbbbbb  <xxxxxx@xxxxxx>

	* src/command.c: Move WEXITSTATUS fall-back definition away from here.

	* src/syscfg.h: Include <sys/wait.h>, if it exists.
	(WEXITSTATUS): Provide fall-back definition, if none in
	<sys/wait.h>.  Move MS Windows specific replacement from command.c
	to here.

	* configure.ac: Add call to AC_HEADER_SYS_WAIT

The above is a good match in terms of files that changed and the change 
log for that day.  Hence, in this case we would substitute Author hhhh 
bbbbbb  <xxxxxx@xxxxxx> for bbbbbb <bbbbbb>

But then the second example isn't so simple:

GIT LOG
-------
commit 1455f9768f84f061aade6a9d52c29dfd92f621db
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:52:24 2017 +0000

     Add menu items to edit gnuplot.ini and wgnuplot.ini

  ChangeLog            | 6 ++++++
  src/win/wgnuplot.mnu | 9 ++++++++-
  2 files changed, 14 insertions(+), 1 deletion(-)

commit c5031aa2e31adb4b98569da80f2eb65abd282310
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:43:05 2017 +0000

     Build and install support files for lua/tikz

  config/msvc/Makefile | 32 ++++++++++++++++++++++++++++++--
  1 file changed, 30 insertions(+), 2 deletions(-)

commit 6078650b9396c309b593f0395cb0ef6fa552329a
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:36:50 2017 +0000

     Add a note on secure APIs

  ChangeLog             | 3 +++
  config/mingw/Makefile | 4 +++-
  2 files changed, 6 insertions(+), 1 deletion(-)

commit b720450b7620be7a5946b851411e49eb8b791521
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:28:39 2017 +0000

     Default to Mingw-w64 and Direct2D v1.1

  ChangeLog             | 4 ++++
  config/mingw/Makefile | 6 +++---
  2 files changed, 7 insertions(+), 3 deletions(-)

commit 14ed6d64ad2375f33868ae9603fae9ce17f087c0
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:23:19 2017 +0000

     Add helpfiles to 'all' target

  ChangeLog             |  5 +++++
  config/mingw/Makefile | 10 +++++-----
  2 files changed, 10 insertions(+), 5 deletions(-)

CHANGELOG
---------
2017-10-06  bbbbbb mmmmmm  <xxxxxx@xxxxxx>

	* config/mingw/Makefile:  Add helpfiles to "all" target, including
	the japanese version.  Remove helpfile from default target.

	* config/mingw/Makefile:  Default to Mingw-w64 and Direct2D v1.1.
	Note that building using Mingw32 currently does not work anyway
	due to missing headers libraries for newer Windows APIs.

	* config/mingw/Makefile:  Add a note that secure APIs are required
	(pointed out by Allin Cottrell on the mailing list).

	* config/msvc/Makefile:  Build and install support files for the
	lua/tikz terminal.

	src/win/wgnuplot.mnu:  Add menu items to edit gnuplot.ini and
	wgnuplot.ini to 'Help' menu.

So, this second example is sort of a series of commits in which 
ChangeLog entry was constructed piecemeal over time.  In that case, we 
probably wouldn't substitute bbbbbb mmmmmm  <xxxxxx@xxxxxx> for mmmmmm. 
But in all likelihood it is the maintainer who is building the changes 
and ChangeLog entry over the course of a day in this way, so the Author 
should be correct already.

And I'm going to guess that, generally, when Ethan has put together a 
ChangeLog entry for contributed work from a contributed patch, he pretty 
much does it as one CVS "commit" (i.e., more like the first example 
above).  He does go back and change typos and such after the fact, but 
such clean-ups can be left as is and attributed to Ethan.

So, if one were to write a script that goes through the "git log --stat" 
and whenever on a matching day there is a "ball of files" in a commit 
that matches to 90% a "ball of files" in a ChangeLog, substitute the 
Author info, otherwise leave the maintainer as Author; might that be 
good enough?


>> Hmmm, this probably comes about because of misalignment of changeset
>> groupings and the converters revision count.  That is, the CVS tag numbers
>> are translated in a way that doesn't agree with the original file versions.
>> Do all these complaints come at the very end?  That is, is the last version
>> of, say file src/graphics.c, 1.464.2.37?
> 
> I don't know and I'm not too eager to dig into it as it won't bring
> anything even if I "debug it".

I think doing a parallel reconstruction of a tagged version in both CVS 
and git (or SVN) with the idea in mind of making them file-by-file exact 
could lead to the most insight as far as alignment.  Those tags being 
correct is actually a little higher priority than having the exact 
contribution attributes by user per commit.


>> This makes me think that none of the tags after conversion will be reliable.
>> That's a pretty crucial issue, i.e., the ability to reconstruct program
>> versions older than the conversion date/time.
> 
> Well, one needs to be aware that there is one caveat with cvs -> git conversion.
> 
> CVS theoretically supports tagging strange combination of files that
> never existed together as such in the main branch. Getting the exact
> tag might not always be possible unless one first creates a branch
> with those exact versions of all files and then makes a tag on that
> branch. I don't know how Eric's tool handles that.

So, when a release is done currently, are a collection of files grouped 
into an archive file and that's the official release, sitting on a 
server somewhere?  It's not the tagged files in the repository that is 
considered the release?

Dan

Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

[Mojca M. <moj...@gm...>]

On 7 October 2017 at 22:22, Hans-Bernhard Bröker wrote:
> Am 07.10.2017 um 20:30 schrieb sfeam via gnuplot-beta:
>
>> So I am making a plea for a  volunteer to step up and transfer the project
>> files
>> to some git repository.
>
> Going all the way to Git might not be optimal for us.  SVN is closer in
> philosophy to CVS.

Each conversion from one technology to another is time consuming and
lossy in some way or another.

CVS is already "stone age" technology and has been deprecated and
inherently broken in my point of view. For ages.

SVN is at least not broken, it's still being actively developed, it
still has its niche use and might be better for particular type of
use(rs). But it's already declining and numerous projects migrate from
subversion to GIT (or Hg). With current instability of sourceforge,
another downtime might again mean inability to continue regular
development for a few weeks (something that already happened in the
past). With Git you can both keep committing locally and/or switch to
a backup server location is seconds. And if someone really hates git,
it's still possible to use the "subversion layer" locally (at least
GitHub offers that functionality).

While there was less incentive to migrate to another technology if
gnuplot was using SVN at this moment, there's little point in
replacing one dead technology with another one that's already in
decline.

To me that's like replacing a 56k modem with 1 Mbit ADSL when you have
optic fiber in your backyard :)

>> I don't really care much where the repository lives, but unless the
>> associated
>> gnuplot web site, bug trackers, mailing lists, etc are also moved it would
>> seem simplest to continue using SourceForge.
>
> I vote to keep it on SourceForge.  They offer both SVN and git, and IMHO it
> makes sense to keep it all in one place.

That's up to mainly Ethan to decide. I'm not a big fan of SourceForge
and prefer any other hosting provider, but if the repo is in git, at
least one can get a nice mirror at GitHub. SourceForge is very
user-unfriendly as far as browsing commit history is concerned.

The only thing that's missing on, say, GitHub, are the mailing lists,
but the existing lists can stay.

Here are some huge advantages of GitHub that I wanted to point out.
- If someone without commit rights creates a pull request, all it
takes is hitting a button to accept the changes (of course once you
have tested them).
- With a pull request, the changes don't get outdated as fast. When I
submitted something to the existing bug tracker, it took 5 years to
accept it. At any given moment inbetween the patch was most likely
outdated and needed to be manually fixed in order to apply cleanly.
With a pull request, git takes care of making sure that the patch can
still be applied even if the files in question change in the meantime.
- It is easy to set up Travis builds, so that gnuplot gets rebuilt on
several machines after each commit and for each pull request. Then you
can immediately see if a submitted patch breaks something.
- You wanted to keep the info about the author of the patch. If you
keep using existing tracker, you'll need to fix that info manually and
many committers would forget to do it. With pull requests, you get the
author info correct automatically.

Of course there are other providers, not only GitHub, many of them
much better than SF.

Mojca

Re: Aw: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

[Mojca M. <moj...@gm...>]

On 9 October 2017 at 08:30, Daniel J Sebald wrote:
> On 10/09/2017 12:15 AM, Mojca Miklavec wrote:
>>
>> They are actually "lost" is CVS already, while they are (and will)
>> still (be) in ChangeLog.
>>
>> What one *can* do with cvs2git conversion is to start with something
>> that looks like a reasonable conversion already and then make a map
>>
>>      <commit-shasum> <author>
>>
>> for all commits where the author doesn't match the committer. Then one
>> can run a script that changes the author of each individual commit.
>
> This is what I was wondering about, i.e., an iterative approach where it
> might not be correct on the first pass but then somehow run a script or
> program that cross-references comments and adds or removes author info to
> keep everything in sync.
>
> I thought that the git database was encoded such that changing authorship
> wouldn't be so easy unless there is a git command that does so.

This is one of the reasons why I like git a lot. You can basically do
whatever you please with a git repository. In contrast to subversion
(and also mercurial ot a large extent), changing the history of a git
repository is considered "normal" and there's built-in support to do
very strange things. Or, if the support is not built-in, it's "easy"
to write a python/perl/bash script to achieve what you want.

The main "problem" with assigning the correct author is getting the
mapping right. That requires quite some man-hours, I guess. Doing the
change on the git end is more or less straightforward.

>> PS: w.r.t. the question of what could go wrong with my conversion,
>> this is what the "git cvsimport" complains about:
>>
>> revision 1.3 of file docs/pdffigures.tex is tagged but not present
>> revision 1.29 of file src/contour.c is tagged but not present
...
>> Skipping #CVSPS_NO_BRANCH

I need to add that this comes from "git cvsimport" (which is
considered buggy). But just to show a partial answer to "what's wrong
with the repo on github".

> Hmmm, this probably comes about because of misalignment of changeset
> groupings and the converters revision count.  That is, the CVS tag numbers
> are translated in a way that doesn't agree with the original file versions.
> Do all these complaints come at the very end?  That is, is the last version
> of, say file src/graphics.c, 1.464.2.37?

I don't know and I'm not too eager to dig into it as it won't bring
anything even if I "debug it".

> This makes me think that none of the tags after conversion will be reliable.
> That's a pretty crucial issue, i.e., the ability to reconstruct program
> versions older than the conversion date/time.

Well, one needs to be aware that there is one caveat with cvs -> git conversion.

CVS theoretically supports tagging strange combination of files that
never existed together as such in the main branch. Getting the exact
tag might not always be possible unless one first creates a branch
with those exact versions of all files and then makes a tag on that
branch. I don't know how Eric's tool handles that.

On 9 October 2017 at 08:21, sfeam wrote:
>
> True.  So as long as the original commit dates are retained in some form,
> the modified files can still be mapped to the ChangeLog description and
> hence the original author.  OK.
>
>         Ethan

The timestamps are (usually) retained. I'm not 100% sure, but I seem
to remember that CVS is not timezone-aware and would accept whatever
date the committer has set on his machine.

Mojca

Re: Aw: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On 10/09/2017 01:30 AM, Daniel J Sebald wrote:
> On 10/09/2017 12:15 AM, Mojca Miklavec wrote:
>> On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote:
[snip]
> This makes me think that none of the tags after conversion will be 
> reliable.  That's a pretty crucial issue, i.e., the ability to 
> reconstruct program versions older than the conversion date/time.

Maybe a script that retrieves a tag-name version from both the original 
CVS repository and the translated repository then does a diff between 
the two directories?  That seems like something that can be automated. 
Any discrepancy has to fixed somehow, then rerun until all versions 
match file-by-file.

Dan

Re: Aw: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On 10/09/2017 12:15 AM, Mojca Miklavec wrote:
> On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote:
>>
>> I have a question though.
>> We have a much longer list of contributors (as opposed to committers) because
>> the project workflow historically had a large number of contributors funneling
>> contributions through a small number of people with cvs commit privilege.
>>
>> I found 168 unique contributors listed in the ChangeLog files,
>> compared to the 14 committers in your list above.
>> Will the names of the true contributors be lost in the conversion process?
>> That would be sad.
> 
> They are actually "lost" is CVS already, while they are (and will)
> still (be) in ChangeLog.
> 
> What one *can* do with cvs2git conversion is to start with something
> that looks like a reasonable conversion already and then make a map
> 
>      <commit-shasum> <author>
> 
> for all commits where the author doesn't match the committer. Then one
> can run a script that changes the author of each individual commit.

This is what I was wondering about, i.e., an iterative approach where it 
might not be correct on the first pass but then somehow run a script or 
program that cross-references comments and adds or removes author info 
to keep everything in sync.

I thought that the git database was encoded such that changing 
authorship wouldn't be so easy unless there is a git command that does so.


> Mojca
> 
> 
> PS: w.r.t. the question of what could go wrong with my conversion,
> this is what the "git cvsimport" complains about:
> 
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.117.2.7 of file src/mouse.c is tagged but not present
> revision 1.31.2.1 of file src/datafile.h is tagged but not present
> revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
> revision 1.31.2.1 of file src/datafile.h is tagged but not present
> revision 1.117.2.7 of file src/mouse.c is tagged but not present
> revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.464.2.38 of file src/graphics.c is tagged but not present
> revision 1.464.2.38 of file src/graphics.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> Skipping #CVSPS_NO_BRANCH

Hmmm, this probably comes about because of misalignment of changeset 
groupings and the converters revision count.  That is, the CVS tag 
numbers are translated in a way that doesn't agree with the original 
file versions.  Do all these complaints come at the very end?  That is, 
is the last version of, say file src/graphics.c, 1.464.2.37?

This makes me think that none of the tags after conversion will be 
reliable.  That's a pretty crucial issue, i.e., the ability to 
reconstruct program versions older than the conversion date/time.

Dan

Re: Aw: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

Mojca Miklavec <moj...@gm...>:
> On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote:
> >
> > I have a question though.
> > We have a much longer list of contributors (as opposed to committers) because
> > the project workflow historically had a large number of contributors funneling
> > contributions through a small number of people with cvs commit privilege.
> >
> > I found 168 unique contributors listed in the ChangeLog files,
> > compared to the 14 committers in your list above.
> > Will the names of the true contributors be lost in the conversion process?
> > That would be sad.
> 
> They are actually "lost" is CVS already, while they are (and will)
> still (be) in ChangeLog.

That is correct.

> What one *can* do with cvs2git conversion is to start with something
> that looks like a reasonable conversion already and then make a map
> 
>     <commit-shasum> <author>
> 
> for all commits where the author doesn't match the committer. Then one
> can run a script that changes the author of each individual commit.

My tools can do something similar.  The problem is making that map.
Somebody would have to grovel through every single change file making
a list of entries of the form

<date> <author> <files>

Possibly a script could be written to do this.  I'd then have to write a Python
extension of reposurgeon that would walk through the commit list looking for
an exact match of file list and a rough match of date - as I previously
noted, CVS dates aren't reliable.

> PS: w.r.t. the question of what could go wrong with my conversion,
> this is what the "git cvsimport" complains about:

The git maintainers' conversion engine is seriously buggy and should
not be trusted on any repository with a nontrivial branch structure.

I've tried to get them to use cvs-fast-export, but there's an incremental-
conversion feature they're attached to that their engine pretends to do.
They're attached to the pretense and are willing to accept buggy conversions
to get it.

Yes, this is infuriating.
-- 
		<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: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On Monday, 09 October 2017 07:15:29 Mojca Miklavec wrote:
> On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote:
> >
> > I have a question though.
> > We have a much longer list of contributors (as opposed to committers) because
> > the project workflow historically had a large number of contributors funneling
> > contributions through a small number of people with cvs commit privilege.
> >
> > I found 168 unique contributors listed in the ChangeLog files,
> > compared to the 14 committers in your list above.
> > Will the names of the true contributors be lost in the conversion process?
> > That would be sad.
> 
> They are actually "lost" is CVS already, while they are (and will)
> still (be) in ChangeLog.

True.  So as long as the original commit dates are retained in some form,
the modified files can still be mapped to the ChangeLog description and 
hence the original author.  OK.

	Ethan

> 
> What one *can* do with cvs2git conversion is to start with something
> that looks like a reasonable conversion already and then make a map
> 
>     <commit-shasum> <author>
> 
> for all commits where the author doesn't match the committer. Then one
> can run a script that changes the author of each individual commit.
> 
> Mojca
> 
> 
> PS: w.r.t. the question of what could go wrong with my conversion,
> this is what the "git cvsimport" complains about:
> 
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.117.2.7 of file src/mouse.c is tagged but not present
> revision 1.31.2.1 of file src/datafile.h is tagged but not present
> revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
> revision 1.31.2.1 of file src/datafile.h is tagged but not present
> revision 1.117.2.7 of file src/mouse.c is tagged but not present
> revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.464.2.38 of file src/graphics.c is tagged but not present
> revision 1.464.2.38 of file src/graphics.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> Skipping #CVSPS_NO_BRANCH

Re: Aw: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

[Mojca M. <moj...@gm...>]

On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote:
>
> I have a question though.
> We have a much longer list of contributors (as opposed to committers) because
> the project workflow historically had a large number of contributors funneling
> contributions through a small number of people with cvs commit privilege.
>
> I found 168 unique contributors listed in the ChangeLog files,
> compared to the 14 committers in your list above.
> Will the names of the true contributors be lost in the conversion process?
> That would be sad.

They are actually "lost" is CVS already, while they are (and will)
still (be) in ChangeLog.

What one *can* do with cvs2git conversion is to start with something
that looks like a reasonable conversion already and then make a map

    <commit-shasum> <author>

for all commits where the author doesn't match the committer. Then one
can run a script that changes the author of each individual commit.

Mojca


PS: w.r.t. the question of what could go wrong with my conversion,
this is what the "git cvsimport" complains about:

revision 1.3 of file docs/pdffigures.tex is tagged but not present
revision 1.3 of file docs/pdffigures.tex is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.117.2.7 of file src/mouse.c is tagged but not present
revision 1.31.2.1 of file src/datafile.h is tagged but not present
revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
revision 1.31.2.1 of file src/datafile.h is tagged but not present
revision 1.117.2.7 of file src/mouse.c is tagged but not present
revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
revision 1.3 of file docs/pdffigures.tex is tagged but not present
revision 1.3 of file docs/pdffigures.tex is tagged but not present
revision 1.464.2.38 of file src/graphics.c is tagged but not present
revision 1.464.2.38 of file src/graphics.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
Skipping #CVSPS_NO_BRANCH

Re: Aw: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On Sunday, 08 October 2017 15:54:36 Bastian Märkisch wrote:
> According to the DVCS migration HOWTO http://www.catb.org/~esr/reposurgeon/dvcs-migration-guide.html
> we need a list of committers. Please find below my first attempt on that. Commiter IDs
> are taken from the openhub summary https://www.openhub.net/p/gnuplot/contributors, 
> full names and emails from the ChangeLog, and timezones are guesswork mostly. Please send
> additions or corrections either to this list or directly to me.
>   
>   Bastian
> 
> --
> amai = Alexander Mai  <st0...@hr...>  Europe/Berlin
> broeker =  Hans-Bernhard Broeker  <br...@ph...>  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...>
> lhecking = Lars Hecking  <lhe...@us...>
> 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...>
> uid93776 = Ethan A Merritt  <merritt@u.washington.edu>
> 

Thanks.
I have a question though.
We have a much longer list of contributors (as opposed to committers) because
the project workflow historically had a large number of contributors funneling
contributions through a small number of people with cvs commit privilege.

I found 168 unique contributors listed in the ChangeLog files,
compared to the 14 committers in your list above. 
Will the names of the true contributors be lost in the conversion process?
That would be sad.

[list of Email addresses redacted, but I can send it privately if it will help]

	Ethan 

Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On 10/08/2017 09:49 AM, Allin Cottrell wrote:
> On Sun, 8 Oct 2017, Daniel J Sebald wrote:
> 
>> On 10/07/2017 02:32 PM, Daniel J Sebald wrote:
>>> On 10/07/2017 01:30 PM, sfeam via gnuplot-beta wrote:
>> [snip]
>>> Another question is SourceForge's support for an HTML interface to 
>>> the git repository.  It's nice to have an HTML-viewable log of what's 
>>> going on rather than have to pull all the latest changesets.  Do 
>>> maintainers want to go all out with pull-requests, etc.?  Probably 
>>> not, seeing as changes are sort of funneled down to a few people for 
>>> review, rather than having a whole large team of players committing 
>>> to the canonical repository.  So, in that respect, SourceForge's 
>>> support for pull-requests isn't that critical. Just a nice log and 
>>> difference viewer is good.  Staying with SourceForge is fine with me, 
>>> if that criteria can be met.
>>
>> Here are a couple examples of HTML interface to repositories on 
>> SourceForge; one SVN, one git:
>>
>> SVN
>> https://sourceforge.net/p/skychart/code/3668/log/
>>
>> git
>> https://sourceforge.net/p/maxima/website/commit_browser
>>
>> Neither are the most elegant such interface I've seen, but the basic 
>> elements are there, i.e., a list of changes and a means to get the 
>> diff hunks for that change.  SVN HTML actually looks a little better 
>> in the sense that it allows viewing diff hunks for all changed files 
>> at once [...]
> 
> You get that in the HTML git viewer if you click on the commit ID -- if 
> I'm understanding you right. (You see diff hunks for all files affecting 
> by the given commit.)

Ah, yes there it is, but where is a convenient commit ID?  I can click 
on the Parent ID and the Child ID and get a whole list of diff hunks. 
But it would be nice if there were an ID for the current highlighted 
changeset in the--what looks to be--flash window list.  Can you click on 
the ID at the front of the list of changesets?  That doesn't seem to 
work for me; maybe my version of Flash isn't working properly.

Dan

Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On 10/08/2017 08:31 AM, Hans-Bernhard Bröker wrote:
> Am 08.10.2017 um 02:15 schrieb Daniel J Sebald:
>> On 10/07/2017 06:05 PM, Mojca Miklavec wrote:
[snip]
> Git users advocate a similar use by splitting a commit message into a 
> single-line summary (equivalent to typical CVS check-in comments), and 
> the longer description below that, after a blank line.  So if ChangeLog 
> entries can be moved into the log, they could become the bottom part of 
> individual log entries.  If they can't, so be it.

The message is actually sort of there already via this cvsimport 
conversion.  I understand now that the CVS is file-atomic changes and 
cvsimport is looking for groups of changes with very near the same time 
stamp, but it seems for the most part cvsimport is associating the 
change to ChangeLog with the pertinent group of changes.  For example, 
here is the first diff hunk of the most recent changeset in the test 
repository:

sebald@ ~/gnuplot/test_repository/gnuplot $ git diff 1455f9768f8 0a3035e39a1
diff --git a/ChangeLog b/ChangeLog
index 45b8ac3..bd497d8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2017-10-06  Hhhh-Bbbb  <xxx...@xx...>
+
+       * src/command.c: Move WEXITSTATUS fall-back definition away from 
here.
+
+       * src/syscfg.h: Include <sys/wait.h>, if it exists.
+       (WEXITSTATUS): Provide fall-back definition, if none in
+       <sys/wait.h>.  Move MS Windows specific replacement from command.c
+       to here.
+
+       * configure.ac: Add call to AC_HEADER_SYS_WAIT
+
  2017-10-06  Bbbb Mmmm  <xxx...@xx...>

         * config/mingw/Makefile:  Add helpfiles to "all" target, including

If one looks at the repository in a viewer like gitg, the added lines 
are color coded.  Given that ChangeLog is alphabetically often the first 
file, one ostensibly sees short-description/detailed-file-changes next 
to one another in the repository viewer.

I agree with the advocated format: a one line short description followed 
by a starred (*) list of files, then colon (:) and brief description of 
what change in the file.  (Pagers know how to color code that format.) 
The descriptions have to have enough detail and key words to be useful; 
not something like, "Changed some code that was bad".  People might find 
it a pain to write a detailed message, but there is a non-obvious 
benefit to writing the changeset message.  Looking at staged diff-hunks 
to be checked in while writing the message forces one to think a bit 
more and catches a lot of bugs and less-than-optimal constructs (for me 
anyway).  As I see it, writing the message results in better quality 
changesets.

Dan

Re: Scoping of variables in block constructs

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

On Sunday, 08 October 2017 21:17:40 Achim Gratz wrote:
> sfeam via gnuplot-beta writes:
> > With one exception, gnuplot variables are global.
> 
> That is not what I was seeing (much to my surprise), although things may
> have been complicated by my additional use of a call statement and
> mixing with functions.  So, I have a file that implements a callable
> include:

Too complicated for me to work through in detail but one line
is waving a red flag.   This line
     set ytics @ticdef
is almost certainly not what you want to do.

The macro expansion operator @ is like a #define statement in C.
It causes a substitution at the time the file/block/clause/program unit
is read in.  It is _not_ reevaluated at run time.

An example of evaluation at run time would be:

   ... loop that constructs ticdef ...
   eval "set ytics " . ticdef

	Ethan


> 
> --8<---------------cut here---------------start------------->8---
> # call "scale.gp" linear|asinh knee
> type = ((ARGC>0) ? ARG1 : "asinh")
> knee = ((ARGC>1) ? ARG2 : 1e-5)
> ticdef = ''
> if (type eq "asinh") {
>   s(y) = asinh( 0.5*y/knee )
>   tic( s,u,n,v ) = sprintf( '"%s%i %s" %ss(%f),', s, n, u, ((s eq "±")?'':s), v );
>   omag = 1.
>   ticdef = tic( "±", "s", 0, 0 )
>   do for [unit in "s ms µs ns"] {
>     do for [mag = 0:2] {
>       m = 10**mag
>       v = omag*m
>       ticdef = ticdef . tic( "+", unit, m, v)
>       ticdef = ticdef . tic( "-", unit, m, v)
>     }
>     omag = omag / 1000.
>   }
>   ticdef = '(' . ticdef . ')'
> }
> if (type eq "linear") {
>   s(y) = y
> }
> set ytics @ticdef
> --8<---------------cut here---------------end--------------->8---
> 
> The original version created ticdef inside the block and also set the
> ytics there, but the result was never visible in the caller.  This is
> with gnuplot 5.0.7 from openSUSE.
> 
> 
> Regards,
> Achim.
>