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

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Saturday, 3 September 2022 13:12:11 PDT Dima Kogan wrote:
> >> Let's say the request was "I want a gnuplot-powered plotting widget in
> >> my GTK application". What would you suggest in that case?
> >
> > Isn't that what wxt is? 
> 
> Is it? If I was building a GTK application (not wx; plain GTK), could I
> use the gnuplot wxt terminal as a widget in that application? The docs
> don't make that clear, and definitely don't tell you how to do that.

You seem to be asking for a cross-platform UI with widgets based on gtk.
What I meant was that wxWidgets claims to be exactly that, although it
doesn't use (or at least doesn't default to using) gtk on all the 
supported platforms.  So if you base your UI on wxWidgets, then gnuplot's
wxt terminal is a natural fit.

> Similarly, what if I was building a Qt application? "help qt" mentions a
> "widget" option, which maybe provides this function, but that option
> isn't documented, so I don't know what it does.

In the file .../src/Makefile.am is a commented out section that builds
a simple Qt app with embedded gnuplot windows.  

Edit that file to un-comment the section and re-run
    ./prepare; ./configure; make
    ./embed_example

	Ethan

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Saturday, 3 September 2022 13:04:11 PDT Dima Kogan wrote:
> Hans-Bernhard Bröker <HBB...@t-...> writes:
> 
> > Am 02.09.2022 um 02:22 schrieb Dima Kogan:
> >
> >> It feels like an odd thing to do to specifically mask out SIGTSTP,
> >> but I guess that's fine. Masking out SIGINT creates zombies, though,
> >
> > Well, the documented intent is to keep gnuplot_x11 from being killed
> > by Ctrl-C or Ctrl-Z typed into the console --- presumably the one its
> > parent gnuplot process was started from.
> 
> But you DO want it to die when the user hits C-c on the console!

Your expectations are unusual in this regard.
Ctrl-C is a normal way to return control to an interactive session.
For example it is documented as the recommended way to break out of a
long-running "fit" command.  It is safe to hit Ctrl-C in any gnuplot session.
The program will not exit and the graphics window will not close.

> Otherwise you get zombies. 

I suspect these are not zombies. Can you kill then with SIGTERM?
  killall gnuplot_x11 -SIGTERM

More likely they are hung waiting for piped input from a gnuplot
session that segfaulted.  That is not something that should be an
issue unless you have a more fundamental problem with the
gnuplot end of the pipe, and you can clean them up with 'killall'
if it bothers you to see them listed in a process table.

	Ethan


> There's some logic in there to die via a more
> "controlled" path or something, so most of the time the child
> gnuplot_x11 process does go away in response to a C-c, but sometimes it
> doesn't. I do see straggler gnuplot_x11 processes sometimes. And when
> debugging some updates to gnuplot_x11 I see them all the time.
> 
> 
> > It would be _very_ surprising to find out that this particular snippet
> > would have been as badly wrong as you claim it to be, after all this
> > time. X11 may be considered unimportant by some today, but that
> > definitely would have been no excuse of the majority of that time
> > frame.
> 
> I claim there's a bug, not that gnuplot_x11 is horribly, unusably
> broken. There are other gnuplot_x11 bugs that definitely exist that I
> can report too, but nobody has the cycles to work on them (including
> me), so that's not obviously useful.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

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

> Again only guessing, but I wonder if some window managers send SIGINT
> to the controlling process (or did back in the day) when a window is
> forcibly closed. 
>
>> I can try to keep SIGINT only, and dogfood that change in my everyday
>> usage (I make a LOT of plots). If I don't find anything obviously broken
>> as a result after a few weeks, can we merge it?
>
> You make a lot of plots but presumably they are all made from the
> same environment.  My concern would be that it breaks some other 
> window manager or desktop or OS or X-server etc...

I have the same concern too, but I can't effectively test other people's
setups. If nobody has the cycles to think about fixing bugs in the x11
terminal, maybe we should just leave this alone.


> ... Hang on a minute, when you say "keep SIGINT only" do you mean keep the
> SIGINT handling as it is (masked) or do you mean keep (as in "not block")
> SIGINT?

I meant a small patch that only changes the handing of SIGINT: SIGINT
would have the default behavior (killing gnuplot_x11), but SIGTSTP would
be ignored. To keep the patch as small as possible, since the SIGTSTP
behavior isn't all that important.


>> In my mind, one big argument for gnuplot in general, as compared to
>> other plotting libraries, is its speed. Using a non-x11 terminal dulls
>> that argument.
>
> I think we had this discussion about 10 years ago :-)
>    https://sourceforge.net/p/gnuplot/mailman/message/30718556/

We did! I completely forgot about that!


> At the time there was at least one plot type (3D images)
> for which x11 was faster, but I do not think that is true today.
>
> It's been a while since I did extensive benchmarking, but here's a
> quick timing run on my home desktop:
>
> [~/temp] setenv GNUTERM x11 ; time gnuplot all.dem < /bin/yes >& /dev/null
> 14.931u 3.520s 0:52.84 34.9%    0+0k 8+0io 0pf+0w
> [~/temp] setenv GNUTERM qt ; time gnuplot all.dem < /bin/yes > & /dev/null
> 13.143u 2.276s 0:21.02 73.3%    0+0k 0+0io 0pf+0w
> [~/temp] setenv GNUTERM wxt ; time gnuplot all.dem < /bin/yes > & /dev/null
> 40.824u 4.306s 0:48.56 92.9%    0+0k 4328+0io 1008pf+0w
>
> Both wxt and qt are faster than x11 (clock time).
> qt is impressively faster - the test run completes in less
> than half the time used by x11.
>
> Note that the 'u' and 's' times for wxt are for a single process
> while those for x11 and qt are for the inboard (gnuplot) process only.
> But qt is faster than x11 by that measure also.

I guess I wasn't convinced by the thread 10 years ago, but I'll look
again. Thanks for the measurements. In your view, which is the one to
use for interactive plotting on GNU/Linux boxes? qt or wxt? I just
quickly tried both of them, and there are a few bugs/quirks in both of
them I'd want to fix before moving all my usage to one of those. That's
for a later email.


