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

AW: Windows binary package for testing, "help" command

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

> -----Ursprüngliche Nachricht-----
> Von: Allin Cottrell [mailto:cot...@wf...]
> Gesendet: Freitag, 10. November 2017 00:55
> An: Tait <gnu...@t4...>
> Cc: gnuplot beta list <gnu...@li...>
> Betreff: Re: Windows binary package for testing, "help" command
> 
> On Thu, 9 Nov 2017, Tait wrote:
> 
> > Maybe this is a known issue, but the help commands don't seem to work.
> > Normally "help set xtics" would pull up the help on xtics. It just
> > seems to pull up a blank page now.
> 
> Oof, this is some Windows nonsense. Apparently they've decided that their
> "compiled HTML" help files are a serious security hole, so showing such
help is
> disabled by default (hence the blank page).
> 
> If you right-click on the wgnuplot.chm file and select the "Properties"
option
> there's an "unblock" check-box: check that and the Help will appear!
(Don't ask
> me how any user is supposed to figure that out without savvy use of
google.)
> 
> Allin Cottrell
> 

Thanks for testing. That is a somewhat weird problem, which I cannot
reproduce on two different machines (both different levels of Win10) I
tried. Also one of reasons for the installer was to avoid that Windows
"security" flag for CHM files. So changing that flag shouldn't be necessary.
If it is indeed needed in this case, I would not know why and how to avoid
that.
I will try to upload the zip file version tonight.

  Bastian

Re: Windows binary package for testing, "help" command

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

On Thu, 9 Nov 2017, Tait wrote:

> Maybe this is a known issue, but the help commands don't
> seem to work. Normally "help set xtics" would pull up the
> help on xtics. It just seems to pull up a blank page now.

Oof, this is some Windows nonsense. Apparently they've decided that 
their "compiled HTML" help files are a serious security hole, so 
showing such help is disabled by default (hence the blank page).

If you right-click on the wgnuplot.chm file and select the 
"Properties" option there's an "unblock" check-box: check that and 
the Help will appear! (Don't ask me how any user is supposed to 
figure that out without savvy use of google.)

Allin Cottrell

Re: Windows binary package for testing, "help" command

[Tait <gnu...@t4...>]

Do you think you could upload it as a zip?

Maybe this is a known issue, but the help commands don't
seem to work. Normally "help set xtics" would pull up the
help on xtics. It just seems to pull up a blank page now.


"\"Bastian Märkisch\"" <bma...@we...> said (on 2017/11/08):
> Dear gnuplotters,
> 
> A testing release of the Windows 64bit binary distribution of the upcoming release 5.2.2 is now available at 
> https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
> 
> This is the first release package build on a new machine, so please give it some testing.  Feedback much appreciated.
> 
> 
>   Bastian
> 
> ------------------------------------------------------------------------------
> 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: 5.2-stable regression for log axes still not fixed completely

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

Achim Gratz writes:
>>> I have to get to the bottom of it later.  The only other difference to
>>> 5.0.7 I've noticed is that the key box in some cases overlaps with some
>>> labeling outside the main plot area.  Again, I don't know exactly when
>>> and why that happens, but I will eventually try to find out.
>>
>> Are these 3D plots?
>
> No, distribution plots, sometimes with reversed and/or logarithmic axes.
>
>> Have a look at the documentation for "set key fixed".
>
> I'll have to trace the same steps as outlined above, then I can be back
> with more questions (unless it's already obvious by then).

This happens because the timestamp position changes in 5.2.x from
inbetween the axis labeling and a key box in the bottom margin to the
actual bottom of the margin.  I've confirmed that the position was
inbetween the two parts from at least 4.0 onwards to 5.0.7.  There is
some space inbetween the axis labeling and the key box title that looks
like a leftover from the previous behaviour.

In addition poking around the key box settings has revealed a few other
things that seem buggy and/or underdocumented, I'll make separate posts
about them later.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: 5.2-stable regression for log axes still not fixed completely

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

Ethan A Merritt via gnuplot-beta writes:
> Here is a patch that I think will do the job.
> Since our SourceForge repository is currently in an undefined state
> (cvs is frozen,  conversion to git has been done but may have to
> be redone if problems turn up), it may be a while before this change
> is visible in source downloaded from sf.net.

Thanks, I hope to have some time on the weekend to look at it.


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: 5.2-stable regression for log axes still not fixed completely

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

On Wednesday, November 8, 2017 10:41:11 AM PST Achim Gratz wrote:
> Ethan A Merritt via gnuplot-beta writes:
> > 
> > I think the actual error is that
> > set xrange [*:*] turns on autoscaling but does not erase the previous
> > min/max.  Since they were both negative numbers, "set log" complains.
> 
> Yes, that sounds like a good explanation.
> 
> > The code has a special check that handles the default axis range
> > setting [-10:10].  Maybe that check should be extended to cover all
> > cases of negative range limits?   Not sure.  But really I think the
> > problem is that "set auto" and "set range [*:*] don't actually clear
> > the previous limits.  Unfortunately I suspect that the "refresh"
> > command relies on that, so the best fix is not immediately clear.
> 
> I don't think I can currently help with that.  As a workaround it seems
> that
> 
> unset xrange; set autoscale x
> 
> might do in our scripts, so I'm inclined to go with that for now.

Here is a patch that I think will do the job.
Since our SourceForge repository is currently in an undefined state
(cvs is frozen,  conversion to git has been done but may have to
be redone if problems turn up), it may be a while before this change
is visible in source downloaded from sf.net.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff --git a/src/set.c b/src/set.c
index 2286ab362..c83d5905b 100644
--- a/src/set.c
+++ b/src/set.c
@@ -2790,10 +2790,17 @@ set_logscale()
 		dummy = "x"; break;
 	    }
 
