gnuplot-info Mailing List for gnuplot (Page 7)

Hi Norwid,

On 15/04/2024 13:29, Norwid Behrnd via 
gnuplot-info wrote:
> the "tiles" are equidistant along (x,y) and the color levels appear to me
> symmetric (like an axis C_\infty in molecular symmetry / point groups,
> perpendicular to the drawing plane) around the central tile with an offset,
> i.e. its centre is at (0.5,0.5) instead of exactly (0,0) you prefer.  I do
> not know how to shift the array of tiles to account for this.

Can't do that in Gnuplot, AFAIU. You get either 
4-corners average or one of the corners. You'd 
have to shift gridlines and labels instead.

> notice `set samples 8 ; set isosamples 8` is a rather "lucky combination" as
> e.g., `set samples 9 ; set isosamples 9` or `set samples 7 ; set isosamples 7`
> distort the symmetry of this intensity map which can be misleading.

That combination wasn't 'lucky' in the sense of 
'well guessed'.

I wanted just what's on screen (now), i.e. 
coloured-squares visualisation of discrete 
Gaussian distribution in 2d, centered on (0,0), 
with squares' centers representing gridlines.

Like for representing digital low pass filtering 
of rasters.

The problem is (is it a bug? a feature?) that 
'samples' setting if used by itself (without 
'isosamples') produces *asymmetrical* picture 
along X and Y axii, which shouldn't be the case, 
as whatever value 'isosamples' was set to, it 
should be (?) used for both axii.

Just guessing, looks like a case of 
non-propagation of generalised values to 
non-generalised ones in the program source.

Thank you for that 'contourfill' snippet, looks 
interesting. But for my ongoing projects I'll 
stick with what I know. :)

-Yury

Hello Yury,

in your approach 

> I have to use BOTH `samples` and `isosamples`, 
> set to the same value. The following produces 
> just what was intended:
> ```
> set terminal x11 ;
> set size square.
> set xrange [-3:4]; set yrange [-3:4];
> set samples 8 ; set isosamples 8
> sigma = 2.0;
> f(x,y) = (1/(2*pi*sigma**2)) * 
> exp(-(x*x+y*y)/(2*sigma**2)) ;
> set grid
> set pm3d map corners2color c1;.
> splot f(x,y)
> ```

the "tiles" are equidistant along (x,y) and the color levels appear to me
symmetric (like an axis C_\infty in molecular symmetry / point groups,
perpendicular to the drawing plane) around the central tile with an offset,
i.e. its centre is at (0.5,0.5) instead of exactly (0,0) you prefer.  I do
not know how to shift the array of tiles to account for this.  In addition, I
notice `set samples 8 ; set isosamples 8` is a rather "lucky combination" as
e.g., `set samples 9 ; set isosamples 9` or `set samples 7 ; set isosamples 7`
distort the symmetry of this intensity map which can be misleading.

Previously, my suggest was to increase the levels of `samples` / `isosamples`
to yield an offset no longer significant for the visual analysis of the 3D map.
Meanwhile, I read newly released gnuplot 6 provides an automatic `counterfill`
with a better visualization of the local extreme around (0,0) in the
projection worth to try as an alternative approach: 

```
set terminal x11 ;
set terminal qt;
set size square
set xrange [-3:4]; set yrange [-3:4];
set samples 100 ; set isosamples 100
sigma = 2.0;
f(x,y) = (1/(2*pi*sigma**2)) * exp(-(x*x+y*y)/(2*sigma**2)) ;
set grid

set contourfill auto 10
splot f(x,y) with contourfill
# set view map; replot  # uncomment for the static 2D projection
```