>> Let's say the request was "I want a gnuplot-powered plotting widget in
>> my GTK application". What would you suggest in that case?
>
> Isn't that what wxt is? 

Is it? If I was building a GTK application (not wx; plain GTK), could I
use the gnuplot wxt terminal as a widget in that application? The docs
don't make that clear, and definitely don't tell you how to do that.

Similarly, what if I was building a Qt application? "help qt" mentions a
"widget" option, which maybe provides this function, but that option
isn't documented, so I don't know what it does.

And I want to use FLTK for my applications, so these don't help me. I
guess a new "fltk" terminal would be the "right" way to do that, but
that's not a good use of anybody's time. x11 is a good base to build on,
since all the widget toolkits depend on it (for now at least), and I bet
you could build UI widgets for most toolkits based on "set terminal x11
window whatever".

So yeah. I think there's value in maintaining it, and fixing bugs in it.
I don't have a ton of cycles to put towards that, but I will send some
patches when they're ready.

dima

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

Hans-Bernhard Bröker <HBB...@t-...> writes:

> Am 02.09.2022 um 02:22 schrieb Dima Kogan:
>
>> It feels like an odd thing to do to specifically mask out SIGTSTP,
>> but I guess that's fine. Masking out SIGINT creates zombies, though,
>
> Well, the documented intent is to keep gnuplot_x11 from being killed
> by Ctrl-C or Ctrl-Z typed into the console --- presumably the one its
> parent gnuplot process was started from.

But you DO want it to die when the user hits C-c on the console!
Otherwise you get zombies. There's some logic in there to die via a more
"controlled" path or something, so most of the time the child
gnuplot_x11 process does go away in response to a C-c, but sometimes it
doesn't. I do see straggler gnuplot_x11 processes sometimes. And when
debugging some updates to gnuplot_x11 I see them all the time.


> It would be _very_ surprising to find out that this particular snippet
> would have been as badly wrong as you claim it to be, after all this
> time. X11 may be considered unimportant by some today, but that
> definitely would have been no excuse of the majority of that time
> frame.

I claim there's a bug, not that gnuplot_x11 is horribly, unusably
broken. There are other gnuplot_x11 bugs that definitely exist that I
can report too, but nobody has the cycles to work on them (including
me), so that's not obviously useful.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

Am 02.09.2022 um 02:22 schrieb Dima Kogan:

> I suspected this predates you. 

Oh, there's no question at all about that ;-).  Those lines have 
remained essentially unchanged since version 3.2, from 1992.  Yes, 
that's 30 years ago.

> It feels like an odd thing to do to
> specifically mask out SIGTSTP, but I guess that's fine. Masking out
> SIGINT creates zombies, though, 

Well, the documented intent is to keep gnuplot_x11 from being killed by 
Ctrl-C or Ctrl-Z typed into the console --- presumably the one its 
parent gnuplot process was started from.

It would be _very_ surprising to find out that this particular snippet 
would have been as badly wrong as you claim it to be, after all this 
time.  X11 may be considered unimportant by some today, but that 
definitely would have been no excuse of the majority of that time frame.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Thursday, 1 September 2022 17:22:37 PDT Dima Kogan wrote:
> Hi Ethan.
> 
> 
> Ethan A Merritt <me...@uw...> writes:
> 
> > On Thursday, 1 September 2022 00:12:01 PDT Dima Kogan wrote:
> >>
> >> I'm looking at patching gplt_x11.c to work better with existing X window
> >> IDs. This is coming along. In the process I'm discovering other things.
> >> One is that for some reason the gnuplot x11 backend is explicitly
> >> ignoring the SIGINT and SIGTSTP signals:
> >
> > I do not recall, or never knew, those details. But I would imagine
> > that it ignores SIGTSTP because backgrounding gnuplot_x11 would be a
> > bad idea - it would stop responding to new commands from the main
> > gnuplot process.
> 
> I suspected this predates you. It feels like an odd thing to do to
> specifically mask out SIGTSTP, but I guess that's fine. Masking out
> SIGINT creates zombies, though, so there's a clear downside. 

Again only guessing, but I wonder if some window managers send SIGINT
to the controlling process (or did back in the day) when a window is
forcibly closed. 

> I can try to keep SIGINT only, and dogfood that change in my everyday
> usage (I make a LOT of plots). If I don't find anything obviously broken
> as a result after a few weeks, can we merge it?

You make a lot of plots but presumably they are all made from the
same environment.  My concern would be that it breaks some other 
window manager or desktop or OS or X-server etc...

... Hang on a minute, when you say "keep SIGINT only" do you mean keep the
SIGINT handling as it is (masked) or do you mean keep (as in "not block")
SIGINT?
 
> > It's been too many years since I was seriously using or looking at the 
> > x11 terminal driver.  I think the world has moved on from direct use
> > of Xlib to drive graphics output, in favor of higher level libraries.
> 
> One could say that the world has moved on from gnuplot too, yet here we
> are. For my own interactive use I use the x11 terminal exclusively. I
> find it to be dramatically faster than both qt and wxt. Doubly so if
> x-forwarding (the world is in the process of moving on from X, but it's
> not clear if it will ever get there). Yes, the x11 terminal doesn't do
> anti-aliasing or transparency or fancy text like qt and wxt do, but I've
> never felt like I missed those features in my usage.

If by "fancy text" you mean the text mark-up, it does support that.
The bigger issue is that it doesn't handle UTF8 [*].
X11 and PostScript were state of the art back when gnuplot was new,
but they both suffer from the same myopic view characteristic of
that era: "256 characters are enough".

 > In my mind, one big argument for gnuplot in general, as compared to
> other plotting libraries, is its speed. Using a non-x11 terminal dulls
> that argument.

I think we had this discussion about 10 years ago :-)
   https://sourceforge.net/p/gnuplot/mailman/message/30718556/

At the time there was at least one plot type (3D images)
for which x11 was faster, but I do not think that is true today.

It's been a while since I did extensive benchmarking, but here's a
quick timing run on my home desktop:

[~/temp] setenv GNUTERM x11 ; time gnuplot all.dem < /bin/yes >& /dev/null
14.931u 3.520s 0:52.84 34.9%    0+0k 8+0io 0pf+0w
[~/temp] setenv GNUTERM qt ; time gnuplot all.dem < /bin/yes > & /dev/null
13.143u 2.276s 0:21.02 73.3%    0+0k 0+0io 0pf+0w
[~/temp] setenv GNUTERM wxt ; time gnuplot all.dem < /bin/yes > & /dev/null
40.824u 4.306s 0:48.56 92.9%    0+0k 4328+0io 1008pf+0w

Both wxt and qt are faster than x11 (clock time).
qt is impressively faster - the test run completes in less
than half the time used by x11.

Note that the 'u' and 's' times for wxt are for a single process
while those for x11 and qt are for the inboard (gnuplot) process only.
But qt is faster than x11 by that measure also.

Also note that there are some compute-heavy demos in that test set.
If I were to limit it to the ones that are more purely graphics
then the speed difference would be even more noticeable in favor of qt.
 
>
> [Large snip that I may get back to later]
>

> Let's say the request was "I want a gnuplot-powered plotting widget in
> my GTK application". What would you suggest in that case?

Isn't that what wxt is? 
On linux anyway.
The OSX version of wxt uses a different, non-GTK, back end by default;
I do not know if you can persuade it to use GTK there instead.

	Ethan

[*] Long ago I managed to get x11 to more or less handle UTF8 by
using multi-font support and encoding ISO10646 for the x11 fonts.
The scripts I used then no longer work, and I can't be bothered
to figure out how or if it can be made to work again now.

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

Hi Ethan.


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

> On Thursday, 1 September 2022 00:12:01 PDT Dima Kogan wrote:
>>
>> I'm looking at patching gplt_x11.c to work better with existing X window
>> IDs. This is coming along. In the process I'm discovering other things.
>> One is that for some reason the gnuplot x11 backend is explicitly
>> ignoring the SIGINT and SIGTSTP signals:
>
> I do not recall, or never knew, those details. But I would imagine
> that it ignores SIGTSTP because backgrounding gnuplot_x11 would be a
> bad idea - it would stop responding to new commands from the main
> gnuplot process.

I suspected this predates you. It feels like an odd thing to do to
specifically mask out SIGTSTP, but I guess that's fine. Masking out
SIGINT creates zombies, though, so there's a clear downside. I can try
to keep SIGINT only, and dogfood that change in my everyday usage (I
make a LOT of plots). If I don't find anything obviously broken as a
result after a few weeks, can we merge it?


> It's been too many years since I was seriously using or looking at the 
> x11 terminal driver.  I think the world has moved on from direct use
> of Xlib to drive graphics output, in favor of higher level libraries.

One could say that the world has moved on from gnuplot too, yet here we
are. For my own interactive use I use the x11 terminal exclusively. I
find it to be dramatically faster than both qt and wxt. Doubly so if
x-forwarding (the world is in the process of moving on from X, but it's
not clear if it will ever get there). Yes, the x11 terminal doesn't do
anti-aliasing or transparency or fancy text like qt and wxt do, but I've
never felt like I missed those features in my usage.

In my mind, one big argument for gnuplot in general, as compared to
other plotting libraries, is its speed. Using a non-x11 terminal dulls
that argument.


> You said you were looking at this in order to create a gnuplot widget
> for FLTK? I've not previously heard of FLTK, and the fltk.org web site
> is not particularly informative. It looks like it's left over from
> twenty years ago. Can you describe the functionality you need?

FLTK is a widget set. Like Qt or wxt or GTK. It's simple and fast, but
for the purposes of this conversation this is a detail. We can be
talking about GTK instead.


> For example, do you need mousing support inside this widget? If not,
> can you use one of the png terminals rather than x11? The graphics
> would be better, particularly the text handling.
>
> Or maybe you could use svg + domterm? http://domterm.org/Features.html

OK, so on a very high-level a want a plotting library that is

- Fast

- Stable over time

- Available in all contexts in which I plot stuff. Currently this is
  from the terminal, from python, and (hopefully) from an FLTK widget.
  Other people could want to plot from Qt or GTK or R or whatever, and
  it'd be awesome if the same plotting backend was available in all of
  those.

Today, gnuplot is the closest to tick all those boxes for me. There's no
reason why the preferred Python plotting library (matplotlib) is
different from the R plotting library (ggplot2) is different from
whatever you're supposed to do in GTK (gtkdatabox?). And so on. I
generally use FLTK for GUI tools, so I'd like good plotting there, but
the FLTK part is a detail. It would be awesome if Gnuplot were available
as a widget for every GUI toolkit, which is obviously a lot of work. Or
we can use the x11 terminal talking to an external X window, and with a
small number of limitations, we'd be done.

Let's say the request was "I want a gnuplot-powered plotting widget in
my GTK application". What would you suggest in that case?

Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

On Thursday, 1 September 2022 00:12:01 PDT Dima Kogan wrote:
> Hi.
> 
> I'm looking at patching gplt_x11.c to work better with existing X window
> IDs. This is coming along. In the process I'm discovering other things.
> One is that for some reason the gnuplot x11 backend is explicitly
> ignoring the SIGINT and SIGTSTP signals:

You ask "why"?

I do not recall, or never knew, those details.
But I would imagine that it ignores SIGTSTP because backgrounding
gnuplot_x11 would be a bad idea - it would stop responding to new
commands from the main gnuplot process.

It's been too many years since I was seriously using or looking at the 
x11 terminal driver.  I think the world has moved on from direct use
of Xlib to drive graphics output, in favor of higher level libraries.

You said you were looking at this in order to create a gnuplot widget
for FLTK?  I've not previously heard of FLTK, and the fltk.org web site
is not particularly informative.  It looks like it's left over from
twenty years ago.  Can you describe the functionality you need?

For example, do you need mousing support inside this widget?
If not, can you use one of the png terminals rather than x11?
The graphics would be better, particularly the text handling.

Or maybe you could use svg + domterm?
http://domterm.org/Features.html


	Ethan

