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

Re: Scoping of variables in block constructs

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

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:

--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.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

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

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

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

On Sunday, 08 October 2017 20:02:12 Hans-Bernhard Bröker wrote:
> Am 08.10.2017 um 01:05 schrieb Mojca Miklavec:
> 
> > Some tags are missing, but that's easy to fix (I think I disabled that
> > because a removed a number of useless tags, but I'm no longer sure).
> 
> Using Eric S. Raymond's reposurgeon and cvs2svn to experiment with, I 
> found a further complication that's missing from that existing github 
> mirror: the "faq" module in our CVS repository.  This means we have two 
> modules in our repository, causing tools to actually generate the 
> "gnuplot" path component again, and later failing many of their 
> comparisons because of it.
> 
> E.g. reposurgeon's "make branchescompare" complains that none of the 
> branches or tags of the generated git repository have the 'faq' directory.
> 
> So: what are we to do with the "faq" module?

It's pretty horribly out of date, so dropping it altogether to be rewritten
at some later date is an attractive, and simple, option.

Keeping it in a separate module seems an unnecessary complication.
Whether we keep the current document or trash it and start over,
either way it could move to the docs directory.

	Ethan

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

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

Am 08.10.2017 um 01:05 schrieb Mojca Miklavec:

> Some tags are missing, but that's easy to fix (I think I disabled that
> because a removed a number of useless tags, but I'm no longer sure).

Using Eric S. Raymond's reposurgeon and cvs2svn to experiment with, I 
found a further complication that's missing from that existing github 
mirror: the "faq" module in our CVS repository.  This means we have two 
modules in our repository, causing tools to actually generate the 
"gnuplot" path component again, and later failing many of their 
comparisons because of it.

E.g. reposurgeon's "make branchescompare" complains that none of the 
branches or tags of the generated git repository have the 'faq' directory.

So: what are we to do with the "faq" module?

Re: Scoping of variables in block constructs

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

On Sunday, 08 October 2017 13:32:04 Achim Gratz wrote:
> 
> Is there some description how the variable scoping is supposed to work
> in blocks?  It seems that they will need to be defined outside the block
> in order to be visible beyond the block and any set operations inside
> the block will be nixed when that block is left?

With one exception, gnuplot variables are global.
There is a single, persistent, list of active variables indexed by name.  
Assignment to a variable creates or replaces an entry in that list.
The only way to remove a variable from that list is the "undefine" command.

The one exception is the controlling variable of an iteration.
In that case the scope of the variable name is the iteration itself.
A previous instance of that variable name, if any, is saved at the
start of the iteration and restored at the end
Example:
        j = "foo"
	do for [j=1:3] {
		plot for [j=5:6] x*j title "plot x*".j
	}   
	print "j =", j    # will report j = "foo"

Re-use of the name "j" in the do loop shadows the global
variable of that name, and re-use in the plot statement
shadows both of the outer uses.  

Block structure is not relevant per se except that one use of a
block is to delineate the content of an iteration.

	Ethan



> 
> 
> Regards,
> Achim.
> 

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

[Allin C. <cot...@wf...>]

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

Allin

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

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

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>


> Gesendet: Samstag, 07. Oktober 2017 um 22:22 Uhr
> Von: "Hans-Bernhard Bröker" <HBB...@t-...>
> An: gnuplot-beta <gnu...@li...>
> Betreff: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)
>
> 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.  But as the primary maintainer for the last several 
> years, that decision is clearly yours.
> 
> > 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.
> 
> > If no one steps up, then I'm afraid gnuplot development will be offline
> > indefinitely.   
> 
> I'd hate to see that happen.
> 
> Eric S. Raymond has offered (twice) to help us with such a repository 
> move, but I fear this rather short notice by SF may overload his ability 
> to help all affected projects in time.  If that helps, I can offer to 
> share the workload with Mr. Raymond, to whatever extent that even makes 
> sense.
> 
> I'll be transforming another (smaller) project myself, so I'll have to 
> learn how this is done, anyway.  I've already begun experimenting with 
> the tools in question.

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

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

Am 08.10.2017 um 02:15 schrieb Daniel J Sebald:
> On 10/07/2017 06:05 PM, Mojca Miklavec wrote:

>> I decided to delete "missing" and "config/djconfig.sh" on purpose
>> because I had problems whenever I tried to build gnuplot.

For "missing" that might make some sense, since that file should never 
have been checked in to begin with --- it's supposed to be supplied by 
automake.

But I cannot imagine how a script used only to build gnuplot for MS-DOS 
could ever, possibly disrupt operations on other platforms, where it 
will never be used for anything.

>> Even if this conversion would serve as a starting point, here's still
>> a TODO list:
>> - "convert" .cvsignore to .gitignore (this could either be done
>> "properly" for all commits or just for the last commit)
> 
> Properly for all commits sounds difficult.  I suppose the two files have 
> pretty much the same form, given no comment characters or anything are 
> in .cvsignore; it's just a list of files.  Could we somehow create a 
> link from .gitignore to .cvsignore for older entries and then starting 
> with the new entries remove the link and rename .cvsignore to .gitignore?

The tools offered by Eric S. Raymond do this automatically.  They build 
.gitignore files to track the .cvsignore changes fully, including 
entries to make git ignore all those files that CVS ignores by default.

>> 1.) Wrong date extraction for $Id fields

That should solve itself as we remove the $Id entries from the source 
--- that's if we do go for git instead of SVN.

>> 2.) It's explicitly suggested that one should not use incremental
>> updates of the repository, but rather create a single conversion. I
>> don't know what consequences that might have.

This is mainly a problem only for your current situation, where CVS is 
the master repository, and git only used to track it.  What we're up to 
now is to make a git repository that's to be come the master itself.

