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

Re: Cloning errors - SOLVED

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

Colin Baxter <m4...@ya...> writes:

> If I comment-out the `fsckObjects = true' setting in my ~/.gitconfig
> then I can pull the gnuplot repro successfully.

Ah, I can reproduce it now. Thanks for poking at it, Colin. On an older
i686 box:

  $ git fsck

  Checking object directories: 100% (256/256), done.
  error in commit f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
  error in commit 3cc239823f5447fdb739014e076463c8da6225dd: badDateOverflow: invalid author/committer line - date causes integer overflow
  Checking objects: 100% (86573/86573), done.

Both of these commits are from 2006, but "git log" says "Date: Thu Jan 1
00:00:00 1970 +0000". On a more recent amd64 box I don't get "git fsck"
to complain, but the commits are still there, and their date is more
interesting: "Date: Sun Jul 27 02:03:19 2206 +0200".

It isn't particularly difficult to fix this for the master branch, but
since this would be a history rewrite, the resulting tree would be a
fork, effectively. There aren't a ton of people committing to this repo,
so fixing it wouldn't be too disruptive. Strong feelings either way?

Re: Cloning errors - SOLVED

[Colin B. <m4...@ya...>]

If I comment-out the `fsckObjects = true' setting in my ~/.gitconfig
then I can pull the gnuplot repro successfully.

Thanks again.

Best wishes,

Colin.



Colin Baxter
URL: http://www.Colin-Baxter.com

Re: Cloning errors

[Colin B. <m4...@ya...>]

Dear Dima,
>>>>> Dima Kogan <gn...@di...> writes:

    > Colin Baxter <m4...@ya...> writes:
    >> The failing command is `git clone
    >> https://git.code.sf.net/p/gnuplot/gnuplot-main <RET>'

    > Hmmm. I tried on an older i686 build of Ubuntu (identical to
    > Debian in most ways), and it works ok. Old-ish git too:

    >   root@ubuntu-s-1vcpu-1gb-nyc1-01:~# dpkg -l git
    > ... 1:2.7.4-0ubuntu1.6 i386

    > We COULD fix the repo, but it's not obviously worth the trouble if
    > this isn't even clearly reproducible. Any theories about what
    > specifically is causing the trouble on your box? It's not the i686
    > or the older git, at least not on their own.

I've installed the latest git (Version 2.27.0) but I get the same
cloning errors. Time allowing, I'll investigate further.

Thank you very much for your help.

Best wishes,

Colin.

 
Colin Baxter
URL: http://www.Colin-Baxter.com

Re: Cloning errors

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

Colin Baxter <m4...@ya...> writes:

> The failing command is
> `git clone https://git.code.sf.net/p/gnuplot/gnuplot-main <RET>'

Hmmm. I tried on an older i686 build of Ubuntu (identical to Debian in
most ways), and it works ok. Old-ish git too:

  root@ubuntu-s-1vcpu-1gb-nyc1-01:~# dpkg -l git
  ... 1:2.7.4-0ubuntu1.6 i386

We COULD fix the repo, but it's not obviously worth the trouble if this
isn't even clearly reproducible. Any theories about what specifically is
causing the trouble on your box? It's not the i686 or the older git, at
least not on their own.

Re: Bug in 5.4.rc2

[Ethan A M. <me...@uw...>]