> 
>   https://urldefense.com/v3/__https://github.com/gnuplot/gnuplot/blob/e9779f00507187653b8fb317f492833af5eaaa9a/src/gplt_x11.c*L5270__;Iw!!K-Hz7m0Vt54!nm8TuNQnOSs9oWJELaBt7rhGmG84fkSGIXqAfuInBOuZk6jnG84SldATh5Xd6jUvN2MWtynemioL8wudnMTwBw$  
> 
> This results in zombie gplt_x11 processes. During normal operation
> usually this doesn't happen, but I do periodically see gplt_x11 zombies.
> While testing my new patches, I see these all the time, however. Does
> anybody know why we're ignoring these signals? Version control says that
> we were doing this from day 0 more or less.
> 
> Removing those two signal() calls doesn't obviously break anything, and
> results in the zombie processes going away. Can/should we get rid of
> those?
> 
> Thanks
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!nm8TuNQnOSs9oWJELaBt7rhGmG84fkSGIXqAfuInBOuZk6jnG84SldATh5Xd6jUvN2MWtynemioL8wuvoGg3ZA$  
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

[Tatsuro M. <tma...@ya...>]

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> Date: 2022/09/01 木 16:12
> Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> 
> 
> I reverted the commit 1955b4151ceef88de644bc89c39477a3d537ad13 and ps_symbols.ps was generated correctly.
> 
> The commit 1955b4151ceef88de644bc89c39477a3d537ad13 may be inadequate and should be improved.
> I will file a bug report.
> 
> Tatsuro
> 
> > ----- Original Message -----
> > 
> > From: "Ethan A Merritt" <me...@uw...>
> > To: "gnu...@li..." <gnu...@li...>; "Tatsuro MATSUOKA" <tma...@ya...>
> > Date: 2022/09/01 木 15:44
> > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > 
> > 
> > On Wednesday, 31 August 2022 23:14:07 PDT Tatsuro MATSUOKA wrote:
> > > I have tested on Ubuntu-22.04 (WLS2) and Cygwin.
> > > For both: ps_symbols.ps (5.5 )  1631 lines.
> > > 
> > > The phenomenon is windows specific and something is changed in the postscript terminal on gnuplot-5.5 on windows.
> > 
> > I see only one Windows-specific change to post.trm in the past year or so:
> > 
> > commit 1955b4151ceef88de644bc89c39477a3d537ad13
> > Author: Bastian Maerkisch <bma...@we...>
> > Date:   Sat Feb 12 19:00:42 2022 +0100
> > 
> >     pslatex, pstex: make sure we don't mix style of line endings
> >     
> >     (La)TeX chokes on mixing different line endings of Postscript data. This
> >     would be the case for a git checkout on Windows. We now make sure that we
> >     consistently use CR only line endings on Windows/DOS/OS/2.
> > 
> > > Is it better to file as a bug report?
> > 
> > That would be fine.
> > But before the bug report you could try reverting the above commit
> > to see if that fixes it.
> > 
> > 	Ethan
> > 
> > 
> > 
> > 
> > > 
> > > Tatsuro
> > >  
> > > 
> > > > ----- Original Message -----
> > > > 
> > > > From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> > > > To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> > > > Date: 2022/09/01 木 14:49
> > > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > > 
> > > > 
> > > > Thank you for your reply.
> > > > 
> > > > For me,two files are different
> > > > ps_symbols.ps (5.4.4 )  1631 lines 
> > > > ps_symbols.ps (5.5 )  1248 lines 
> > > > 
> > > > I have tested only on windows.
> > > > I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.
> > > > 
> > > > Tatsuro
> > > > 
> > > > > ----- Original Message -----
> > > > > 
> > > > > From: "Ethan A Merritt" <me...@uw...>
> > > > > To: "gnu...@li..." <gnu...@li...>
> > > > > Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> > > > > Date: 2022/09/01 木 14:34
> > > > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > > > 
> > > > > 
> > > > > On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > > > > > I cannot judge whether this is a bug or not.
> > > > > > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> > > > > 
> > > > > I cannot reproduce this.
> > > > > I get identical postscript output files using either gnuplot 5.4 or 5.5,
> > > > > differing only in the Creator and CreationDate header lines.
> > > > > 
> > > > > 	Ethan
> > > > > 
> > > > > 
> > > > > > 
> > > > > > $ gs ps_symbols.ps
> > > > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > > > see the file COPYING for details.
> > > > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > > > > > Error: /undefined in UL
> > > > > > Operand stack:
> > > > > >    1.0
> > > > > > Execution stack:
> > > > > >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > > > > > Dictionary stack:
> > > > > >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > > > > > Current allocation mode is local
> > > > > > Current file position is 19030
> > > > > > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > > > > > 
> > > > > > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > > > > > 
> > > > > > $ gs ps_symbols.ps
> > > > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > > > see the file COPYING for details.
> > > > > > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > > > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > > > > > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > > > > > >>showpage, press <return> to continue<<
> > > > > > 
> > > > > > Tatsuro
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > gnuplot-beta mailing list
> > > > > > gnu...@li...
> > > > > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > gnuplot-beta mailing list
> > > > gnu...@li...
> > > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!idKMZV_2_Z7sJbrlulcygodVbisihJwDPL6BOkPj6BbPTWYonmPpgkWJM4Wj3ekBKyOwlC3_gAlViyui2QRc$  
> > > > 
> > > 
> > > 
> > 
> > 
> > -- 
> > Ethan A Merritt
> > Biomolecular Structure Center,  K-428 Health Sciences Bldg
> > MS 357742,   University of Washington, Seattle 98195-7742
> > 
> > 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

Hi.

I'm looking at patching gplt_x11.c to work better with existing X window
IDs. This is coming along. In the process I'm discovering other things.
One is that for some reason the gnuplot x11 backend is explicitly
ignoring the SIGINT and SIGTSTP signals:

  https://github.com/gnuplot/gnuplot/blob/e9779f00507187653b8fb317f492833af5eaaa9a/src/gplt_x11.c#L5270

This results in zombie gplt_x11 processes. During normal operation
usually this doesn't happen, but I do periodically see gplt_x11 zombies.
While testing my new patches, I see these all the time, however. Does
anybody know why we're ignoring these signals? Version control says that
we were doing this from day 0 more or less.

