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

Re: Trial git repo is back up

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

17. okt. 2017 18:06 steam wrote:

On Wednesday, 18 October 2017 02:12:51 Mojca Miklavec wrote:
> 17. okt. 2017 09:01 "Eric S. Raymond" wrote:

> I would suggest unifying those names (perhaps to something like v5.2.rc0),
> but that can be done later.

???
Sorry, I don't get it.
Why would you want to unify any of those?


Why would you want version 3.7.1 to be called GNUPLOT_RELEASE_3_7_1 and
version 5.2.1 to be called Release_5_2_1? Why not use something following
the same pattern for both? Like a simple v3.7.1/v5.2.1?

What I want is to be able to check them out separately.


Sure, changing the name won't disable it, but unless you unify names,
you'll have to check the exact name for each revision you'll want to
checkout.

Everything labeled pre* or BETA* can be junked, but that is
not what I understand as "unify".

Now maybe I just misunderstand the whole git thing.
Remember I'm new to this and thinking in terms of CVS.
What I'm thinking is that if I do
 git checkout Release_5_0_7

I'll get the same files that were in the release tarball
gnuplot-5.0.7.tar.gz


No, you won't because the generated files (configure etc) are missing. On
Github one can attach files to tags though.

And if for some reason we wanted to continue development of the 5.0 series
for a release 5.0.8, I could clone it (I don't know what git command that
is)
as a new branch Release_5_0_8 and push that one back to the repository.
Have I got that wrong?


You would checkout the branch 5.0, make changes to it and then tag a new
release. You would never make a 5.0.8 branch, only a tag.

Mojca

Re: Trial git repo is back up

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

On Wednesday, 18 October 2017 02:12:51 Mojca Miklavec wrote:
> 17. okt. 2017 09:01 "Eric S. Raymond" wrote:
> 
> I see
> 
> esr@snark:/mnt/vault/esr-vault/gnuplot/gnuplot$ git tag --list
> BETA_347_980925
> BETA_347_981005
> BETA_347_98101301
> BETA_347_981121
> BETA_348
> BETA_348_981204
> BETA_349
> BETA_349_990114
> GNUPLOT_19991210
> GNUPLOT_20000330
> GNUPLOT_37_20000507
> GNUPLOT_990311
> GNUPLOT_990312
> GNUPLOT_990404
> GNUPLOT_990507
> GNUPLOT_990602
> GNUPLOT_990612
> GNUPLOT_990705
> GNUPLOT_RELEASE_19991103
> GNUPLOT_RELEASE_3_7_1
> GNUPLOT_RELEASE_3_7_2
> GNUPLOT_RELEASE_3_7_3
> Release_4_2_1
> Release_4_2_1-pre1
> Release_4_2_3
> Release_4_2_4
> Release_4_2_5
> Release_4_2_6
> Release_4_4_0
> Release_4_4_1
> Release_4_4_2
> Release_4_4_3
> Release_4_4_4
> Release_4_4_rc1
> Release_4_6_0
> Release_4_6_1
> Release_4_6_2
> Release_4_6_4
> Release_4_6_5
> Release_4_6_6
> Release_4_6_rc1
> Release_5_0_0
> Release_5_0_1
> Release_5_0_2
> Release_5_0_3
> Release_5_0_4
> Release_5_0_5
> Release_5_0_6
> Release_5_0_7
> Release_5_2_0
> Release_5_2_1
> axis-checkpoint-sourceforge-20000728
> git-conversion
> gnuplot-3-8f
> gnuplot-4-4-alpha
> gnuplot-4-6-alpha
> gnuplot-5-0-rc2
> gnuplot-5-2-rc0
> pm3d-14
> pre-lt-palette
> pre-macport
> pre-pm3d-02
> pre-pm3d-11
> 
> 
> I would suggest unifying those names (perhaps to something like v5.2.rc0),
> but that can be done later.

???
Sorry, I don't get it.
Why would you want to unify any of those?
What I want is to be able to check them out separately.

Everything labeled pre* or BETA* can be junked, but that is
not what I understand as "unify".

Now maybe I just misunderstand the whole git thing.
Remember I'm new to this and thinking in terms of CVS.
What I'm thinking is that if I do 
 git checkout Release_5_0_7