>> 3.) I remember seeing the same cvs commit (which needed a couple of
>> minutes to be uploaded to the server) split in two git commits just
>> because of the varying timestamp.

The problem goes deeper than that.  There is, ultimately, no such thing 
as a multi-file commit in CVS (i.e. no "change sets").  Even a single 
client-side invocation of 'cvs ci' is to the server just a loose 
sequence of individual file commits that just happen to be close in 
time, and with the same check-in description.  Tools try to stitch those 
sequences back together again, but they cannot be perfet.

And that's before you come to users or cvs clients who, for whatever 
reason, really do perform multiple check-ins one by one even if they do 
form a coherent group.

>> 4.) If one deletes a folder in CVS, the files are probably gone
>> forever and one doesn't get them in conversion.

The files are still there in the CVS archive.  There is, e.g., a folder

	doc/Attic/ps/Attic

in the archive that holds the deleted contents of the deleted folder 
doc/ps.  At least one of the tools on offer says it cannot use the 
contents of that folder, though.

>> 5.) I had some issues with files that only differed in case and I got
>> "lossy conversion" (files lost) on my Mac (this conversion is done on
>> Linux though).

I think that means the transformation really has to be done in a 
case-sensitive environment; probably Linux.  We shouldn't accept lossy 
conversion if at all avoidable.

> I don't think I explained that well enough.  I didn't mean to do the 
> work of slice-and-dice all the individual entries of ChangeLog.0 through 
> ChaneLog.5 and ChangeLog.  What I meant was that all the ChangeLog.0 
> through ChangeLog are concatenated into one big comment and that comment 
> is the first entry of creating the new repository.

Oh hell no.  Turning all 1.7 MB of ChangeLog in to a single gargantuan 
log message would serve no purpose other than to annoy casual viewers. 
If we can't get ChangeLog mapped into the check-in messages entry by 
entry, then it has to stay out of there.

ChangeLog entries and check-in comments are, by design, separate 
documentation streams, serving different purposes.  Check-in messages 
are to keep others appraised of what a change is about, whereas 
ChangeLog is for looking up details during the work, without having to 
ask the server all the time.

Sometimes a single ChangeLog entry will cover multiple changesets 
(because a single person checked in multiple changes in a single day), 
sometimes a single changeset will affect multiple ChangeLog entries 
(e.g. if a previous entry was corrected later).

ChangeLog entries are supposed to be more detailed, mentioning exact 
locations of changes, and describing what exactly was changed, in which 
files, and how.  Check-in comments, OTOH, are usually kept short, to the 
point of terseness.  Most are a single line, and they only describe what 
the change was for, but not how it was achieved.

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.

Scoping of variables in block constructs

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

Is there some description how the variable scoping is supposed to work
in blocks?  It seems that they will need to be defined outside the block
in order to be visible beyond the block and any set operations inside
the block will be nixed when that block is left?


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

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

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

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, 
and git HTML seems kind of slow to load.  Scrolling through all the 
changes is much faster than looking at diff hunks for only one file at a 
time for dozens of files.

Dan

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

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

On 10/07/2017 06:05 PM, Mojca Miklavec wrote:
> On 7 October 2017 at 23:05, Daniel J Sebald wrote:
>> On 10/07/2017 02:25 PM, Achim Gratz wrote:
>>>
>>> sfeam via gnuplot-beta writes:
>>>>
>>>> Well guys, it's been fun.
>>>>
>>>> SourceForge has announced that they will shut down CVS support next
>>>> month.
>>>> I have little time available to deal with this, and minimal prior
>>>> experience with git.
>>>>
>>>> So I am making a plea for a  volunteer to step up and transfer the
>>>> project files
>>>> to some git repository.
>>>
>>>
>>> There's already an unofficial repository (not that I'd endorse GitHub):
>>> https://github.com/gnuplot/gnuplot
>>>
>>> As noted on that page, this uses cvsimport to do the mirroring, which
>>> sometimes produces somewhat strange commits on the Git side.  You might
>>> want to get in touch with Eric S. Raymond if you want the CVS repo
>>> cleaned and converted with some more care into Git (he's done that
>>> before for other projects).
>>
>>
>> I did
>>
>> mkdir temp_repository; cd temp_repository
>> git clone https://github.com/gnuplot/gnuplot.git
>> cd gnuplot
>> gitg
>>
>> and things look reasonable as far as change history, tags and branches.
> 
> Some tags are missing, but that's easy to fix (I think I disabled that
> because a removed a number of useless tags, but I'm no longer sure).
> 
>> Can you point to some examples of strange commits in this record to give us
>> an idea?
> 
> I cannot remember all the details.
> 
> I remember various problems I had and I made several attempts to
> change the repository in the past after some new commits came in. The
> script I use for conversion at the moment is at the bottom. The fact
> that I need(ed?) to delete some files (docs/pdffigures.tex in
> particular) is strange.
> 
> I decided to delete "missing" and "config/djconfig.sh" on purpose
> because I had problems whenever I tried to build gnuplot.
> 
> I had to change quite some file permissions (otherwise git would
> always complain about some changes in my local tree).
> 
> Even if this conversion would serve as a starting point, here's still
> a TODO list:
> - "convert" .cvsignore to .gitignore (this could either be done
> "properly" for all commits or just for the last commit)

Properly for all commits sounds difficult.  I suppose the two files have 
pretty much the same form, given no comment characters or anything are 
in .cvsignore; it's just a list of files.  Could we somehow create a 
link from .gitignore to .cvsignore for older entries and then starting 
with the new entries remove the link and rename .cvsignore to .gitignore?

Even if such a thing can't be done, no one is going to use the new 
repository retroactively in CVS for editing/developing purposes, so 
wouldn't have any use for .cvsignore.  Moving .cvsignore to .gitignore 
as one of the first new changesets might do.