Credit for the inspiration is due to Lee Philips' [Gnuplot 6 comes with
pie](https://lwn.net/Articles/961003/) published by February 9, 2024.

Norwid

Greetings,

Thanks  for Gnuplot.  I've been using it to graph various sensor
readings for some years now.  From time to time, it becomes useful to
make modifications and between the documentation, various examples, and
trial-and-error the results look nice in addition to being functional.

My question is how would I set X-Range to be the time from 00:00:00 to
23:59:59 on the current date?  Specifically, I would like the X-axis to
range from midnight to midnight for the current date.

I can't hard code it in to Gnuplot since, obviously, the date changes
every day.  Also since the data to be graphed comes in at different
times during the day, using it provides an inconsistent X-Range which
changes as the hours go by.  So that can't be used either.

One way seems to be to use system() to call the date(1) utility twice
and storing output in variables.  This is seen in lines 25 through 27 of
the script below.

Perhaps there is a better way without needing to use the system() call?

/Lars

PS.  The file x.txt has three tab-delimited columns. e.g.

2024-04-14      10:40:00        20.375
2024-04-14      10:50:00        20.375
2024-04-14      11:00:00        20.437
2024-04-14      11:10:00        20.5
2024-04-14      11:20:00        20.5


--

#!/usr/bin/gnuplot

set output "./x.png"
set term png size 400, 400
set term png background "#fff0f0f0"
set termoption font "Liberation Sans, 12"

set datafile separator tab

set xdata time
set timefmt "%Y-%m-%d\t%H:%M:%S"
set xtics format "%H" font "Liberation Sans, 11"
set xtics timedate

# draw line at zero
set arrow 1 from graph 0, first 0.0 to graph 1, \
         first 0.0 nohead lw 2 lc rgb "#e0e0e0" back

set ytics format "%0.0f°" font "Liberation Sans, 11"
set yrange [*<-5:30<*] writeback
# set yrange restore

xs=system("date -d '00:00:00' +'%F\t%T'")
xe=system("date -d '23:59:59' +'%F\t%T'")
set xrange [xs:xe]

set xlabel "Time" font "Liberation Sans, 14"
set ylabel "Degrees Celsius" font "Liberation Sans, 14"

set title "Since Midnight" font "Liberation Sans, 16"

# probe 1, change color when at or below 15°C
rgb3(b) = (b <= 15 ? 32767 : 65280 )

plot \
         "./x.txt" \
         using 1:3:(rgb3($3)) \
                 with line lw 1 lc rgb variable \
                 title ""

Hello,

Lot of the links on gnuplot.info are broken, and give from 404 to empty pages.

Namely documentation link is broken which kind of defeats the purpose...

http://gnuplot.info/docs_5.5/gnuplot5.html  ->  http://www.gnuplot.info/docs_5.5/gnuplot5.html

Peter

Hello Norwid,

On 11/04/2024 11:47, Norwid Behrnd via 
gnuplot-info wrote:
> Option i) retains the pm3d map and offers a smoother visual representation by
> increase of the `isosample` parametre alone

Thank you and everybody for your replies. You 
gave me an idea how to 'put a plaster on it', at 
least.

I have to use BOTH `samples` and `isosamples`, 
set to the same value. The following produces 
just what was intended:
```
set terminal x11 ;
set size square.
set xrange [-3:4]; set yrange [-3:4];
set samples 8 ; set isosamples 8
sigma = 2.0;
f(x,y) = (1/(2*pi*sigma**2)) * 
exp(-(x*x+y*y)/(2*sigma**2)) ;
set grid
set pm3d map corners2color c1;.
splot f(x,y)
```
However, my question stands.
When using my original example (with `samples` 
only), there's an unexpected (?) asymmetry in 
the output, which Dr. Lippert confirms.
AFAIU there shouldn't be.

-Yury

Hello,

not sure if I understood you well, I see two approaches for the task ahead.
However in both instances, because it is about the visualization of a grid --
regardless if the visualization retains the 3D perspective, or is a 2D
projection / a map -- I would use `isosamples` instead of `samples`.

Option i) retains the pm3d map and offers a smoother visual representation by
increase of the `isosample` parametre alone

```
set terminal x11;
set size square;
set xrange [-3:3]; set yrange [-3:3];
set isosamples 100, 100;  # number of isosample points along (x,y)

sigma = 2.0;
f(x,y) = (1/(2*pi*sigma**2)) * exp(-(x**2+y**2)/(2*sigma**2));
set grid;
set pm3d map corners2color c1;
splot f(x,y);
```

Option ii) presumes you seek a presentation with contour lines, can both afford
gnuplot defines the corresponding levels, and the absence of the pm3d map:

```
set terminal x11;
set size square;
set xrange [-3:3]; set yrange [-3:3];
set isosamples 100; # number of isosample points along x equals the along y

sigma = 2.0;
f(x,y) = (1/(2*pi*sigma**2)) * exp(-(x**2+y**2)/(2*sigma**2));
set grid;
set contour base;
unset surface;  # no need to display the grid by `isosample`
set view map;
splot f(x,y);
```

Both approaches were tested with gnuplot 6.0.0 as provided by Linux Debian
13/trixie.

Norwid

Hi,

Can't test with other versions right now, but 
with 5.4.3 and 6.0.0 on linux I'm having an 
issue plotting this:

set terminal x11 ;
set size square
set xrange [-3:3]; set yrange [-3:3];
set samples 7
sigma = 2.0;
f(x,y) = (1/(2*pi*sigma**2)) * 
exp(-(x**2+y**2)/(2*sigma**2)) ;
set grid
set pm3d map corners2color c1;
splot \
   f(x,y) \

AFAIU, this should construct radial-symmetric 
color map with grid lines separating color changes.

What it makes instead on my system is a colormap 
with an arbitrary number of samples for Y axis. 
I see at least 8 color changes along Y axis, and 
generally color rectangles are smaller along Y 
axis, while grid squares are okay.

Is this a known or documented behaviour?

-Yury

By the way, it could be safe to add

set output

before set terminal X11 to be certain that the png file is closed.