I'll get the same files that were in the release tarball
gnuplot-5.0.7.tar.gz
And if for some reason we wanted to continue development of the 5.0 series
for a release 5.0.8, I could clone it (I don't know what git command that is)
as a new branch Release_5_0_8 and push that one back to the repository.
Have I got that wrong?

	Ethan

Re: Trial git repo is back up

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

17. okt. 2017 09:01 "Eric S. Raymond" wrote:

I see

esr@snark:/mnt/vault/esr-vault/gnuplot/gnuplot$ git tag --list
BETA_347_980925
BETA_347_981005
BETA_347_98101301
BETA_347_981121
BETA_348
BETA_348_981204
BETA_349
BETA_349_990114
GNUPLOT_19991210
GNUPLOT_20000330
GNUPLOT_37_20000507
GNUPLOT_990311
GNUPLOT_990312
GNUPLOT_990404
GNUPLOT_990507
GNUPLOT_990602
GNUPLOT_990612
GNUPLOT_990705
GNUPLOT_RELEASE_19991103
GNUPLOT_RELEASE_3_7_1
GNUPLOT_RELEASE_3_7_2
GNUPLOT_RELEASE_3_7_3
Release_4_2_1
Release_4_2_1-pre1
Release_4_2_3
Release_4_2_4
Release_4_2_5
Release_4_2_6
Release_4_4_0
Release_4_4_1
Release_4_4_2
Release_4_4_3
Release_4_4_4
Release_4_4_rc1
Release_4_6_0
Release_4_6_1
Release_4_6_2
Release_4_6_4
Release_4_6_5
Release_4_6_6
Release_4_6_rc1
Release_5_0_0
Release_5_0_1
Release_5_0_2
Release_5_0_3
Release_5_0_4
Release_5_0_5
Release_5_0_6
Release_5_0_7
Release_5_2_0
Release_5_2_1
axis-checkpoint-sourceforge-20000728
git-conversion
gnuplot-3-8f
gnuplot-4-4-alpha
gnuplot-4-6-alpha
gnuplot-5-0-rc2
gnuplot-5-2-rc0
pm3d-14
pre-lt-palette
pre-macport
pre-pm3d-02
pre-pm3d-11


I would suggest unifying those names (perhaps to something like v5.2.rc0),
but that can be done later.

Mojca

Re: Trial git repo is back up

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

On 10/17/2017 06:01 AM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
>> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
>>> Trial git repo is back up, with the conversion bug I previously noted fixed.
>>
>> Also, the branches are tags are not in the repository, at least not in the
>> conventional way.  In neither git-gui, gitk nor gitg are there any branches
>> listed other than "master" and "origin > master".  It could be there is some
>> fragments of branches though.  In gitk I look at the visual, colored
>> branches.  There are no bifurcations, but there are occasional colored lines
>> appearing that then go away.  I suspect that those lines are supposed to be
>> the branches.  I'm attaching a small portion of a screen shot illustrating
>> how the line changes color rather than splitting out into branch.
>>
>> My guess is that all the changeset info is there, but the labels that
>> associate branch names with the SHAs are missing.
>>
>> Dan
>>
> 
> CVS branch labels turn into git lightweight tags. Look at the output
> of git tag -l to check whether any tags actually got lost in the conversion.

Tags rather than branches?  I think we'd prefer the CVS branches be 
mapped to git branches.


> The way gitk displays these (or doesn't) is confusing - I've never quite
> understood its rules.  Adding the --tags option shows more of them.

Yes, gitk takes the easy way out by displaying all the commits for a 
branch contiguously, then all the commits for the trunk or another 
branch.  Unlike most viewers, it doesn't seem to be able to display the 
commits chronologically and construct the trellis around that.  qgit is 
similar to gitk (probably using some of the same underlying tools as 
gitk).  So, although it displays things in a way that should be 
understandable, it doesn't really present a convenient view of the graph.

So, let me go back to gitg.  I've placed a screenshot of the test 
repository that was generated with cvsimport here:

http://www.dansebald.com/gnuplot/cvsimport_conversion_Screenshot_from_2017-10-17_11-52-18.png

That conversion has associated git branches with CVS branches, sort of 
what I was expecting.

Dan

Re: Trial git repo is back up

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

sfeam <sf...@us...>:
> I'm not seeing any tags or branches at all. 
> 
> himeji [15] git pull
> Already up-to-date.
> himeji [16] git branch --list
> * master
> himeji [17] git tag --list
> himeji [18] 

I see

esr@snark:/mnt/vault/esr-vault/gnuplot/gnuplot$ git tag --list
BETA_347_980925
BETA_347_981005
BETA_347_98101301
BETA_347_981121
BETA_348
BETA_348_981204
BETA_349
BETA_349_990114
GNUPLOT_19991210
GNUPLOT_20000330
GNUPLOT_37_20000507
GNUPLOT_990311
GNUPLOT_990312
GNUPLOT_990404
GNUPLOT_990507
GNUPLOT_990602
GNUPLOT_990612
GNUPLOT_990705
GNUPLOT_RELEASE_19991103
GNUPLOT_RELEASE_3_7_1
GNUPLOT_RELEASE_3_7_2
GNUPLOT_RELEASE_3_7_3
Release_4_2_1
Release_4_2_1-pre1
Release_4_2_3
Release_4_2_4
Release_4_2_5
Release_4_2_6
Release_4_4_0
Release_4_4_1
Release_4_4_2
Release_4_4_3
Release_4_4_4
Release_4_4_rc1
Release_4_6_0
Release_4_6_1
Release_4_6_2
Release_4_6_4
Release_4_6_5
Release_4_6_6
Release_4_6_rc1
Release_5_0_0
Release_5_0_1
Release_5_0_2
Release_5_0_3
Release_5_0_4
Release_5_0_5
Release_5_0_6
Release_5_0_7
Release_5_2_0
Release_5_2_1
axis-checkpoint-sourceforge-20000728
git-conversion
gnuplot-3-8f
gnuplot-4-4-alpha
gnuplot-4-6-alpha
gnuplot-5-0-rc2
gnuplot-5-2-rc0
pm3d-14
pre-lt-palette
pre-macport
pre-pm3d-02
pre-pm3d-11

I'll try adding a git push --tags to my conversion script.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

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

On Tuesday, 17 October 2017 07:01:45 Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
> > On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> > >Trial git repo is back up, with the conversion bug I previously noted fixed.
> > 
> > Also, the branches are tags are not in the repository, at least not in the
> > conventional way.  In neither git-gui, gitk nor gitg are there any branches
> > listed other than "master" and "origin > master".  It could be there is some
> > fragments of branches though.  In gitk I look at the visual, colored
> > branches.  There are no bifurcations, but there are occasional colored lines
> > appearing that then go away.  I suspect that those lines are supposed to be
> > the branches.  I'm attaching a small portion of a screen shot illustrating
> > how the line changes color rather than splitting out into branch.
> > 
> > My guess is that all the changeset info is there, but the labels that
> > associate branch names with the SHAs are missing.
> > 
> > Dan
> > 
> 
> CVS branch labels turn into git lightweight tags. Look at the output
> of git tag -l to check whether any tags actually got lost in the conversion.
> 
> The way gitk displays these (or doesn't) is confusing - I've never quite
> understood its rules.  Adding the --tags option shows more of them.

I'm not seeing any tags or branches at all. 

himeji [15] git pull
Already up-to-date.
himeji [16] git branch --list
* master
himeji [17] git tag --list
himeji [18] 


	Ethan

Re: Trial git repo is back up

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

Daniel J Sebald <dan...@ie...>:
> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> >Trial git repo is back up, with the conversion bug I previously noted fixed.
> 
> Also, the branches are tags are not in the repository, at least not in the
> conventional way.  In neither git-gui, gitk nor gitg are there any branches
> listed other than "master" and "origin > master".  It could be there is some
> fragments of branches though.  In gitk I look at the visual, colored
> branches.  There are no bifurcations, but there are occasional colored lines
> appearing that then go away.  I suspect that those lines are supposed to be
> the branches.  I'm attaching a small portion of a screen shot illustrating
> how the line changes color rather than splitting out into branch.
> 
> My guess is that all the changeset info is there, but the labels that
> associate branch names with the SHAs are missing.
> 
> Dan
> 

CVS branch labels turn into git lightweight tags. Look at the output
of git tag -l to check whether any tags actually got lost in the conversion.

The way gitk displays these (or doesn't) is confusing - I've never quite
understood its rules.  Adding the --tags option shows more of them.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

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

Daniel J Sebald <dan...@ie...>:
> I'm even wondering if we could even replace the "empty log message" with
> some estimate of a message extracted from the corresponding ChangeLog entry.
> But, there are only 210 such messages:
> 
> git log | grep "empty log message" | wc
>     210    1050    6300
> 
> Maybe those could be replaced by hand (if at all), everyone doing five or
> ten summary lines, but it isn't that important.

A few of those are CVS artifacts that can be removed entirely.

But yes, I've done this sort of thing (filling in blank comments)
in the past.  In this case it should be oretty easy - use gitk to locate
the bad comment, look at the associated ChangeLog entry.

Everybody, feel free to send me proposed fill-ins; I'll add those
transformations to the conversion script.  It's easily done in
reposurgeon.
-- 
		<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: [BUG] config.ac

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

On 10/17/2017 12:34 AM, Mojca Miklavec wrote:
> 
> 
> 16. okt. 2017 8:58 PM je oseba "sfeam via gnuplot-beta" napisala:
> 
>     Is this issue the same as Bug #1119?
> 
>     https://sourceforge.net/p/gnuplot/bugs/1119/
>     <https://sourceforge.net/p/gnuplot/bugs/1119/>
> 
> 
> It's not. The main problem there is that DESTDIR is not respected and 
> make clean would not remove files either.
That's "make uninstall", as opposed to "clean", correct?  Let's continue 
at the bug-report site.

Dan

Re: [BUG] config.ac

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

16. okt. 2017 8:58 PM je oseba "sfeam via gnuplot-beta" napisala:

Is this issue the same as Bug #1119?

   https://sourceforge.net/p/gnuplot/bugs/1119/


It's not. The main problem there is that DESTDIR is not respected and make
clean would not remove files either.

Mojca

Re: [BUG] config.ac

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

On 10/16/2017 10:57 PM, sfeam wrote:
> Is this issue the same as Bug #1119?
> 
>     https://sourceforge.net/p/gnuplot/bugs/1119/
> 
> 	Ethan

It certainly looks like the same issue.  I don't know how Macports works 
or why it is unable to remove the files (presuming Macports has adequate 
privilege).  Also, I can understand the various directories for 
different types of files, but whether those subdirectories are meant to 
be a subdirectory of TEXDIR or somewhere else I'm not sure.

Dan


> On Monday, 16 October 2017 20:42:32 Daniel J Sebald wrote:
>> On 10/16/2017 08:29 PM, Daniel J Sebald wrote:
>>> On 10/16/2017 07:35 PM, Ethan A Merritt via gnuplot-beta wrote:
>>>   > On Sunday, 15 October, 2017 17:40:03 Achim Gratz wrote:
>>>   >
>>>   >  >
>>>   >
>>>   >  > The configury supposedly tries to find TEXDIR via kpsexpand, but that
>>>   >
>>>   >  > code never gets run if $prefix is set.
>>>   >
>>>   > I really don't know if this is correct or not.
>>>   >
>>>   > In my experience there are so many places that the TeX stuff
>>>   >
>>>   > might go, your only hope is to manually specify where it is
>>>   >
>>>   > on the current system. It doesn't help any that according to the
>>>   >
>>>   > man page
>>>   >
>>>   > "the syntax for kpsexpand is incompatible with teTeX´s as of version
>>> 0.4"
>>>   >
>>>   > I read the existing ./configure logic to be that anything kpsexpand
>>>   >
>>>   > returns is where things would be by default, but if you are specifying
>>>   >
>>>   > a $prefix then you are overriding the default.
>>>   >
>>>   > Does it ever make sense to mix the two?
>>>   >
>>>   > What do other people think?
>>>
>>> Well, this
>>>
>>> AC_ARG_WITH(texdir,dnl
>>>     [--with-texdir=DIR       where to install latex style files
>>>                             (default by kpsexpand in subdir PACKAGE)],
>>>     TEXDIR="$withval",
>>>     TEXDIR="no")
>>>
>>> means a person can't choose a directory name "no".
>>>
>>> The goal is to find a location for gnuplot's few supplemental tex/latex
>>> files?  I presume we really don't want those to go to kpsexpand's local
>>> tex; that's the system's copy of tex source.  Most typically we want the
>>> extra TeX files to go somewhere in the directory tree where gnuplot is
>>> installed.  Is that correct?
>>>
>>> So, the logic of the current configure is (if no TEXDIR is specified) to
>>> choose the location where gnuplot is installed as the base directory for
>>> where TeX files will be placed.  If there is no such prefix, then it
>>> looks to the default kpsexpand location.  I presume that when the TeX
>>> files are installed at the location of the gnuplot executable that the
>>> TeX path is somehow added to the TeX system paths?
>>
>> Oh, wait, I don't think I was understanding that correctly.  kpsexpand's
>> '$TEXMFLOCAL' is a location for "non-system" TeX files (that will be
>> recognized in TeX/LaTeX's path?).  So, that is typically where we want
>> files to go, regardless of whether one indicates a gnuplot installation
>> prefix or not.  Is that right?  We really want to use $prefix as a last
>> resort then, correct?  In that case, I would go with what Achim is arguing.
>>
>> +    TEXDIR=`$KPSEXPAND '$TEXMFLOCAL'`
>>
>> [Do we know that kpsexpand is present once reaching this point?]
>>
>> +    if test "x$TEXDIR" = "x" -o "$TEXDIR" = "\$TEXMFLOCAL"; then
>>
>> [If kpsexpand  fails to find a TEXMFLOCAL, how do we know that
>> TEXMFLOCAL is going to be present in our environment?  Just hoping by
>> chance that it is?  If we didn't have kpsexpand, I could see attempting
>> this last-ditch effort.]
>>
>> +      if test "x$prefix" != "xNONE"; then
>> +        TEXDIR=${prefix}/share/texmf
>> +      else
>>            TEXDIR=${ac_default_prefix}/share/texmf
>>          fi
>>
>> Dan
>>
>> ------------------------------------------------------------------------------
>> 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: [BUG] config.ac

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

Is this issue the same as Bug #1119?

   https://sourceforge.net/p/gnuplot/bugs/1119/

	Ethan

On Monday, 16 October 2017 20:42:32 Daniel J Sebald wrote:
> On 10/16/2017 08:29 PM, Daniel J Sebald wrote:
> > On 10/16/2017 07:35 PM, Ethan A Merritt via gnuplot-beta wrote:
> >  > On Sunday, 15 October, 2017 17:40:03 Achim Gratz wrote:
> >  >
> >  >  >
> >  >
> >  >  > The configury supposedly tries to find TEXDIR via kpsexpand, but that
> >  >
> >  >  > code never gets run if $prefix is set.
> >  >
> >  > I really don't know if this is correct or not.
> >  >
> >  > In my experience there are so many places that the TeX stuff
> >  >
> >  > might go, your only hope is to manually specify where it is
> >  >
> >  > on the current system. It doesn't help any that according to the
> >  >
> >  > man page
> >  >
> >  > "the syntax for kpsexpand is incompatible with teTeX´s as of version 
> > 0.4"
> >  >
> >  > I read the existing ./configure logic to be that anything kpsexpand
> >  >
> >  > returns is where things would be by default, but if you are specifying
> >  >
> >  > a $prefix then you are overriding the default.
> >  >
> >  > Does it ever make sense to mix the two?
> >  >
> >  > What do other people think?
> > 
> > Well, this
> > 
> > AC_ARG_WITH(texdir,dnl
> >    [--with-texdir=DIR       where to install latex style files
> >                            (default by kpsexpand in subdir PACKAGE)],
> >    TEXDIR="$withval",
> >    TEXDIR="no")
> > 
> > means a person can't choose a directory name "no".
> > 
> > The goal is to find a location for gnuplot's few supplemental tex/latex 
> > files?  I presume we really don't want those to go to kpsexpand's local 
> > tex; that's the system's copy of tex source.  Most typically we want the 
> > extra TeX files to go somewhere in the directory tree where gnuplot is 
> > installed.  Is that correct?
> > 
> > So, the logic of the current configure is (if no TEXDIR is specified) to 
> > choose the location where gnuplot is installed as the base directory for 
> > where TeX files will be placed.  If there is no such prefix, then it 
> > looks to the default kpsexpand location.  I presume that when the TeX 
> > files are installed at the location of the gnuplot executable that the 
> > TeX path is somehow added to the TeX system paths?
> 
> Oh, wait, I don't think I was understanding that correctly.  kpsexpand's 
> '$TEXMFLOCAL' is a location for "non-system" TeX files (that will be 
> recognized in TeX/LaTeX's path?).  So, that is typically where we want 
> files to go, regardless of whether one indicates a gnuplot installation 
> prefix or not.  Is that right?  We really want to use $prefix as a last 
> resort then, correct?  In that case, I would go with what Achim is arguing.
> 
> +    TEXDIR=`$KPSEXPAND '$TEXMFLOCAL'`
> 
> [Do we know that kpsexpand is present once reaching this point?]
> 
> +    if test "x$TEXDIR" = "x" -o "$TEXDIR" = "\$TEXMFLOCAL"; then
> 
> [If kpsexpand  fails to find a TEXMFLOCAL, how do we know that 
> TEXMFLOCAL is going to be present in our environment?  Just hoping by 
> chance that it is?  If we didn't have kpsexpand, I could see attempting 
> this last-ditch effort.]
> 
> +      if test "x$prefix" != "xNONE"; then
> +        TEXDIR=${prefix}/share/texmf
> +      else
>           TEXDIR=${ac_default_prefix}/share/texmf
>         fi
> 
> Dan
> 
> ------------------------------------------------------------------------------
> 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: Trial git repo is back up

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

Ethan A Merritt <sf...@us...>:
> Yeah. I only looked for your name in particular because you
> raised the issue.

It's good that he did. There's an actual bug; I'll chase it down after
I have slept.
-- 
		<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: [BUG] config.ac

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

On 10/16/2017 08:29 PM, Daniel J Sebald wrote:
> On 10/16/2017 07:35 PM, Ethan A Merritt via gnuplot-beta wrote:
>  > On Sunday, 15 October, 2017 17:40:03 Achim Gratz wrote:
>  >
>  >  >
>  >
>  >  > The configury supposedly tries to find TEXDIR via kpsexpand, but that
>  >
>  >  > code never gets run if $prefix is set.
>  >
>  > I really don't know if this is correct or not.
>  >
>  > In my experience there are so many places that the TeX stuff
>  >
>  > might go, your only hope is to manually specify where it is
>  >
>  > on the current system. It doesn't help any that according to the
>  >
>  > man page
>  >
>  > "the syntax for kpsexpand is incompatible with teTeX´s as of version 
> 0.4"
>  >
>  > I read the existing ./configure logic to be that anything kpsexpand
>  >
>  > returns is where things would be by default, but if you are specifying
>  >
>  > a $prefix then you are overriding the default.
>  >
>  > Does it ever make sense to mix the two?
>  >
>  > What do other people think?
> 
> Well, this
> 
> AC_ARG_WITH(texdir,dnl
>    [--with-texdir=DIR       where to install latex style files
>                            (default by kpsexpand in subdir PACKAGE)],
>    TEXDIR="$withval",
>    TEXDIR="no")
> 
> means a person can't choose a directory name "no".
> 
> The goal is to find a location for gnuplot's few supplemental tex/latex 
> files?  I presume we really don't want those to go to kpsexpand's local 
> tex; that's the system's copy of tex source.  Most typically we want the 
> extra TeX files to go somewhere in the directory tree where gnuplot is 
> installed.  Is that correct?
> 
> So, the logic of the current configure is (if no TEXDIR is specified) to 
> choose the location where gnuplot is installed as the base directory for 
> where TeX files will be placed.  If there is no such prefix, then it 
> looks to the default kpsexpand location.  I presume that when the TeX 
> files are installed at the location of the gnuplot executable that the 
> TeX path is somehow added to the TeX system paths?

Oh, wait, I don't think I was understanding that correctly.  kpsexpand's 
'$TEXMFLOCAL' is a location for "non-system" TeX files (that will be 
recognized in TeX/LaTeX's path?).  So, that is typically where we want 
files to go, regardless of whether one indicates a gnuplot installation 
prefix or not.  Is that right?  We really want to use $prefix as a last 
resort then, correct?  In that case, I would go with what Achim is arguing.

+    TEXDIR=`$KPSEXPAND '$TEXMFLOCAL'`

[Do we know that kpsexpand is present once reaching this point?]

+    if test "x$TEXDIR" = "x" -o "$TEXDIR" = "\$TEXMFLOCAL"; then

[If kpsexpand  fails to find a TEXMFLOCAL, how do we know that 
TEXMFLOCAL is going to be present in our environment?  Just hoping by 
chance that it is?  If we didn't have kpsexpand, I could see attempting 
this last-ditch effort.]

+      if test "x$prefix" != "xNONE"; then
+        TEXDIR=${prefix}/share/texmf
+      else
          TEXDIR=${ac_default_prefix}/share/texmf
        fi

Dan

Re: [BUG] config.ac

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

On 10/16/2017 07:35 PM, Ethan A Merritt via gnuplot-beta wrote:
 > On Sunday, 15 October, 2017 17:40:03 Achim Gratz wrote:
 >
 >  >
 >
 >  > The configury supposedly tries to find TEXDIR via kpsexpand, but that
 >
 >  > code never gets run if $prefix is set.
 >
 > I really don't know if this is correct or not.
 >
 > In my experience there are so many places that the TeX stuff
 >
 > might go, your only hope is to manually specify where it is
 >
 > on the current system. It doesn't help any that according to the
 >
 > man page
 >
 > "the syntax for kpsexpand is incompatible with teTeX´s as of version 0.4"
 >
 > I read the existing ./configure logic to be that anything kpsexpand
 >
 > returns is where things would be by default, but if you are specifying
 >
 > a $prefix then you are overriding the default.
 >
 > Does it ever make sense to mix the two?
 >
 > What do other people think?

Well, this

AC_ARG_WITH(texdir,dnl
   [--with-texdir=DIR       where to install latex style files
                           (default by kpsexpand in subdir PACKAGE)],
   TEXDIR="$withval",
   TEXDIR="no")

means a person can't choose a directory name "no".

The goal is to find a location for gnuplot's few supplemental tex/latex 
files?  I presume we really don't want those to go to kpsexpand's local 
tex; that's the system's copy of tex source.  Most typically we want the 
extra TeX files to go somewhere in the directory tree where gnuplot is 
installed.  Is that correct?

So, the logic of the current configure is (if no TEXDIR is specified) to 
choose the location where gnuplot is installed as the base directory for 
where TeX files will be placed.  If there is no such prefix, then it 
looks to the default kpsexpand location.  I presume that when the TeX 
files are installed at the location of the gnuplot executable that the 
TeX path is somehow added to the TeX system paths?

 From Achim's patch of the first email:

+    TEXDIR=`$KPSEXPAND '$TEXMFLOCAL'`
+    if test "x$TEXDIR" = "x" -o "$TEXDIR" = "\$TEXMFLOCAL"; then

Aren't these two lines doing the same thing, in most cases?  Anyway, the 
patch seems to make kpsexpand's location for system TeX files the higher 
priority location.

Dan

Re: [BUG] config.ac

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

On Sunday, 15 October, 2017 17:40:03 Achim Gratz wrote:
> 
> The configury supposedly tries to find TEXDIR via kpsexpand, but that
> code never gets run if $prefix is set. 

I really don't know if this is correct or not.

In my experience there are so many places that the TeX stuff
might go, your only hope is to manually specify where it is
on the current system.  It doesn't help any that according to the
man page 
"the syntax for kpsexpand is incompatible with teTeX´s as of version 0.4"

I read the existing ./configure logic to be that anything kpsexpand
returns is where things would be by default, but if you are specifying
a $prefix then you are overriding the default.
Does it ever make sense to mix the two?  

What do other people think?

	Ethan


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

Re: Trial git repo is back up

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

On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> Trial git repo is back up, with the conversion bug I previously noted fixed.

Also, the branches are tags are not in the repository, at least not in 
the conventional way.  In neither git-gui, gitk nor gitg are there any 
branches listed other than "master" and "origin > master".  It could be 
there is some fragments of branches though.  In gitk I look at the 
visual, colored branches.  There are no bifurcations, but there are 
occasional colored lines appearing that then go away.  I suspect that 
those lines are supposed to be the branches.  I'm attaching a small 
portion of a screen shot illustrating how the line changes color rather 
than splitting out into branch.

My guess is that all the changeset info is there, but the labels that 
associate branch names with the SHAs are missing.

Dan

Re: Trial git repo is back up

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

On 10/16/2017 02:48 PM, Ethan A Merritt wrote:
> On Monday, 16 October, 2017 14:27:09 Daniel J Sebald wrote:
> 
>  > > your name shows in the associated ChangeLog entry but
>  > > has not been propagated to the patchset itself.
>  > > Same for the next 5 most ChangeLog entries with your name.
>  > > So it does seem that your name in particular is failing to trigger a
>  > > match event in the annotation process.
>  >
>  > There are probably more.  For example
>  >
>  > <sfeam!2015-09-11T19:48:01+00:00Z> 2015-09-11 Akira Kakuto
>  > <ka...@fu...>
>  >
>  > doesn't appear in the log either.
>  >
> 
> Yeah. I only looked for your name in particular because you
> raised the issue.
> 
> But you know what? I don't think it matters that much, at least
> for viewing through the SourceForge interface. However it is that
> you ended up with a commit identifier, once you click on it the
> first thing shown is the ChangeLog entry with authorship
> attribution.

I'm fine with having the detailed ChangeLog entry there as the first 
diff.  But the main reasons for having the proper authorship in the 
changeset is for searching purposes, i.e.

git log | less

In less one can then search for changesets authored by whomever to get 
an idea of when something was done, etc.  We have the info, something

I'm even wondering if we could even replace the "empty log message" with 
some estimate of a message extracted from the corresponding ChangeLog 
entry.  But, there are only 210 such messages:

git log | grep "empty log message" | wc
     210    1050    6300

Maybe those could be replaced by hand (if at all), everyone doing five 
or ten summary lines, but it isn't that important.

Dan

Re: Trial git repo is back up

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

On Monday, 16 October, 2017 14:27:09 Daniel J Sebald wrote:
> > your name shows in the associated ChangeLog entry but
> > has not been propagated to the patchset itself.
> > Same for the next 5 most ChangeLog entries with your name.
> > So it does seem that your name in particular is failing to trigger a
> > match event in the annotation process.
> 
> There are probably more.  For example
> 
> <sfeam!2015-09-11T19:48:01+00:00Z> 2015-09-11 Akira Kakuto 
> <ka...@fu...>
> 
> doesn't appear in the log either.
> 

Yeah. I only looked for your name in particular because you
raised the issue.

But you know what?  I don't think it matters that much, at least
for viewing through the SourceForge interface.  However it is that
you ended up with a commit identifier, once you click on it the
first thing shown is the ChangeLog entry with authorship
attribution.   

The mapping looks OK, it's only the label on the column marked
"author" that's misleading.   It should say "commited by".

	Ethan

Re: Trial git repo is back up

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

On 10/16/2017 02:07 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
>> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
>>> Trial git repo is back up, with the conversion bug I previously noted fixed.
>>
>> Generally, cloning seems to take longer than I had expected, given gnuplot
>> is a rather lean project.  It could be that SourceForge is just slow.  The
>> cloning seems "chunky" in the respect it loads a bunch of objects then sort
>> of slows down; speeds up again, slows down.
> 
> There's a pack command that helps with that - I forgot to use it.  I'll
> do it on the next version; I've added it to the conversion script.
> 
>> I don't see any authorship mapping; everything seems to appear as the
>> committer is the author.  For example, I've searched "git log" for "Sebald"
>> and only see my name appear in ancillary comments.  Never is my name/address
>> as gotten from the ChangeLog record in the authorship line.
> 
> That's...very odd.  I'll look into it.
> 
>> Some entries near the beginning of the project, as viewed through gitg:
>>
>> # Apr 15 1998, 20:16 Initial import of beta340.
>>
>> In gitg, no file diffs appear.
> 
> I see it too.  Some kind of fluky CVS artifact - probably of no
> significance. A pretty common sort of glitch in older repos.

Yes, it's as though two entries were made for the same CVS checkin.  The 
above and next entries have the same time stamp.


>> # Apr 15 1998, 20:16 *** empty log message ***
>>
>> In gitg, "Loading diff..." never resolves.
> 
> I see two commits that could match that.  They're both huge tree imports;
> I'm not surprised your differ does a semi-infinite grind.

Oh, sure enough.  gitk has no problems with the repo and actually 
resolves diffs quite quickly compared to gitg, which often displayes 
"Loading diff..." for five seconds or more.  gitg project has switched 
to gtk3 recently, and it just isn't the same as it once was.  The older 
version was the best at displaying diffs and having a handy window for 
commit messages that one could edit while staging/de-staging individual 
hunks.  The new version now opens a *modal* commit message window, which 
is too cumbersome for efficient work.  It is "git gui" and "gitk" for 
me, for now.

Dan

Re: Trial git repo is back up

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

On 10/16/2017 01:59 PM, Ethan A Merritt wrote:
> On Monday, 16 October, 2017 13:42:30 Daniel J Sebald wrote:
>  > On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
>  > > Trial git repo is back up, with the conversion bug I previously 
> noted fixed.
>  >
>  > Generally, cloning seems to take longer than I had expected, given
>  > gnuplot is a rather lean project. It could be that SourceForge is just
>  > slow. The cloning seems "chunky" in the respect it loads a bunch of
>  > objects then sort of slows down; speeds up again, slows down.
>  >
> 
>  > I don't see any authorship mapping; everything seems to appear as the
>  > committer is the author. For example, I've searched "git log" for
>  > "Sebald" and only see my name appear in ancillary comments. Never is my
>  > name/address as gotten from the ChangeLog record in the authorship line.
> 
> I see separate authorship attached to many of the commits,
> but yes I agree that in your case it doesn't seem to have been picked up.
> 
> E.g.
> 
> https://sourceforge.net/p/gnuplot/git-main/ci/ef67fa09f12cd5f4cc869f7231d9e1f9b14c43a0/
> 
> your name shows in the associated ChangeLog entry but
> has not been propagated to the patchset itself.
> Same for the next 5 most ChangeLog entries with your name.
> So it does seem that your name in particular is failing to trigger a
> match event in the annotation process.

There are probably more.  For example

<sfeam!2015-09-11T19:48:01+00:00Z> 2015-09-11 Akira Kakuto 
<ka...@fu...>

doesn't appear in the log either.

Dan

Re: Trial git repo is back up

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

Ethan A Merritt <sf...@us...>:
> I see separate authorship attached to many of the commits,
> but yes I agree that in your case it doesn't seem to have been picked up.
> E.g.
>   https://sourceforge.net/p/gnuplot/git-main/ci/ef67fa09f12cd5f4cc869f7231d9e1f9b14c43a0/
> 
> your name shows in the associated ChangeLog entry but
> has not been propagated to the patchset itself.
> Same for the next 5 most ChangeLog entries with your name.
> 
> So it does seem that your name in particular is failing to trigger a
> match event in the annotation process. 

I'll run some traces.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

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

Daniel J Sebald <dan...@ie...>:
> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> >Trial git repo is back up, with the conversion bug I previously noted fixed.
> 
> Generally, cloning seems to take longer than I had expected, given gnuplot
> is a rather lean project.  It could be that SourceForge is just slow.  The
> cloning seems "chunky" in the respect it loads a bunch of objects then sort
> of slows down; speeds up again, slows down.

There's a pack command that helps with that - I forgot to use it.  I'll
do it on the next version; I've added it to the conversion script.

> I don't see any authorship mapping; everything seems to appear as the
> committer is the author.  For example, I've searched "git log" for "Sebald"
> and only see my name appear in ancillary comments.  Never is my name/address
> as gotten from the ChangeLog record in the authorship line.

That's...very odd.  I'll look into it.

> Some entries near the beginning of the project, as viewed through gitg:
> 
> # Apr 15 1998, 20:16 Initial import of beta340.
> 
> In gitg, no file diffs appear.

I see it too.  Some kind of fluky CVS artifact - probably of no
significance. A pretty common sort of glitch in older repos.

> # Apr 15 1998, 20:16 *** empty log message ***
> 
> In gitg, "Loading diff..." never resolves.

I see two commits that could match that.  They're both huge tree imports;
I'm not surprised your differ does a semi-infinite grind.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Trial git repo is back up

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

On Monday, 16 October, 2017 13:42:30 Daniel J Sebald wrote:
> On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> > Trial git repo is back up, with the conversion bug I previously noted fixed.
> 
> Generally, cloning seems to take longer than I had expected, given 
> gnuplot is a rather lean project.  It could be that SourceForge is just 
> slow.  The cloning seems "chunky" in the respect it loads a bunch of 
> objects then sort of slows down; speeds up again, slows down.
> 
> I don't see any authorship mapping; everything seems to appear as the 
> committer is the author.  For example, I've searched "git log" for 
> "Sebald" and only see my name appear in ancillary comments.  Never is my 
> name/address as gotten from the ChangeLog record in the authorship line.

I see separate authorship attached to many of the commits,
but yes I agree that in your case it doesn't seem to have been picked up.
E.g.
  https://sourceforge.net/p/gnuplot/git-main/ci/ef67fa09f12cd5f4cc869f7231d9e1f9b14c43a0/

your name shows in the associated ChangeLog entry but
has not been propagated to the patchset itself.
Same for the next 5 most ChangeLog entries with your name.

So it does seem that your name in particular is failing to trigger a
match event in the annotation process. 

	Ethan

Re: Trial git repo is back up

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

On 10/16/2017 01:17 PM, Eric S. Raymond wrote:
> Trial git repo is back up, with the conversion bug I previously noted fixed.

Generally, cloning seems to take longer than I had expected, given 
gnuplot is a rather lean project.  It could be that SourceForge is just 
slow.  The cloning seems "chunky" in the respect it loads a bunch of 
objects then sort of slows down; speeds up again, slows down.

I don't see any authorship mapping; everything seems to appear as the 
committer is the author.  For example, I've searched "git log" for 
"Sebald" and only see my name appear in ancillary comments.  Never is my 
name/address as gotten from the ChangeLog record in the authorship line.

Some entries near the beginning of the project, as viewed through gitg:

# Apr 15 1998, 20:16 Initial import of beta340.

In gitg, no file diffs appear.

# Apr 15 1998, 20:16 *** empty log message ***

In gitg, "Loading diff..." never resolves.

Dan