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

Re: Inquiry for amos routine for expint

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

On Wednesday, 15 December 2021 00:43:54 PST Tatsuro MATSUOKA wrote:
> /cygdrive/f/Work/Tatsuro/cygwinwork/gnuplot/gnuplot-main/gnuplot-main/conftest.c:56: undefined reference to `zairy_'
> collect2: error: ld returned 1 exit status
> configure:8799: $? = 1
> 
> def file of libamos has  zairy_ symbol

Some fortran compilers historically used a convention that subroutine
names always ended in an underscore.   

The gcc compiler package supports either the "always use underscore"
or "never use underscore" convention, but you have to use the same
convention when compiling all the source files that will be linked
together.  That includes libraries.

For gfortran the two options are
	-funderscoring
	-fno-underscoring

This is noted in the gnuplot source for the c/fortran interface routines
in gnuplot's .../src/amos_airy.c

 * The zairy_() routine (note Fortran naming and parameter passing conventions)
 * is found, for example, in libopenspecfun.  We use it to calculate Ai(z).
 * Similarly zbiry_() is used to calcualte Bi(z).

It could be that the zairy function you compiled from source lacks the
trailing underscore because the gfortran compiler defaulted to the wrong
underscoring convention.

I would worry a bit about this part also:
> I tried to use expint on the development brach on Cygwin.
>
> amos library, 
> http://www.netlib.org/amos/
>
> i1mach.f, r1mach.f, d1mach (replacement of the above)
> http://www.netlib.org/blas/i1mach.f
> http://www.netlib.org/blas/r1mach.f
> http://www.netlib.org/blas/d1mach.f

These source files were incorrect for use on my linux machines.
I replaced them with local definitions in C in order to build a
working copy of libamos.   I do not know whether that is or is
not a problem for your Cygwin environment.

I had considered to add the relevant libamos source files
in a new subdirectory of the gnuplot source, along with a
autoconf/Makefile template so that the library can be built
automatically via ./configure; make gnuplot

I decided not to add it when I found that at least some 
linux distributions are already providing either a pre-built
version of libamos or a version of libopenspecfun, which
provides all of the needed functions except cexint.
However your story here shows that it remains a bit tricky
to find and build all the relevant source if you do not have
one of the pre-built libraries.

So do people think it would be good to add the Amos source
to the gnuplot repository and distribution package?

I have source files from the original Sandia Laboratories
work by Donald Amos.  Some, but not all, of these were
later archived in netlib.  Note that the version of cexint.f
that I have did _not_ come from the TOMS/ACM publication
collection.

Separate from discussion of including the Amos source in the
gnuplot repository, I can send you Makefiles and C versions of
the *1mach files if you like.  Just let me know.

	Ethan  


> > ----- Original Message -----
> 
> > Hello
> > 
> > I tried to use expint on the development brach on Cygwin.
> > 
> > amos library, 
> > http://www.netlib.org/amos/
> > 
> > i1mach.f, r1mach.f, d1mach (replacement of the above)
> > http://www.netlib.org/blas/i1mach.f
> > http://www.netlib.org/blas/r1mach.f
> > http://www.netlib.org/blas/d1mach.f
> > 
> > cexint, zexint
> > http://www.netlib.org/toms-2014-06-10/683
> > 
> > I have checked cexint, zexint  by cqccex.f and zqccex.f.
> >  QUICK CHECKS FOR CEXINT ARE OK.
> >  QUICK CHECKS FOR ZEXINT ARE OK.
> > 
> > all.dem runs without problem
> > 
> > However, load 'expint.dem' seems to be invaild.
> > See the below screenshot files
> > http://tmacchant33.starfree.jp/Files/expint1.png
> > http://tmacchant33.starfree.jp/Files/expint2.png
> > 
> > Any suggestions?
> > 
> > Refernce
> > confiure
> > LDFLAGS='-L/usr/local/lib -lamos' \
> > ./configure --prefix=/cygdrive/f/Work/Tatsuro/cygwinwork/gnuplot/gnuplot-main/usr/local \
> >   --with-qt=no \
> >   --disable-dependency-tracking \
> >   --enable-plugins \
> >   --with-latex \
> >   --with-kpsexpand \
> >   --with-x \
> >   --with-readline=gnu \
> >   --with-gd \
> >   --with-lua \
> >   --with-bitmap-terminals \
> >   --enable-history-file \
> >   --enable-stats \
> >   --without-ggi \
> >   --without-gpic \
> >   --without-mif
> > 
> > config.log
> > http://tmacchant33.starfree.jp/Files/config.log
> > 
> > Tatsuro
> 
> Sorry I did see config.log in details.
> 
> gnuplot will be compiled with the following configurable features:
> 
>   Mouse support in interactive terminals: yes
>   Typing <space> in plot window raises console: yes
>   Readline library: GNU readline library with  -lncurses
>   Command-line history file: yes
>   Check current directory for .gnuplot file: no (use --with-cwdrc to enable)
>   Sort help/subtopic tables by column: no (use --without-row-help to enable)
>   cerf() and other special functions from libcerf: yes
>   Airy and Bessel functions from libopenspecfun or libamos: yes
>   Complex exponential integral cexint from libamos: yes
>   plugin support for loading external functions: yes
>   Statistical summary of data ("stats" command): yes
> 
> But config.log says 
> 
> configure:8714: gcc -o conftest.exe -g -O2  -I/include  -L/usr/local/lib -lamos -L/lib -lcerf  conftest.c -lcerf   >&5
> configure:8714: $? = 0
> configure:8734: result: -lcerf
> configure:8766: checking for amos libraries using LDFLAGS: -L/usr/local/lib -lamos -L/lib -lcerf   
> configure:8769: checking for library containing zairy_
> configure:8799: gcc -o conftest.exe -g -O2  -I/include  -L/usr/local/lib -lamos -L/lib -lcerf   conftest.c -lcerf  >&5
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/ccYZXooH.o: in function `main':
> /cygdrive/f/Work/Tatsuro/cygwinwork/gnuplot/gnuplot-main/gnuplot-main/conftest.c:56: undefined reference to `zairy_'
> collect2: error: ld returned 1 exit status
> configure:8799: $? = 1
> 
> def file of libamos has  zairy_ symbol
> 
> Hmmmm?
> 
> Tatsuro
> 
> 
> 
> _______________________________________________
> 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: Inquiry for amos routine for expint

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

> ----- Original Message -----

> Hello
> 
> I tried to use expint on the development brach on Cygwin.
> 
> amos library, 
> http://www.netlib.org/amos/
> 
> i1mach.f, r1mach.f, d1mach (replacement of the above)
> http://www.netlib.org/blas/i1mach.f
> http://www.netlib.org/blas/r1mach.f
> http://www.netlib.org/blas/d1mach.f
> 
> cexint, zexint
> http://www.netlib.org/toms-2014-06-10/683
> 
> I have checked cexint, zexint  by cqccex.f and zqccex.f.
>  QUICK CHECKS FOR CEXINT ARE OK.
>  QUICK CHECKS FOR ZEXINT ARE OK.
> 
> all.dem runs without problem
> 
> However, load 'expint.dem' seems to be invaild.
> See the below screenshot files
> http://tmacchant33.starfree.jp/Files/expint1.png
> http://tmacchant33.starfree.jp/Files/expint2.png
> 
> Any suggestions?
> 
> Refernce
> confiure
> LDFLAGS='-L/usr/local/lib -lamos' \
> ./configure --prefix=/cygdrive/f/Work/Tatsuro/cygwinwork/gnuplot/gnuplot-main/usr/local \
>   --with-qt=no \
>   --disable-dependency-tracking \
>   --enable-plugins \
>   --with-latex \
>   --with-kpsexpand \
>   --with-x \
>   --with-readline=gnu \
>   --with-gd \
>   --with-lua \
>   --with-bitmap-terminals \
>   --enable-history-file \
>   --enable-stats \
>   --without-ggi \
>   --without-gpic \
>   --without-mif
> 
> config.log
> http://tmacchant33.starfree.jp/Files/config.log
> 
> Tatsuro

Sorry I did see config.log in details.

gnuplot will be compiled with the following configurable features:

  Mouse support in interactive terminals: yes
  Typing <space> in plot window raises console: yes
  Readline library: GNU readline library with  -lncurses
  Command-line history file: yes
  Check current directory for .gnuplot file: no (use --with-cwdrc to enable)
  Sort help/subtopic tables by column: no (use --without-row-help to enable)
  cerf() and other special functions from libcerf: yes
  Airy and Bessel functions from libopenspecfun or libamos: yes
  Complex exponential integral cexint from libamos: yes
  plugin support for loading external functions: yes
  Statistical summary of data ("stats" command): yes

But config.log says 

configure:8714: gcc -o conftest.exe -g -O2  -I/include  -L/usr/local/lib -lamos -L/lib -lcerf  conftest.c -lcerf   >&5
configure:8714: $? = 0
configure:8734: result: -lcerf
configure:8766: checking for amos libraries using LDFLAGS: -L/usr/local/lib -lamos -L/lib -lcerf   
configure:8769: checking for library containing zairy_
configure:8799: gcc -o conftest.exe -g -O2  -I/include  -L/usr/local/lib -lamos -L/lib -lcerf   conftest.c -lcerf  >&5
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /tmp/ccYZXooH.o: in function `main':
/cygdrive/f/Work/Tatsuro/cygwinwork/gnuplot/gnuplot-main/gnuplot-main/conftest.c:56: undefined reference to `zairy_'
collect2: error: ld returned 1 exit status
configure:8799: $? = 1

def file of libamos has  zairy_ symbol

Hmmmm?

Tatsuro

Inquiry for amos routine for expint

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

Hello

I tried to use expint on the development brach on Cygwin.

amos library, 
http://www.netlib.org/amos/

i1mach.f, r1mach.f, d1mach (replacement of the above)
http://www.netlib.org/blas/i1mach.f
http://www.netlib.org/blas/r1mach.f
http://www.netlib.org/blas/d1mach.f

cexint, zexint
http://www.netlib.org/toms-2014-06-10/683

I have checked cexint, zexint  by cqccex.f and zqccex.f.
 QUICK CHECKS FOR CEXINT ARE OK.
 QUICK CHECKS FOR ZEXINT ARE OK.

all.dem runs without problem

However, load 'expint.dem' seems to be invaild.
See the below screenshot files
http://tmacchant33.starfree.jp/Files/expint1.png
http://tmacchant33.starfree.jp/Files/expint2.png

Any suggestions?

Refernce
confiure
LDFLAGS='-L/usr/local/lib -lamos' \
./configure --prefix=/cygdrive/f/Work/Tatsuro/cygwinwork/gnuplot/gnuplot-main/usr/local \
  --with-qt=no \
  --disable-dependency-tracking \
  --enable-plugins \
  --with-latex \
  --with-kpsexpand \
  --with-x \
  --with-readline=gnu \
  --with-gd \
  --with-lua \
  --with-bitmap-terminals \
  --enable-history-file \
  --enable-stats \
  --without-ggi \
  --without-gpic \
  --without-mif

config.log
http://tmacchant33.starfree.jp/Files/config.log

Tatsuro

Re: Historical question about gnuplot's PostScript terminal

[Petr M. <mi...@ph...>]

Hello Ethan & others,

well, that's really history...

I have coded "pm3d" algorithm for postscript in 1995 as a stand-alone C++ 
program of the same name, and later made it as an splot mode for gnuplot in 
1999. The main idea was to visualize large synchrotron scan series (reciprocal 
space maps) without gridding (very slow and memory expensive at that time), 
print them via postscript on colour printers as fast as possible during/after 
the experiment. (Actually, I had such an algorithm in a Pascal program in 
1994, but it was low-resolution for DOS screen only, thus I had to rewrite it 
for high-res so I have selected postscript.)

One of my favourite testing data ("GaAs fish") had almost 40000 measured 
points, thus postscript header was always much smaller than the data part. 
Speed of printers was never a problem - anyway, in 90's, there only few colour 
postscript printers per institute and you need to walk there :-)


Thus, requirements for the program:

1. Smallest postscript size possible: disks were small and LaTeX postscript 
file size with included many figures was growing fast.

2. The postscript header should be readable & editable by any text editor in 
order to easily change the gray <=> colour version of the same file (gray 
version for a publication, colour for a poster), or change your preferable 
colour sequence without the need to process the original data again.


Thus the g command with 4 digits precision and various rgbformulae so that the 
file owner can play with/change easily an own set of colour mapping formulae.


Well, now I can see that one byte per line can be saved by change of
.1234 g
=>
1234 g
using  1000 div setgray   :-) Wow, unnoticed for 25 years...


Further postscript file size decrease for regular (e.g. image) data can be 
done via scripts
 	pm3dCompress.awk
 	pm3dConvertToImage.awk

They compress information about quadrangle sizes, but not of same successive 
colours. That was actually not necessary - experimental data are noisy and 
calculated data are continuous, thus sequent colours are diffent; and missing 
data (forbidden regions, such as those outside of the Ewald sphere) need not 
to be written in the input data file at all. Omitting repetive .xxxx g would 
save some space if pm3d mode is used for plotting of some geometries.

The gray/gamma/colour and rgbformulae palettes were in gnuplot the only option 
for a long time. Much later other palettes were added so that gnuplot can have 
same palettes as in AFM, Matlab, etc.

That's the summary about the pm3d & rgbformulae history. I hope this shows 
that the colour coding was/is not that complicated.

Greetings, Petr



On Mon, 15 Nov 2021, Ethan A Merritt wrote:

> The PostScript terminal implements palette colors in a complicated way.
> Or at least it seems complicated to me in retrospect.
> I'm wondering if there was a reason it was done the way it was.
>
> The way it was (and still is)
> =============================
>
> If the palette mode is "rgbformulae"
>   - PostScript implementations of the 3 formulae are written in the output
>   - the function \g is defined to convert gray->rgb using them analytically
> If the palette mode is "functions"
>   - The terminal writes out an approximation table for each function
>   - the function \g is defined to convert gray->rgb using interpolation
>     between table entries
> If the palette mode is "defined"
>   - The terminal writes the gradient definitions
>   - the function \g is defined to convert gray->rgb using interpolation
>
> In all cases the actual "change color" command in the PostScript output
> ends up looking like this
>      .1234 g
> where ".1234" is the gray value for conversion, and the \g function
> converts this into the native PostScript command
>      .rrr .ggg. .bbb  setrgbcolor
>
> As I understand it, the original idea was that ".1234 g" uses only
> 5 characters for the gray value rather than approximately 15-18 characters
> if the driver were to write out the .rrr .ggg .bbb values separately.
> So it saves some space in the output file.
>
> On the other hand, the interpolation tables take up a lot of space too.
> And the burden of converting every single gray value into RGB was borne
> by the printer, which I imagine was pretty slow back in the day...
>
> Also, the four digit precision of the gray value means that the driver
> cannot skip writing a "change color" sequence to the output even if it
> turns out that successive similar gray values will all map to the same RGB.
>
> Why wasn't it this instead?
> ===========================
>
> The driver always writes a 24bit hex-encoded RGB color:
>    0xAABBCC g
> As before, the function \g is defined to unpack this into
>    .rrr .ggg .bbb setrgbcolor
>
> That's 8 characters for the color rather than 5, so slightly worse.
> But not much worse.
>
> Since the conversion from gray->RGB is done by gnuplot rather than
> by a PostScript interpreter running in a printer, it's much faster.
>
> Bonus 1: The terminal driver knows exactly what the RGB value will be,
> and can choose not to write it if it duplicates the previous value.
>
> Bonus 2: No need to write out analytical functions or interpolation
> tables that are specific to a single pm3d plot.  The gray->RGB
> conversion has already been done at the time of file creation.
>
> 	just curious
>
> 		Ethan
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Historical question about gnuplot's PostScript terminal

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

The PostScript terminal implements palette colors in a complicated way.
Or at least it seems complicated to me in retrospect.
I'm wondering if there was a reason it was done the way it was.

The way it was (and still is)
=============================

If the palette mode is "rgbformulae"
   - PostScript implementations of the 3 formulae are written in the output
   - the function \g is defined to convert gray->rgb using them analytically
If the palette mode is "functions"
   - The terminal writes out an approximation table for each function
   - the function \g is defined to convert gray->rgb using interpolation
     between table entries
If the palette mode is "defined"
   - The terminal writes the gradient definitions
   - the function \g is defined to convert gray->rgb using interpolation

In all cases the actual "change color" command in the PostScript output
ends up looking like this
      .1234 g
where ".1234" is the gray value for conversion, and the \g function
converts this into the native PostScript command
      .rrr .ggg. .bbb  setrgbcolor

As I understand it, the original idea was that ".1234 g" uses only
5 characters for the gray value rather than approximately 15-18 characters
if the driver were to write out the .rrr .ggg .bbb values separately.
So it saves some space in the output file.

On the other hand, the interpolation tables take up a lot of space too.
And the burden of converting every single gray value into RGB was borne
by the printer, which I imagine was pretty slow back in the day...

Also, the four digit precision of the gray value means that the driver
cannot skip writing a "change color" sequence to the output even if it
turns out that successive similar gray values will all map to the same RGB.

Why wasn't it this instead?
===========================

The driver always writes a 24bit hex-encoded RGB color:
    0xAABBCC g
As before, the function \g is defined to unpack this into 
    .rrr .ggg .bbb setrgbcolor

That's 8 characters for the color rather than 5, so slightly worse.
But not much worse.

Since the conversion from gray->RGB is done by gnuplot rather than
by a PostScript interpreter running in a printer, it's much faster.

Bonus 1: The terminal driver knows exactly what the RGB value will be,
and can choose not to write it if it duplicates the previous value.

Bonus 2: No need to write out analytical functions or interpolation
tables that are specific to a single pm3d plot.  The gray->RGB
conversion has already been done at the time of file creation.

	just curious

		Ethan

Re: [PATCH] XDG base directory support (history and wxt)

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

> 2021/09/23 7:11, Ethan A Merritt <me...@uw...> wrote:
> 
> I'm not actually using XDG normally, so I could do only limited testing.

The point is that it does not interfere/surprise users who do not
know/use/like XDG. If you find anything it may bother those users
please let met know.

--
Jun

Re: [PATCH] XDG base directory support (history and wxt)

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

I applied this patch and did a commit to the development branch.
I added a brief mention under "set history" in the documentation.

I'm not actually using XDG normally, so I could do only limited testing.

	thanks,

		Ethan

On Tuesday, 14 September 2021 02:11:58 PDT Jun T wrote:
> 
> > 2021/09/14 4:06, Ethan A Merritt <me...@uw...> wrote:
> > 
> >  I realize that the previous XDG patch already put a
> > chunk of code in plot.c to hande the gnuplotrc file, but wouldn't it
> > be better to have that code and the new patch code for the history file
> > live in xdg.c instead?
> > Then in plot.c or history.c the call site would
> > be:
> > 
> > #ifdef USE_XDG_BASEDIR
> >    expanded_history_filename = some_new_xdg_routine(GNUPLOT_HISTORY_FILE));
> > #endif
> >    if (!expanded_history_filename) {
> > 	/* current code */
> > 	expanded_history_filename = tilde_expand(GNUPLOT_HISTORY_FILE);
> >    }
> >    read_history(expanded_history_filename);
> 
> How about the revised patch (xdg-v2.patch)?
> I moved "most" of the complication into a function in xdg.c, but plot.c is
> not as simple as above.
> 
> 
> >> [2] Migration
> >> With the patch, gnuplot will continue to use traditional config or history
> >> files in ~/ if they exist (as it does for the main config file ~/.gnuplot).
> >> Users must move the traditional files to XDG dirs (or remove ~/.gnuplot-wxt
> >> and ~/.gnuplot_history) manually if they want to migrate.
> > 
> > Isn't the obvious migration to set
> > 	XDG_DATA_DIRS = $HOME:$HOME/.local/share
> > 	XDG_CONFIG_HOME = $HOME:$HOME/.config
> 
> I couldn't understand this part...
> 
> > Your current home directory files will be used whether or not
> > you have XDG enabled, so moving files is not required.
> 
> > If you choose to enable XDG and move the files, that works also.
> 
> Yes, this is the case with my match.
> 
> As I wrote, with my patch, if ~/.gnuplot_history or ~/.gnuplot-wxt exists
> gnuplot will continue to use them. User need not do anything if they are
> satisfied with this traditional behavior.
> 
> If a user wants to use XDG directory, she/he must manually move
> ~/.gnuplot_history to ~/.local/state/gnuplot_history, and
> ~/.gnuplot-wxt to ~/.config/gnuplot/gnuplot-wxt.conf
> (or just remove them), but need not set XDG_CONFIG_HOME etc.
> 
> (if XDG_CONFIG_HOME is set then it is used instead of ~/.config/, of course)
> 
> Is this OK?
> 
> 


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

Re: [PATCH] XDG base directory support (history and wxt)

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

> 2021/09/14 17:35, Petr Mikulik <mi...@ph...> wrote:

> I don't have $HOME/.local/state.

With my patch, if ~/.gnuplot_history does not exist, gnuplot will try to create
~/.local/state/, and if it fails (permission problem, or ~/.local/ not exists)
then fall back to ~/.gnuplot_history.

XDG_STATE_HOME is new but the spec
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
says this is the place for history, so I used it in my patch.
But XDG_DATA_HOME (~/.local/share) would also be OK since the history file of
gnuplot is "portable" and can be "shared".

Another option is to save everything (including history) in ~/.config/gnuplot/,
but I fear many pro-XDG people will complain...

> I see that QT terminal has its config in $HOME/.config/gnuplot, while WX terminal in $HOME. I think WX config should go to $HOME/.config/gnuplot/ as well.

I guess many users feel the same way.

Re: [PATCH] XDG base directory support (history and wxt)

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

> 2021/09/14 4:06, Ethan A Merritt <me...@uw...> wrote:
> 
>  I realize that the previous XDG patch already put a
> chunk of code in plot.c to hande the gnuplotrc file, but wouldn't it
> be better to have that code and the new patch code for the history file
> live in xdg.c instead?
> Then in plot.c or history.c the call site would
> be:
> 
> #ifdef USE_XDG_BASEDIR
>    expanded_history_filename = some_new_xdg_routine(GNUPLOT_HISTORY_FILE));
> #endif
>    if (!expanded_history_filename) {
> 	/* current code */
> 	expanded_history_filename = tilde_expand(GNUPLOT_HISTORY_FILE);
>    }
>    read_history(expanded_history_filename);

How about the revised patch (xdg-v2.patch)?
I moved "most" of the complication into a function in xdg.c, but plot.c is
not as simple as above.


>> [2] Migration
>> With the patch, gnuplot will continue to use traditional config or history
>> files in ~/ if they exist (as it does for the main config file ~/.gnuplot).
>> Users must move the traditional files to XDG dirs (or remove ~/.gnuplot-wxt
>> and ~/.gnuplot_history) manually if they want to migrate.
> 
> Isn't the obvious migration to set
> 	XDG_DATA_DIRS = $HOME:$HOME/.local/share
> 	XDG_CONFIG_HOME = $HOME:$HOME/.config

I couldn't understand this part...

> Your current home directory files will be used whether or not
> you have XDG enabled, so moving files is not required.

> If you choose to enable XDG and move the files, that works also.

Yes, this is the case with my match.

As I wrote, with my patch, if ~/.gnuplot_history or ~/.gnuplot-wxt exists
gnuplot will continue to use them. User need not do anything if they are
satisfied with this traditional behavior.

If a user wants to use XDG directory, she/he must manually move
~/.gnuplot_history to ~/.local/state/gnuplot_history, and
~/.gnuplot-wxt to ~/.config/gnuplot/gnuplot-wxt.conf
(or just remove them), but need not set XDG_CONFIG_HOME etc.

(if XDG_CONFIG_HOME is set then it is used instead of ~/.config/, of course)

Is this OK?

Re: [PATCH] XDG base directory support (history and wxt)

[Petr M. <mi...@ph...>]

> I'm not a fan of XDG basedir, but moving only ~/.gnuplot to XDG
> directory may be a kind of "half done".
>
> Attached is a possible patch for moving ~/{.gnuplot_history,.gnuplot-wxt}
> to XDG directories (it seems qtterminal.conf is already taken care of).
> Since only one file (the history file) is saved in the directory, I think
...
> we can save it directly under XDG ( ~/.local/state/gnuplot_history)
> instead of saving it as ~/.local/state/gnuplot/history.

I noticed many programs store they files in $HOME/.config, and some in 
$HOME/.local/share, and some in all of them.

I don't have $HOME/.local/state.

For example Midnight Commander: there is a command line option
 	mc -F
which shows these locations.


I see that QT terminal has its config in $HOME/.config/gnuplot, while WX 
terminal in $HOME. I think WX config should go to $HOME/.config/gnuplot/ as 
well.

---
Petr Mikulik

Re: [PATCH] XDG base directory support (history and wxt)

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

On Sunday, 12 September 2021 07:29:51 PDT Jun. T wrote:
> I'm not a fan of XDG basedir, but moving only ~/.gnuplot to XDG
> directory may be a kind of "half done".

I am not a fan either. Neither my home nor my lab machines use XDG
except for the KDE desktop itself, so I don't even have any examples
to look it from other user applications.

The one possible advantage I see, which isn't currently in place at all,
would be to use a XDG_CONFIG file to set the default gnuplot terminal
type.  That way distros who provide separate x11/wxt/qt/dumb packages
for gnuplot installation could place a corresponding file in 
/etc/xdg/gnuplot.config to set the appropriate system default.
Users could override this in $HOME/.config/gnuplotrc or whatever the
xdg convention is.

In any case I would prefer to minimize any references to XDG in the
core source code.  I realize that the previous XDG patch already put a
chunk of code in plot.c to hande the gnuplotrc file, but wouldn't it
be better to have that code and the new patch code for the history file
live in xdg.c instead?  Then in plot.c or history.c the call site would
be:

#ifdef USE_XDG_BASEDIR
    expanded_history_filename = some_new_xdg_routine(GNUPLOT_HISTORY_FILE));
#endif
    if (!expanded_history_filename) {
	/* current code */
	expanded_history_filename = tilde_expand(GNUPLOT_HISTORY_FILE);
    }
    read_history(expanded_history_filename);
 
> Attached is a possible patch for moving ~/{.gnuplot_history,.gnuplot-wxt}
> to XDG directories (it seems qtterminal.conf is already taken care of).
> A few points to discuss:
> 
> [1] Where to save the history?
> There were three possibilities $XDG_{CONFIG,DATA,CACHE}_HOME, and probably
> DATA directory is most widely used for history (but I'm not sure).
> But to make the situation still more complicated, they added one more
> directory $XDG_STATE_HOME recently. It seems this directory is most
> suitable for history, but it is new and very few programs are using it yet,
> and I'm rather suspicious of whether many programs that are already using
> DATA (or CACHE?) directory for history will modify their code.
> (and XDG may add more basedirs to make it further complicated...)
> 
> In the attached patch I use the STATE directory,
> but I have no objection to using other directories.
> 
> Since only one file (the history file) is saved in the directory, I think
> we can save it directly under XDG ( ~/.local/state/gnuplot_history)
> instead of saving it as ~/.local/state/gnuplot/history.
> 
> [2] Migration
> With the patch, gnuplot will continue to use traditional config or history
> files in ~/ if they exist (as it does for the main config file ~/.gnuplot).
> Users must move the traditional files to XDG dirs (or remove ~/.gnuplot-wxt
> and ~/.gnuplot_history) manually if they want to migrate.

Isn't the obvious migration to set
	XDG_DATA_DIRS = $HOME:$HOME/.local/share
	XDG_CONFIG_HOME = $HOME:$HOME/.config
and so on?  Your current home directory files will be used whether or not
you have XDG enabled, so moving files is not required.
If you choose to enable XDG and move the files, that works also.

> 
> We could make gnuplot to force move traditional ones to XDG directories, but
> I rather hesitate to do this.

See above.  I see no reason to do this.
But since I'm not actually using XDG maybe I am failing to see a possible benefit.

Other comments or opinions?

	Ethan


> [3] wxWidgets
> They added a function (wxStandardPaths::FileLayout()) for supporting XDG
> basedir in wxWidgets 3.1.1.
> https://docs.wxwidgets.org/3.1.5/classwx_standard_paths.html
> But even if FileLayout is set to FileLayout_XDG, it seems I still need to set
> the full pathname of the config flie manually in wxFileConfig constructor to
> make it saved in $XDG_CONFIG_HOME/gnuplot/ (i.e., not directly under
> $XDG_CONFIG_HOME/). So I didn't use wxStandardPaths but used xdg_get_var() in
> xdg.c and manually set the full pathname of the config file.
> 
> Good thing of this is it works with older wxWidgets (3.1.x is a kind of
> development release).
> 
> I'm not familiar with wxWidgets. If there are anyone who knows wxWidgets better
> please feel free to improve the patch.
> 
> [4] Documents
> Are there any documents that need be updated?
> 
> 
> 
> 


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

[PATCH] XDG base directory support (history and wxt)

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

I'm not a fan of XDG basedir, but moving only ~/.gnuplot to XDG
directory may be a kind of "half done".

Attached is a possible patch for moving ~/{.gnuplot_history,.gnuplot-wxt}
to XDG directories (it seems qtterminal.conf is already taken care of).
A few points to discuss:

[1] Where to save the history?
There were three possibilities $XDG_{CONFIG,DATA,CACHE}_HOME, and probably
DATA directory is most widely used for history (but I'm not sure).
But to make the situation still more complicated, they added one more
directory $XDG_STATE_HOME recently. It seems this directory is most
suitable for history, but it is new and very few programs are using it yet,
and I'm rather suspicious of whether many programs that are already using
DATA (or CACHE?) directory for history will modify their code.
(and XDG may add more basedirs to make it further complicated...)

In the attached patch I use the STATE directory,
but I have no objection to using other directories.

Since only one file (the history file) is saved in the directory, I think
we can save it directly under XDG ( ~/.local/state/gnuplot_history)
instead of saving it as ~/.local/state/gnuplot/history.

[2] Migration
With the patch, gnuplot will continue to use traditional config or history
files in ~/ if they exist (as it does for the main config file ~/.gnuplot).
Users must move the traditional files to XDG dirs (or remove ~/.gnuplot-wxt
and ~/.gnuplot_history) manually if they want to migrate.

We could make gnuplot to force move traditional ones to XDG directories, but
I rather hesitate to do this.

[3] wxWidgets
They added a function (wxStandardPaths::FileLayout()) for supporting XDG
basedir in wxWidgets 3.1.1.
https://docs.wxwidgets.org/3.1.5/classwx_standard_paths.html
But even if FileLayout is set to FileLayout_XDG, it seems I still need to set
the full pathname of the config flie manually in wxFileConfig constructor to
make it saved in $XDG_CONFIG_HOME/gnuplot/ (i.e., not directly under
$XDG_CONFIG_HOME/). So I didn't use wxStandardPaths but used xdg_get_var() in
xdg.c and manually set the full pathname of the config file.

Good thing of this is it works with older wxWidgets (3.1.x is a kind of
development release).

I'm not familiar with wxWidgets. If there are anyone who knows wxWidgets better
please feel free to improve the patch.

[4] Documents
Are there any documents that need be updated?

Re: [PATCH] support XDG_CONFIG_HOME on macOS

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

Sorry, this should be better.
Define USE_XDG_BASEDIR in xdg.h.

Jun


diff --git a/src/plot.c b/src/plot.c
index 8e91239cf..66fdb6e45 100644
--- a/src/plot.c
+++ b/src/plot.c
@@ -789,7 +789,7 @@ load_rcfile(int where)
 	PATH_CONCAT(rcfile, PLOTRC);
 	plotrc = fopen(rcfile, "r");
     } else if (where == 3) {
-#ifdef __unix__
+#ifdef USE_XDG_BASEDIR
 	char * XDGConfigHome = xdg_get_var(kXDGConfigHome);
 	size_t len = strlen(XDGConfigHome);
 	rcfile = gp_alloc(len + 1 + sizeof("gnuplot/gnuplotrc"), "rcfile");
diff --git a/src/xdg.c b/src/xdg.c
index 93e4c227d..e6652d329 100644
--- a/src/xdg.c
+++ b/src/xdg.c
@@ -2,7 +2,7 @@
 #include "plot.h"
 #include "util.h"
 
-#ifdef __unix__
+#ifdef USE_XDG_BASEDIR
 
 #include <assert.h>
 #include <stdio.h>
@@ -57,4 +57,4 @@ char *xdg_get_var(const XDGVarType idx) {
     return XDGVar;
 }
 
-#endif /* __unix__ */
+#endif /* USE_XDG_BASEDIR */
diff --git a/src/xdg.h b/src/xdg.h
index acfdda19d..cab5e1415 100644
--- a/src/xdg.h
+++ b/src/xdg.h
@@ -1,7 +1,9 @@
 #ifndef GNUPLOT_XDG_H
 #define GNUPLOT_XDG_H
 
-#ifdef __unix__
+#if defined(__unix__) || (defined(__APPLE__) && defined(__MACH__))
+
+#define USE_XDG_BASEDIR
 
 /* List of possible XDG variables */
 typedef enum {
@@ -16,7 +18,7 @@ typedef enum {
 
 char *xdg_get_var(const XDGVarType idx);
 
-#endif /* __unix__ */
+#endif /* USE_XDG_BASEDIR */
 
 #endif /* GNUPLOT_XDG_H */
 

[PATCH] fix manpage (XDG_DATA_HOME --> XDG_CONFIG_HOME)

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

XDG_DATA_HOME mentioned in the manpage should be XDG_CONFIG_HOME.



diff --git a/man/gnuplot.1 b/man/gnuplot.1
index 8075a7cf2..9b81df586 100644
--- a/man/gnuplot.1
+++ b/man/gnuplot.1
@@ -48,7 +48,7 @@ Support for a huge variety of output devices and file formats.
 .PP
 \fB\-c scriptname ARG1 ARG2 ..., load script using gnuplot's "call" mechanism and pass it the remainder of the command line as arguments
 .PP
-\fB\-d, \-\-default\fP settings.  Do not read from gnuplotrc, ~/.gnuplot, and $XDG_DATA_HOME/gnuplot/gnuplotrc on entry.
+\fB\-d, \-\-default\fP settings.  Do not read from gnuplotrc, ~/.gnuplot, and $XDG_CONFIG_HOME/gnuplot/gnuplotrc on entry.
 .PP
 \fB\-e "command list"\fP executes the requested commands before loading the next input file.
 .PP
@@ -69,7 +69,7 @@ gnuplot.  None of these are required.
 .TP
 .B GNUTERM
 The name of the terminal type to be used by default.  This can be
-overridden by the gnuplotrc, .gnuplot, or $XDG_DATA_HOME/gnuplot/gnuplotrc
+overridden by the gnuplotrc, .gnuplot, or $XDG_CONFIG_HOME/gnuplot/gnuplotrc
 start-up files and, of course, by later explicit "set terminal" commands.
 .TP
 .B GNUHELP 

[PATCH] support XDG_CONFIG_HOME on macOS

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

macOS does not define __unix__ but it can support XDG_CONFIG_HOME.

I believe just checking for __APPLE__ is enough, but added a check for
__MACH__ since it is the method recommended by Apple (and used in m4/apple.m4).


diff --git a/src/plot.c b/src/plot.c
index 8e91239cf..f41a192b0 100644
--- a/src/plot.c
+++ b/src/plot.c
@@ -789,7 +789,7 @@ load_rcfile(int where)
 	PATH_CONCAT(rcfile, PLOTRC);
 	plotrc = fopen(rcfile, "r");
     } else if (where == 3) {
-#ifdef __unix__
+#if defined(__unix__) || (defined(__APPLE__) && defined(__MACH__))
 	char * XDGConfigHome = xdg_get_var(kXDGConfigHome);
 	size_t len = strlen(XDGConfigHome);
 	rcfile = gp_alloc(len + 1 + sizeof("gnuplot/gnuplotrc"), "rcfile");
diff --git a/src/xdg.c b/src/xdg.c
index 93e4c227d..985dc77d4 100644
--- a/src/xdg.c
+++ b/src/xdg.c
@@ -2,7 +2,7 @@
 #include "plot.h"
 #include "util.h"
 
-#ifdef __unix__
+#if defined(__unix__) || (defined(__APPLE__) && defined(__MACH__))
 
 #include <assert.h>
 #include <stdio.h>
@@ -57,4 +57,4 @@ char *xdg_get_var(const XDGVarType idx) {
     return XDGVar;
 }
 
-#endif /* __unix__ */
+#endif /* __unix__ || macOS */
diff --git a/src/xdg.h b/src/xdg.h
index acfdda19d..8460edfa0 100644
--- a/src/xdg.h
+++ b/src/xdg.h
@@ -1,7 +1,7 @@
 #ifndef GNUPLOT_XDG_H
 #define GNUPLOT_XDG_H
 
-#ifdef __unix__
+#if defined(__unix__) || (defined(__APPLE__) && defined(__MACH__))
 
 /* List of possible XDG variables */
 typedef enum {
@@ -16,7 +16,7 @@ typedef enum {
 
 char *xdg_get_var(const XDGVarType idx);
 
-#endif /* __unix__ */
+#endif /* __unix__ || macOS */
 
 #endif /* GNUPLOT_XDG_H */
 

Re: ECCN Request

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

On Tuesday, 17 August 2021 14:55:13 PDT Tait wrote:
> 
> I take the silence to mean nobody else knows or has looked into
> this either. A bunch of volunteers writing open-source software
> would have little reason to deal with export control
> regulations, so perhaps that not surprising. Please do not
> consider this any sort of remotely authoritative answer! I'm
> just an uninformed nobody eyeballing things. If you need an ECCN
> for whatever you're doing, then I believe you'll need to
> self-certify that gnuplot is EAR99.

My first take is doubt that any "exported item" is involved.
Who is exporting what from where to where?

If someone out there is shipping/exporting a product that
falls under the jurisdiction of the US Dept of Commerce and 
incorporates gnuplot, then maybe they need an export code
for their product.  But that's on them, not on us.
And it would be an export code for their product, not a 
code for gnuplot, although the inclusion of gnuplot might
indicate that the export code would include a letter "D".

	with the usual disclaimer that I am not a lawyer
	and this is not legal advice,

		Ethan


> "Balick, Rebekah C [US] (ES)" <Reb...@ng...> said (on 2021/08/02):
> > 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: ECCN Request

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

I take the silence to mean nobody else knows or has looked into
this either. A bunch of volunteers writing open-source software
would have little reason to deal with export control
regulations, so perhaps that not surprising. Please do not
consider this any sort of remotely authoritative answer! I'm
just an uninformed nobody eyeballing things. If you need an ECCN
for whatever you're doing, then I believe you'll need to
self-certify that gnuplot is EAR99.

Ethan and 

"Balick, Rebekah C [US] (ES)" <Reb...@ng...> said (on 2021/08/02):
> 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!
> 


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

Re: [PATCH] suppress 'invalid font size' warning from aqua terminal

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

Applied.
Thanks
	Ethan

On Wednesday, 4 August 2021 20:54:24 PDT Jun T wrote:
> On macOS, if I run
> 
> gnuplot> set term aqua
> 
> I get
> 
> warning: invalid terminal font size
> 
> It seems there is no real problem here, but it is somewhat annoying.
> 
> This can be fixed by calling set_font_size() always, i.e.,
> even if fsize is not specified in the 'set term' command.
> (set_font_size() sets term->h_char and v_char)
> 
> 
> diff --git a/term/aquaterm.trm b/term/aquaterm.trm
> index 939ac8411..f24595465 100644
> --- a/term/aquaterm.trm
> +++ b/term/aquaterm.trm
> @@ -234,7 +234,6 @@ AQUA_options()
>  	if (size > 0)
>  	    AQUA_fontSizeDef = size;
>  	AQUA_fontSizeCur = AQUA_fontSizeDef;
> -	set_font_size(AQUA_fontSizeCur);
>  
>  	continue;
>      }
> @@ -250,7 +249,6 @@ AQUA_options()
>  	if ((size = real_expression()) > 0)
>  	    AQUA_fontSizeDef = size;
>  	AQUA_fontSizeCur = AQUA_fontSizeDef;
> -	set_font_size(AQUA_fontSizeCur);
>  	continue;
>      }
>  
> @@ -308,6 +306,7 @@ AQUA_options()
>  
>      int_error(c_token, "unexpected text at end of command");
>    }
> +  set_font_size(AQUA_fontSizeCur);
>  
>    if (AQUA_title[0]=='\0') /* always set title */
>      sprintf(AQUA_title, "Figure %d", AQUA_plotRef);

[PATCH] suppress 'invalid font size' warning from aqua terminal

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

On macOS, if I run

gnuplot> set term aqua

I get

warning: invalid terminal font size

It seems there is no real problem here, but it is somewhat annoying.

This can be fixed by calling set_font_size() always, i.e.,
even if fsize is not specified in the 'set term' command.
(set_font_size() sets term->h_char and v_char)


diff --git a/term/aquaterm.trm b/term/aquaterm.trm
index 939ac8411..f24595465 100644
--- a/term/aquaterm.trm
+++ b/term/aquaterm.trm
@@ -234,7 +234,6 @@ AQUA_options()
 	if (size > 0)
 	    AQUA_fontSizeDef = size;
 	AQUA_fontSizeCur = AQUA_fontSizeDef;
-	set_font_size(AQUA_fontSizeCur);
 
 	continue;
     }
@@ -250,7 +249,6 @@ AQUA_options()
 	if ((size = real_expression()) > 0)
 	    AQUA_fontSizeDef = size;
 	AQUA_fontSizeCur = AQUA_fontSizeDef;
-	set_font_size(AQUA_fontSizeCur);
 	continue;
     }
 
@@ -308,6 +306,7 @@ AQUA_options()
 
     int_error(c_token, "unexpected text at end of command");
   }
+  set_font_size(AQUA_fontSizeCur);
 
   if (AQUA_title[0]=='\0') /* always set title */
     sprintf(AQUA_title, "Figure %d", AQUA_plotRef);

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>