> - remove all the expansion strings ($Id)
> - collect a list of names with emails from contributors to the sources
> (perhaps along with timezones) and replace cvs usernames and
> timestamps with proper names and emails
> 
> I can name a few other problems I had at various points, but I'm not
> sure if any of those apply to my copy of gnuplot's repo.
> 1.) Wrong date extraction for $Id fields
> 2.) It's explicitly suggested that one should not use incremental
> updates of the repository, but rather create a single conversion. I
> don't know what consequences that might have.
> 3.) I remember seeing the same cvs commit (which needed a couple of
> minutes to be uploaded to the server) split in two git commits just
> because of the varying timestamp.
> 4.) If one deletes a folder in CVS, the files are probably gone
> forever and one doesn't get them in conversion.
> 5.) I had some issues with files that only differed in case and I got
> "lossy conversion" (files lost) on my Mac (this conversion is done on
> Linux though).
> 6.) I forgot a "--delete" switch in rsync calls, so some files
> persisted in the git repository even after being deleted from CVS.
> 7.) Not sure if file permissions are ok. Under CVS they kept changing.
> The expression I used tried to fix permissions, but not sure if that's
> all correct.

OK, you've got the lead so far. :-)

Regarding 2, there should be no incremental CVS-to-git (SVN?) 
conversions.  I suggest one conversion to a new repository, then it's 
new-repo-only from there on out.  The normal process that has been used 
for CVS will be discontinued soon anyway, so even someone continuing 
with CVS offline means extra work of changing the process slightly.

I would say, though, that once the conversion to a new repository is 
done that there be no new commits for a week.  That way everyone will 
have a chance to get a local copy and experiment with their favorite 
tools and if someone discovers something not-so-good about the 
conversion it will give a chance to scrap the repository and redo it.


>> I'm wondering now about my suggestion of putting all the ChangeLog files
>> into a changelog comment so that it can be included in the
>>
>> git log
>>
>> command.  The reason is that there are, in fact, entries for all the
>> changesets (where they came from, I don't know, they don't exactly match the
>> ChangeLog).  So mixing those in with the equivalent ChangeLog comment might
>> create a confusing duplication.
> 
> While that can theoretically be done: who is going to do the work? See
> also my next comment and a link to xkcd (to predict what happens
> next).

I don't think I explained that well enough.  I didn't mean to do the 
work of slice-and-dice all the individual entries of ChangeLog.0 through 
ChaneLog.5 and ChangeLog.  What I meant was that all the ChangeLog.0 
through ChangeLog are concatenated into one big comment and that comment 
is the first entry of creating the new repository.  So it might be 
something like the following just after conversion:

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

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

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

[...ETC...]

commit 123865547396c309b593f0395cb0ef6fa552329a
Author: cccccc <cccccc>
Date:   Sat Oct 7 01:02:03 2017 +0000
2017-10-06  bbbbbb  <bbbbbb>

         * 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  mmmmmm  <mmmmmm>

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

[...BIG LONG COMMIT MESSAGE...]

1998-04-09  hhhhhh  <hhhhhh>

	* ChangeLog: New file.

	* gplt_x11.c (prepare_plot): Remove unused definition term_icon[10].

	* set.c (set_arrow, set_linestyle): Replace aggregate initialisation
	for non-ANSI compilers.

	* Makefile.in: General cleanup. Add full support for GNU auto* tools.

	* missing: New file required for full GNU auto* tools support. Taken
	from automake 1.3 distribution.

	* acinclude.m4: New macros gp_PROG_CPP_STRINGIFY, taken from egcs,
	and AM_MISSING_PROG, from automake 1.3 distribution. Fixes in
	gp_CHECK_LIB_PATH and gp_CHECK_HEADER.

	* aclocal.m4: Regenerated from acinclude.m4 with aclocal.

But note how the conversion-created comments are chronological, and the 
ChangeLog-created comment is chronological, but the two groups cover the 
same range, which would be confusing.

In any case, my point is that the above would put all the history into 
one location, good for searching "git log".  The ChangeLog files could 
then be excluded.  Maybe something creative comes to mind.  But it's not 
that much work to grep ChangeLog files so old history is always 
search-able in any case.

The interesting observance of the repository is that the commit messages 
from ChangeLog are effectively sliced-and-diced.  The reason is that the 
first diff-hunk of most changesets is the ChangeLog, i.e., the 
most-recently added comment.  So, just look within the changeset diffs 
to get the pertinent ChangeLog message.  That doesn't do anything for 
searching, however.


>>   Let's compare an example.  The first in the
>> list (via "git log") is
>>
>> commit 0a3035e39a1f9402a474d0ea9300deac4cd9ef33
>> Author: broxxxx <broxxxx>
>> 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.
>>
>> whose changed files (via gitg) are
>>
>> ▶15     ChangeLog
>> ▶4      configure.ac
>> ▶6      src/command.c
>> ▶20     src/syscfg.h
>>
>> While the entry in ChangeLog is as follows (I put 'x' in for email address
>> to keep out of the content):
>>
>> 2017-10-06  xxxxxxxxx xxxxxxx  <xx...@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
>>
>> Moving forward, the changeset comments should look more like the second
>> example from the ChangeLog, as that highlights nicely in vi-based pagers.
> 
> That's something that maintainers should strongly encourage (or
> enforce?) among themselves.

Yes, and I think that maintainers can touch-up the message associated 
with an exported changeset because it is an ASCII diff file (posted to 
SourceForge bug reports) with a little extra detail near the top.