Removing those two signal() calls doesn't obviously break anything, and
results in the zombie processes going away. Can/should we get rid of
those?

Thanks

Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

[Tatsuro M. <tma...@ya...>]

I reverted the commit 1955b4151ceef88de644bc89c39477a3d537ad13 and ps_symbols.ps was generated correctly.

The commit 1955b4151ceef88de644bc89c39477a3d537ad13 may be inadequate and should be improved.
I will file a bug report.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "gnu...@li..." <gnu...@li...>; "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2022/09/01 木 15:44
> Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> 
> 
> On Wednesday, 31 August 2022 23:14:07 PDT Tatsuro MATSUOKA wrote:
> > I have tested on Ubuntu-22.04 (WLS2) and Cygwin.
> > For both: ps_symbols.ps (5.5 )  1631 lines.
> > 
> > The phenomenon is windows specific and something is changed in the postscript terminal on gnuplot-5.5 on windows.
> 
> I see only one Windows-specific change to post.trm in the past year or so:
> 
> commit 1955b4151ceef88de644bc89c39477a3d537ad13
> Author: Bastian Maerkisch <bma...@we...>
> Date:   Sat Feb 12 19:00:42 2022 +0100
> 
>     pslatex, pstex: make sure we don't mix style of line endings
>     
>     (La)TeX chokes on mixing different line endings of Postscript data. This
>     would be the case for a git checkout on Windows. We now make sure that we
>     consistently use CR only line endings on Windows/DOS/OS/2.
> 
> > Is it better to file as a bug report?
> 
> That would be fine.
> But before the bug report you could try reverting the above commit
> to see if that fixes it.
> 
> 	Ethan
> 
> 
> 
> 
> > 
> > Tatsuro
> >  
> > 
> > > ----- Original Message -----
> > > 
> > > From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> > > To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> > > Date: 2022/09/01 木 14:49
> > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > 
> > > 
> > > Thank you for your reply.
> > > 
> > > For me,two files are different
> > > ps_symbols.ps (5.4.4 )  1631 lines 
> > > ps_symbols.ps (5.5 )  1248 lines 
> > > 
> > > I have tested only on windows.
> > > I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.
> > > 
> > > Tatsuro
> > > 
> > > > ----- Original Message -----
> > > > 
> > > > From: "Ethan A Merritt" <me...@uw...>
> > > > To: "gnu...@li..." <gnu...@li...>
> > > > Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> > > > Date: 2022/09/01 木 14:34
> > > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > > 
> > > > 
> > > > On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > > > > I cannot judge whether this is a bug or not.
> > > > > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> > > > 
> > > > I cannot reproduce this.
> > > > I get identical postscript output files using either gnuplot 5.4 or 5.5,
> > > > differing only in the Creator and CreationDate header lines.
> > > > 
> > > > 	Ethan
> > > > 
> > > > 
> > > > > 
> > > > > $ gs ps_symbols.ps
> > > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > > see the file COPYING for details.
> > > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > > > > Error: /undefined in UL
> > > > > Operand stack:
> > > > >    1.0
> > > > > Execution stack:
> > > > >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > > > > Dictionary stack:
> > > > >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > > > > Current allocation mode is local
> > > > > Current file position is 19030
> > > > > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > > > > 
> > > > > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > > > > 
> > > > > $ gs ps_symbols.ps
> > > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > > see the file COPYING for details.
> > > > > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > > > > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > > > > >>showpage, press <return> to continue<<
> > > > > 
> > > > > Tatsuro
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > gnuplot-beta mailing list
> > > > > gnu...@li...
> > > > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!idKMZV_2_Z7sJbrlulcygodVbisihJwDPL6BOkPj6BbPTWYonmPpgkWJM4Wj3ekBKyOwlC3_gAlViyui2QRc$  
> > > 
> > 
> > 
> 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center,  K-428 Health Sciences Bldg
> MS 357742,   University of Washington, Seattle 98195-7742
> 
> 

Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

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

On Wednesday, 31 August 2022 23:14:07 PDT Tatsuro MATSUOKA wrote:
> I have tested on Ubuntu-22.04 (WLS2) and Cygwin.
> For both: ps_symbols.ps (5.5 )  1631 lines.
> 
> The phenomenon is windows specific and something is changed in the postscript terminal on gnuplot-5.5 on windows.

I see only one Windows-specific change to post.trm in the past year or so:

commit 1955b4151ceef88de644bc89c39477a3d537ad13
Author: Bastian Maerkisch <bma...@we...>
Date:   Sat Feb 12 19:00:42 2022 +0100

    pslatex, pstex: make sure we don't mix style of line endings
    
    (La)TeX chokes on mixing different line endings of Postscript data. This
    would be the case for a git checkout on Windows. We now make sure that we
    consistently use CR only line endings on Windows/DOS/OS/2.

> Is it better to file as a bug report?

That would be fine.
But before the bug report you could try reverting the above commit
to see if that fixes it.

	Ethan




> 
> Tatsuro
>  
> 
> > ----- Original Message -----
> > 
> > From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> > To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> > Date: 2022/09/01 木 14:49
> > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > 
> > 
> > Thank you for your reply.
> > 
> > For me,two files are different
> > ps_symbols.ps (5.4.4 )  1631 lines 
> > ps_symbols.ps (5.5 )  1248 lines 
> > 
> > I have tested only on windows.
> > I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.
> > 
> > Tatsuro
> > 
> > > ----- Original Message -----
> > > 
> > > From: "Ethan A Merritt" <me...@uw...>
> > > To: "gnu...@li..." <gnu...@li...>
> > > Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> > > Date: 2022/09/01 木 14:34
> > > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > > 
> > > 
> > > On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > > > I cannot judge whether this is a bug or not.
> > > > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> > > 
> > > I cannot reproduce this.
> > > I get identical postscript output files using either gnuplot 5.4 or 5.5,
> > > differing only in the Creator and CreationDate header lines.
> > > 
> > > 	Ethan
> > > 
> > > 
> > > > 
> > > > $ gs ps_symbols.ps
> > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > see the file COPYING for details.
> > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > > > Error: /undefined in UL
> > > > Operand stack:
> > > >    1.0
> > > > Execution stack:
> > > >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > > > Dictionary stack:
> > > >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > > > Current allocation mode is local
> > > > Current file position is 19030
> > > > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > > > 
> > > > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > > > 
> > > > $ gs ps_symbols.ps
> > > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > > see the file COPYING for details.
> > > > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > > > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > > > >>showpage, press <return> to continue<<
> > > > 
> > > > Tatsuro
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > gnuplot-beta mailing list
> > > > gnu...@li...
> > > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!idKMZV_2_Z7sJbrlulcygodVbisihJwDPL6BOkPj6BbPTWYonmPpgkWJM4Wj3ekBKyOwlC3_gAlViyui2QRc$  
> > 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

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