-	    /* Avoid a warning message trigger by default axis range [-10:10] */
+	    /* Avoid a warning message triggered by default axis range [-10:10] */
 	    if (axis_array[axis].set_min <= 0 && axis_array[axis].set_max > 0)
 		axis_array[axis].set_min = 0.1;
 
+	    /* Also forgive negative axis limits if we are currently autoscaling */
+	    if ((axis_array[axis].set_autoscale != AUTOSCALE_NONE)
+	    &&  (axis_array[axis].set_min <= 0 || axis_array[axis].set_max <= 0)) {
+		axis_array[axis].set_min = 0.1;
+		axis_array[axis].set_max = 10.;
+	    }
+
 	    if (newbase == 10.) {
 		sprintf(command, "set nonlinear %s via log10(%s) inv 10**%s",
 			axis_name(axis), dummy, dummy);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Windows binary package for testing

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

Dear gnuplotters,

A testing release of the Windows 64bit binary distribution of the upcoming release 5.2.2 is now available at 
https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

This is the first release package build on a new machine, so please give it some testing.  Feedback much appreciated.


  Bastian

Re: 5.2-stable regression for log axes still not fixed completely

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

Ethan A Merritt via gnuplot-beta writes:
> That first line is not a legal command in version 5, or at any rate
> it is meaningless.

Well, that code is some years old and I haven't yet the need or
otherwise gotten around to clue it in to the fact we're no longer using
gnuplot-4.x on any installation.

> If that command is actually doing something, that's a bug all by itself.

I think not, but I've just stopped fiddling with it when I had the
reproducer down to three lines.  :-)

> On the other hand, that spurious warning is generated even without
> "reverse/noreverse" involved.  I think the actual error is that 
> set xrange [*:*] turns on autoscaling but does not erase the previous
> min/max.  Since they were both negative numbers, "set log" complains.

Yes, that sounds like a good explanation.

> The code has a special check that handles the default axis range
> setting [-10:10].  Maybe that check should be extended to cover all
> cases of negative range limits?   Not sure.  But really I think the
> problem is that "set auto" and "set range [*:*] don't actually clear
> the previous limits.  Unfortunately I suspect that the "refresh" command
> relies on that, so the best fix is not immediately clear.

I don't think I can currently help with that.  As a workaround it seems
that

unset xrange; set autoscale x

might do in our scripts, so I'm inclined to go with that for now.


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

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

Re: Short vectors are not plotted

[Ethan A M. <EAM...@gm...>]

On Saturday, 04 November 2017 21:43:09 Dima Kogan wrote:
> Ethan Merritt <eam...@gm...> writes:
> 
> > Here's a start. I'll probably commit these changes to CVS when the
> > current turmoil settles. After applying this patch there is only one
> > call site for term->arrow() in the code base, in draw_clip_arrow().
> > Could be I'm missing some complication, but it looks to me that any
> > changes needed for your heads-only implementation can be limited to
> > this one routine.
> 
> Here's a new patch series. These assume your use_draw_clip_arrow.patch
> is applied. Again, please apply with 'git am', or let me know what is
> unsatisfactory, so that I can address it.
> 
> The updates are similar to the last patch series in that some functions
> took integers previously, but now they take floating-point values. In a
> number of cases, this patch series makes available both flavors: integer
> and floating-point. Is this what you had in mind?
> 
> And two more related points:
> 
> 1. This patch uncovered an inconsistency in much of our code: when
> converting a floating-point terminal coordinate to an integer one,
> sometimes we round (either with (int)(x+0.5) or by calling
> axis_map_toint()) and sometimes we floor ( (int)(x) ). Looks like it's
> more or less random which one we pick. We should always round, I
> suspect. This patch series doesn't attempt to resolve this, but a future
> set of patches should.