> Guidelines can be found under:
>      https://xkcd.com/1296/
> 
> For another project we tried to enforce another rule: keep the commit
> history linear (unless branches are needed of course, but we try to
> rebase pull requests instead of merging them and developers are
> discouraged to do rebasing on master as well).
> 
>> Currently in the translated repository, there are but a few users making
>> commits.  Going forward, the names of the user who creates the original
>> changeset will end up in that Author location even though one of the
>> maintainers pushes the changes to the repository when ready.  (That name is
>> a configuration parameter in a person's OS account via the hidden file
>> .gitconfig)
> 
> I like that anyway.

Me too; just noting what maintainers should expect from a change to git.

Dan

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

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

On 7 October 2017 at 23:05, Daniel J Sebald wrote:
> On 10/07/2017 02:25 PM, Achim Gratz wrote:
>>
>> sfeam via gnuplot-beta writes:
>>>
>>> Well guys, it's been fun.
>>>
>>> SourceForge has announced that they will shut down CVS support next
>>> month.
>>> I have little time available to deal with this, and minimal prior
>>> experience with git.
>>>
>>> So I am making a plea for a  volunteer to step up and transfer the
>>> project files
>>> to some git repository.
>>
>>
>> There's already an unofficial repository (not that I'd endorse GitHub):
>> https://github.com/gnuplot/gnuplot
>>
>> As noted on that page, this uses cvsimport to do the mirroring, which
>> sometimes produces somewhat strange commits on the Git side.  You might
>> want to get in touch with Eric S. Raymond if you want the CVS repo
>> cleaned and converted with some more care into Git (he's done that
>> before for other projects).
>
>
> I did
>
> mkdir temp_repository; cd temp_repository
> git clone https://github.com/gnuplot/gnuplot.git
> cd gnuplot
> gitg
>
> and things look reasonable as far as change history, tags and branches.

Some tags are missing, but that's easy to fix (I think I disabled that
because a removed a number of useless tags, but I'm no longer sure).

> Can you point to some examples of strange commits in this record to give us
> an idea?

I cannot remember all the details.

I remember various problems I had and I made several attempts to
change the repository in the past after some new commits came in. The
script I use for conversion at the moment is at the bottom. The fact
that I need(ed?) to delete some files (docs/pdffigures.tex in
particular) is strange.

I decided to delete "missing" and "config/djconfig.sh" on purpose
because I had problems whenever I tried to build gnuplot.

I had to change quite some file permissions (otherwise git would
always complain about some changes in my local tree).

Even if this conversion would serve as a starting point, here's still
a TODO list:
- "convert" .cvsignore to .gitignore (this could either be done
"properly" for all commits or just for the last commit)
- remove all the expansion strings ($Id)
- collect a list of names with emails from contributors to the sources
(perhaps along with timezones) and replace cvs usernames and
timestamps with proper names and emails

I can name a few other problems I had at various points, but I'm not
sure if any of those apply to my copy of gnuplot's repo.
1.) Wrong date extraction for $Id fields
2.) It's explicitly suggested that one should not use incremental
updates of the repository, but rather create a single conversion. I
don't know what consequences that might have.
3.) I remember seeing the same cvs commit (which needed a couple of
minutes to be uploaded to the server) split in two git commits just
because of the varying timestamp.
4.) If one deletes a folder in CVS, the files are probably gone
forever and one doesn't get them in conversion.
5.) I had some issues with files that only differed in case and I got
"lossy conversion" (files lost) on my Mac (this conversion is done on
Linux though).
6.) I forgot a "--delete" switch in rsync calls, so some files
persisted in the git repository even after being deleted from CVS.
7.) Not sure if file permissions are ok. Under CVS they kept changing.
The expression I used tried to fix permissions, but not sure if that's
all correct.

> I'm wondering now about my suggestion of putting all the ChangeLog files
> into a changelog comment so that it can be included in the
>
> git log
>
> command.  The reason is that there are, in fact, entries for all the
> changesets (where they came from, I don't know, they don't exactly match the
> ChangeLog).  So mixing those in with the equivalent ChangeLog comment might
> create a confusing duplication.

While that can theoretically be done: who is going to do the work? See
also my next comment and a link to xkcd (to predict what happens
next).

>  Let's compare an example.  The first in the
> list (via "git log") is
>
> commit 0a3035e39a1f9402a474d0ea9300deac4cd9ef33
> Author: broxxxx <broxxxx>
> 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.
>
> whose changed files (via gitg) are
>
> ▶15     ChangeLog
> ▶4      configure.ac
> ▶6      src/command.c
> ▶20     src/syscfg.h
>
> While the entry in ChangeLog is as follows (I put 'x' in for email address
> to keep out of the content):
>
> 2017-10-06  xxxxxxxxx xxxxxxx  <xx...@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
>
> Moving forward, the changeset comments should look more like the second
> example from the ChangeLog, as that highlights nicely in vi-based pagers.

That's something that maintainers should strongly encourage (or
enforce?) among themselves.

Guidelines can be found under:
    https://xkcd.com/1296/

For another project we tried to enforce another rule: keep the commit
history linear (unless branches are needed of course, but we try to
rebase pull requests instead of merging them and developers are
discouraged to do rebasing on master as well).

> Currently in the translated repository, there are but a few users making
> commits.  Going forward, the names of the user who creates the original
> changeset will end up in that Author location even though one of the
> maintainers pushes the changes to the repository when ready.  (That name is
> a configuration parameter in a person's OS account via the hidden file
> .gitconfig)

I like that anyway.

Mojca

#----------------------------

export DIR=$PWD
export GP_CVS=$DIR/cvs/gnuplot/gnuplot

mkdir -p $DIR/cvs
mkdir -p $DIR/git

rsync -aO --delete
rsync://gnuplot.cvs.sourceforge.net/cvsroot/gnuplot/ $DIR/cvs/gnuplot

cd $DIR/cvs/gnuplot/gnuplot

