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

OS name for mac in gnuplot documents

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

In documents for gnuplot, the OS name for the mac is the Mac OS X or OSX.
At present, the Mac OS X or OSX is deprecated.
Please use macOS, instead.
See:
https://en.wikipedia.org/wiki/MacOS

Tatsuro

Re: Invalid data read by strcol(), possible memory corruption

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

On Tuesday, 7 March 2023 11:38:22 PST Juhász Péter wrote:
> The following data file + gnuplot script produce incorrect behavior
> with a recent git build, indicating possible memory corruption while
> reading strings from the data file:
>
> # -- data file ---
> 1;1;
> 1;2;
> 1aa;3;1.1
> 1;4;
> 1;5;
> 1;2;
> 1;3;
> 1;4;
> 1;5;
>
> # -- script ----
> set dataf sep ';'
> plot 'foo' u 0:2:(strcol(3)) w labels point
>
>
> On my machine this produces a plot where all points after the third
> have the same "1.1" label. When you move the plot around (in an
> interactive terminal, e.g. with an arrow key), all points get the same
> label.

Yes, a bug.  Or arguably two bugs.
An empty final field in a csv file was correctly flagged as "missing",
but the string-handling code did not check for this flag. Instead it
used a leftover pointer from a previous string operation.

Two fixes now applied to 5.4 6.0 6.1

1) Clear pointer to previous string operation when an empty
   field is encountered
2) In the string-handling code (df_parse_string_field) substitute
   a new empty string for a NULL string pointer


        Ethan

> Interestingly, everything seems to work as expected if you remove the
> "a"s from the data file. Other, even weirder effects can be coaxed out
> of gnuplot if you add some characters to other lines than the third.
>
> This seems like a bug. I think the explicit non-standard separator and
> the field being the last one are both necessary conditions.
>
> Some background and explanation:
>
> This report is actually related to an earlier discussion on this list,
> where I complained that lines containing missing values are silently
> dropped, and that column(i) seemed different from $i. Today I updated
> to the current development version, and noticed that my workaround to
> the missing values using column() no longer worked. So I experimented
> with some things, and at first I've thought that strcol() might be able
> to help me, as it didn't seem to be bothered by missing fields, but
> then I noticed the weirdness described above.
>
> As for fixing this bug, I think it is important to preserve strcol()'s
> ability to just return the empty string in case of missing data - after
> all, it is advertised to return the content of column X as a string. If
> the column is empty, then by definition its contents are the empty
> string.
>
> best regards,
> Peter Juhasz

Invalid data read by strcol(), possible memory corruption

[Juhász P. <pet...@gm...>]

Dear gnuplot list members,

The following data file + gnuplot script produce incorrect behavior
with a recent git build, indicating possible memory corruption while
reading strings from the data file:

# -- data file ---
1;1;
1;2;
1aa;3;1.1
1;4;
1;5;
1;2;
1;3;
1;4;
1;5;

# -- script ----
set dataf sep ';'
plot 'foo' u 0:2:(strcol(3)) w labels point


On my machine this produces a plot where all points after the third
have the same "1.1" label. When you move the plot around (in an
interactive terminal, e.g. with an arrow key), all points get the same
label.

Interestingly, everything seems to work as expected if you remove the
"a"s from the data file. Other, even weirder effects can be coaxed out
of gnuplot if you add some characters to other lines than the third.

This seems like a bug. I think the explicit non-standard separator and
the field being the last one are both necessary conditions.

Some background and explanation:

This report is actually related to an earlier discussion on this list,
where I complained that lines containing missing values are silently
dropped, and that column(i) seemed different from $i. Today I updated
to the current development version, and noticed that my workaround to
the missing values using column() no longer worked. So I experimented
with some things, and at first I've thought that strcol() might be able
to help me, as it didn't seem to be bothered by missing fields, but
then I noticed the weirdness described above.

As for fixing this bug, I think it is important to preserve strcol()'s
ability to just return the empty string in case of missing data - after
all, it is advertised to return the content of column X as a string. If
the column is empty, then by definition its contents are the empty
string.

best regards,
Peter Juhasz