Your patch set definitely runs aground on that point.
I tried to compare results before/after the patches but there are so many
single-digit coordinate changes throughout that it's impossible.
Yes it may be worth it to review the double->termcoord conversion 
everywhere in the program, but let's disentangle that from changes to
handling short vectors.

Here's how I tested:
    ./gnuplot-before -e 'set term post color' all.dem < /bin/yes > all_before.ps
    ./gnuplot-after -e 'set term post color' all.dem < /bin/yes > all_after.ps

    diff -ur all_before.ps all_after.ps > all.diff
    diffstat all.diff

    diffstat all.diff
     all_after.ps |234431 +++++++++++++++++++++++++++++++-----------------------------
     1 file changed, 121820 insertions(+), 112611 deletions(-)

Ugh. Too many differences to evaluate in detail.  So I tried to back out all
the changes to existing coordinate routines and instead provide totally
separate routines to be called only along the new clip_arrow code path.
This reduced the background single-pixel changes a bit, but I must have
missed some places because are still a very large number of single-pixel
differences.

     diff -ur all_before.ps all_version2.ps > all_v2.diff
     diffstat all_v2.diff
     all_version2.ps |59388 +++++++++++++++++++++++++++++++++--------------------------
     1 file changed, 34040 insertions(+), 25348 deletions(-)

That let me look for problem areas, and I found some.
There are many cases where the coordinates passed to the terminal
driver have overflowed.  For example the "Let's smile with parametric filled curves" plot
in the filledcurves demo ends like this:

    gsave [] 0 setdash
    3980 1811 M
    0 -221 V
    -218 37 V
    -653259491 771754262 M
    3980 1590 L
    stroke
    grestore

The coordinates in that last move (M) command are nonsense.
This is also evident in the *.ps output from the Gantt chart demo.
Note that this demo seems to display correctly on the Qt termimal.
That might mean there's a postscript-specific bug or it might
be different terminal scale factors, or different terminal clipping
policies, or something else.

However, my quick hack to separate the generic and arrow-specific
effects of your patches may have introduced its own bugs.  
So I think I will hand it back to you to debug my debugging :-)

	Ethan


> 2. I discovered the issue with the vector fields manifests in two
> different ways. For very short vectors, they simply disappear, as we
> discussed. For vectors that are short, but not 0-pixels-short, the
> arrowheads are still plotted, but the angular resolution becomes very
> poor. The patches here resolve both of these.
> 
> 
> Thanks.
> 
> 

Re: 5.2-stable regression for log axes still not fixed completely

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

On Tuesday, November 7, 2017 12:48:39 PM PST Achim Gratz wrote:
> Achim Gratz writes:
> > Right now it's somewhere in a 1800 pages PDF report, I'll have to
> > isolate the offending plots and get at the gnuplot code for that.  For
> > now I only know that those plots I've looked at didn't show any
> > unexpected defects, so the warning seems to be spurious as far as the
> > result goes.
> 
> This one _should_ be simple to fix: The warnings get issued when a
> previous plot used a reverse linear axis that is constrained to negative
> values and the next plot uses a logarithmic axis.  To reproduce:
> 
> --8<---------------cut here---------------start------------->8---
> set xrange [-2*pi:-pi] reverse
> set xrange [*:*] noreverse
> set log x
> --8<---------------cut here---------------end--------------->8---

Hold on a minute.
That first line is not a legal command in version 5, or at any rate
it is meaningless.  The "reverse" keyword only applies to autoscaling.
If that command is actually doing something, that's a bug all by itself.

... [thinking] ...

On the other hand, that spurious warning is generated even without
"reverse/noreverse" involved.  I think the actual error is that 
set xrange [*:*] turns on autoscaling but does not erase the previous
min/max.  Since they were both negative numbers, "set log" complains.

The code has a special check that handles the default axis range
setting [-10:10].  Maybe that check should be extended to cover all
cases of negative range limits?   Not sure.  But really I think the
problem is that "set auto" and "set range [*:*] don't actually clear
the previous limits.  Unfortunately I suspect that the "refresh" command
relies on that, so the best fix is not immediately clear.

	Ethan



> 
> The error does not happen if the max of the first xrange is positive.
> It seems that switching on autoscale does not correctly invalidate some
> of the internal variables set up by the first xrange.
> 
> The explanation for why this error is not having consequences on my
> plots is that the correct range for the (now logarithmic) axis will
> always be set later on.
> 
> 
> Regards
> Achim.