On Friday, 26 June 2020 12:42:04 PDT Dima Kogan wrote:
> The simplest patch is this:
> 
> diff --git a/src/plot2d.c b/src/plot2d.c
> index c81fc2344..a8e598359 100644
> --- a/src/plot2d.c
> +++ b/src/plot2d.c
> @@ -1097,7 +1097,7 @@ get_data(struct curve_points *current_plot)
>  	    coordval major_axis = (j >= 3) ? fabs(v[2]) : 0.0;
>  	    coordval minor_axis = (j >= 4) ? fabs(v[3]) : (j >= 3) ? fabs(v[2]) : 0.0;
>  	    coordval orientation = (j >= 5) ? v[4] : 0.0;
> -	    coordval flag = (major_axis > 0 && minor_axis > 0) ? 0.0 : DEFAULT_RADIUS;
> +	    coordval flag = (j >= 3) ? 0.0 : DEFAULT_RADIUS;
> 
>  	    if (j == 2)	/* FIXME: why not also for j == 3 or 4? */
>  		orientation = default_ellipse.o.ellipse.orientation;
> 
> I.e. we use the default ellipse style only if no axis sizes are given at
> all. If anything is given, we use it. Thoughts?

I think I like the other option better:
	zero means zero
	negative means use default from "set style ellipse"

But I also think you can achieve what you want without changing the code
at all, by setting the default ellipse to have 0 size.
Right?

I'm working on something else at the moment.
I'll get back to this afterwards.

	Ethan

Re: Bug in 5.4.rc2

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

The simplest patch is this:

diff --git a/src/plot2d.c b/src/plot2d.c
index c81fc2344..a8e598359 100644
--- a/src/plot2d.c
+++ b/src/plot2d.c
@@ -1097,7 +1097,7 @@ get_data(struct curve_points *current_plot)
 	    coordval major_axis = (j >= 3) ? fabs(v[2]) : 0.0;
 	    coordval minor_axis = (j >= 4) ? fabs(v[3]) : (j >= 3) ? fabs(v[2]) : 0.0;
 	    coordval orientation = (j >= 5) ? v[4] : 0.0;
-	    coordval flag = (major_axis > 0 && minor_axis > 0) ? 0.0 : DEFAULT_RADIUS;
+	    coordval flag = (j >= 3) ? 0.0 : DEFAULT_RADIUS;

 	    if (j == 2)	/* FIXME: why not also for j == 3 or 4? */
 		orientation = default_ellipse.o.ellipse.orientation;

I.e. we use the default ellipse style only if no axis sizes are given at
all. If anything is given, we use it. Thoughts?

Re: Bug in 5.4.rc2

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

Ethan A Merritt <me...@uw...> writes:

> On Friday, 26 June 2020 02:21:58 PDT Dima Kogan wrote:
>> Ethan A Merritt <me...@uw...> writes:
>>
>> > Sounds like your plot wants to use "with ellipses".
>>
>> OK, I'm using ellipses now. It does what I want. I just hit a corner
>> case, however that did a surprising thing. The corner case is this:
>>
>>   plot '-' notitle with ellipses
>>   0 0 0 0
>>
>> <snip>
>>
>> Thus here I would expect nothing
>> drawn, or maybe just a single dot drawn. Instead it draws an ellipse of
>> some arbitrary size, independent of the zoom level: it's an abstract
>> symbol.
>
> I can see why you would expect the size to go to zero or a dot if
> the axis length values reach 0.  That would be reasonable, but currently
> it interprets that as a request to use the default properties set by
>       set style ellipse ...
> which also seem reasonable.  Did it do something else?
>
>> Proposal: ellipses with axis lengths >= 0 are not abstract symbols, and
>> are drawn as the data dictates. axis lengths < 0 may be rendered as
>> symbols.
>>
>> Reasonable?
>
> Currently the code uses the absolute value of the axis lengths,
> so negative values have no special meaning.

Right. But that's an implementation detail. The data could potentially
contain size-0 ellipses, and they should be drawn as size-0 ellipses. If
we really want to have a mode where the default properties are used
instead, they should be accessed with size<0. But I don't actually think
that's useful: if the user is specifying an ellipse size, we should use
it.

Want a patch?

Re: Bug in 5.4.rc2

[Ethan A M. <me...@uw...>]