chmod 755 missing,v config/djconfig.sh,v
# set 644 to all non-executable files
find . ! -perm /111 -type f -exec chmod 644 {} \;
# set 755 to all executable files
find . -perm 111 -type f -exec chmod 755 {} \;
# remove pdffigures.tex (always complaining)
# rm docs/pdffigures.tex,v

cd $DIR

# update from CVS
git cvsimport -C $DIR/git/gnuplot.git -p x -d $DIR/cvs/gnuplot gnuplot

# push any changes back to github
cd $DIR/git/gnuplot.git
git push -q github --all
#git push github --tags

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

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

On 10/07/2017 02:25 PM, Achim Gratz wrote:
> sfeam via gnuplot-beta writes:
>> Well guys, it's been fun.
>>
>> SourceForge has announced that they will shut down CVS support next month.
>> I have little time available to deal with this, and minimal prior experience with git.
>>
>> So I am making a plea for a  volunteer to step up and transfer the project files
>> to some git repository.
> 
> There's already an unofficial repository (not that I'd endorse GitHub):
> https://github.com/gnuplot/gnuplot
> 
> As noted on that page, this uses cvsimport to do the mirroring, which
> sometimes produces somewhat strange commits on the Git side.  You might
> want to get in touch with Eric S. Raymond if you want the CVS repo
> cleaned and converted with some more care into Git (he's done that
> before for other projects).

I did

mkdir temp_repository; cd temp_repository
git clone https://github.com/gnuplot/gnuplot.git
cd gnuplot
gitg

and things look reasonable as far as change history, tags and branches.

Can you point to some examples of strange commits in this record to give 
us an idea?

I'm wondering now about my suggestion of putting all the ChangeLog files 
into a changelog comment so that it can be included in the

git log

command.  The reason is that there are, in fact, entries for all the 
changesets (where they came from, I don't know, they don't exactly match 
the ChangeLog).  So mixing those in with the equivalent ChangeLog 
comment might create a confusing duplication.  Let's compare an example. 
  The first in the list (via "git log") is

commit 0a3035e39a1f9402a474d0ea9300deac4cd9ef33
Author: broxxxx <broxxxx>
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.

whose changed files (via gitg) are

▶15	ChangeLog
▶4	configure.ac
▶6	src/command.c
▶20	src/syscfg.h

While the entry in ChangeLog is as follows (I put 'x' in for email 
address to keep out of the content):

2017-10-06  xxxxxxxxx xxxxxxx  <xx...@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

Moving forward, the changeset comments should look more like the second 
example from the ChangeLog, as that highlights nicely in vi-based pagers.

Currently in the translated repository, there are but a few users making 
commits.  Going forward, the names of the user who creates the original 
changeset will end up in that Author location even though one of the 
maintainers pushes the changes to the repository when ready.  (That name 
is a configuration parameter in a person's OS account via the hidden 
file .gitconfig)

Dan

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

[Allin C. <cot...@wf...>]

On Sat, 7 Oct 2017, Bastian Märkisch wrote:

> Hello Ethan,
>
> In the past we had a few discussions on migrating away from CVS on 
> the list - with different opinions on Git, Hg, or Subversion. 
> Personally, I am not unhappy about the end of CVS support by SF, 
> but I hardly have experience with repository conversion myself.
>
> Eric S. Raymond and Allin Cottrel kindly offered help to convert 
> about two years ago. I am attaching a copy of one of their emails 
> below.

My offer of help still stands (and I do have fairly recent 
successful experience with CVS -> git at sourceforge), but if Mr 
Raymond's also still stands his expertise in this sort of thing 
greatly exceeds mine.

Allin Cottrell

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

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

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.  But as the primary maintainer for the last several 
years, that decision is clearly yours.

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

> If no one steps up, then I'm afraid gnuplot development will be offline
> indefinitely.   

I'd hate to see that happen.

Eric S. Raymond has offered (twice) to help us with such a repository 
move, but I fear this rather short notice by SF may overload his ability 
to help all affected projects in time.  If that helps, I can offer to 
share the workload with Mr. Raymond, to whatever extent that even makes 
sense.

I'll be transforming another (smaller) project myself, so I'll have to 
learn how this is done, anyway.  I've already begun experimenting with 
the tools in question.

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

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

On 10/07/2017 02:32 PM, Daniel J Sebald wrote:

> For any volunteer thinking about taking on the transference from CVS to 
> git, my idea of what to do with the old ChangeLog is the following:  The 
> nice thing about git changesets is that one can do
> 
> git log
> 
> and then use the usual unix-like vi searching through the pager-log it 
> generates.  I wonder if as the very first changeset in the new 
> repository (or even if there is a comment associated with the "git init" 
> process) that we take the whole contents of the current ChangeLog and 
> copy that as the initial comment.  It will be big, but at least we can 
> then do a
> 
> git log
> 
> and that whole long ChangeLog history is right there at hand for 
> searching purposes along with all the change-logs that come after it.

I would add that if the CVS-to-git conversion process means that we 
couldn't put the ChangeLog's comment as the first entry, I think we 
could branch from the initial repository with a changeset consisting of 
the ChangeLog history as the first comment, and then rebase all the 
changesets onto that branch.  Maybe it doesn't make a difference where 
the ChangeLog contents appears in the log if all the comments for 
individual CVS changes are empty.

Dan

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

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

On 10/07/2017 01:30 PM, sfeam via gnuplot-beta wrote:
> Well guys, it's been fun.
> 
> SourceForge has announced that they will shut down CVS support next month.
> I have little time available to deal with this, and minimal prior experience with git.

First, building the git repository sans change history is simple.  Just 
get a fresh CVS checkout and build a git repository from scratch.  So 
there's that option to fall back on.

