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

ECCN Request

[Balick, R. C [U. (ES) <Reb...@ng...>]

Hello,

I would like to request the ECCN (Export Control Classification Number) for GNUplot 5.0. It should be a 5 or 6 digit code of numbers and letters such as EAR99 or 5D002. I need this in order to maintain the software downloaded. Thank you!

Re: Histograms that include empty bins

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

On Monday, 26 July 2021 22:56:59 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > Not sure I understand what kind of plot you are aiming for, and you
> > don't give an example of the real data format
> 
> Hi. The little example was a close approximation to what I want. If it
> helps, here's what I REALLY want. I have a data file with sorted
> timestamps, one per line, that record the time when something failed. I
> want to make a plot of "failures per hour", as a function of time. So I
> want to consolidate the data into bins, but instead of "with boxes", I'd
> like to plot "with lines". Currently this doesn't work the way I want
> because any hour blocks that have 0 failures in them don't get a y=0
> point in the line plot.
> 
> 
> 
> > but how about initializing all the bins to zero?
> >
> > # initialize a bunch of bins to zero
> >   set print $BINS
> >   do for [i=1:10] { print i, 0.0 }
> >   unset print
> > # add the real data to those same bins
> >   set table $BINS append
> >   plot DATA using (histbin($1)):(1.0) with table
> >   unset table
> > # now plot the data as before
> >   plot $BINS using 1:2 smooth freq with boxes fill solid border lt -1
> 
> That's interesting. Unfortunately I'm using feedgnuplot for this, which
> cannot currently use tables. It expects a single "plot" command to do
> all the work. Suggestions?

Append a boatload of zero-value timepoints to your data file?
Maybe  plot '<cat REALDATA ZEROS' using ...

Teach feedgnuplot to do something more than it does now?

Use another interface that doesn't have that limitation?
For instance, have you tried the gaston front-end to gnuplot in julia?
    https://mbaz.github.io/Gaston.jl/v0.10.0/

	Ethan

Re: Histograms that include empty bins

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

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

> Not sure I understand what kind of plot you are aiming for, and you
> don't give an example of the real data format

Hi. The little example was a close approximation to what I want. If it
helps, here's what I REALLY want. I have a data file with sorted
timestamps, one per line, that record the time when something failed. I
want to make a plot of "failures per hour", as a function of time. So I
want to consolidate the data into bins, but instead of "with boxes", I'd
like to plot "with lines". Currently this doesn't work the way I want
because any hour blocks that have 0 failures in them don't get a y=0
point in the line plot.



> but how about initializing all the bins to zero?
>
> # initialize a bunch of bins to zero
>   set print $BINS
>   do for [i=1:10] { print i, 0.0 }
>   unset print
> # add the real data to those same bins
>   set table $BINS append
>   plot DATA using (histbin($1)):(1.0) with table
>   unset table
> # now plot the data as before
>   plot $BINS using 1:2 smooth freq with boxes fill solid border lt -1

That's interesting. Unfortunately I'm using feedgnuplot for this, which
cannot currently use tables. It expects a single "plot" command to do
all the work. Suggestions?

Re: Histograms that include empty bins

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

Not sure I understand what kind of plot you are aiming for,
and you don't give an example of the real data format,
but how about initializing all the bins to zero?

# initialize a bunch of bins to zero
  set print $BINS
  do for [i=1:10] { print i, 0.0 }
  unset print
# add the real data to those same bins
  set table $BINS append
  plot DATA using (histbin($1)):(1.0) with table
  unset table
# now plot the data as before
  plot $BINS using 1:2 smooth freq with boxes fill solid border lt -1

	Ethan


On Sunday, 25 July 2021 17:20:13 PDT Dima Kogan wrote:
> Hi. I just tried to patch gnuplot to do something that I thought would
> be simple, but it actually looks like it wouldn't be. Can I get a
> suggestion?
> 
> I'm making a simple histogram. This works as expected:
> 
> set boxwidth 1
> histbin(x) = floor(0.5 + x)
> plot '-' using (histbin($1)):(1.0) smooth freq with boxes fill solid border lt -1 
> 1
> 2
> 4
> 5
> e
> 
> Here I get 4 bins of width 1, centered at 1, 2, 4, 5. Notably, there's a
> gap: there's no bin centered at 3. Internally, gnuplot omits this bin
> entirely, instead of producing an empty bin. This matters if you make a
> this plot "with linespoints" instead of "with boxes". I want a plot that
> includes the point (3,0), but the current code doesn't include that
> point. Is there an obvious way to include that?
> 
> Thanks!

Histograms that include empty bins

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

Hi. I just tried to patch gnuplot to do something that I thought would
be simple, but it actually looks like it wouldn't be. Can I get a
suggestion?

I'm making a simple histogram. This works as expected:

set boxwidth 1
histbin(x) = floor(0.5 + x)
plot '-' using (histbin($1)):(1.0) smooth freq with boxes fill solid border lt -1 
1
2
4
5
e

Here I get 4 bins of width 1, centered at 1, 2, 4, 5. Notably, there's a
gap: there's no bin centered at 3. Internally, gnuplot omits this bin
entirely, instead of producing an empty bin. This matters if you make a
this plot "with linespoints" instead of "with boxes". I want a plot that
includes the point (3,0), but the current code doesn't include that
point. Is there an obvious way to include that?

Thanks!

Aw: What is the state of the Windows piping bug ?

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

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Ethan,</div>

<div>&nbsp;</div>

<div>The Windows builds for 5.4.2 are just that - builds from the 5.4.2 source release.</div>

<div>&nbsp;</div>

<div>The piping bug #2412 has been confirmed fixed by the commit you mentioned.</div>

<div>It was introduced by an attempt to fix bug #2204 and I am waiting for feedback</div>

<div>on this one. We should only release 5.4.3 with this issue confirmed, too.</div>

<div>
<div>&nbsp;</div>

<div>
<div>In any case the Windows binary already now resolves some serious platform-specific</div>

<div>bugs, including a crash due to initialization errors, see #2223, #2227, #2286,</div>

<div>#2402.&nbsp; So the advisory on not using it at all is too strong in my opinion.</div>

<div>&nbsp;</div>
</div>

<div>Btw. please note that the &quot;-os2&quot; file is for OS/2, eComStation, ArcaOS and &quot;_dj&quot;</div>

<div>is a DOS (32bit) version.</div>

<div>
<div><br/>
&nbsp; Bastian</div>

<div>&nbsp;</div>

<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Donnerstag, 15. Juli 2021 um 06:30 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Ethan A Merritt&quot; &lt;me...@uw...&gt;<br/>
<b>An:</b>&nbsp;gnu...@li...<br/>
<b>Cc:</b>&nbsp;&quot;Bastian M&auml;rkisch&quot; &lt;bma...@we...&gt;<br/>
<b>Betreff:</b>&nbsp;What is the state of the Windows piping bug ?</div>

<div name="quoted-content"><!--p, li {
}
-->
<div style="font-family: &quot;DejaVu Sans&quot;;font-size: 10.0pt;font-weight: 400;font-style: normal;">
<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">Bastian:</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">Your fix for the WIndows piping bug went into the stable branch on 10 July.</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">This was after the nominal release date for version 5.4.2</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">The Windows binaries on SourceForge are timestamped that same day.</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">gp542-os2-emx.zip 2021-07-11 3.4 MB</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">gp541-win64-mingw.7z 2021-07-10 28.8 MB</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">gp542_dj.zip 2021-07-10 4.0 MB</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">gp542-win64-mingw.exe 2021-07-10 31.7 MB</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">Is the fix included in these binaries or not?</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">If it is then the README on the download site should say so</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">(right now it advises not to use the Windows binaries)</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">If it is not - should we put out a quick version 5.4.3 for Windows?</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">Commit a501a67a</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;"><span style="font-family: monospace;color: rgb(0,0,0);background-color: rgb(255,255,255);">Author: Bastian Maerkisch &lt;bma...@we...&gt; </span><br/>
<span style="font-family: monospace;">Date: &nbsp;&nbsp;Sat Jul 10 20:41:40 2021 +0200<br/>
<br/>
&nbsp;&nbsp;&nbsp;Fix handling Window messages for input from a pipe<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<br/>
&nbsp;&nbsp;&nbsp;As pointed out in bug report #2412, MsgWaitForMultipleObjects() does not work<br/>
&nbsp;&nbsp;&nbsp;as expected if the input comes from a pipe. This reverts 651af6267b<br/>
&nbsp;&nbsp;&nbsp;&quot;Wait for pipe events without additional thread&quot;, which aimed at speeding-up<br/>
&nbsp;&nbsp;&nbsp;piped input, Instead of recreating the input thread for every single<br/>
&nbsp;&nbsp;&nbsp;character, we now keep the thread alive and signal an event object on new<br/>
&nbsp;&nbsp;&nbsp;input. This should still be much faster.<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<br/>
&nbsp;&nbsp;&nbsp;Bugs #2412 and #2204</span><br/>
&nbsp;</p>
</div>
</div>
</div>
</div>
</div></div></body></html>

What is the state of the Windows piping bug ?

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

Bastian:

Your fix for the WIndows piping bug went into the stable branch on 10 July.

This was after the nominal release date for version 5.4.2

The Windows binaries on SourceForge are timestamped that same day.

gp542-os2-emx.zip	2021-07-11	3.4 MB
gp541-win64-mingw.7z	2021-07-10	28.8 MB
gp542_dj.zip   	2021-07-10	4.0 MB
gp542-win64-mingw.exe	2021-07-10	31.7 MB

Is the fix included in these binaries or not?

If it is then the README on the download site should say so
(right now it advises not to use the Windows binaries)

If it is not - should we put out a quick version 5.4.3 for Windows?

Commit a501a67a
Author: Bastian Maerkisch <bma...@we...> 

Re: problems of gnuplot 5.4 with pipes in Windows

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

I don't know anything about this code, so feel free to tell me 
I'm misdirected but...

In ConsoleGetch(), _get_osfhandle is used on stdin. MS cautions 
[1] this might not be valid, and ConsoleGetch() does not check 
h!=-2. GetStdHandle or CreateFile [2] might be a better choice?

MsgWaitForMultipleObjects is described as a "very tricky" API 
[3]. Although nothing else seems to fall afoul of [4]'s 
recommendations, I don't know why WaitForSingleObject isn't used 
instead, or just plain ReadFile. MS notes fread locks out other
threads [5]. Is the writer ever another thread?

As an incidental note, pipes created from cmd like in bug 2412 
appear to be anonymous pipes and those do not support 
asynchronous read/write. [6] I don't think this matters here, 
but I mention it in case anybody thought they were going to get 
clever.

[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/get-osfhandle?view=msvc-160
[2] https://docs.microsoft.com/en-us/windows/console/console-handles
[3] https://docs.microsoft.com/en-us/archive/blogs/larryosterman/things-you-shouldnt-do-part-4-msgwaitformultipleobjects-is-a-very-tricky-api
[4] https://devblogs.microsoft.com/oldnewthing/20050217-00/?p=36423
[5] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fread?view=msvc-160
[6] https://docs.microsoft.com/en-us/windows/win32/ipc/anonymous-pipe-operations

(Dropped CCs because this isn't about the Python problem anymore.)

Ethan A Merritt <me...@uw...> said (on 2021/06/19):
> ...
> My understanding is that this is a known problem when combining specifically
> gnuplot version 5.4 and Windows version 10.
> 
> Issue tracker here
>    https://sourceforge.net/p/gnuplot/bugs/2412/

Re: problems of gnuplot 5.4 when pipng commands from python

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

You are operating on Windows 10?
I had hoped you would get a response from someone more familiar with
Windows than I am, but it seems rather quiet here lately.

My understanding is that this is a known problem when combining specifically
gnuplot version 5.4 and Windows version 10.

Issue tracker here
   https://sourceforge.net/p/gnuplot/bugs/2412/

There is a suggestion there that reverting commit 651af626
may fix the problem, or at least return it to the same behavior
as gnuplot 5.2.   If you are able to build gnuplot from the
git source and confirm that reverting that commit works, that
would be very useful information.

    best,

	Ethan


On Thursday, 17 June 2021 02:48:15 PDT hua...@si... wrote:
> Dear developers of gnuplot,First I want to thank you very much for developing such powerful tool.
> I use gnuplot 5.4 in my own python program to check the results of some searching process.
> the related code is like follows:
> from subprocess import *  gnuplot= Popen(r"C:/Progra~1/gnuplot/bin/wgnuplot_pipes.exe", stdin = PIPE, stderr=PIPE,stdout=PIPE)  gnuplot.stdin.write(b"set terminal windows \n")  gnuplot.stdin.write(b"plot(sin(x)) \n")  gnuplot.stdin.flush()
> input('Press the Return key to quit: ')  #pause gnuplot.stdin.close()  
> In the above code, after Popen, the main gnuplot window is successfully launched.However, there is no any response for the next instructions, and nothing has happened.My Python version is 3.8.5
> So how to solve the problem ?
> Best regards,Wendong 
> 

problems of gnuplot 5.4 when pipng commands from python

[<hua...@si...>]

Dear developers of gnuplot,First I want to thank you very much for developing such powerful tool.
I use gnuplot 5.4 in my own python program to check the results of some searching process.
the related code is like follows:
from subprocess import *  gnuplot= Popen(r"C:/Progra~1/gnuplot/bin/wgnuplot_pipes.exe", stdin = PIPE, stderr=PIPE,stdout=PIPE)  gnuplot.stdin.write(b"set terminal windows \n")  gnuplot.stdin.write(b"plot(sin(x)) \n")  gnuplot.stdin.flush()
input('Press the Return key to quit: ')  #pause gnuplot.stdin.close()  
In the above code, after Popen, the main gnuplot window is successfully launched.However, there is no any response for the next instructions, and nothing has happened.My Python version is 3.8.5
So how to solve the problem ?
Best regards,Wendong 

Re: libcerf function voigt_hwhm not suitable for external use

[Joachim W. <j.w...@fz...>]

Dear Ethan,

thanks for responding four orders of magnitude faster than me.

No, there were no test cases in your initial mail. I would
be very interest to see my implementation fail. My newly
added tests vary gamma/sigma from 1e-180 to 1e+180. Are the
problematic values sparse in this interval? Or do the
problems only arise for sigma != 1?

Anyway, it will be much better to have an algorithm that
is proven to converge. Thanks for sharing your code. I could
adapt it easily, but I am even more glad to accept your offer
that you submit the necessary changes to libcerf as a merge
request. I will then release 1.16 within days.

Best regards, Joachim

Re: libcerf function voigt_hwhm not suitable for external use

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

Joachim:

It is good to hear that you are looking into this.
It was pretty easy to trigger the non-convergence error from gnuplot;
did I not send test cases?  
Testing these functions in gnuplot is really easy because you can
sample any desired domain in the complex plane (or in this case [sigma,gamma])
with a single command and plot the result.  Glitches or non-convergence or
outright errors and crashes show up immediately.
Sample plots using functions from libcerf are shown here:
    http://gnuplot.sourceforge.net/demo_5.5/cerf.html

Some time after I sent you that original note, I went ahead and re-implemented
the function directly in gnuplot.  I attach the code to this mail.
Note that it uses a different optimization algorithm (regula falsi)
that unlike the code in libcerf at that time is guaranteed to converge.

This code is from the file libcerf.c in the gnuplot project git repository.
You are welcome to adapt it for inclusion in libcerf, or I would be
willing to do so myself and contribute it.

	best regards,

		Ethan


On Thursday, 10 June 2021 07:18:03 PDT Joachim Wuttke wrote:
> Dear Ethan,
> 
> thank you very much for the kind mail you wrote me more than a year ago.
> 
> Today, finally, I looked into the issue.  I wrote a new test that computes
> voigt_hwhm for 100'000 different ratios gamma/sigma.  As expected, the Newton
> algorithm did not fail a single time.  The deviation of the final result from
> the initial estimate is always smaller then 1E-2.  The cases I had guarded
> with messages to stderr and an exit statement will never happen.  Therefore
> I converted them to assert statements.  These improvements are available
> in the freshly released v1.15.
> 
> Sorry for not answering earlier.
> 
> Kind greetings, Joachim
> 
> 
> 
> On 25/02/2020 20.03, Ethan A Merritt wrote:
> > In response to a gnuplot feature request, I added a wrapper in
> > gnuplot to find the width of the Voight profile by calling libcerf function
> > voigt_hwhm().
> > 
> > However on further evaluation this has turned out to be problematic.
> > The current libcerf source for this function deals badly with out-of-range
> > input.  It prints to stderr (problematic by itself) and then either
> > - returns an incorrect value
> > - calls exit(-1)
> > 
> > A call to exit() from a library routine is almost never a good thing to 
> do,
> > since it prevents error-handling and possible recovery by the calling
> > program.  Limiting error reporting to a message on stderr also prevents
> > detection and recovery by the calling program.
> > 
> > I suggest that it would be preferable to return NaN whenever the
> > input is out of range or the function does not converge.
> > 
> > Alternatively libcerf could provide an error-check routine or status variable,
> > but then you would run into issues of thread-safety and so on.
> > 
> > I am hoping that the libcerf function can be improved in a subsequent
> > version, but for now I will consider implementing equivalent code
> > directly in gnuplot.
> > 
> > 	Ethan
> > 
> > 
> 
> 


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

Re: libcerf function voigt_hwhm not suitable for external use

[Joachim W. <j.w...@fz...>]

Dear Ethan,

thank you very much for the kind mail you wrote me more than a year ago.

Today, finally, I looked into the issue.  I wrote a new test that computes
voigt_hwhm for 100'000 different ratios gamma/sigma.  As expected, the Newton
algorithm did not fail a single time.  The deviation of the final result from
the initial estimate is always smaller then 1E-2.  The cases I had guarded
with messages to stderr and an exit statement will never happen.  Therefore
I converted them to assert statements.  These improvements are available
in the freshly released v1.15.

Sorry for not answering earlier.

Kind greetings, Joachim



On 25/02/2020 20.03, Ethan A Merritt wrote:
> In response to a gnuplot feature request, I added a wrapper in
> gnuplot to find the width of the Voight profile by calling libcerf function
> voigt_hwhm().
> 
> However on further evaluation this has turned out to be problematic.
> The current libcerf source for this function deals badly with out-of-range
> input.  It prints to stderr (problematic by itself) and then either
> - returns an incorrect value
> - calls exit(-1)
> 
> A call to exit() from a library routine is almost never a good thing to 
do,
> since it prevents error-handling and possible recovery by the calling
> program.  Limiting error reporting to a message on stderr also prevents
> detection and recovery by the calling program.
> 
> I suggest that it would be preferable to return NaN whenever the
> input is out of range or the function does not converge.
> 
> Alternatively libcerf could provide an error-check routine or status variable,
> but then you would run into issues of thread-safety and so on.
> 
> I am hoping that the libcerf function can be improved in a subsequent
> version, but for now I will consider implementing equivalent code
> directly in gnuplot.
> 
> 	Ethan
> 
> 

gnuplot 5.4.2 Release

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

Release 5.4.2 is now out

Source tarball

    https://sf.net/projects/gnuplot/files/gnuplot/5.4.2/gnuplot-5.4.2.tar.gz

Release Notes

    http://gnuplot.sourceforge.net/ReleaseNotes_5_4_2.html

The release contains lots of little fixes.  The biggest one from my
perspective is that the single-threaded version of the wxt terminal
is now usable again under linux.  Also fixed is the problem that
"set term qt persist" could leave zombie gnuplot_qt processes.

On the other hand, there are known issues under Windows 10
    Piped command input does not work reliably (Bugs #2204 #2412)
    Export to EMF file from toolbar may not work
So Windows 10 users may want to stick with version 5.2 for now.
When these problems are fixed I figure to put out a version 5.4.3
immediately that may be relevant only to Windows users.

	happy gnuplotting,

		Ethan 

gnuplot 5.4.2 Release

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

Release 5.4.2 is now out

Source tarball

    https://sf.net/projects/gnuplot/files/gnuplot/5.4.2/gnuplot-5.4.2.tar.gz

Release Notes

    http://gnuplot.sourceforge.net/ReleaseNotes_5_4_2.html

The release contains lots of little fixes.  The biggest one from my
perspective is that the single-threaded version of the wxt terminal
is now usable again under linux.  Also fixed is the problem that
"set term qt persist" could leave zombie gnuplot_qt processes.

On the other hand, there are known issues under Windows 10
    Piped command input does not work reliably (Bugs #2204 #2412)
    Export to EMF file from toolbar may not work
So Windows 10 users may want to stick with version 5.2 for now.
When these problems are fixed I figure to put out a version 5.4.3
immediately that may be relevant only to Windows users.

	happy gnuplotting,

		Ethan 

Testing version of gnuplot 5.4.2 release

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

I have placed a tarball of version 5.4.2 SourceForge for testing:

https://sf.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.2beta.tar.gz

Known issue:
    Piped command input does not work reliably under Windows 10

Have I described this problem correctly?  

The discussion under Bug #2412 suggests that it can be fixed
by reverting commit 651af6267b0270a71c6e0c0c2345f2c01a68eea6
Would it be possible to do that revert for the 5.4.2 release
and note that the problem (slow response) in Bug #2204 still
needs a permanent fix?


	cheers,
		Ethan 

Re: y2tics issue

[m s. <mw...@us...>]

On 3/30/2021 8:18 PM, Ethan A Merritt wrote:
> On Tuesday, 30 March 2021 16:35:36 PDT m sutton wrote:
>> Hi all,
>>
>> Here is the script
>>
>> set yrange [-2:2]
>> set y2tics -1,1,1
>> set y2tics add ("top" 1,"middle" 0, "bottom" -1)
>>
>> plot sin(x)
>>
>>
>>
>>
>>
>> The commands place the desired y2axis tics in V5.2.8 and
>>        earlier.  However, I don't get any y2axis tics in V5.4.1 with
>>        either the X11 or QT terminals.  I do get this warning message
>>        "warning: y2 axis range undefined or overflow".
>>
>> show y2range yields:
>>
>>
>> set y2range [ * : * ] noreverse writeback  # (currently
>>          [1.00000e+308:-1.00000e+308] )
> You have no data or plot displayed to y2, and no range set,
> so the error message is correct.

This construct has worked for a long time.  I just wanted to make sure
something wasn't broken as I upgrade my plotting scripts to V5.4.

>
>> What am I missing?
> Either
>      plot sin(x) axes x1y2       # y1 axis is not used at all; autoscale y2
> or
>      set link y2                 # y2 replicates range and scaling from y1
>      plot sin(x)
>
>
My initial thought was to explicitly set y2range, but the set link y2
looks to be more flexible.

Thanks,

MikeS

Re: y2tics issue

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

On Tuesday, 30 March 2021 16:35:36 PDT m sutton wrote:
> Hi all,
> 
> Here is the script
> 
> set yrange [-2:2]
> set y2tics -1,1,1
> set y2tics add ("top" 1,"middle" 0, "bottom" -1)
> 
> plot sin(x)
> 
> 
> 
> 
> 
> The commands place the desired y2axis tics in V5.2.8 and
>       earlier.  However, I don't get any y2axis tics in V5.4.1 with
>       either the X11 or QT terminals.  I do get this warning message
>       "warning: y2 axis range undefined or overflow".
> 
> show y2range yields:
> 
> 
> set y2range [ * : * ] noreverse writeback  # (currently
>         [1.00000e+308:-1.00000e+308] )

You have no data or plot displayed to y2, and no range set,
so the error message is correct.
 
> What am I missing?

Either 
    plot sin(x) axes x1y2       # y1 axis is not used at all; autoscale y2
or
    set link y2                 # y2 replicates range and scaling from y1
    plot sin(x)


	Ethan
> 
> Regards,
> 
> MikeS
> 
> 
> 


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

y2tics issue

[m s. <mw...@us...>]

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi all,</p>
    <p>Here is the script</p>
    <blockquote>
      <p><font face="Courier New, Courier, monospace">set yrange [-2:2]<br>
          set y2tics -1,1,1<br>
          set y2tics add ("top" 1,"middle" 0, "bottom" -1)<br>
          <br>
          plot sin(x)<br>
        </font></p>
    </blockquote>
    <p><br>
    </p>
    <p>The commands place the desired y2axis tics in V5.2.8 and
      earlier.  However, I don't get any y2axis tics in V5.4.1 with
      either the X11 or QT terminals.  I do get this warning message
      "warning: y2 axis range undefined or overflow".</p>
    show y2range yields:<br>
    <blockquote>
      <p>set y2range [ * : * ] noreverse writeback  # (currently
        [1.00000e+308:-1.00000e+308] )</p>
    </blockquote>
    <p>What am I missing?</p>
    <p>Regards,</p>
    <p>MikeS</p>
    <p><br>
    </p>
  </body>
</html>

Re: gnuplot for macOS 11 + M1

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

On Thu, 25 Mar 2021, Mojca Miklavec wrote:

> On Wed, 24 Mar 2021 at 00:42, Allin Cottrell wrote:
>>
>> Just wondering: has anyone produced a Mac package of gnuplot
>> targetting OS 11 ("Big Sur") with M1 processor?
>
> There is a package inside package managers (for example in MacPorts, I
> guess it's present in others as well), but that probably doesn't
> count?
> (There might be some issues with wx, but I need to check.)

There are issues with wx. I've built wxWidgets 3.0.5 for arm64, but 
I had to drop the dataObject module because it calls on QuickTime 
APIs, which are removed in macOS 11. And that means that I had to 
hack the gnuplot wxterm code to disable copy-to-clipboard, which 
depends on dataObject. There may be a way of performing surgery on 
dataObject but I haven't attempted that yet.

So I now have an arm64 build of gnuplot 5.4.1 with wx, but I don't 
have access to an M1 Mac so I don't know yet if it actually works.

Allin Cottrell

Re: gnuplot for macOS 11 + M1

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

On Wednesday, 24 March 2021 22:48:34 PDT Mojca Miklavec wrote:
> On Wed, 24 Mar 2021 at 00:42, Allin Cottrell wrote:
> >
> > Just wondering: has anyone produced a Mac package of gnuplot
> > targetting OS 11 ("Big Sur") with M1 processor?
> 
> There is a package inside package managers (for example in MacPorts, I
> guess it's present in others as well), but that probably doesn't
> count?
> (There might be some issues with wx, but I need to check.)
> 
> I tried to create a nice standalone .app years ago, but the fact that
> this requires the terminal to start makes it somewhat annoying for
> bundling.
> (I would find it much easier to bundle it if there was some wx or
> qt-based simplistic terminal available as well.)

Not sure I understand.

You mean run you would like to run gnuplot from, e.g., qterminal
instead of xterm or whatever terminal emulator you have now?
I think it might even be possible to have "set term qt widget <id>"
direct the plot output to a tab of qterminal, but I don't have any
idea how to determine what the widget id would be.

If svg output is acceptable, you can definitely do this using
domterm and telling gnuplot "set term domterm".  For that matter
there's a qt version of domterm and I have used it to run gnuplot
with output back to the window it is running in.
So yeah, it's possible.

	Ethan

> I know there are workarounds, but I never found the existing bundle
> particularly friendly to use, so I keep using the packager where it's
> also a lot easier to keep the software up to date.
> 
> Mojca
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


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

Re: gnuplot for macOS 11 + M1

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

On Wed, 24 Mar 2021 at 00:42, Allin Cottrell wrote:
>
> Just wondering: has anyone produced a Mac package of gnuplot
> targetting OS 11 ("Big Sur") with M1 processor?

There is a package inside package managers (for example in MacPorts, I
guess it's present in others as well), but that probably doesn't
count?
(There might be some issues with wx, but I need to check.)

I tried to create a nice standalone .app years ago, but the fact that
this requires the terminal to start makes it somewhat annoying for
bundling.
(I would find it much easier to bundle it if there was some wx or
qt-based simplistic terminal available as well.)
I know there are workarounds, but I never found the existing bundle
particularly friendly to use, so I keep using the packager where it's
also a lot easier to keep the software up to date.

Mojca

gnuplot for macOS 11 + M1

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

Just wondering: has anyone produced a Mac package of gnuplot 
targetting OS 11 ("Big Sur") with M1 processor?

I have need of such, but would be glad to piggy-back if there's 
something already available. If not, I'll see what I can come up 
with.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: Qt terminal size settings

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

On Tuesday, 2 March 2021 15:36:12 PST m sutton wrote:
> On 2/24/2021 11:59 PM, Ethan A Merritt wrote:
> > On Wednesday, 24 February 2021 18:50:51 PST m sutton wrote:
> >> Hi All,
> >>
> >> I have used the X11 terminal forever.  I'm looking to use the Qt
> >> terminal with my switch to version 5.4.
> >>
> >> One thing I can't seem to do is set the default plot window size. With
> >> X11 you could do this through the Xresource mechanism.
> >>
> >> I can set it with the 'set term qt' command, but I would like to be able
> >> to set in the Qt settings dialog.  Then it could be saved with the settings.

> > I do this by setting the environmental variable GNUTERM
> > in my login profile:
> >
> >      setenv GNUTERM "qt size 700,440 font 'ArnoPro,12'"
> >
> > 	Ethan
> 
> I guess I didn't realize the GNUTERM could contain terminal options. 
> Until now I never had the need to have options in GNUTERM.
> 
> 
> >
> >> I also noticed that the 'set term qt' command doesn't support a
> >> rounded/norounded option for line drawing.  This can only be done via
> >> the Qt settings dialog.
> >>
> >> So here is my idea.  Add window width and height inputs to the Qt
> >> settings dialog to set a default terminal size. Add rounded/norounded
> >> (aka butt) option to the 'set term qt' command.

> Any thoughts on extending the 'set term qt' to have options like
> rounded/norounded and antialias on/off capability?  I would really like
> to set these on the fly without my users having to open the settings dialog.

Only that it would be harder than you might think.  Remember that there
are two separate programs involved.  Command line input goes to gnuplot
but the display is being managed by gnuplot_qt, which looks at the 
saved settings in ~/.config/gnuplot_qtrc and changes made via the dialog.

	Ethan   

Re: Qt terminal size settings

[m s. <mw...@us...>]

On 2/24/2021 11:59 PM, Ethan A Merritt wrote:
> On Wednesday, 24 February 2021 18:50:51 PST m sutton wrote:
>> Hi All,
>>
>> I have used the X11 terminal forever.  I'm looking to use the Qt
>> terminal with my switch to version 5.4.
>>
>> One thing I can't seem to do is set the default plot window size. With
>> X11 you could do this through the Xresource mechanism.
>>
>> I can set it with the 'set term qt' command, but I would like to be able
>> to set in the Qt settings dialog.  Then it could be saved with the settings.
> I do this by setting the environmental variable GNUTERM
> in my login profile:
>
>      setenv GNUTERM "qt size 700,440 font 'ArnoPro,12'"
>
> 	Ethan

I guess I didn't realize the GNUTERM could contain terminal options. 
Until now I never had the need to have options in GNUTERM.


>
>> I also noticed that the 'set term qt' command doesn't support a
>> rounded/norounded option for line drawing.  This can only be done via
>> the Qt settings dialog.
>>
>> So here is my idea.  Add window width and height inputs to the Qt
>> settings dialog to set a default terminal size. Add rounded/norounded
>> (aka butt) option to the 'set term qt' command.
Any thoughts on extending the 'set term qt' to have options like
rounded/norounded and antialias on/off capability?  I would really like
to set these on the fly without my users having to open the settings dialog.

MikeS