On Friday, 26 June 2020 02:21:58 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > Sounds like your plot wants to use "with ellipses".
> 
> OK, I'm using ellipses now. It does what I want. I just hit a corner
> case, however that did a surprising thing. The corner case is this:
> 
>   plot '-' notitle with ellipses
>   0 0 0 0
> 
> I'm plotting an ellipse at the origin with axis lengths 0. The
> previously stated purpose was to draw an ellipse with the described
> geometry against the graph coordinates, instead of drawing an abstract
> symbol, like "with circles" does.

I do not recognize that description.  Abstract symbol?
Sounds like a bug.  There is no special code in plot_circles() to
do something other than draw an arc of a circle.
What exactly did you provide as a plot command, and what did
the symbol look like?

> Thus here I would expect nothing
> drawn, or maybe just a single dot drawn. Instead it draws an ellipse of
> some arbitrary size, independent of the zoom level: it's an abstract
> symbol.

I can see why you would expect the size to go to zero or a dot if
the axis length values reach 0.  That would be reasonable, but currently
it interprets that as a request to use the default properties set by
      set style ellipse ...
which also seem reasonable.  Did it do something else?

> Proposal: ellipses with axis lengths >= 0 are not abstract symbols, and
> are drawn as the data dictates. axis lengths < 0 may be rendered as
> symbols.
> 
> Reasonable?

Currently the code uses the absolute value of the axis lengths,
so negative values have no special meaning.
What kind of symbols are you proposing,
and when would you use this rather than plotting `with points`?

	Ethan

	Ethan

Re: Bug in 5.4.rc2

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

Ethan A Merritt <me...@uw...> writes:

> Sounds like your plot wants to use "with ellipses".

OK, I'm using ellipses now. It does what I want. I just hit a corner
case, however that did a surprising thing. The corner case is this:

  plot '-' notitle with ellipses
  0 0 0 0

I'm plotting an ellipse at the origin with axis lengths 0. The
previously stated purpose was to draw an ellipse with the described
geometry against the graph coordinates, instead of drawing an abstract
symbol, like "with circles" does. Thus here I would expect nothing
drawn, or maybe just a single dot drawn. Instead it draws an ellipse of
some arbitrary size, independent of the zoom level: it's an abstract
symbol.

Proposal: ellipses with axis lengths >= 0 are not abstract symbols, and
are drawn as the data dictates. axis lengths < 0 may be rendered as
symbols.

Reasonable?

Re: Cloning errors

[Colin B. <m4...@ya...>]

Hello Dima,
>>>>> Dima Kogan <gn...@di...> writes:

    > Hi. Yes, that's probably what's happening. What I meant to ask
    > though, was the exact "git clone" command that's failing. What
    > repo are you pulling down? I tried some older git builds on i686,
    > and they all work fine with the gnuplot repo. Maybe I'm not
    > cloning exactly the thing you were cloning?

Sorry about the misunderstanding.