One big question is whether there is a simple way to take the whole CVS 
data base and convert all the change history into a git repository with 
associated changesets.  I think we've discussed before that the 
ChangeLog contents probably can't be sliced and diced into all the 
associated changesets--would have been nice, but at least we'll keep the 
ChangeLog file.  [Or, for someone interested in taking on the transfer, 
I'll write below something that could be done.]  There will no longer be 
a ChangeLog file.  Instead all the per-changeset comments will be 
inherent in the changeset itself.  That means that the person writing 
the changeset also writes the comments similar to the format used in 
ChangeLog then exports the whole changeset as a diff-file which has the 
comment at the top.  That can be edited by the maintainers and the 
pushed into the canonical repository.  That actually can save 
maintainers a lot of work.

You'll like git (or mercurial), though, once used to it.  It's not too 
difficult to use if utilizing only the simple commands, or working with 
the repository via gitg or something similar is easy.  But the diff 
tools and so on are much nicer than CVS.

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.

For any volunteer thinking about taking on the transference from CVS to 
git, my idea of what to do with the old ChangeLog is the following:  The 
nice thing about git changesets is that one can do

git log

and then use the usual unix-like vi searching through the pager-log it 
generates.  I wonder if as the very first changeset in the new 
repository (or even if there is a comment associated with the "git init" 
process) that we take the whole contents of the current ChangeLog and 
copy that as the initial comment.  It will be big, but at least we can 
then do a

git log

and that whole long ChangeLog history is right there at hand for 
searching purposes along with all the change-logs that come after it.

Dan



> So I am making a plea for a  volunteer to step up and transfer the project files
> to some git repository.
> 
> 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.
> 
> If no one steps up, then I'm afraid gnuplot development will be offline
> indefinitely.   I will try to put out a 5.2.1 release before the deadline so
> that at least the current state of development is captured.
> I'll also make and keep an rsync backup.
> 
> Please feel free to contact me privately if you don't want to reply here,
> but everyone reading this has a stake in the project and is welcome
> to offer opinions, suggestions, or whatever help you can.
> 
> 	Ethan
> 
> ----------  Forwarded Message  ----------
> 
> Subject: CVS support at SourceForge and Nov. 30
> Date: Saturday, 07 October 2017, 16:20:47
> From: SourceForge Support <cvs...@so...>
> 
> Greetings project admin,
> 
> We have been planning to discontinue CVS support here at SourceForge for several years now, and that time has finally arrived. Since your project is making use of CVS for your source version control, you should now convert your repository over to another version control system.
> 
> The current plan is to stop allowing CVS commits by November 30th. To be able to continue making source code changes you’ll need to have your CVS repo converted by then. The ssh access method will stop working, but read-only access via both pserver, rsync, and interactive shell will continue to be available past the cutoff date (we haven’t determined if or when the read-only support will end). This means that you will have plenty of time to convert your data to a new SCM format, even well past the cutoff date.
> 
> If you don’t have a particular SCM choice in mind, we recommend choosing Subversion (SVN) since it has a workflow that is most similar to that of CVS. You might also want to choose Git, which is very popular these days, though it does have a steeper learning curve compared to switching to Subversion. You can even give each one a try and keep the one you like best. Don’t be afraid to experiment.
> 
> For information on how to convert your repository from CVS to SVN or Git, visit the following web page: https://sourceforge.net/p/forge/documentation/CVS/
> 
> The page also documents the rsync backup method.
> 
> We hope that your conversion goes smoothly. You can let us know if you run into any issues by replying to this email.
> 
> Sincerely,
> 
> SourceForge Support
> 
> -----------------------------------------
> 
> ------------------------------------------------------------------------------
> 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

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

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

Hello Ethan,

In the past we had a few discussions on migrating away from CVS on the list - with different opinions on Git, Hg, or Subversion.  Personally, I am not unhappy about the end of CVS support by SF, but I hardly have experience with repository conversion myself.

Eric S. Raymond and Allin Cottrel kindly offered help to convert about two years ago. I am attaching a copy of one of their emails below.

Bastian


> -----Ursprüngliche Nachricht-----
> Von: Eric S. Raymond [mailto:es...@th...]
> Gesendet: Montag, 23. November 2015 23:25
> An: Allin Cottrell <cot...@wf...>
> Cc: gnu...@li...
> Betreff: Re: CVS woes
> 
> Allin Cottrell <cot...@wf...>:
> > Any plans for gnuplot to migrate to git? That seems to be _much_
> > better supported at sourceforge. I recently converted gretl
> > (econometrics software on sourceforge) from CVS to git and it has been
> > trouble-free since. If there's interest I can send my recipe for the
> > transition. (There are several "how-to"s out there, but they're not
> > all up to date.)
> 
> I still lurk on this list because I offered to do a git conversion a couple years
> back.  I'm a former GNUPlot contributor and now maintain cvs-fast-export; I'm
> the author of one of those how-tos.
> 
> The maintainers weren't interested, last time.  We'll see if anything has
> changed.  It should; in 2015 still using CVS has gone beyond quaint and retro
> into embarrassing, do-you-never-want-to-have-new-contributors
> territory.
> --
> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>

> -----Ursprüngliche Nachricht-----
> Von: sfeam via gnuplot-beta [mailto:gnu...@li...]
> Gesendet: Samstag, 7. Oktober 2017 20:31
> An: gnu...@li...
> Betreff: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)
> 
> Well guys, it's been fun.
> 
> SourceForge has announced that they will shut down CVS support next month.
> I have little time available to deal with this, and minimal prior experience with
> git.
> 
> So I am making a plea for a  volunteer to step up and transfer the project files
> to some git repository.
> 
> 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.
> 
> If no one steps up, then I'm afraid gnuplot development will be offline
> indefinitely.   I will try to put out a 5.2.1 release before the deadline so
> that at least the current state of development is captured.
> I'll also make and keep an rsync backup.
> 
> Please feel free to contact me privately if you don't want to reply here, but
> everyone reading this has a stake in the project and is welcome to offer
> opinions, suggestions, or whatever help you can.
> 
> 	Ethan
> 
> ----------  Forwarded Message  ----------
> 
> Subject: CVS support at SourceForge and Nov. 30
> Date: Saturday, 07 October 2017, 16:20:47
> From: SourceForge Support <cvs...@so...>
> 
> Greetings project admin,
> 
> We have been planning to discontinue CVS support here at SourceForge for
> several years now, and that time has finally arrived. Since your project is
> making use of CVS for your source version control, you should now convert your
> repository over to another version control system.
> 
> The current plan is to stop allowing CVS commits by November 30th. To be able
> to continue making source code changes you’ll need to have your CVS repo
> converted by then. The ssh access method will stop working, but read-only
> access via both pserver, rsync, and interactive shell will continue to be available
> past the cutoff date (we haven’t determined if or when the read-only support
> will end). This means that you will have plenty of time to convert your data to a
> new SCM format, even well past the cutoff date.
> 
> If you don’t have a particular SCM choice in mind, we recommend choosing
> Subversion (SVN) since it has a workflow that is most similar to that of CVS. You
> might also want to choose Git, which is very popular these days, though it does
> have a steeper learning curve compared to switching to Subversion. You can
> even give each one a try and keep the one you like best. Don’t be afraid to
> experiment.
> 
> For information on how to convert your repository from CVS to SVN or Git, visit
> the following web page: https://sourceforge.net/p/forge/documentation/CVS/
> 
> The page also documents the rsync backup method.
> 
> We hope that your conversion goes smoothly. You can let us know if you run
> into any issues by replying to this email.
> 
> Sincerely,
> 
> SourceForge Support
> 
> -----------------------------------------
> 
> ------------------------------------------------------------------------------
> 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

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

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