Build instruction on Ubuntu

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

I wrote the Build instruction on Ubuntu, especially for the development version
https://sourceforge.net/p/gnuplot/support-requests/282/

Tatsuro

Re: Description of libwebp in gnuplot document (6.0 and 6.1)

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

Yes, the webp terminal is built only if the configure script finds the
required support libraries.
If they are not found it prints a message in the summary output,
for instance:

  libgd-based png jpeg gif sixel: yes (with animated gif)
 cairo-based pdf png  : yes
 webp                 : no (requires cairo, pango, libwebp, libwebpmux)
 lua/TikZ             : yes
 wxt                  : yes
 Qt                   : yes (qt5)

The webp and webpmux libraries are available directly from Google
    https://developers.google.com/speed/webp/download
They are included as standard packages in my linux distro (Mageia);
I do not know which other distros package them.

    Ethan


On Thu, Mar 2, 2023 at 1:05 AM Tatsuro MATSUOKA via gnuplot-beta <
gnu...@li...> wrote:

> Does the description of libwebp in any gnuplot documents?
> I could nor find it in the INSTALL for 6.1 and 6.0.
> To use the webp terminal, one has to install libwebp as dependencies for
> 6.0 and 6.1.
>
> Tatsuro
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!mUI1w0bpE45rtVTUk-Bu-ULyUvolwuj9opPMPR0KwMr-GjCi0IPR720BeSFBPmtoDjUhqUVM6a-0x2lLyjjWdkoara0JsAdzaxSY$
>


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

Description of libwebp in gnuplot document (6.0 and 6.1)

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

Does the description of libwebp in any gnuplot documents?
I could nor find it in the INSTALL for 6.1 and 6.0.
To use the webp terminal, one has to install libwebp as dependencies for 6.0 and 6.1.

Tatsuro

Re: The version number of the development version is still 5.5 on http://www.gnuplot.info/

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

On Thursday, 16 February 2023 00:32:30 PST Tatsuro MATSUOKA via
gnuplot-beta wrote:
>
> Hello
> The version number of the development version is still 5.5 on https://urldefense.com/v3/__http://www.gnuplot.info/__;!!K-Hz7m0Vt54!hXW0ERx3Fsinr61H0_3Qut1OKjUPAAc6zBwAeK_IFZ17yXban9T3W1zMih1T3XJRZnB3EKgpOkp4c6YWlIoxtMF5wb0BkY669ZH6$
>
> Tatsuro

I am still working to update the documentation and demo collection
for version 6.   They are not ready quite yet, although you can
see the current state of the demos at
   https://gnuplot.sourceforge.net/demo_6.0/


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

The version number of the development version is still 5.5 on http://www.gnuplot.info/

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

Hello
The version number of the development version is still 5.5 on http://www.gnuplot.info/

Tatsuro

Gnuplot 5.4.6 Release now available for download

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

Release 5.4.6 is now available for download from SourceForge.
Many thanks to Tatsuro Matsuoka for preparing Windows binaries.

       Gnuplot Version 5.4 Patchlevel 6

Version 5.4.6 is an incremental release in the stable 5.4 series.
It contains various minor and terminal-specific bug fixes.

It also adds two new features back-ported from the development version.
(1) new options for fixing the key layout
    set key  columns <exact no of columns>
    set key  keywidth <exact width>
(2) XDG support (freedesktop standard configuration files)
    startup file:      $XDG_CONFIG_HOME/gnuplot/gnuplotrc
    history file:      $XDG_STATE_HOME/gnuplot_history
    wxt configuration: $XDG_CONFIG_HOME/gnuplot/gnuplot-wxt.conf

Full list of changes in the release notes.

Files:
    gnuplot-5.4.6.tar.gz        source files for all operating systems
    ReleaseNotes_5_4_6          release notes
    Gnuplot_5_4.pdf             user manual
    gp546-win64-mingw.7z        binary package for Windows
    gp546-win64-mingw.exe       binary package for Windows (self-installing)

     happy gnuplotting
          Ethan

Re: Gnuplot 5.4.6 release tarball available for testing

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