Re: 5.2-stable regression for log axes still not fixed completely

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

Achim Gratz writes:
> Right now it's somewhere in a 1800 pages PDF report, I'll have to
> isolate the offending plots and get at the gnuplot code for that.  For
> now I only know that those plots I've looked at didn't show any
> unexpected defects, so the warning seems to be spurious as far as the
> result goes.

This one _should_ be simple to fix: The warnings get issued when a
previous plot used a reverse linear axis that is constrained to negative
values and the next plot uses a logarithmic axis.  To reproduce:

--8<---------------cut here---------------start------------->8---
set xrange [-2*pi:-pi] reverse
set xrange [*:*] noreverse
set log x
--8<---------------cut here---------------end--------------->8---

The error does not happen if the max of the first xrange is positive.
It seems that switching on autoscale does not correctly invalidate some
of the internal variables set up by the first xrange.

The explanation for why this error is not having consequences on my
plots is that the correct range for the (now logarithmic) axis will
always be set later on.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: 5.2-stable regression for log axes still not fixed completely

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

Ethan A Merritt via gnuplot-beta writes:
>> I've released 5.2.1 for Cygwin and have tested it today.  There are some
>> seemingly harmless (if annoying) warnings about the linked axes not
>> matching up as expected and the symptom in general seems to be that the
>> sign of the two values that are supposedly identical are reversed. 
>
> That's unexpected, since the test is now being made against the 
> absolute value of the difference, so sign should not matter.
> If you can provide a script that shows the problem, I'd like to fix it
> before packaging up 5.2.2

Right now it's somewhere in a 1800 pages PDF report, I'll have to
isolate the offending plots and get at the gnuplot code for that.  For
now I only know that those plots I've looked at didn't show any
unexpected defects, so the warning seems to be spurious as far as the
result goes.

>> I have to get to the bottom of it later.  The only other difference to
>> 5.0.7 I've noticed is that the key box in some cases overlaps with some
>> labeling outside the main plot area.  Again, I don't know exactly when
>> and why that happens, but I will eventually try to find out.
>
> Are these 3D plots?

No, distribution plots, sometimes with reversed and/or logarithmic axes.

> Have a look at the documentation for "set key fixed".

I'll have to trace the same steps as outlined above, then I can be back
with more questions (unless it's already obvious by then).


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: 5.2-stable regression for log axes still not fixed completely

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

On Monday, November 6, 2017 11:52:48 AM PST Achim Gratz wrote:
> Achim Gratz writes:
> > I can't test it on production code for about the next two weeks (I
> > might
> > build it before), but having the patch works just fine for me, no need
> > for a tarball.
> 
> I've released 5.2.1 for Cygwin and have tested it today.  There are some
> seemingly harmless (if annoying) warnings about the linked axes not
> matching up as expected and the symptom in general seems to be that the
> sign of the two values that are supposedly identical are reversed. 

That's unexpected, since the test is now being made against the 
absolute value of the difference, so sign should not matter.
If you can provide a script that shows the problem, I'd like to fix it
before packaging up 5.2.2

> I have to get to the bottom of it later.  The only other difference to
> 5.0.7 I've noticed is that the key box in some cases overlaps with some
> labeling outside the main plot area.  Again, I don't know exactly when
> and why that happens, but I will eventually try to find out.

Are these 3D plots?
Have a look at the documentation for "set key fixed".

	Ethan

 
> 
> Regards,
> Achim.

Re: 5.2-stable regression for log axes still not fixed completely

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

Achim Gratz writes:
> I can't test it on production code for about the next two weeks (I might
> build it before), but having the patch works just fine for me, no need
> for a tarball.

I've released 5.2.1 for Cygwin and have tested it today.  There are some
seemingly harmless (if annoying) warnings about the linked axes not
matching up as expected and the symptom in general seems to be that the
sign of the two values that are supposedly identical are reversed.  I
have to get to the bottom of it later.  The only other difference to
5.0.7 I've noticed is that the key box in some cases overlaps with some
labeling outside the main plot area.  Again, I don't know exactly when
and why that happens, but I will eventually try to find out.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

belated conversion help

[Tait <gnu...@t4...>]

It turns out SourceForge dropped me from the mailing list not
long before Ethan's plea for conversion assistance. I didn't
notice until I recently heard elsewhere about SourceForge ending
CVS commit support and thought of gnuplot. I would have gladly
helped, but it seems I'm too late now; sorry. However, I'm happy
to assist going forward with git questions or any remaining
conversion work.

Re: State of the CVS conversion

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