On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> I cannot judge whether this is a bug or not.
> The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.

I cannot reproduce this.
I get identical postscript output files using either gnuplot 5.4 or 5.5,
differing only in the Creator and CreationDate header lines.

	Ethan


> 
> $ gs ps_symbols.ps
> GPL Ghostscript 9.55.0 (2021-09-27)
> Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> see the file COPYING for details.
> Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> Error: /undefined in UL
> Operand stack:
>    1.0
> Execution stack:
>    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> Dictionary stack:
>    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> Current allocation mode is local
> Current file position is 19030
> GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> 
> ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> 
> $ gs ps_symbols.ps
> GPL Ghostscript 9.55.0 (2021-09-27)
> Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> see the file COPYING for details.
> Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> >>showpage, press <return> to continue<<
> 
> Tatsuro
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> 

Re: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

[Tatsuro M. <tma...@ya...>]

I have tested on Ubuntu-22.04 (WLS2) and Cygwin.
For both: ps_symbols.ps (5.5 )  1631 lines.

The phenomenon is windows specific and something is changed in the postscript terminal on gnuplot-5.5 on windows.
Is it better to file as a bug report?

Tatsuro
 

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> Date: 2022/09/01 木 14:49
> Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> 
> 
> Thank you for your reply.
> 
> For me,two files are different
> ps_symbols.ps (5.4.4 )  1631 lines 
> ps_symbols.ps (5.5 )  1248 lines 
> 
> I have tested only on windows.
> I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.
> 
> Tatsuro
> 
> > ----- Original Message -----
> > 
> > From: "Ethan A Merritt" <me...@uw...>
> > To: "gnu...@li..." <gnu...@li...>
> > Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> > Date: 2022/09/01 木 14:34
> > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > 
> > 
> > On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > > I cannot judge whether this is a bug or not.
> > > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> > 
> > I cannot reproduce this.
> > I get identical postscript output files using either gnuplot 5.4 or 5.5,
> > differing only in the Creator and CreationDate header lines.
> > 
> > 	Ethan
> > 
> > 
> > > 
> > > $ gs ps_symbols.ps
> > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > see the file COPYING for details.
> > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > > Error: /undefined in UL
> > > Operand stack:
> > >    1.0
> > > Execution stack:
> > >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > > Dictionary stack:
> > >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > > Current allocation mode is local
> > > Current file position is 19030
> > > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > > 
> > > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > > 
> > > $ gs ps_symbols.ps
> > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > see the file COPYING for details.
> > > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > > >>showpage, press <return> to continue<<
> > > 
> > > Tatsuro
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

[Tatsuro M. <tma...@ya...>]

Thank you for your reply.

For me,two files are different
ps_symbols.ps (5.4.4 )  1631 lines 
ps_symbols.ps (5.5 )  1248 lines 

I have tested only on windows.
I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "gnu...@li..." <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2022/09/01 木 14:34
> Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> 
> 
> On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > I cannot judge whether this is a bug or not.
> > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> 
> I cannot reproduce this.
> I get identical postscript output files using either gnuplot 5.4 or 5.5,
> differing only in the Creator and CreationDate header lines.
> 
> 	Ethan
> 
> 
> > 
> > $ gs ps_symbols.ps
> > GPL Ghostscript 9.55.0 (2021-09-27)
> > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > see the file COPYING for details.
> > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > Error: /undefined in UL
> > Operand stack:
> >    1.0
> > Execution stack:
> >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > Dictionary stack:
> >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > Current allocation mode is local
> > Current file position is 19030
> > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > 
> > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > 
> > $ gs ps_symbols.ps
> > GPL Ghostscript 9.55.0 (2021-09-27)
> > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > see the file COPYING for details.
> > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > >>showpage, press <return> to continue<<
> > 
> > Tatsuro
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > 
> 
> 
> 
> 

ps_symbols.ps procuded using gnuplot-5.5 is invalid

[Tatsuro M. <tma...@ya...>]

I cannot judge whether this is a bug or not.
The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.

$ gs ps_symbols.ps
GPL Ghostscript 9.55.0 (2021-09-27)
Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
Error: /undefined in UL
Operand stack:
   1.0
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
Current allocation mode is local
Current file position is 19030
GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1

ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.

$ gs ps_symbols.ps
GPL Ghostscript 9.55.0 (2021-09-27)
Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
>>showpage, press <return> to continue<<

Tatsuro

Re: gnuplot latex documentation error with (MiKTeX 22.7)

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

On Thursday, 25 August 2022 21:06:33 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> I have a situation to make gnuplot.pdf on windows (MinGW-w64) with MiKTeX 22.7
> 
> ************************************************************************************************.
>   :
>   :
> LaTeX Warning: Reference `set label' on page 70 undefined on input line 6036.
> 
> 
> LaTeX Warning: Reference `hypertext' on page 70 undefined on input line 6059.
> 
> 
> 
> pdfTeX warning: pdflatex.exe (file ./figure_labels2.pdf): PDF inclusion: found
> PDF version <1.7>, but at most version <1.5> allowed
> 
> ! LaTeX Error: Unicode character ∙ (U+2219)
>                not set up for use with LaTeX.


U+2219 is \bullet in LaTeX.
Perhaps the unicode support package included with MiKTeX 22.7 is incomplete?
The file .../texmf-dist/tex/generic/unicode-data/UnicodeData.txt
should contain a line