sfeam via gnuplot-beta writes:
> Well guys, it's been fun.
>
> SourceForge has announced that they will shut down CVS support next month.
> I have little time available to deal with this, and minimal prior experience with git.
>
> So I am making a plea for a  volunteer to step up and transfer the project files
> to some git repository.

There's already an unofficial repository (not that I'd endorse GitHub):
https://github.com/gnuplot/gnuplot

As noted on that page, this uses cvsimport to do the mirroring, which
sometimes produces somewhat strange commits on the Git side.  You might
want to get in touch with Eric S. Raymond if you want the CVS repo
cleaned and converted with some more care into Git (he's done that
before for other projects).


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

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

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

Well guys, it's been fun.

SourceForge has announced that they will shut down CVS support next month.
I have little time available to deal with this, and minimal prior experience with git.

So I am making a plea for a  volunteer to step up and transfer the project files
to some git repository.

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.

If no one steps up, then I'm afraid gnuplot development will be offline 
indefinitely.   I will try to put out a 5.2.1 release before the deadline so
that at least the current state of development is captured.
I'll also make and keep an rsync backup.

Please feel free to contact me privately if you don't want to reply here,
but everyone reading this has a stake in the project and is welcome
to offer opinions, suggestions, or whatever help you can.

	Ethan

----------  Forwarded Message  ----------

Subject: CVS support at SourceForge and Nov. 30
Date: Saturday, 07 October 2017, 16:20:47
From: SourceForge Support <cvs...@so...>

Greetings project admin,

We have been planning to discontinue CVS support here at SourceForge for several years now, and that time has finally arrived. Since your project is making use of CVS for your source version control, you should now convert your repository over to another version control system.

The current plan is to stop allowing CVS commits by November 30th. To be able to continue making source code changes you’ll need to have your CVS repo converted by then. The ssh access method will stop working, but read-only access via both pserver, rsync, and interactive shell will continue to be available past the cutoff date (we haven’t determined if or when the read-only support will end). This means that you will have plenty of time to convert your data to a new SCM format, even well past the cutoff date.

If you don’t have a particular SCM choice in mind, we recommend choosing Subversion (SVN) since it has a workflow that is most similar to that of CVS. You might also want to choose Git, which is very popular these days, though it does have a steeper learning curve compared to switching to Subversion. You can even give each one a try and keep the one you like best. Don’t be afraid to experiment.

For information on how to convert your repository from CVS to SVN or Git, visit the following web page: https://sourceforge.net/p/forge/documentation/CVS/

The page also documents the rsync backup method.

We hope that your conversion goes smoothly. You can let us know if you run into any issues by replying to this email.

Sincerely,

SourceForge Support

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

Re: swprintf_s in src/win32

[Allin C. <cot...@wf...>]

On Fri, 29 Sep 2017, Hans-Bernhard Bröker wrote:

> Am 29.09.2017 um 22:48 schrieb Allin Cottrell:
>
>> In current mingw64 built from source on Linux (x86_64-w64-mingw32 and 
>> i686-w64-mingw32) MINGW_HAS_SECURE_API is not defined in _mingw.h, or 
>> anywhere else, unless you choose --enable-secure-api at configure time 
>> (it's not enabled by default). Most software I've cross-built for Windows 
>> doesn't require sec_api so building wgnuplot is the first time I've come 
>> across this.
>
> Well, suffice it to say that the provided configuration in config/mingw is 
> explicitly designed for MSYS2 MinGW, which doesn't need that switch (and 
> would cause redefinition warnings if it was set).
>
> A cross-build from Linux is a completely separate kettle of fish.  There 
> would be a lot of other problems with that, starting with the lack of a Linux 
> edition of Microsoft's HTML Help Workshop...

It's easy enough to borrow a copy of wgnuplot.chm from a native 
Windows build, if one doesn't have the patience to get the HTML Help 
builder working under wine. Everything else works OK, modulo the MS 
"secure api" requirement (which is a relatively new thing, it wasn't 
an issue in years past).