sfeam <sf...@us...>:
> On Saturday, 04 November 2017 17:17:39 Eric S. Raymond wrote:
> > sfeam <sf...@us...>:
> > > On Saturday, 04 November 2017 10:30:34 Eric S. Raymond wrote:
> > > > "Bastian Märkisch" <bma...@we...>:
> > > > > There are a few cases which we probably would like to fix because the
> > > > > ChangeLog was modified in an "atypical" way.  Should this be done now
> > > > > or can this be corrected after the conversion (sorry, not really 
> > > > > familiar with git yet)?
> > > > 
> > > > It can be done either way.  Safest to do it before the cutover, so the
> > > > changest get recorded in reconvert and not lost if we do some other
> > > > modification.
> > > 
> > > Could you provide a recipe for making such a correction?
> > 
> > If you have a speification for a changeset, like say
> > 
> >    <es...@th...!2017-11-04T16:44:25>
> > 
> > you can say
> > 
> > reposurgeon
> > reposrgeon> read gnuplot
> > reposurgeon> <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly <fr...@fo...>"
> > reposurgeon rebuild
> > 
> > Of course, you can do more tham one of these per session.
> 
> You lost me. 
> How would I have a specification for a changeset in that form?
> If this is editing the cvs copy, how is it better than using sed or vi to
> do the same thing?

This is not editing the CVS copy.  It's editing the git conversion


>  
> > However, after doing this you need to run forcepush to put the new
> > repo in place.  Patches done between your last pull and the foecepush
> > will be lost.
> 
> Push it where?  Back to SourceForge?

Exactly.

> I think I'm not going to touch any of this.  If Dan or Bastian or you send me
> an updated reconvert script I'd be happy to run it, but I worry I'll do more
> harm than good if I start editing with unfamiliar tools.

We know these things so you don't have to. :-)

> > There is something strange going on, though.  I can see all branches in
> > the GUI, but if I
> > 
> >     git clone ssh://esr@git.code.sf.net/p/gnuplot/git-main
> > 
> > I only get the master branch!  How did you do your clone?
> 
> Since I don't have any prior expectations, I can't say whether I got everything
> at once or not.  How would I tell?  
> 
> Here's what I did:
> 
> $ git clone ssh://sfeam@git.code.sf.net/p/gnuplot/git-main gnuplot-git-main
> 
> $ cd gnuplot-git-main
>    # Now the current directory tree holds what looks like the current tip files
>    # However gitk run in this same directory shows all the branches,
>    # so I figured the rest are packed in ./.git somewhere to be reconstructed
>    # on demand.  No?
>    # The gitk GUI run from here pushes to origin
> 
> $ git checkout -track origin/branch-5-2-stable
>    # Magically the contents of the current directory tree switch to the branch tip
>    # I was surprised, but since I didn't know otherwise I assumed this was OK
>    # Did it unpack them from the local copy or pull for sf.net?  I don't know.
>    # The gitk GUI run from here now pushes to origin/branch-5-2-stable
> 
> That's as far as I got, but it was sufficient to show that I could use gitk to
> modify either the main branch or the 5-2-stable branch.

I forgot that you have to use --mirror to pull all branches.  It's OK.
-- 
		<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: Short vectors are not plotted

[Dima K. <gn...@di...>]

Ethan Merritt <eam...@gm...> writes:

> Here's a start. I'll probably commit these changes to CVS when the
> current turmoil settles. After applying this patch there is only one
> call site for term->arrow() in the code base, in draw_clip_arrow().
> Could be I'm missing some complication, but it looks to me that any
> changes needed for your heads-only implementation can be limited to
> this one routine.

Here's a new patch series. These assume your use_draw_clip_arrow.patch
is applied. Again, please apply with 'git am', or let me know what is
unsatisfactory, so that I can address it.

The updates are similar to the last patch series in that some functions
took integers previously, but now they take floating-point values. In a
number of cases, this patch series makes available both flavors: integer
and floating-point. Is this what you had in mind?

And two more related points:

1. This patch uncovered an inconsistency in much of our code: when
converting a floating-point terminal coordinate to an integer one,
sometimes we round (either with (int)(x+0.5) or by calling
axis_map_toint()) and sometimes we floor ( (int)(x) ). Looks like it's
more or less random which one we pick. We should always round, I
suspect. This patch series doesn't attempt to resolve this, but a future
set of patches should.

2. I discovered the issue with the vector fields manifests in two
different ways. For very short vectors, they simply disappear, as we
discussed. For vectors that are short, but not 0-pixels-short, the
arrowheads are still plotted, but the angular resolution becomes very
poor. The patches here resolve both of these.


Thanks.

Re: State of the CVS conversion

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