2219;BULLET OPERATOR;Sm;0;ON;;;;;N;;;;;


As a work-around, this thread 
  https://tex.stackexchange.com/questions/598469/package-inputenc-error-unicode-character-%E2%88%99-u2219

suggests it may be possible to say
    \usepackage{newunicodechar}
    \newunicodechar{^^^^2219}{\cdot}

but I think it would be better to figure out what is wrong with the MiKTeX
installation.


	Ethan

gnuplot latex documentation error with (MiKTeX 22.7)

[Tatsuro M. <tma...@ya...>]

I have a situation to make gnuplot.pdf on windows (MinGW-w64) with MiKTeX 22.7

************************************************************************************************.
  :
  :
LaTeX Warning: Reference `set label' on page 70 undefined on input line 6036.


LaTeX Warning: Reference `hypertext' on page 70 undefined on input line 6059.



pdfTeX warning: pdflatex.exe (file ./figure_labels2.pdf): PDF inclusion: found
PDF version <1.7>, but at most version <1.5> allowed

! LaTeX Error: Unicode character ∙ (U+2219)
               not set up for use with LaTeX.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

******************************************************************************************************


I have not met such error on MiKTeX 22.3.

Any suggestions are welcome.

Tatsuro 

Re: xyplane tics too large with orthogonal splot views

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

On Thursday, 11 August 2022 15:06:40 PDT Dima Kogan wrote:
> Hi. I just made some 3D plots from an orthogonal side view (set view
> 90,0). This has special-case logic in gnuplot to treat it like a 2D plot
> in some ways. It looks like the logic isn't completely right, though,
> and the tics on the xy plane end up larger than they should. And the
> tics appear on both sides of the plane, which isn't obviously right. Can
> somebody please take a look?

I think there is not an easy fix for this.
The original code assumes that the vertical axis is "y" just
about everywhere, and calculates various scale factors using
that assumption. A complete fix would have to handle all the
various possible projections and rotations as special cases
wherever it makes a difference.

Possibly the odd placement of mirrored tics can be repaired,
or tic mirroring ignored in this projection.  I'll look at that.

But the tic length - meh. You can fix it for any given plot using
"set xtic scale" so IMHO it's not a high priority to rework all the code
just for that. But if someone is inspired to do so, fine - go for it.
I suggest that you file this as a bug report on the tracker so it
isn't forgotten.

	Ethan

Re: xyplane tics too large with orthogonal splot views

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

On Thursday, 11 August 2022 18:10:44 PDT Dima Kogan wrote:

> > It's also a bit weird that "set xyplane at <foo>" is actually
> > acting as if it were "set xrange [ low : high + foo ].
> > I worry that setting <foo> to anything other than zero may
> > have other unexpected side effects.
> > 
> >         Ethan

> Something is being strangely proportional. If
> I make the same plot, but do so interactively, (without "set terminal"
> or "set output"), then I see the length of the tics change as I
> interactively move the xyplane (shift+button2+drag up/down).

That would be an example of "unexpected side effects" :-)

I think the tic lengths are changing due to the changing aspect ratio
of the plot.  I see the same effect just by changing the window size
by dragging a corner with the mouse.

There does seem to be a difference between gnuplot 4 and gnuplot 5,
so the change/bug/quirk/whatever probably dates back a few years.
I'll have a look but I'm working on other things right now.

	Ethan

Re: xyplane tics too large with orthogonal splot views

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

Thanks for looking, Ethan. Something is being strangely proportional. If
I make the same plot, but do so interactively, (without "set terminal"
or "set output"), then I see the length of the tics change as I
interactively move the xyplane (shift+button2+drag up/down).

Re: xyplane tics too large with orthogonal splot views

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

On Thursday, 11 August 2022 15:06:40 PDT Dima Kogan wrote:
> Hi. I just made some 3D plots from an orthogonal side view (set view
> 90,0). This has special-case logic in gnuplot to treat it like a 2D plot
> in some ways. It looks like the logic isn't completely right, though,
> and the tics on the xy plane end up larger than they should. And the
> tics appear on both sides of the plane, which isn't obviously right. Can
> somebody please take a look?

I'll have a look.

Meanwhile as you probably found, you can "fix" the output with

    set xtics nomirror scale 0.5

It's also a bit weird that "set xyplane at <foo>" is actually
acting as if it were "set xrange [ low : high + foo ].
I worry that setting <foo> to anything other than zero may
have other unexpected side effects.

	Ethan

> This happens with the latest gnuplot in git.
> 
> The script appears below, and the result is attached.
> 
> Thanks!
> 
> 
> 
> set view 90,0
> set xyplane at -0.1
> set xtics 0.5
> set ytics 0.5
> set view equal xyz
> set xlabel "x"
> set ylabel "y"
> set zlabel "z"
> 
> set terminal png size 600,1000
> set output "/tmp/tics-too-big.png"
> splot '-'   using 1:2:3:4:5:6 notitle with vectors , \
>       '-'   using 1:2:3:4:5:6 notitle with vectors
> 0.0 0.0 0.0 0.3333335701378377 0.0 0.0
> 0.0 0.0 0.0 0.0 0.3333335701378377 0.0
> 0.0 0.0 0.0 0.0 0.0 0.6666671402756754
> e
> -1.487915757943345 -0.8842424394390623 4.822904587742955 0.3295936234755228 -0.004829189464130801 0.04955795873753832
> -1.487915757943345 -0.8842424394390623 4.822904587742955 0.0054208354243061585 0.33327029824180776 -0.0035765673425567357
> -1.487915757943345 -0.8842424394390623 4.822904587742955 -0.09899347227801636 0.008684749800146774 0.6592191922953985
> e
> set output
> 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

xyplane tics too large with orthogonal splot views

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

Hi. I just made some 3D plots from an orthogonal side view (set view
90,0). This has special-case logic in gnuplot to treat it like a 2D plot
in some ways. It looks like the logic isn't completely right, though,
and the tics on the xy plane end up larger than they should. And the
tics appear on both sides of the plane, which isn't obviously right. Can
somebody please take a look?