The failing command is
`git clone https://git.code.sf.net/p/gnuplot/gnuplot-main <RET>'

--------- Begin screen output -----
Cloning into 'gnuplot-main'...
remote: Enumerating objects: 86573, done.
Counting objects: 100% (86573/86573), done.
remote: Compressing objects: 100% (18752/18752), done.
error: object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
Error in object
fatal: index-pack failed
--------- End screen output --------

Hope this helps.

As a test, I've added by head the Newsgroup name to this email, so if
successful this message will also appear in the news list.

Best wishes,

Colin.

Colin Baxter
URL: http://www.Colin-Baxter.com

Re: Cloning errors

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

Colin Baxter <m4...@ya...> writes:

> For some reason, my replies get rejected by
> gnu...@li....

It requires that the From: address is subscribed to the list, which
could be tripping you up.

I'm having trouble reproducing. Can you please post the exact command
that's failing? Thanks.

Re: Cloning errors

[Colin B. <m4...@ya...>]

>>>>> Tait  <gnu...@t4...> writes:

    > Curious; I don't get that error. What version of git are you
    > using, on what OS?

For some reason, my replies get rejected by
gnu...@li.... This follow-up is therefore my reply. 

I'm using git version 2.9.5 on 3.16.0-11-686-pae #1 SMP Debian 3.16.84-1
(2020-06-09) i686 GNU/Linux. I see the latest git is 2.27.0 so perhaps I
should upgrade; however, gnuplot is the first git repository that's
given the error.


Best wishes,


>>>>> Colin Baxter <m4...@ya...> writes:

    > Hello,

    > Git cloning https://git.code.sf.net/p/gnuplot/.... fails with

    > remote: Compressing objects: 100% (18752/18752), done.  error:
    > object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow:
    > invalid author/committer line - date causes integer overflow
    > fatal: Error in object fatal: index-pack failed

    > Best wishes,


    > Colin Baxter URL: http://www.Colin-Baxter.com
    > ---------------------------------------------------------------------
    > GnuPG fingerprint: 68A8 799C 0230 16E7 BF68 2A27 BBFA 2492 91F5
    > 41C8 ---------------------------------------------------------------------



    > _______________________________________________ gnuplot-beta
    > mailing list gnu...@li... Membership
    > management via:
    > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Cloning errors

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

Curious; I don't get that error. What version of git are you
using, on what OS?

Cloning into 'gnuplot-main'...
remote: Enumerating objects: 86573, done.
remote: Counting objects: 100% (86573/86573), done.
remote: Compressing objects: 100% (18752/18752), done.
remote: Total 86573 (delta 70470), reused 83123 (delta 67685)
Receiving objects: 100% (86573/86573), 24.98 MiB | 8.77 MiB/s, done.
Resolving deltas: 100% (70470/70470), done.

But that said, the referenced commit does clearly have an
invalid date:
  tree 31bef65a8811b246449435d6334cd03b80364528
  parent 8d0b9267c9f623c99a2f949652180e2e07845847
  author Timothee Lecomte <tim...@en...> 7465328412 +0200
  committer Timothee Lecomte <tim...@en...> 1154067612 +0200
  
  Reword the warning about problems with piping /dev/null with mouse support...
  
  ...to reflect 4.2 behaviour.

If I've calculated correctly, 7465328412 would be about July,
2206. In any case, it and others (like 3cc23982) are part of
history now, so I can't understand why git doesn't warn by
default instead of treating it as fatal.

I'm guessing this only affects old versions. There was a config
option to turn it down to a warning, which I assume would let
you clone successfully:
  https://github.com/c3e/grundgesetz-dev/issues/28


Colin Baxter <m4...@ya...> said (on 2020/06/25):
> Hello,
> 
> Git cloning https://git.code.sf.net/p/gnuplot/.... fails with
> 
> remote: Compressing objects: 100% (18752/18752), done.        
> error: object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
> fatal: Error in object
> fatal: index-pack failed
> 
> Best wishes,
> 
> 
> Colin Baxter

Cloning errors

[Colin B. <m4...@ya...>]

Hello,

Git cloning https://git.code.sf.net/p/gnuplot/.... fails with

remote: Compressing objects: 100% (18752/18752), done.        
error: object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
fatal: Error in object
fatal: index-pack failed

Best wishes,


Colin Baxter
URL: http://www.Colin-Baxter.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------

Re: bug in 5.4rc2 X11 terminal

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

Ethan A Merritt <me...@uw...> writes:

> On Wednesday, 24 June 2020 10:20:48 PDT Dima Kogan wrote:
>> So I really would like to keep this working reasonably. If we currently
>> have a unicode problem that makes tic mark labels render improperly, an
>> easy "fix" would be to not feed unicode to the x11 terminal.
>
> That is exactly what "set encoding XXX" does, for any XXX that is not utf8.
>
> Or did you mean that <x11 terminal + non-ascii encoding> would be
> a special case when generating tic labels?
> We generally try to keep terminal-specific tests out of the core code,
> but we do have tests for TeX-based terminals so it's not an absolute
> prohibition.

I meant that if we have a known issue where utf8 breaks tic labels with
the x11 terminal, then we can do the "set encoding xxx" internally,
without making the user work around the bug.


> For a long time now utf8 has been the default on linux. So I would
> expect that most linux users would have to deal with this when using
> the x11 terminal with their default locale.

Yes, but I can't reproduce it. I tried today to take away my local
ascii-only setting, and it still seems to work. I even tried to "set
encoding utf8", and my tic labels STILL look ok. And I use gnuplot a LOT
on all sorts of boxes, and I've never seen this. So I would guess that
this isn't an issue that gnuplot has with the default settings for most
people.

Pieter-Tjerk: do you have any theories about what it is about your setup
that triggered this problem?

Re: bug in 5.4rc2 X11 terminal

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

On Wed, 24 Jun 2020, Ethan A Merritt wrote:

> For a long time now utf8 has been the default on linux.
> So I would expect that most linux users would have to deal with this
> when using the x11 terminal with their default locale.

It "just works" here. Xterm using utf8, gnuplot using utf8 (as 
everything should!). So the multiplication signs come out right on 
the axes if I do, e.g.,

set term x11
plot sin(x)*1.0e-5

The only slightly odd thing is what "show encoding" produces:

         nominal character encoding is default
         however LC_CTYPE in current locale is en_US.utf8

I'm not sure what the first line means, or what the force of the 
"however" is.

Allin Cottrell

Re: bug in 5.4rc2 X11 terminal

[Ethan A M. <me...@uw...>]

On Wednesday, 24 June 2020 10:20:48 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > Back when people cared about x11, the tools and fonts necessary to set
> > up utf8 support were maintained, albeit difficult to use. Now I cannot
> > get it to work at all. I imagine it is still possible but I cannot
> > point to a recipe for how to do it.
> >
> > I think the best advice is "don't use the x11 terminal".
> 
> Yeah, that's too bad, but I think we can do better than that advice
> suggests.
> 
> I use the x11 terminal almost exclusively for one reason: it's
> dramatically faster and lighter than all the alternatives. The
> difference is very noticeable when X-forwarding or when repeatedly
> replotting (interactively rotating a 3D plot, using feedgnuplot
> --stream, etc).
> 
> So I really would like to keep this working reasonably. If we currently
> have a unicode problem that makes tic mark labels render improperly, an
> easy "fix" would be to not feed unicode to the x11 terminal.

That is exactly what "set encoding XXX" does, for any XXX that is not utf8.

Or did you mean that <x11 terminal + non-ascii encoding> would be
a special case when generating tic labels? 
We generally try to keep terminal-specific tests out of the core code,
but we do have tests for TeX-based terminals so it's not an absolute
prohibition.

> If somebody
> has the time and motivation to fix it properly, that'd be awesome of
> course, but just sending ascii across would solve the 99% case in the
> meantime.
> 
> But I can't reproduce the issue in this report, and until that happens,
> there's nothing to "fix".

For a long time now utf8 has been the default on linux.
So I would expect that most linux users would have to deal with this
when using the x11 terminal with their default locale.  

	Ethan

Re: bug in 5.4rc2 X11 terminal

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

Ethan A Merritt <me...@uw...> writes:

> Back when people cared about x11, the tools and fonts necessary to set
> up utf8 support were maintained, albeit difficult to use. Now I cannot
> get it to work at all. I imagine it is still possible but I cannot
> point to a recipe for how to do it.
>
> I think the best advice is "don't use the x11 terminal".

Yeah, that's too bad, but I think we can do better than that advice
suggests.

I use the x11 terminal almost exclusively for one reason: it's
dramatically faster and lighter than all the alternatives. The
difference is very noticeable when X-forwarding or when repeatedly
replotting (interactively rotating a 3D plot, using feedgnuplot
--stream, etc).

So I really would like to keep this working reasonably. If we currently
have a unicode problem that makes tic mark labels render improperly, an
easy "fix" would be to not feed unicode to the x11 terminal. If somebody
has the time and motivation to fix it properly, that'd be awesome of
course, but just sending ascii across would solve the 99% case in the
meantime.

But I can't reproduce the issue in this report, and until that happens,
there's nothing to "fix".

Re: bug in 5.4rc2 X11 terminal

[Ethan A M. <me...@uw...>]

On Wednesday, 24 June 2020 09:04:32 PDT Dima Kogan wrote:
> Pieter-Tjerk de Boer <p.t...@ut...> writes:
> 
> > So, somehow, Debian's native gnuplot sets encoding to default even in
> > the C.UTF-8 locale, while 5.4rc2 only does that in the C locale.
> >
> > Thanks for the help; this provides me with sufficient ways to
> > circumvent the problem.
> 
> For what it's worth, my local environment is set to use C instead of
> UTF-8, which is probably why things consistently work here.
> 
> I tried to set the locale environment in various ways to reproduce the
> issue you saw, and I can't. IF gnuplot 5.4 has this issue with the x11
> terminal (requiring the user to explicitly turn off unicode), then I
> think we should fix it in some way.
> 
> But I can't reproduce the problem, so maybe there isn't anything to fix?
> Can anybody else see this issue?

Back when people cared about x11, the tools and fonts necessary to
set up utf8 support were maintained, albeit difficult to use.
Now I cannot get it to work at all.  I imagine it is still possible but
I cannot point to a recipe for how to do it.

I think the best advice is "don't use the x11 terminal".

	Ethan
  

Re: bug in 5.4rc2 X11 terminal

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

Pieter-Tjerk de Boer <p.t...@ut...> writes:

> So, somehow, Debian's native gnuplot sets encoding to default even in
> the C.UTF-8 locale, while 5.4rc2 only does that in the C locale.
>
> Thanks for the help; this provides me with sufficient ways to
> circumvent the problem.

For what it's worth, my local environment is set to use C instead of
UTF-8, which is probably why things consistently work here.

I tried to set the locale environment in various ways to reproduce the
issue you saw, and I can't. IF gnuplot 5.4 has this issue with the x11
terminal (requiring the user to explicitly turn off unicode), then I
think we should fix it in some way.

But I can't reproduce the problem, so maybe there isn't anything to fix?
Can anybody else see this issue?

Re: bug in 5.4rc2 X11 terminal

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

On Tue, Jun 23, 2020 at 10:43:32PM -0700, Dima Kogan wrote:
> I use Debian and the x11 terminal routinely, and have never seen this
> issue.
> 
> Ethan: if there's some sort of utf-8 issue as you suspect, would it show
> up in "show encoding"? I see this on my machine:
> 
>   gnuplot> show encoding
> 
>           nominal character encoding is default
>           however LC_CTYPE in current locale is C

In Debian's native gnuplot 5.2pl6 I get:

  gnuplot> show encoding
          nominal character encoding is default
          however LC_CTYPE in current locale is C.UTF-8

while in 5.4rc2 I get:

  gnuplot> show encoding
          nominal character encoding is utf8
          however LC_CTYPE in current locale is C.UTF-8

Setting encoding to "default" rather than "utf8" indeed fixes the problem
I had in the x11 terminal on 5.4rc2.

> I guess the locale being "C" means I'm not doing unicode, and that's why
> things work for me?

Ah, interesting: if I start gnuplot 5.4rc2 with LC_CTYPE set to C, I get
the same as you:

  gnuplot> show encoding
          nominal character encoding is default
          however LC_CTYPE in current locale is C

So, somehow, Debian's native gnuplot sets encoding to default even in
the C.UTF-8 locale, while 5.4rc2 only does that in the C locale.

Thanks for the help; this provides me with sufficient ways to circumvent
the problem.

Regards,
  Pieter-Tjerk

Re: bug in 5.4rc2 X11 terminal

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

I use Debian and the x11 terminal routinely, and have never seen this
issue.

Ethan: if there's some sort of utf-8 issue as you suspect, would it show
up in "show encoding"? I see this on my machine:

  gnuplot> show encoding

          nominal character encoding is default
          however LC_CTYPE in current locale is C

I guess the locale being "C" means I'm not doing unicode, and that's why
things work for me?

Re: bug in 5.4rc2 X11 terminal

[Ethan A M. <me...@uw...>]

On Tuesday, 23 June 2020 13:17:19 PDT Pieter-Tjerk de Boer wrote:
> Hello,
> 
> Something goes wrong with fonts or character encodings on the x11 terminal.
> See the attached which is the result of simply  
>   plot 1e6
> The vertical labels have a few unintended characters instead of multiplication
> signs (crosses).
> 
> Debian's stock gnuplot 5.2pl6 version displays the multiplication sign
> correctly on the x11 terminal, as does 5.4rc2 with the Qt terminal.
> 
> Any idea what this could be? Any test I could do to help debug it?

Most likely your gnuplot session is operating with encoding utf8,
but your x11 terminal font handling is not set up to handle it.
It is possible to set it up, but it's a horrible pain and depends on exactly
what fonts you have available.   Either switch to
     set encoding iso_8859_15    (probably)
or switch to another terminal that has kept up with the modern world
and knows how to handle utf8.  I long ago switched to from x11 to qt
for daily use, but wxt or even sixel might fit your environment better.

If you stick with x11  and iso_8859_15, remember to switch the
encoding back to utf8 for output to pdf or TeX.

	Ethan

> 
> Regards,
>   Pieter-Tjerk
> 

Re: Bug in 5.4.rc2

[Ethan A M. <me...@uw...>]

On Tuesday, 23 June 2020 11:24:24 PDT Dima Kogan wrote:
> I finished a patch just as you wrote this. The patch is attached. I
> tried several operations, and it appears to do what I want, and not
> break anything. The code has a lot of confusion about the meaning of
> xlow/xhigh/ylow/yhigh in arguments to store2d_point() and again, in the
> *cp structure this function fills. The previous code was passing the x,y
> extents to store2d_point(), but if you do that, you run out of
> arguments, and can't pass the y extents even if you wanted to. This
> patch computes the extents inside store2d_point(), so there are
> arguments left over. 

That won't work.
The eventual extent of a cicle along the y axis will not be known
until after the scaling on both x and y is complete.  For an auto-scaled
plot that will not be true until all the plot components, including functions,
have been processed.  There is not enough information yet at the time
store2d_point() is called.

"with circles" is not the only plot style for which autoscaling must
be delayed till later.  That is the reason for the extra routines
box_range_fiddling()  impulse_range_fiddling() histogram_range_fiddling()
and so on.   However for those plot styles the extra routine can
be called following the individual plot component "with <whatever>".
To handle circles you'd have to wait until _all_ plot components had
contributed to the autoscaling.  That could be done, but it would introduce
a new stage of processing that has not been needed before this.
And even so it would be imprecise, because if you must increase
the y range to fit the circles that will itself increase the y-radius of
the circles so you would need to iterate or estimate the asymptote.

So not impossible, but more difficult than autoscaling other plot styles.

	Ethan

Re: Bug in 5.4.rc2

[Ethan A M. <me...@uw...>]

On Tuesday, 23 June 2020 11:33:13 PDT Dima Kogan wrote:
> Dima Kogan <gn...@di...> writes:
> 
> > I finished a patch just as you wrote this.
> 
> So I just played with the patched code a bit more, and it's plotting the
> circles as circles even if the aspect ratio is not square. So it's
> clearly insufficient. Hmm

Indeed. That is the purpose of the style.  It _always_ draws circles,
regardless of aspect ratio and regardless of y scaling.

Sounds like your plot wants to use  "with ellipses".

	Ethan