On Saturday, 04 November 2017 17:17:39 Eric S. Raymond wrote:
> sfeam <sf...@us...>:
> > On Saturday, 04 November 2017 10:30:34 Eric S. Raymond wrote:
> > > "Bastian Märkisch" <bma...@we...>:
> > > > There are a few cases which we probably would like to fix because the
> > > > ChangeLog was modified in an "atypical" way.  Should this be done now
> > > > or can this be corrected after the conversion (sorry, not really 
> > > > familiar with git yet)?
> > > 
> > > It can be done either way.  Safest to do it before the cutover, so the
> > > changest get recorded in reconvert and not lost if we do some other
> > > modification.
> > 
> > Could you provide a recipe for making such a correction?
> 
> If you have a speification for a changeset, like say
> 
>    <es...@th...!2017-11-04T16:44:25>
> 
> you can say
> 
> reposurgeon
> reposrgeon> read gnuplot
> reposurgeon> <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly <fr...@fo...>"
> reposurgeon rebuild
> 
> Of course, you can do more tham one of these per session.

You lost me. 
How would I have a specification for a changeset in that form?
If this is editing the cvs copy, how is it better than using sed or vi to
do the same thing?
 
> However, after doing this you need to run forcepush to put the new
> repo in place.  Patches done between your last pull and the foecepush
> will be lost.

Push it where?  Back to SourceForge?

I think I'm not going to touch any of this.  If Dan or Bastian or you send me
an updated reconvert script I'd be happy to run it, but I worry I'll do more
harm than good if I start editing with unfamiliar tools.

> > I've pushed some trivial patches against branch-5-2-stable so
> > the git content has already  diverged in minor ways from the cvs version.
> > No real harm will be done if the conversion is re-executed with fewer
> > rough corners.  Just let me know if that's the plan.
> 
> The plan is up to you.  But it looks like you did 'reconvert' rather than
> 'reconvert finish', so you probably want to do one more reconvert run.

Oops. Yeah, I missed that.
Sigh.
That means I have to blow away the sf.net repository, reinitialize,
and push from the local copy again.  Right?

 
> You don't need to lose your work. From your command line
> 
> git checkout branch-5-2-stable
> git format-patch HEAD~3..HEAD
> 
> This will make some patch files with the prefix 000* that you can reapply
> to a git repo with the 'git am' command.

Thanks, that's useful.
In this case I have all the patches anyhow but I can see that's useful
for catching changes by other people.

> > Oh - one other question.
> > Can other people actually see the files inside branch-X-X-stable
> > via the SourceForge web view interface?   I find that in order to
> > make this work I have to hit the "Repository Refresh" button.
> > Thing is, that button is in a tab marked "admin-git-main" that 
> > I don't think normal users can see.  
> 
> Look off to the left of the main window in the SourceForge web GUI.  You'll
> see buttons you can use to select a branch for viewing.  They work for me.

Good to know.
They work for me also, but they don't seem to show recent changes until
I hit the "Repository Refresh" button.
 
> There is something strange going on, though.  I can see all branches in
> the GUI, but if I
> 
>     git clone ssh://esr@git.code.sf.net/p/gnuplot/git-main
> 
> I only get the master branch!  How did you do your clone?

Since I don't have any prior expectations, I can't say whether I got everything
at once or not.  How would I tell?  

Here's what I did:

$ git clone ssh://sfeam@git.code.sf.net/p/gnuplot/git-main gnuplot-git-main

$ cd gnuplot-git-main
   # Now the current directory tree holds what looks like the current tip files
   # However gitk run in this same directory shows all the branches,
   # so I figured the rest are packed in ./.git somewhere to be reconstructed
   # on demand.  No?
   # The gitk GUI run from here pushes to origin

$ git checkout -track origin/branch-5-2-stable
   # Magically the contents of the current directory tree switch to the branch tip
   # I was surprised, but since I didn't know otherwise I assumed this was OK
   # Did it unpack them from the local copy or pull for sf.net?  I don't know.
   # The gitk GUI run from here now pushes to origin/branch-5-2-stable

That's as far as I got, but it was sufficient to show that I could use gitk to
modify either the main branch or the 5-2-stable branch.

	Ethan

Re: State of the CVS conversion

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

sfeam <sf...@us...>:
> On Saturday, 04 November 2017 10:30:34 Eric S. Raymond wrote:
> > "Bastian Märkisch" <bma...@we...>:
> > > There are a few cases which we probably would like to fix because the
> > > ChangeLog was modified in an "atypical" way.  Should this be done now
> > > or can this be corrected after the conversion (sorry, not really 
> > > familiar with git yet)?
> > 
> > It can be done either way.  Safest to do it before the cutover, so the
> > changest get recorded in reconvert and not lost if we do some other
> > modification.
> 
> Could you provide a recipe for making such a correction?