I have executed the test build mingw64(windows).
The build and all.dem went well

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" 
> To: "gnuplot-beta
> Date: 2023/02/08 水 06:04
> Subject: Gnuplot 5.4.6 release tarball available for testing
> 
> 
> I have placed a pre-release tarball of 5.4.6 on the testing area of SourceForge
> 
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.6testing.tar.gz
> 
> If no problems are reported, I plan to use this for release
> of version 5.4.6 next weekend.
> 
> Changes in 5.4.6
> ================
> * NEW    set key {columns <exact no of columns>}
>          set key {keywidth <exact width>}
> * NEW    XDG support
>            startup file:      $XDG_CONFIG_HOME/gnuplot/gnuplotrc
>            history file:      $XDG_STATE_HOME/gnuplot_history
>            wxt configuration: $XDG_CONFIG_HOME/gnuplot/gnuplot-wxt.conf
> * CHANGE remove "alldoc" build target
> * CHANGE plot with polygons fillstyle empty really does mean empty
> * FIX    windows: various problems mixing piped input and stdin        Bug #2491
> * FIX    x11: bad interactions of lt nodraw, bgnd and dash pattern     Bug #2572
> * FIX    wxt: export-to-file widget should preserve line properties
> * FIX    svg: set initial default fill to "none"
> * FIX    png: back-compatibility with very old versions of gdlib       Bug #2579
> * FIX    variable pointtype, pointsize in plot style yerrorlines
> * FIX    border color for polygons with variable fillcolor
> * FIX    definition followed by iteration in a plot command            Bug #2580
> * FIX    parametric plot with filledcurves y1=<limit>                  Bug #1797
> 
> 
>      Ethan
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Gnuplot 5.4.6 release tarball available for testing

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

I have placed a pre-release tarball of 5.4.6 on the testing area of SourceForge

    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.6testing.tar.gz

If no problems are reported, I plan to use this for release
of version 5.4.6 next weekend.

Changes in 5.4.6
================
* NEW    set key {columns <exact no of columns>}
         set key {keywidth <exact width>}
* NEW    XDG support
           startup file:      $XDG_CONFIG_HOME/gnuplot/gnuplotrc
           history file:      $XDG_STATE_HOME/gnuplot_history
           wxt configuration: $XDG_CONFIG_HOME/gnuplot/gnuplot-wxt.conf
* CHANGE remove "alldoc" build target
* CHANGE plot with polygons fillstyle empty really does mean empty
* FIX    windows: various problems mixing piped input and stdin        Bug #2491
* FIX    x11: bad interactions of lt nodraw, bgnd and dash pattern     Bug #2572
* FIX    wxt: export-to-file widget should preserve line properties
* FIX    svg: set initial default fill to "none"
* FIX    png: back-compatibility with very old versions of gdlib       Bug #2579
* FIX    variable pointtype, pointsize in plot style yerrorlines
* FIX    border color for polygons with variable fillcolor
* FIX    definition followed by iteration in a plot command            Bug #2580
* FIX    parametric plot with filledcurves y1=<limit>                  Bug #1797


     Ethan

Re: Description of the qt terminal in INSTALL

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

On Monday, 23 January 2023 01:20:10 PST Tatsuro MATSUOKA via gnuplot-beta wrote:
>
> In the file INSTALL of source directory, there is description for wxt terminal
> Compiling Gnuplot with the wxWidgets terminal
> ==============================================
>
> However, there is no description for Qt terminal.
> Is this intentional?

The text about wxt was added when the wxt terminal itself was added in 2006.
It probably seemed important to inform people that there was a new option
that was cross-platform (linux, Mac, and Windows).  That no longer seems
very special, so I think that text section is no longer needed.

No one added similar text when the qt terminal was added in 2009.

The INSTALL file is very old and still very out of date.
I will make another attempt to revise and update it, including your patches.


        Ethan

Description of the qt terminal in INSTALL

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

In the file INSTALL of source directory, there is description for wxt terminal
Compiling Gnuplot with the wxWidgets terminal
==============================================

However, there is no description for Qt terminal.
Is this intentional?

Tatsuro