Le 7/04/24 à 12:52, igor via gnuplot-info a écrit :
> Thank you! I will try.
>
> You know, when I tried to run from the terminal
> gnuplot -p Well.plt
> everything went well.
>
> But usually I'm running this from the Fortran code, and there are only 
> three lines regarding Gnuplot plot (and these three lines are the same 
> in all my programs except for the names of data file and plt file):
>
> At the very beginning:
>     character(len=*), parameter :: OUT_FILE = 'Well.txt'   ! Output file.
>     character(len=*), parameter :: PLT_FILE = 'Well.plt'   ! Gnuplot 
> file.
> The very last line:
>     call execute_command_line('gnuplot -p ' // PLT_FILE)
>
> That's the only lines there which have any relations to Gnuplot. 
> Fortran program writes data file and after that calls Gnuplot -
> and I'm again getting aforementioned error! More than that, in some 
> cases I'm getting plot from 0 to 2.8, in some cases - from 0 to 2.5, 
> for this particular data from 0 to 1.9 while always data file has a 
> range from 0 to 3.12.
>
> So the reason looks like not in the Gnuplot itself - but may be you 
> have any idea what it could be???
>
> *SORRY! I'VE FOUND THE REASON!*
>
> As always, it's very simple.
> The line to write data file is:
>     write (fu, *) Pi*m/180.0, m !.....
>
> But this time I've forgot to put this line:
>     close (fu)
> before calling Gnuplot.
>
> With this line everything is perfect.
> Sorry, sorry, sorry.
>
> Thank you very much for your attention!
> Igor
>
> 07.04.2024 13:06, theozh via gnuplot-info пишет:
>>
>> I cannot reproduce your issue.
>> Maybe you have set a certain xrange earlier?
>>
>> Either insert a line "reset session" at the beginning
>> or
>> change the plot command to
>>
>> plot [*:*][*:*] "Well.txt"  using 1:2 with lines
>>
>> Am 07.04.2024 um 11:40 schrieb igor:
>>> Sorry, that's not the issue.
>>>
>>> The issue is that the X range in the data is from 0 to 3.12, but in 
>>> the plot it is much shorter (about from 0 to 1.9)!
>>> Please don't take into account these additional columns, there was 
>>> the same story when they existed - I've mentioned that I've 
>>> simplified everything what I could.
>>>
>>> Igor
>>>
>>> 07.04.2024 12:25, theozh via gnuplot-info пишет:
>>>> Your data file has only 2 columns.
>>>> So, how should gnuplot be able to plot columns 4 and 5?
>>>>
>>>>
>>>> _______________________________________________
>>>> gnuplot-info mailing list
>>>> gnu...@li...
>>>> Membership management via: 
>>>> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>>
>>
>> _______________________________________________
>> gnuplot-info mailing list
>> gnu...@li...
>> Membership management via: 
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-info

Thank you! I will try.

You know, when I tried to run from the terminal
gnuplot -p Well.plt
everything went well.

But usually I'm running this from the Fortran code, and there are only 
three lines regarding Gnuplot plot (and these three lines are the same 
in all my programs except for the names of data file and plt file):

At the very beginning:
     character(len=*), parameter :: OUT_FILE = 'Well.txt'   ! Output file.
     character(len=*), parameter :: PLT_FILE = 'Well.plt'   ! Gnuplot file.
The very last line:
     call execute_command_line('gnuplot -p ' // PLT_FILE)

That's the only lines there which have any relations to Gnuplot. Fortran 
program writes data file and after that calls Gnuplot -
and I'm again getting aforementioned error! More than that, in some 
cases I'm getting plot from 0 to 2.8, in some cases - from 0 to 2.5, for 
this particular data from 0 to 1.9 while always data file has a range 
from 0 to 3.12.

So the reason looks like not in the Gnuplot itself - but may be you have 
any idea what it could be???

*SORRY! I'VE FOUND THE REASON!*

As always, it's very simple.
The line to write data file is:
     write (fu, *) Pi*m/180.0, m !.....

But this time I've forgot to put this line:
     close (fu)
before calling Gnuplot.

With this line everything is perfect.
Sorry, sorry, sorry.

Thank you very much for your attention!
Igor

07.04.2024 13:06, theozh via gnuplot-info пишет:
>
> I cannot reproduce your issue.
> Maybe you have set a certain xrange earlier?
>
> Either insert a line "reset session" at the beginning
> or
> change the plot command to
>
> plot [*:*][*:*] "Well.txt"  using 1:2 with lines
>
> Am 07.04.2024 um 11:40 schrieb igor:
>> Sorry, that's not the issue.
>>
>> The issue is that the X range in the data is from 0 to 3.12, but in 
>> the plot it is much shorter (about from 0 to 1.9)!
>> Please don't take into account these additional columns, there was 
>> the same story when they existed - I've mentioned that I've 
>> simplified everything what I could.
>>
>> Igor
>>
>> 07.04.2024 12:25, theozh via gnuplot-info пишет:
>>> Your data file has only 2 columns.
>>> So, how should gnuplot be able to plot columns 4 and 5?
>>>
>>>
>>> _______________________________________________
>>> gnuplot-info mailing list
>>> gnu...@li...
>>> Membership management via: 
>>> https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>
>
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-info

I cannot reproduce your issue.
Maybe you have set a certain xrange earlier?

Either insert a line "reset session" at the beginning
or
change the plot command to

plot [*:*][*:*] "Well.txt"  using 1:2 with lines

Am 07.04.2024 um 11:40 schrieb igor:
> Sorry, that's not the issue.
>
> The issue is that the X range in the data is from 0 to 3.12, but in the plot it is much shorter (about from 0 to 1.9)!
> Please don't take into account these additional columns, there was the same story when they existed - I've mentioned that I've simplified everything what I could.
>
> Igor
>
> 07.04.2024 12:25, theozh via gnuplot-info пишет:
>> Your data file has only 2 columns.
>> So, how should gnuplot be able to plot columns 4 and 5?
>>
>>
>> _______________________________________________
>> gnuplot-info mailing list
>> gnu...@li...
>> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-info

Your data file has only 2 columns.
So, how should gnuplot be able to plot columns 4 and 5?

Hello!

I`m working with gnuplot for rather long time and never had any problems 
which I wasn't able to solve.
But today I've realized that gnuplot plots only part of the file.
I've simplified everything to the very end - still same ploblem.
Here are typical results included.
Please help me!

Sincerely yours,
Igor

It seems that the gnuplot webpage, gnuplot.info, is unavailable at the 
moment.

Hopefully just a transient problem?


  Error 1001

Ray ID: 85b2646f2fee9930 • 2024-02-25 19:35:35 UTC


    DNS resolution error

For what it's worth: Gnuplot 6 made the homepage
of Linux Weekly News today:
	https://lwn.net/

The story itself is here:
	https://lwn.net/Articles/961003/

Best,

		Ph.

-- 

Philipp K. Janert
www.janert.me

On Tue, Feb 6, 2024 at 12:52 PM Robert Dodier <rob...@gm...>
wrote:

> On Sat, Feb 3, 2024 at 7:40 AM Mirko Vukovic <mir...@gm...>
> wrote:
>
> > I can shut down the process by sending the "exit" command.
> >
> > But I'd also like to send a signal (such as SIGTERM) to shut gnuplot
> down.
>
> Probably a cleaner and system independent way to tell gnuplot to shut
> down is just to close the socket through which commands are sent -- I
> don't know for sure, but I suspect that gnuplot will terminate if the
> socket is closed, since that is a widely used convention for
> organizing interprocess communications.
>
> Maxima (https://maxima.sourceforge.io) is a Common Lisp application
> and it has some code to work with gnuplot for plotting; see
> src/plot.lisp and src/gnuplot_def.lisp (I think those are the right
> file names) to get some ideas about how stuff was handled there.
>
>
Thanks Robert,

I looked at the Maxima source in the src/plot.lisp, and your suggestion
worked:

Doing - with apologies for non-lisp readers that the parenthesis may
confuse -

(close (ccl:external-process-input-stream process-handle))

closes the process.

`process-handle' is the structure returned by the command that launches
gnuplot: (ccl:run-program "gnuplot" ...)


Mirko

Hello gnuplot enthusiasts,

I have been using gnuplot for like 15 years to create timeseries charts for all kinds of timeseries data, fairly basic linegraphs (multiplot etc. but still simple) but also histograms. As this feature (timeseries histograms) is not available, or I am not aware of, I use a sort of workaround to emulate histograms. Attached is a sample graph and the gnuplot description (I call them .gpl files). They look nice but can but become very slow, when many instances are involved, many meaning more than 1 or 2 hundred and gnuplot execution times cat go up to 1 min on a M3 MacBook Pro.

The way it works to emulate the histogram mechanism is, it iterates over all instances, plotting the sum of all n instances including the n-th instance first (using boxes!), then overlays the sum of n-1 instances excluding the top instance, then n-2 and so on until all the instances are dealt with. For each timestamp in the data. It’s pretty obvious that this algorithm is not efficient when it comes to a large number of instances. Especially as I use boxes fill solid.

The data is sorted first, with instance 2 (CL3-K) being the “top” instance, that is having the highest sum of all values over all timestamps. The top instance “sits” on the x-axis, the instance with the lowest contribution sits on top of the histogram. The contribution of each instance to the overall total of all instances is provided in brackets, like [#1@24.06%] meaning rank #1 with 24.06 %. Just to be complete.

My question(s): (1) is there a built-in timeseries histogram feature available in gnuplot that would make my workaround obsolete? It should work with a fairly large number of timestamps in the data, like up to 2’000 with time resolution. Or (2) Can I implement a function that starts with sum (all instances) and then on each line subtracts the values of the current line? Or (3) any other idea? My expectation is a factor of 10 at least faster execution. Am I being unrealistic?

Here is my description for the 10 highest instances:

     timeseries using 1:(sum [col= 2:10] column(col)) t "CL1-A[#9@3.58%]" lc rgb "#2EFE2E" with boxes fill solid noborder, \
     timeseries using 1:(sum [col= 2:9] column(col)) t "CL2-A[#8@3.61%]" lc rgb "#64FE2E" with boxes fill solid noborder, \
     timeseries using 1:(sum [col= 2:8] column(col)) t "CL1-B[#7@3.95%]" lc rgb "#9AFE2E" with boxes fill solid noborder, \
     timeseries using 1:(sum [col= 2:7] column(col)) t "CL2-B[#6@3.95%]" lc rgb "#C8FE2E" with boxes fill solid noborder, \
     timeseries using 1:(sum [col= 2:6] column(col)) t "CL6-C[#5@3.95%]" lc rgb "#F7FE2E" with boxes fill solid noborder, \
     timeseries using 1:(sum [col= 2:5] column(col)) t "CL2-J[#4@8.66%]" lc rgb "#FACC2E" with boxes fill solid noborder, \
     timeseries using 1:(sum [col= 2:4] column(col)) t "CL1-J[#3@8.66%]" lc rgb "#FE9A2E" with boxes fill solid noborder, \
     timeseries using 1:(sum [col= 2:3] column(col)) t "CL4-K[#2@24.06%]" lc rgb "#FE642E" with boxes fill solid noborder, \
     timeseries using 1:(sum [col= 2:2] column(col)) t "CL3-K[#1@24.06%]" lc rgb "#FE2E2E" with boxes fill solid noborder

I am absolutely happy to share the mechanism how to create nice looking gnuplot timeseries charts if you would like to add them to the samples, as I think timeseries are an important use case and it should be unnecessary to invent the wheel over and over again.

If this is not the proper channel to ask for help for this kind of use case, please accept my apologies for bothering you.


Cheers,
Werner
_________________________________________________
Dr. Werner Lippert

Partner
peaq GmbH                                       Mobile +41 79 218 84 26
Neugutstrasse 12                                wer...@pe...
CH-8304 Wallisellen                                          www.peaq.ch
_________________________________________________
Get the most out of your Hitachi Storage Systems
With peaq IOportal, SAM4H, Crosscharging and Lifecycle Services

On Sat, Feb 3, 2024 at 7:40 AM Mirko Vukovic <mir...@gm...> wrote:

> I can shut down the process by sending the "exit" command.
>
> But I'd also like to send a signal (such as SIGTERM) to shut gnuplot down.

Probably a cleaner and system independent way to tell gnuplot to shut
down is just to close the socket through which commands are sent -- I
don't know for sure, but I suspect that gnuplot will terminate if the
socket is closed, since that is a widely used convention for
organizing interprocess communications.

Maxima (https://maxima.sourceforge.io) is a Common Lisp application
and it has some code to work with gnuplot for plotting; see
src/plot.lisp and src/gnuplot_def.lisp (I think those are the right
file names) to get some ideas about how stuff was handled there.

best,

Robert

Bottom line here: If you are using Windows then the UNIX signals 
mechanism is not available. msys2 may provide a UNIX-like shell, but 
ultimately it sits atop Windows. The fact that you cannot find a 
signals.h file is entirely predictable. There will not be one.

P.

On 06/02/2024 01:28, Mirko Vukovic wrote:
> Thanks for replying. My answers are below
>
> On Sun, Feb 4, 2024 at 10:20 AM Peter Rockett via gnuplot-info 
> <gnu...@li...> wrote:
>
>     Two questions:
>
>     1) Why do you want to send a SIGTERM to the process? Why isn't "exit"
>     (which you say works) good enough? The signal handler -- either the
>     default or an over-ridden version -- would typically invoke the
>     system
>     call that actually shuts down the process. Which is probably what the
>     gnuplot "exit" command does one way or another.
>
>
> You are correct that I really don't need to send SIGTERM. The reason 
> is my testsuite which is in 3 layers:
> 1. Lifecycle
> 2. IO streams
> 3. sending commands and reading results
>
> I wanted the first layer of the test suite (lifecycle) to be 
> independent of sending commands (last layer).
>
> I agree that this is somewhat of an overkill. But I was curious if it 
> could be done.
>
>     2) What OS are you using? Windows, for example, doesn't use signals -
>     they are a UNIX/Linux/MacOS(?) thing. I suspect sending a signal on
>     Windows will just be ignored, which is consistent with the
>     behaviour you
>     seem to be observing.
>
>
> I am on Windows 11 using gnuplot delivered via MSYS2. Since my 
> original post, I learned that I can use
> taskkill to terminate processes.
>
>
>     FWIW: The exact value of SIGTERM will be defined in a C header file
>     somewhere, probably "signals.h".
>
>
> I did not find that file, but I did not look terribly hard.
>
>
>     P.
>
>
> Thanks,
>
> Mirko

Thanks for replying. My answers are below

On Sun, Feb 4, 2024 at 10:20 AM Peter Rockett via gnuplot-info <
gnu...@li...> wrote:

> Two questions:
>
> 1) Why do you want to send a SIGTERM to the process? Why isn't "exit"
> (which you say works) good enough? The signal handler -- either the
> default or an over-ridden version -- would typically invoke the system
> call that actually shuts down the process. Which is probably what the
> gnuplot "exit" command does one way or another.
>

You are correct that I really don't need to send SIGTERM. The reason is my
testsuite which is in 3 layers:
1. Lifecycle
2. IO streams
3. sending commands and reading results

I wanted the first layer of the test suite (lifecycle) to be independent of
sending commands (last layer).

I agree that this is somewhat of an overkill. But I was curious if it could
be done.



> 2) What OS are you using? Windows, for example, doesn't use signals -
> they are a UNIX/Linux/MacOS(?) thing. I suspect sending a signal on
> Windows will just be ignored, which is consistent with the behaviour you
> seem to be observing.
>