If you have a speification for a changeset, like say

   <es...@th...!2017-11-04T16:44:25>

you can say

reposurgeon
reposrgeon> read gnuplot
reposurgeon> <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly <fr...@fo...>"
reposurgeon rebuild

Of course, you can do more tham one of these per session.

However, after doing this you need to run forcepush to put the new
repo in place.  Patches done between your last pull and the foecepush
will be lost.

> After I tried to make a pass over the ChangeLogs fixing typos etc
> on 13 October, I thought you and Dan told me that it was wasted 
> effort because the conversion script looks at the text originally
> committed, not at the corrected text.
> So how does one fix such a problem?

See above.

For each changeset, reposurgeon looks at the associated ChangeLog (if any)
as it existed *at the time of the changeset*.  Modifying the head version
of ChangeLog to fix the typo is a good idea in itself, but does not
retrospetively fix the attributions of old changesets.

> Meanwhile, I've begun trying to actually use the converted
> repository on sf.net.    I'm having mixed success, but so far I am
> attributing that to my general cluelessness about the best 
> sequence of commands or procedures to 
>   - check out 
>   - modify files
>   - commit 
>   - push
> against a previously-existing branch.   I can make this work with the
> assistance of gitk but so far have failed to make it work from the
> command line.

Perhaps this will help?

http://rogerdudler.github.io/git-guide/

> I've pushed some trivial patches against branch-5-2-stable so
> the git content has already  diverged in minor ways from the cvs version.
> No real harm will be done if the conversion is re-executed with fewer
> rough corners.  Just let me know if that's the plan.

The plan is up to you.  But it looks like you did 'reconvert' rather than
'reconvert finish', so you probably want to do one more reconvert run.

You don't need to lose your work. From your command line

git checkout branch-5-2-stable
git format-patch HEAD~3..HEAD

This will make some patch files with the prefix 000* that you can reapply
to a git repo with the 'git am' command.

> Oh - one other question.
> Can other people actually see the files inside branch-X-X-stable
> via the SourceForge web view interface?   I find that in order to
> make this work I have to hit the "Repository Refresh" button.
> Thing is, that button is in a tab marked "admin-git-main" that 
> I don't think normal users can see.  

Look off to the left of the main window in the SourceForge web GUI.  You'll
see buttons you can use to select a branch for viewing.  They work for me.

There is something strange going on, though.  I can see all branches in
the GUI, but if I

    git clone ssh://esr@git.code.sf.net/p/gnuplot/git-main

I only get the master branch!  How did you do your clone?
-- 
		<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: State of the CVS conversion

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

On Saturday, 04 November 2017 10:30:34 Eric S. Raymond wrote:
> "Bastian Märkisch" <bma...@we...>:
> > There are a few cases which we probably would like to fix because the
> > ChangeLog was modified in an "atypical" way.  Should this be done now
> > or can this be corrected after the conversion (sorry, not really 
> > familiar with git yet)?
> 
> It can be done either way.  Safest to do it before the cutover, so the
> changest get recorded in reconvert and not lost if we do some other
> modification.

Could you provide a recipe for making such a correction?

After I tried to make a pass over the ChangeLogs fixing typos etc
on 13 October, I thought you and Dan told me that it was wasted 
effort because the conversion script looks at the text originally
committed, not at the corrected text.
So how does one fix such a problem?

Meanwhile, I've begun trying to actually use the converted
repository on sf.net.    I'm having mixed success, but so far I am
attributing that to my general cluelessness about the best 
sequence of commands or procedures to 
  - check out 
  - modify files
  - commit 
  - push
against a previously-existing branch.   I can make this work with the
assistance of gitk but so far have failed to make it work from the
command line.

I've pushed some trivial patches against branch-5-2-stable so
the git content has already  diverged in minor ways from the cvs version.
No real harm will be done if the conversion is re-executed with fewer
rough corners.  Just let me know if that's the plan.

Oh - one other question.
Can other people actually see the files inside branch-X-X-stable
via the SourceForge web view interface?   I find that in order to
make this work I have to hit the "Repository Refresh" button.
Thing is, that button is in a tab marked "admin-git-main" that 
I don't think normal users can see.  

	Ethan

Re: State of the CVS conversion

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

"Bastian Märkisch" <bma...@we...>:
> There are a few cases which we probably would like to fix because the
> ChangeLog was modified in an "atypical" way.  Should this be done now
> or can this be corrected after the conversion (sorry, not really 
> familiar with git yet)?

It can be done either way.  Safest to do it before the cutover, so the
changest get recorded in reconvert and not lost if we do some other
modification.
-- 
		<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.

Aw: State of the CVS conversion

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