This happens with the latest gnuplot in git.

The script appears below, and the result is attached.

Thanks!



set view 90,0
set xyplane at -0.1
set xtics 0.5
set ytics 0.5
set view equal xyz
set xlabel "x"
set ylabel "y"
set zlabel "z"

set terminal png size 600,1000
set output "/tmp/tics-too-big.png"
splot '-'   using 1:2:3:4:5:6 notitle with vectors , \
      '-'   using 1:2:3:4:5:6 notitle with vectors
0.0 0.0 0.0 0.3333335701378377 0.0 0.0
0.0 0.0 0.0 0.0 0.3333335701378377 0.0
0.0 0.0 0.0 0.0 0.0 0.6666671402756754
e
-1.487915757943345 -0.8842424394390623 4.822904587742955 0.3295936234755228 -0.004829189464130801 0.04955795873753832
-1.487915757943345 -0.8842424394390623 4.822904587742955 0.0054208354243061585 0.33327029824180776 -0.0035765673425567357
-1.487915757943345 -0.8842424394390623 4.822904587742955 -0.09899347227801636 0.008684749800146774 0.6592191922953985
e
set output

x11 plotting into an existing window behaves badly if the window doesn't (yet) exist

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

Hi. I'm using the x11 terminal to plot into an existing window:

  set terminal x11 window XID

Overall it works really well. I'm seeing an issue when the requested
window doesn't exist: gnuplot simply ignores the request, and pops up a
new X window, as usual. This is never what the user intends, I think.

A less made-up scenario is what I actually encountered when trying to
use this feature: I made a new window, and asked gnuplot to plot into
it. This didn't work because my new target window hasn't been created
YET.

Trying to debug this, I added some more diagnostics to gplt_x11.c
(attached; these should be good-enough to merge). I see that the
failing sequence is:

- in pr_window() gplt_x11.c calls XGetWindowAttributes() on the
  requested window. This is the first time gnuplot does anything with
  the requested window

- If the window already exists, this succeeds, and we continue, happily.
  If not, the error handler is invoked instead. Here's the diagnostic
  output produced with DEBUG:

    gplt_x11.c:1655 psp->external_container = 0x2400005
    gplt_x11.c:6679 (pr_window) 
    gplt_x11.c:6683 was asked to plot externally...
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_GetWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:7269   -> Added an element to FIFO queue.
    gplt_x11.c:6692 making plot window
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_CreateWindow minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:7269   -> Added an element to FIFO queue.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeProperty minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeProperty minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeProperty minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:6795 term_number is -1
    gplt_x11.c:4778 Cursors reset
    gplt_x11.c:7321 Processed element in remove FIFO queue.
    gplt_x11.c:1209 Delete plot -1
    gplt_x11.c:1233 Destroy window 0x36000fe
    gplt_x11.c:7321 Processed element in remove FIFO queue.
    gplt_x11.c:7063 psp->external_container = None
    ...

  The line numbers are off, since I had some extra diagnostic code. We
  do see that X errors are received for every request that touches the
  not-yet-existing window, the error handler does some complex thing I
  don't yet understand, and eventually we psp->external_container =
  None, i.e. we give up on plotting to the requested window, and create
  a new one, as usual.


Would it not make more sense for gplt_x11 to retry
XGetWindowAttributes() call until the requested window exists? I'm not
familiar with Xlib error handling, and this doesn't look completely
trivial, so I wanted to ask here first. Anybody here have experience
with Xlib, and suggestions on the "right" way to implement that?

Thanks

Re: Gnuplot Version 5.4.4 Release

[Tatsuro M. <tma...@ya...>]

I have uploaded windows binary packages.

Tatsuro

> ----- Original Message -----
> Date: 2022/07/18 月 12:32
> Subject: Gnuplot Version 5.4.4 Release
> 
> 
> Release 5.4.4 is now available for download from SourceForge
> 
> Thanks to everyone who tested prior release and to everyone who sent
> bug reports or suggested changes.
> 
> Source tarball
> 
>     https://sf.net/projects/gnuplot/files/gnuplot/5.4.4/gnuplot-5.4.4.tar.gz
> 
> Release notes (10-Jul-2022)
> 
> This release contains bug fixes and a few changes back-ported from the
> development version.  Probably the most noticeable is modification to
> make page layout of 3D plots after "set view map; splot ..." more like
> the corresponding page layout of 2D plots, including display of x2 and y2
> axis labels.
> 
> Changes in 5.4.4
> ================
> * NEW plots can use arrow styles that specify "lc rgb variable" 
> * CHANGE make page layout of "set view map; splot" more like that of "plot"
> *        - honor "set rmargin" and "set tmargin" Bug #2484
> *        - display x2label and y2label Bug #2484
> *        - revised placement of color box Bug #2484
> *        - reconcile linked axis data and tic ranges Bug #2483
> *        - apply "set key invert" to splot Bug #2381
> * CHANGE cairo terminals: increase internal oversampling factor Bugs #2499 #2369
> * CHANGE fig: restore terminal option "pointsmax <N>" Bug #2509
> * CHANGE always add a space between items in a "print" command Bug #2488
> * CHANGE consistent ordering of input columns for "plot ... ps var pt var" Bug #2524
> * CHANGE gnuplot -c script.gp A B -C ... will pass A B -C ... without interpretation
> * CHANGE stricter error checks when promoting string to numeric value Bug #2527
> * CHANGE report GPVAL_TERM_XMIN and friends as floating point values
> * FIX handle combination of axis properties logscale + autoscale + reverse Bug #2347
> * FIX mis-handled arguments at start-up of "gnuplot -c script arg1 ..." Bug #2493
> * FIX windows: redirected output of printf() Bug #2490
> * FIX allow variable point style and point type in plot "with yerrorbars"
> * FIX plots "with labels point pt variable" were off-by-one in choosing point type
> * FIX contour "with labels" from binary data
> * FIX x/y fractional coordinate mouse readout for nonlinear axes Bug #2526
> * FIX Support combination of "set surface explicit; set hidden3d" Bug #2521
> 
> 
>         happy gnuplotting,
> 
>                 Ethan 
> 
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>