I am on Windows 11 using gnuplot delivered via MSYS2. Since my original
post, I learned that I can use
taskkill to terminate processes.


>
> FWIW: The exact value of SIGTERM will be defined in a C header file
> somewhere, probably "signals.h".
>

I did not find that file, but I did not look terribly hard.


>
> P.
>

Thanks,

Mirko

Two questions:

1) Why do you want to send a SIGTERM to the process? Why isn't "exit" 
(which you say works) good enough? The signal handler -- either the 
default or an over-ridden version -- would typically invoke the system 
call that actually shuts down the process. Which is probably what the 
gnuplot "exit" command does one way or another.

2) What OS are you using? Windows, for example, doesn't use signals - 
they are a UNIX/Linux/MacOS(?) thing. I suspect sending a signal on 
Windows will just be ignored, which is consistent with the behaviour you 
seem to be observing.

FWIW: The exact value of SIGTERM will be defined in a C header file 
somewhere, probably "signals.h".

P.


On 03/02/2024 15:39, Mirko Vukovic wrote:
> Hello,
>
> I am writing an interface to gnuplot from common lisp (CL). The CL process
> calls gnuplot and sets up the input & output handles.
>
> I am able to start the gnuplot process, send commands, and fetch output
> (such as from "show version"). I can also generate plots.
>
> I can shut down the process by sending the "exit" command.
>
> But I'd also like to send a signal (such as SIGTERM) to shut gnuplot down.
>
> I tried this by sending the numeral 15 but that did not shut down the
> process.
>
> I searched the source code at a fork on github, found SIGTERM there, but
> not what value to use for it. Nor am I sure that SIGTERM would shut it down.
>
> Please note, that I am very new to this kind of communication with
> processes. I am possibly/likely misunderstanding how things are supposed to
> work. Maybe I am misunderstanding the purpose of SIGTERM, or don't have the
> correct code for it.
>
> Thanks,
>
> Mirko
>
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-info