> Gesendet: Mittwoch, 01. November 2017 um 18:20 Uhr
> Von: "Eric S. Raymond" <es...@th...>
> An: gnuplot-beta <gnu...@li...>
> Betreff: State of the CVS conversion
>
> I've uploaded a fresh version of rhe conversion machinery where you
> can fetch it at
> 
> wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz
> 
> Problems solved in this release:
> 
> * Changelog scanning catches the cases Bastian was worried about.
>   It's probably done.

Great. Thanks.  Looking good as far as I can tell from a quick look
at the conversion.

There are a few cases which we probably would like to fix because the
ChangeLog was modified in an "atypical" way.  Should this be done now
or can this be corrected after the conversion (sorry, not really 
familiar with git yet)?

  Bastian

Re: Documentation for special-filenames

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

On Thursday, November 2, 2017 11:26:33 AM PDT Lutz Maibaum wrote:
> I just noticed that the help text for “special-filenames” does not
> describe the use of ‘-‘, ‘’, pipes, or file descriptors. Instead those
> are all described in the “++” subtopic of “special-filenames”, which
> seems surprising to me. I am using 5.2.1 installed from MacPorts. Is
> that a bug in the documentation?

Yeah, I noticed that same thing last week while
trying to find a help section that would answer a request for
support.  I added a new section in the docs for 5.2.2 and 5.3.

	Ethan

Re: Proposal of reposurgeon applied to cvs2git

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

On 11/02/2017 02:08 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
>> I'm certain HBB would have no problems running the "construct_cvs2git_repo"
>> script, so I would propose that HBB and I take a look at that cvs2git result
>> over the course of a day (I'm already pretty confident) and declare "It's a
>> go", then Eric apply reposurgeon, restoring the items I removed from
>> ./reconvert that are of significance, then post the BETA release to
>> sourceforge.  If everyone's then happy with the beta version, we'd be done.
> 
> Sorry, not interested in going through yet another round of
> complications - unless you think you have fixes or at least good bug
> characterizations for cvs-fast-export or reposurgeon.  Those I'd take.
> 
> For me, messing with cvs2git has negative value.  I can't use it in my
> standard conversion workflow, it makes the refinement cycles too slow.

I wrote the script so that cvs2git is run once and the refinement cycle 
is running reposurgeon on that git repo.  Perhaps things slow down 
because the source is a git repo as opposed to a cvs repo.  I just 
finished a script that loops through every main CVS version name and 
diffs against the cvs2git+reposurgeon version.  Things check out well. 
You did write git support into reposurgeon, and the combo does look nice.


> At some point, somebody in your crew is going to have to decide you'll
> stop screwing with the conversion and cut over to using it.  You've
> long since overshot the amount of effort Ethan and I think is
> appropriate.
> 
> Remember,
> 
>     wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz
> 
> The last change I made was to clean up and parametrize the repository-nuker
> script.  After three weeks of this I think it's time for me to bow out and
> pay attention to projects  I've been neglecting. You guys gave a deadline
> to meet and a policy decision to make.

Sorry Eric, I understand the frustration.  My view, though, is that the 
source of time involved here is the fact cvs-fast-export results 
required so much manual grafting with reposurgeon.  Had I known that was 
involved at the start, I would have suggested a pause.  I myself had to 
dig through a lot of repo-conversions to assist in finding the correct 
branch-points.  That said, my interest is balancing best conversion with 
reasonable effort.

Ethan and HBB make the call here, as I see it.

Thanks for your effort,

Dan

Re: Proposal of reposurgeon applied to cvs2git

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

Daniel J Sebald <dan...@ie...>:
> I'm certain HBB would have no problems running the "construct_cvs2git_repo"
> script, so I would propose that HBB and I take a look at that cvs2git result
> over the course of a day (I'm already pretty confident) and declare "It's a
> go", then Eric apply reposurgeon, restoring the items I removed from
> ./reconvert that are of significance, then post the BETA release to
> sourceforge.  If everyone's then happy with the beta version, we'd be done.

Sorry, not interested in going through yet another round of
complications - unless you think you have fixes or at least good bug
characterizations for cvs-fast-export or reposurgeon.  Those I'd take.

For me, messing with cvs2git has negative value.  I can't use it in my
standard conversion workflow, it makes the refinement cycles too slow.

At some point, somebody in your crew is going to have to decide you'll
stop screwing with the conversion and cut over to using it.  You've
long since overshot the amount of effort Ethan and I think is
appropriate.

Remember,

   wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz

The last change I made was to clean up and parametrize the repository-nuker
script.  After three weeks of this I think it's time for me to bow out and
pay attention to projects  I've been neglecting. You guys gave a deadline
to meet and a policy decision to make. 
-- 
		<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.