All I'm suggesting is something like a note in config/mingw/Makefile 
saying you need to ensure that your mingw64 header build has 
enable-secure-api set. That would have saved me a fair amount of 
frustration.

Allin Cottrell

Re: swprintf_s in src/win32

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

Am 29.09.2017 um 22:48 schrieb Allin Cottrell:

> In current mingw64 built from source on Linux (x86_64-w64-mingw32 and 
> i686-w64-mingw32) MINGW_HAS_SECURE_API is not defined in _mingw.h, or 
> anywhere else, unless you choose --enable-secure-api at configure time 
> (it's not enabled by default). Most software I've cross-built for 
> Windows doesn't require sec_api so building wgnuplot is the first time 
> I've come across this.

Well, suffice it to say that the provided configuration in config/mingw 
is explicitly designed for MSYS2 MinGW, which doesn't need that switch 
(and would cause redefinition warnings if it was set).

A cross-build from Linux is a completely separate kettle of fish.  There 
would be a lot of other problems with that, starting with the lack of a 
Linux edition of Microsoft's HTML Help Workshop...

Re: swprintf_s in src/win32

[Allin C. <cot...@wf...>]

On Fri, 29 Sep 2017, Hans-Bernhard Bröker wrote:

> Am 29.09.2017 um 21:14 schrieb Allin Cottrell:
>> On Fri, 29 Sep 2017, Allin Cottrell wrote:
>
>>> My headers are also version 5.0.2 but I guess something must be wrong with 
>>> my setup; I'll investigate.
>> 
>> Ah, the build goes OK if I add -DMINGW_HAS_SECURE_API to CFLAGS. Maybe that 
>> information could be added in config/mingw?
>
> No, I don't think it should, since the program builds fine without it. I 
> check with both with the MinGW64 cross tools provided by Cygwin (that's 
> config/cygwin) and with MSYS2 MinGW64 (config/mingw).
>
> That switch is supposed to controlled by MinGW's own configuration header, 
> <_mingw.h>.

In current mingw64 built from source on Linux (x86_64-w64-mingw32 
and i686-w64-mingw32) MINGW_HAS_SECURE_API is not defined in 
_mingw.h, or anywhere else, unless you choose --enable-secure-api at 
configure time (it's not enabled by default). Most software I've 
cross-built for Windows doesn't require sec_api so building wgnuplot 
is the first time I've come across this.

I think it should be stated somewhere in config/mingw that you need 
to enable this (somewhow) to build wgnuplot. No harm done if one is 
using a pre-built mingw64 which already enables it.

Allin Cottrell

Re: swprintf_s in src/win32

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

Am 29.09.2017 um 21:14 schrieb Allin Cottrell:
> On Fri, 29 Sep 2017, Allin Cottrell wrote:

>> My headers are also version 5.0.2 but I guess something must be wrong 
>> with my setup; I'll investigate.
> 
> Ah, the build goes OK if I add -DMINGW_HAS_SECURE_API to CFLAGS. Maybe 
> that information could be added in config/mingw?

No, I don't think it should, since the program builds fine without it. 
I check with both with the MinGW64 cross tools provided by Cygwin 
(that's config/cygwin) and with MSYS2 MinGW64 (config/mingw).

That switch is supposed to controlled by MinGW's own configuration 
header, <_mingw.h>.

Re: swprintf_s in src/win32

[Allin C. <cot...@wf...>]

On Fri, 29 Sep 2017, Hans-Bernhard Bröker wrote:

> Am 28.09.2017 um 23:12 schrieb Allin Cottrell:
>> Three of the source files in gnuplot's src/win32 use the function 
>> swprintf_s(), namely wgdiplus.cpp, wmenu.c and wtext.c. In one of these 
>> files, wgdiplus.cpp, there's a recognition that this function is not 
>> universally available:
>> 
>> #ifdef __WATCOMC__
>> // swprintf_s is missing from <cwchar>
>> # define swprintf_s(s, c, f, ...) swprintf(s, c, f, __VA_ARGS__)
>> #endif
>> 
>> It seems to me that this guard against use of an undefined function should 
>> also be present in wmenu.c and wtext.c
>
> It may seem like that at first glance, but it's not actually the case. 
> OpenWatcom does supply swprintf_s(), but only for C source code, not for C++. 
> I.e. it's in <wchar.h>, but not available via its C++ equivalent, <cwchar>.

OK, I see.

> . Moreover, it's not just
>> the Watcom compiler that's affected: swprintf_s is not declared in the 
>> headers provided for cross-compilation via mingw64.
>
> I see no such problem here.  Maybe your version of mingw64 is outdated?
>
> (For reference, I'm using the current version of the MinGW64 headers as 
> installed by Cygwin, from package mingw64-x86_64-headers-5.0.2-1).

My headers are also version 5.0.2 but I guess something must be wrong 
with my setup; I'll investigate.

Allin Cottrell

Re: swprintf_s in src/win32

[Allin C. <cot...@wf...>]

On Fri, 29 Sep 2017, Allin Cottrell wrote:

> On Fri, 29 Sep 2017, Hans-Bernhard Bröker wrote:
>
>> Moreover, it's not just
>>> the Watcom compiler that's affected: swprintf_s is not declared in the 
>>> headers provided for cross-compilation via mingw64.
>> 
>> I see no such problem here.  Maybe your version of mingw64 is outdated?
>> 
>> (For reference, I'm using the current version of the MinGW64 headers as 
>> installed by Cygwin, from package mingw64-x86_64-headers-5.0.2-1).
>
> My headers are also version 5.0.2 but I guess something must be 
> wrong with my setup; I'll investigate.

Ah, the build goes OK if I add -DMINGW_HAS_SECURE_API to CFLAGS. Maybe 
that information could be added in config/mingw?

Allin Cottrell