Hello,

I am writing an interface to gnuplot from common lisp (CL). The CL process
calls gnuplot and sets up the input & output handles.

I am able to start the gnuplot process, send commands, and fetch output
(such as from "show version"). I can also generate plots.

I can shut down the process by sending the "exit" command.

But I'd also like to send a signal (such as SIGTERM) to shut gnuplot down.

I tried this by sending the numeral 15 but that did not shut down the
process.

I searched the source code at a fork on github, found SIGTERM there, but
not what value to use for it. Nor am I sure that SIGTERM would shut it down.

Please note, that I am very new to this kind of communication with
processes. I am possibly/likely misunderstanding how things are supposed to
work. Maybe I am misunderstanding the purpose of SIGTERM, or don't have the
correct code for it.

Thanks,

Mirko

Dear everyone,

I have noticed that an old bug concerning object border colors is back
in stable version 6.0.0. All object lines appear black while they have
the specified color in gnuplot version 5.4.8 (currently on MacPorts).
The error occurs when the linewidth is explicitely specified. A similar
(or even the same?) bug appeared in an earlier version of gnuplot 5.*,
but I do not remember which exact version it was.

Here is a sample script:

reset
set term x11 size 800,600

set object  1 circle at 0,0 size 3 fs empty border rgb '#ff0000' lw 2.0
set object  2 circle at 0,0 size 6 fs empty border rgb '#0000ff' lw 2.0