Re: "make pdf" fails on macOS due to incompatibility of echo

[Jun T <tak...@kb...>]

> 2022/12/16 5:16、Ethan A Merritt <me...@uw...>のメール:
> 
> The various Makefile.am rules in other subdirectories also
> use "echo" rather than "printf".   Was this rule the only
> point of failure?

In other Makefile.am, argumens of echo do not contain
backslash(es); so I think there should be no portability
problem.

Re: "make pdf" fails on macOS due to incompatibility of echo

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

On Thursday, 15 December 2022 08:02:45 PST Jun. T wrote:
> With the current git master, 'make pdf' fails on two of my Macs.

Got it. Thanks.

The various Makefile.am rules in other subdirectories also
use "echo" rather than "printf".   Was this rule the only
point of failure?

        Ethan



> The problem is in docs/Makefile.am:
>
> 201       ( echo "\usepackage{graphicx}" > gpinsetfigure.tex ; \
> 202         echo "\usepackage{picins}" >> gpinsetfigure.tex ; \
> 203         echo "\newcommand{\gpinsetfigure}[1]{" >> gpinsetfigure.tex ; \
> 204         echo "  \parpic[r][rt]{\includegraphics[width=3in,keepaspectratio]{#1}}" >> gpinsetfigure.tex ; \
> 205         echo "}" >> gpinsetfigure.tex ; \
> 206       ) ; \
> 207     $(AM_V_GEN)touch $@
> 208     $(AM_V_GEN)touch figurestyle
>
> [1] On macOS (at least on some versions), echo builtin of /bin/sh interprets
>  '\n' as a newline, and the line 203 will output:
>
> (blank line)
> ewcommand{\gpinsetfigure}[1]{
>
> to gpinsetfigure.tex, and pdflatex fails.
> (I don't know whether this is a bug or feature of macOS)
>
> [2] (also on Linux, not serious) the '\' at the end of line 206
> should be removed. Otherwise, 'make V=0 pdf' gives an error:
>
>     @echo "  GEN     " pdf_figures;touch pdf_figures
> /bin/sh: @echo: command not found
>
> A possible patch is attached.
>
> printf builtin is more portable than echo.
>
> One of $(AM_V_GEN) is replaced by $(AM_V_at) because they give the
> same output when 'make V=0'.
>
>


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

"make html" fails due to a bug in doc2web.c

[Jun. T <tak...@kb...>]

'make html' fails on one of my Mac (intel CPU, macOS Mojave, a rather
old version). The problem is in docs/doc2web.c:

507                 } else {
508                     /* close current file and start a new one */
509                     char newfile[PATH_MAX] = "";
510 
511     end_of_titlepage:
(snip)
531                     /* open new file */
532                     strcat(newfile,path);
533                     strncat(newfile,location,PATH_MAX-strlen(newfile)-6);

If we jump into this block by 'goto end_of_titlepage', then newfile[0] is
not initialized to '\0', and the strcat() at line 532 does not work as expected.
This does not happen on other Macs or on Linux, but I guess C language standard
does not guarantee that newfile is initialized after goto.

We can simply fix this by replacing strcat() at line 532 by
strcpy(newfile, path);

(and the initializer = "" at the end of line 509 is redundant)

"make pdf" fails on macOS due to incompatibility of echo

[Jun. T <tak...@kb...>]

With the current git master, 'make pdf' fails on two of my Macs.
The problem is in docs/Makefile.am:
                                                                    
201       ( echo "\usepackage{graphicx}" > gpinsetfigure.tex ; \
202         echo "\usepackage{picins}" >> gpinsetfigure.tex ; \        
203         echo "\newcommand{\gpinsetfigure}[1]{" >> gpinsetfigure.tex ; \
204         echo "  \parpic[r][rt]{\includegraphics[width=3in,keepaspectratio]{#1}}" >> gpinsetfigure.tex ; \                                    
205         echo "}" >> gpinsetfigure.tex ; \                        
206       ) ; \                                              
207     $(AM_V_GEN)touch $@                                          
208     $(AM_V_GEN)touch figurestyle

[1] On macOS (at least on some versions), echo builtin of /bin/sh interprets
 '\n' as a newline, and the line 203 will output:

(blank line)
ewcommand{\gpinsetfigure}[1]{

to gpinsetfigure.tex, and pdflatex fails.
(I don't know whether this is a bug or feature of macOS)

[2] (also on Linux, not serious) the '\' at the end of line 206
should be removed. Otherwise, 'make V=0 pdf' gives an error:

    @echo "  GEN     " pdf_figures;touch pdf_figures
/bin/sh: @echo: command not found

A possible patch is attached.

printf builtin is more portable than echo.

One of $(AM_V_GEN) is replaced by $(AM_V_at) because they give the
same output when 'make V=0'.

Gnuplot plans: the start of version 6

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

I have pushed a new branch-6-0-stable to the git repository for
for development and eventual release of a version 6 gnuplot.
Further development of version 5 can continue in the main branch
(5.5) although I don't foresee much happening on that side.


Current state of branch-6-0-stable
----------------------------------
So far the changes from the 5.5 branch are mostly to the documentation.
The introductory sections describing new and changed features are
revised to focus on version 6;  several pages of text about "new" things
in version 5 have greatly trimmed back to a summary.
Perhaps these could be removed altogether.

I have no set timeline for a version 6 release.
As a point of reference, transition from version 4->5 took most of a
year back in 2014 and went through three release candidates before
version 5 was announced.

What needs to be done for a version 6?
--------------------------------------
I have started a list of choices that should be made.
I will post them to the mailing list one at a time for separate discussion.
Each one might end in decision to leave things as they are
in version 5 (not much work required) or to make a change
not appropriate in the context of an update to a "stable'
version 5.


What about version 5?
---------------------
I expect to package 5.4.6 in the first part of 2023, with the
usual sort of bug fixes and small additions to the current stable
branch.  Beyond that I do not know.  Depending on how long it takes
to test and revise release candidates for version 6, there might
be additional updates to 5.4.

Is the next stable release 6.0.0?

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

https://sourceforge.net/p/gnuplot/gnuplot-main/ci/0b5abbcf6dd98e30ac422333f051d7f32063251e/
The stable branch for version 6.0 was started.

Is the next stable release 6.0.0?

The sharpen feature seems to be implemented only to branch-6-0-stable but not to the development branch.

Tatsuro

Re: pngcairo terminal: "crop" does different things if background color is specified

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

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

> Fixed now.

Thank you very much, Ethan!

Re: pngcairo terminal: "crop" does different things if background color is specified

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

On Monday, 28 November 2022 22:55:34 PST Ethan A Merritt wrote:
> On Monday, 28 November 2022 21:52:19 PST Dima Kogan wrote:
> > Hi. I'm using a recent gnuplot shipped in Debian, and I'm seeing an odd
> > behavior.
> >
> > I make a trivial .png plot like so:
> >
> >   set terminal pngcairo size 1024,768 notransparent crop
> >   set output "/tmp/tst.png"
> >   plot x
> >
> > Because of the "crop", the resulting image size is a bit smaller than
> > requested. "file /tmp/tst.png" says:
> >
> >   tst.png: PNG image data, 995 x 751, 8-bit/color RGB, non-interlaced
>
> > But if I change the background color by adding to the end of the "set
> > terminal" command:
> >
> >   background "#e8dfd0"
> >
> > then I get a full 1024x768 image. This shouldn't happen: the background
> > color should not be doing anything to the image size.
>
> True.  The current code seems to only test for transparent/non-transparent.
> It should also test for background/non-background.
>
> That's a fixable bug specific to cairopng.

Fixed now.


        Ethan

Re: pngcairo terminal: "crop" does different things if background color is specified

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

On Monday, 28 November 2022 21:52:19 PST Dima Kogan wrote:
> Hi. I'm using a recent gnuplot shipped in Debian, and I'm seeing an odd
> behavior.
>
> I make a trivial .png plot like so:
>
>   set terminal pngcairo size 1024,768 notransparent crop
>   set output "/tmp/tst.png"
>   plot x
>
> Because of the "crop", the resulting image size is a bit smaller than
> requested. "file /tmp/tst.png" says:
>
>   tst.png: PNG image data, 995 x 751, 8-bit/color RGB, non-interlaced
>
> Not entirely sure why it's cropping anything here, but that's how it is.

It crops all whitespace around the edges, so of course it is smaller.


> But if I change the background color by adding to the end of the "set
> terminal" command:
>
>   background "#e8dfd0"
>
> then I get a full 1024x768 image. This shouldn't happen: the background
> color should not be doing anything to the image size.

True.  The current code seems to only test for transparent/non-transparent.
It should also test for background/non-background.

That's a fixable bug specific to cairopng.

You could still clip by filtering the output through an external
tool like ImageMagick.


        Ethan


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

pngcairo terminal: "crop" does different things if background color is specified

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

Hi. I'm using a recent gnuplot shipped in Debian, and I'm seeing an odd
behavior.

I make a trivial .png plot like so:

  set terminal pngcairo size 1024,768 notransparent crop
  set output "/tmp/tst.png"
  plot x

Because of the "crop", the resulting image size is a bit smaller than
requested. "file /tmp/tst.png" says:

  tst.png: PNG image data, 995 x 751, 8-bit/color RGB, non-interlaced

Not entirely sure why it's cropping anything here, but that's how it is.
But if I change the background color by adding to the end of the "set
terminal" command:

  background "#e8dfd0"

then I get a full 1024x768 image. This shouldn't happen: the background
color should not be doing anything to the image size.

Thanks!

R: Is there any explanation for function block?

[Franco <fra...@ng...>]

Dear Professor Merritt

 

Many thanks for your excellent work and for the commitment in keeping Gnuplot up to date.

This page   https://www.sixsigmain.it/Blog_AEX.html

contains videos of a Gnuplot application (*) perfectly operational both on 5.4.x and on all 5.5.x (released this year).

I am sure that with this new feature, the code will be even more simplified. 

 

Franco

 

(*) Given your personal background, the videos will be easy to understand.

 

Da: Ethan A Merritt [mailto:me...@uw...] 
Inviato: sabato 15 ottobre 2022 19:06
A: Tatsuro MATSUOKA <tma...@ya...>
Cc: beta <gnu...@li...>
Oggetto: Re: Is there any explanation for function block?

 

Function blocks are implemented in a new branch that I have not yet committed.  The "local" property for variables was part of that branch but is useful already by itself, so I added it first.  The idea of function blocks is similar to datablocks, except that the text in the block is executed as a function rather than used as data. See earlier discussion attached to Bug #2547 https://sourceforge.net/p/gnuplot/bugs/2547/ and Feature Request 521  https://sourceforge.net/p/gnuplot/feature-requests/521/

 

Here is a draft section of the documentation for the new branch.  It still has a few rough edges, but I expect to merge it in the next week or so.

 

The `function` command signals the definition of a here-document containing 
a named block of gnuplot code that can be called as a function. 
As with data blocks, the name of a function block must begin with a '$'. 
Up to nine named parameters may be specified as part of the definition. 
These names may be used inside the function block as local variables. 
See `local` and `scope`. 

Once the function block is defined, you can invoke it by name anywhere

that a normal function could be used. 

Example: 
     function $sinc(arg) << EOF 
         if (arg == 0) { return 1.0 } 
         return sin(arg) / arg 
     EOF 

     gnuplot> plot $sinc(x) with lines title "sinc(x) as a function block" 

It is not necessary to specify a list of named arguments to a function block 
at the time it is declared. Arguments to the function passed from the command 
line can be accessed inside the function block as ARGV[1] etc, as would be the 
case for a `call` command.  See `ARGV`.  This allows defining a function 
block that can operate on a variable number of arguments.

 

The primary motivation for function block support is to allow definition of 
complicated functions directly in gnuplot.  Execution is of course slower 
than if the same function were coded directly in C or Fortran, but this is 
acceptable for many purposes.  If execution speed matters then the function 
can be implemented later as a plugin instead (see `plugins`). 

A non-trivial example of using function blocks to implement and plot 
a 15-term Lancosz approximation for the complex lngamma function is 
provided in the demo collection as 
^ <a href="http://www.gnuplot.info/demo_5.5/function_block.html"> 
     function_block.dem 
^ </a> 
The function block implementation is slower by a factor of roughly 25 compared 
to the built-in lnGamma function using the same algorithm coded directly in C. 
Nevertheless it is still fast enough for 3D interactive rotation.



 

On Fri, Oct 14, 2022 at 11:40 PM Tatsuro MATSUOKA via gnuplot-beta <gnu...@li... <mailto:gnu...@li...> > wrote:

I found the option --enable-function-blocks is implemented to the development branch.

Is there any explanation for the function block?

Tatsuro



_______________________________________________
gnuplot-beta mailing list
gnu...@li... <mailto:gnu...@li...> 
Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!i-6R1LQEUOPOg9GRf_E7o8MGHFaWf_cXfyDWcdAF0zC6EGVNvS-Yx-0U-vtqT0DdmY1ubirVqocHtClLZsrDvB2_cxG8J_Z9dvdW$ <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!i-6R1LQEUOPOg9GRf_E7o8MGHFaWf_cXfyDWcdAF0zC6EGVNvS-Yx-0U-vtqT0DdmY1ubirVqocHtClLZsrDvB2_cxG8J_Z9dvdW$>   




 

-- 

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

Re: Is there any explanation for function block?

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

Function blocks are implemented in a new branch that I have not yet
committed.  The "local" property for variables was part of that branch but
is useful already by itself, so I added it first.  The idea of function
blocks is similar to datablocks, except that the text in the block is
executed as a function rather than used as data. See earlier discussion
attached to Bug #2547 https://sourceforge.net/p/gnuplot/bugs/2547/ and
Feature Request 521  https://sourceforge.net/p/gnuplot/feature-requests/521/

Here is a draft section of the documentation for the new branch.  It still
has a few rough edges, but I expect to merge it in the next week or so.

The `function` command signals the definition of a here-document containing
a named block of gnuplot code that can be called as a function.
As with data blocks, the name of a function block must begin with a '$'.
Up to nine named parameters may be specified as part of the definition.
These names may be used inside the function block as local variables.
See `local` and `scope`.

Once the function block is defined, you can invoke it by name anywhere
that a normal function could be used.

Example:
     function $sinc(arg) << EOF
         if (arg == 0) { return 1.0 }
         return sin(arg) / arg
     EOF

     gnuplot> plot $sinc(x) with lines title "sinc(x) as a function block"

It is not necessary to specify a list of named arguments to a function
block
at the time it is declared. Arguments to the function passed from the
command
line can be accessed inside the function block as ARGV[1] etc, as would be
the
case for a `call` command.  See `ARGV`.  This allows defining a function
block that can operate on a variable number of arguments.

The primary motivation for function block support is to allow definition of
complicated functions directly in gnuplot.  Execution is of course slower
than if the same function were coded directly in C or Fortran, but this is
acceptable for many purposes.  If execution speed matters then the function
can be implemented later as a plugin instead (see `plugins`).

A non-trivial example of using function blocks to implement and plot
a 15-term Lancosz approximation for the complex lngamma function is
provided in the demo collection as
^ <a href="http://www.gnuplot.info/demo_5.5/function_block.html">
     function_block.dem
^ </a>
The function block implementation is slower by a factor of roughly 25
compared
to the built-in lnGamma function using the same algorithm coded directly in
C.
Nevertheless it is still fast enough for 3D interactive rotation.



On Fri, Oct 14, 2022 at 11:40 PM Tatsuro MATSUOKA via gnuplot-beta <
gnu...@li...> wrote:

> I found the option --enable-function-blocks is implemented to the
> development branch.
>
> Is there any explanation for the function block?
>
> Tatsuro
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!i-6R1LQEUOPOg9GRf_E7o8MGHFaWf_cXfyDWcdAF0zC6EGVNvS-Yx-0U-vtqT0DdmY1ubirVqocHtClLZsrDvB2_cxG8J_Z9dvdW$
>
>


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