plot x

Best wishes,
Ingo

Hi all,

It appears that the A and AAAA DNS records for "www.gnuplot.info" are
pointing to completely different webservers.

The server that's answering IPv4 requests seems to be up-to-date, with
information about Gnuplot 6.0. It reports a Server header of "nginx", and a
Last-Modified date for the front page of December 29, 2023.

The server that's answering IPv6 requests, on the other hand, is
substantially out-of-date. The front page shows Gnuplot 5.4 as the latest
release, with a Last-Modified date of October 2, 2022. New pages such as
http://www.gnuplot.info/ReleaseNotes_6_0_0.html all return 404 errors. The
server also reports its version as Apache 2.2.17, which is from 2010.

This affects everyone with a working IPv6 setup. If it's not possible to
find and update the server that's serving the v6 traffic, then I think it
would be best to remove the AAAA DNS record so that everyone can see the
updated version of the site. v6 support isn't just limited to a few people
anymore.

Thanks,

Andrew

On Monday, 8 January 2024 10:49:48 PST Ingo Thies wrote:
> Dear Ethan,
> 
> I have just solved this by installing gsed and setting a symlink to sed.
> It seems that Apple's version of sed is outdated. Inserting LC_ALL=C in
> front of every sed command in the Makefile seems to be lot of work, so
> I'm happy about my solution, although it might be a bit dirty.

It would not be every sed command.  
This one command is special since it is the makefile rule that converts
from the Japanese documentation EUC-JP encoding to UTF-8.
Everywhere else is UTF-8 already.

	Ethan

> 
> Regards,
> Ingo
> 
> Am 08.01.24 um 19:44 schrieb Ethan Merritt:
> > On Monday, 8 January 2024 09:50:35 PST Ingo Thies via gnuplot-info wrote:
> >> Dear everyone,
> >>
> >> I get the following error when I try to compile gnuplot 6.0.0:
> >>
> >> trm ja/term/webp.trm ja/term/win.trm ja/term/wxt.trm ja/term/x11.trm
> >> ja/term/xlib.trm |\
> >>            LC_ALL=C sort -f -t':' -k2` ; do \
> >>         f=`echo $e |cut -d\: -f1` ; s=`echo $e | cut -d\: -f2` ;\
> >>         sed -n "/^[     ]*$s/,/^[     ]*END_HELP/p" $f ; \
> >>       done >allterm.tmp
> >> sed: RE error: illegal byte sequence
> >> ...
> >>
> >> My system is macos 13.6.3 Ventura, I am using a bash shell.
> > Please see Bug report #2676
> >      https://sourceforge.net/p/gnuplot/bugs/2676/
> >
> > Can you confirm that inserting "LC_ALL=C" immediately in front of "sed"
> > fixes this?
> >
> > 	Ethan
> >
> >> Regards,
> >> Ingo
> >>
> >>
> >>
> >> _______________________________________________
> >> gnuplot-info mailing list
> >> gnu...@li...
> >> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-info
> >>
> >
> >
> >
> 

Dear Ethan,

I have just solved this by installing gsed and setting a symlink to sed.
It seems that Apple's version of sed is outdated. Inserting LC_ALL=C in
front of every sed command in the Makefile seems to be lot of work, so
I'm happy about my solution, although it might be a bit dirty.

Regards,
Ingo

Am 08.01.24 um 19:44 schrieb Ethan Merritt:
> On Monday, 8 January 2024 09:50:35 PST Ingo Thies via gnuplot-info wrote:
>> Dear everyone,
>>
>> I get the following error when I try to compile gnuplot 6.0.0:
>>
>> trm ja/term/webp.trm ja/term/win.trm ja/term/wxt.trm ja/term/x11.trm
>> ja/term/xlib.trm |\
>>            LC_ALL=C sort -f -t':' -k2` ; do \
>>         f=`echo $e |cut -d\: -f1` ; s=`echo $e | cut -d\: -f2` ;\
>>         sed -n "/^[     ]*$s/,/^[     ]*END_HELP/p" $f ; \
>>       done >allterm.tmp
>> sed: RE error: illegal byte sequence
>> ...
>>
>> My system is macos 13.6.3 Ventura, I am using a bash shell.
> Please see Bug report #2676
>      https://sourceforge.net/p/gnuplot/bugs/2676/
>
> Can you confirm that inserting "LC_ALL=C" immediately in front of "sed"
> fixes this?
>
> 	Ethan
>
>> Regards,
>> Ingo
>>
>>
>>
>> _______________________________________________
>> gnuplot-info mailing list
>> gnu...@li...
>> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-info
>>
>
>
>