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

Re: default encoding on Japanese windows environment

[Ethan M. <eam...@gm...>]

On Thursday, 16 December 2021 11:50:25 PST Tatsuro MATSUOKA wrote:
> We consider the case where there is no "set encoding xxxx" in GNUPLOT.INT and GNUTERM is not specified.
> At start up, excution result of "show encoding"
> Cygwin => default (Perhaps on Linux the same)
> Windows (on Japanese env.) => sjis (ShiftJIS, old Japanese encording)
> Windows (not Japanese env.) => I do not know
> 
> Now even on Windows standard text editor notepad.exe, default encoding is utf8 but not sjis.
> Sjis encording is only for backward compatibility.

Are you sure this is set by the program and not by the system or user preferences?
 
> sjis being default encoding on windows on Japanese env. is better to be stopped.

So far as I know gnuplot would only start with encoding SJIS if the user's computer
has current locale set to use sjis.

Gnuplot's initialization is done in routine encoding_from_locale() in file encoding.c.

It first tries to use the system function
	    l = setlocale(LC_CTYPE, "");

The man page says
       If locale is an empty string, "", each part of the locale that should be  modified  is
       set according to the environment variables.  The details are implementation-dependent.
       For glibc, first (regardless of category), the  environment  variable  LC_ALL  is  in‐
       spected, next the environment variable with the same name as the category (see the ta‐
       ble above), and finally the environment variable LANG.  The first existing environment
       variable is used.  If its value is not a valid locale specification, the locale is un‐
       changed, and setlocale() returns NULL.

On linux an appropriate japanese locale string is "ja_JP.UTF-8"
but I know that Windows uses different names for locales.

Do you know if your Japanese env. machine is returning a valid locale specification at this
point?   If so, that is what gnuplot will use.   If no valid return is detected, the program
then falls through to this code:
#ifdef _WIN32
    /* get encoding from currently active codepage */
    if (encoding == S_ENC_INVALID) {
#ifndef WGP_CONSOLE
        encoding = map_codepage_to_encoding(GetACP());
#else
        encoding = map_codepage_to_encoding(GetConsoleCP());
#endif
    }
#endif

So I think that to change the initial encoding in gnuplot, the user needs to either
(1) set an appropriate environmental variable global to the session or
(2) set the code page to CP65001.

Is there a good place to find instructions on how to do this?
Should we add a section to the installation instructions or the user manual?

Re: Re: dafault terminal on windows

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

> That is evidence of a font problem.
It seem to be better to move to the bug ticket.

> If I recall correctly, you can configure wxWidgets to use
> different system back-ends.  If you can figure out what
> configuration option wxt is using to get correct font metrics,
> maybe we can persuade qt to use that same mechanism.
I have only built wxMSW for native windows. 
I used wxGTK for Cygwin.
I do not know whether wxGTK works on windows.

Tatsuro

 

> ----- Original Message -----
> On Wednesday, 15 December 2021 14:39:14 PST Tatsuro MATSUOKA wrote:
> > > This is the first I have heard about broken demos.
> > > Why does the terminal make a difference?
> > > Is this because of UTF-8 encoding?  But that is not specific to qt.
> > 
> > Proportion of size for qt terminal sometimes strane qt terminal for windows.
> > (qt terminal on linux environments(including cywin) strange plots do not appear)
> > 
> > One example jitter.dem
> > http://tmacchant33.starfree.jp/Files/jitter_qt_win.png
> > http://tmacchant33.starfree.jp/Files/jitter_wxt_win.png
> > http://tmacchant33.starfree.jp/Files/jitter_windows_win.png
> 
> That is evidence of a font problem.
> The jitter algorithm calculates displacement in terms of
> horizontal character width, which is obtained from the font
> metrics.  If the font incorrectly reports the width, then
> all of the jitter displacements are too big or too small.
> 
> I am a bit surprised that the wxt terminal doesn't show the
> same problem.  On linux, both qt and wxt use the same font
> mechanism.  But perhaps this isn't the case on Windows.
> 
> If I recall correctly, you can configure wxWidgets to use
> different system back-ends.  If you can figure out what
> configuration option wxt is using to get correct font metrics,
> maybe we can persuade qt to use that same mechanism.
> 
> 	Ethan
> 
> 
> 
> 

Re: dafault terminal on windows

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

On Wednesday, 15 December 2021 14:39:14 PST Tatsuro MATSUOKA wrote:
> > This is the first I have heard about broken demos.
> > Why does the terminal make a difference?
> > Is this because of UTF-8 encoding?  But that is not specific to qt.
> 
> Proportion of size for qt terminal sometimes strane qt terminal for windows.
> (qt terminal on linux environments(including cywin) strange plots do not appear)
> 
> One example jitter.dem
> http://tmacchant33.starfree.jp/Files/jitter_qt_win.png
> http://tmacchant33.starfree.jp/Files/jitter_wxt_win.png
> http://tmacchant33.starfree.jp/Files/jitter_windows_win.png

That is evidence of a font problem.
The jitter algorithm calculates displacement in terms of
horizontal character width, which is obtained from the font
metrics.  If the font incorrectly reports the width, then
all of the jitter displacements are too big or too small.

I am a bit surprised that the wxt terminal doesn't show the
same problem.  On linux, both qt and wxt use the same font
mechanism.  But perhaps this isn't the case on Windows.

If I recall correctly, you can configure wxWidgets to use
different system back-ends.  If you can figure out what
configuration option wxt is using to get correct font metrics,
maybe we can persuade qt to use that same mechanism.

	Ethan

default encoding on Japanese windows environment

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

We consider the case where there is no "set encoding xxxx" in GNUPLOT.INT and GNUTERM is not sprcified.
At start up, excution result of "show encoding"
Cygwin => default (Perhaps on Linux the same)
Windows (on Japanese env.) => sjis (ShiftJIS, old Japanese encording)
Windows (not Japanese env.) => I do not know

Now even on Windows standard text editor notepad.exe, default encoding is utf8 but not sjis.
Sjis encording is only for backward compatibility.

sjis being default encoding on windows on Japanese env. is better to be stopped.

Tatsuro  

windows binary package distribution of the development version is resumed.

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

I resumed to distribute windows binary package for the development version because  I  recieved the request.
http://tmacchant33.starfree.jp/gnuplot_bin.html

Notes
Because of  initairization issue for qt terminal, the qt terminal is omitted at the moment.
I only provide a zip archived package at the moment. 
Distribution cycle is not so frequent as before.

Please try new features .and feedback to gnuplot-beta mailing-list or ticket in the SourceForge.

Tatsuro

Re: dafault terminal on windows

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

> This is the first I have heard about broken demos.
> Why does the terminal make a difference?
> Is this because of UTF-8 encoding?  But that is not specific to qt.

Proportion of size for qt terminal sometimes strane qt terminal for windows.
(qt terminal on linux environments(including cywin) strange plots do not appear)

One example jitter.dem
http://tmacchant33.starfree.jp/Files/jitter_qt_win.png
http://tmacchant33.starfree.jp/Files/jitter_wxt_win.png
http://tmacchant33.starfree.jp/Files/jitter_windows_win.png

> I have no opinion on the windows default terminal.
> If there is consensus that it should be changed,
> it would be good to make that change soon.
> 
> I was thinking that January 1 would be a good target date for
> the 5.4.3 minor release, and planned to package up a testing
> I have no opinion on the windows default terminal.
> If there is consensus that it should be changed,
> it would be good to make that change soon.

I will follow Bastian's decision.

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2021/12/16 木 07:02
> Subject: Re: dafault terminal on windows
> 
> 
> On Wednesday, 15 December 2021 13:38:24 PST Tatsuro MATSUOKA wrote:
> > I realized that defalut terminal is qt on gnuplot windows on version 5.4.
> > However, many plots of all.demo are still broken in qt terminal.
> 
> ??
> This is the first I have heard about broken demos.
> Why does the terminal make a difference?
> Is this because of UTF-8 encoding?  But that is not specific to qt.
> 
> 
> > Why qt terminal becomes defaut from 5.4 (For 5.2 wxt is default)? 
> > windows terminal is now improved.
> > Is there possibility to go back where windows terminal is default?
> 
> I have no opinion on the windows default terminal.
> If there is consensus that it should be changed,
> it would be good to make that change soon.
> 
> I was thinking that January 1 would be a good target date for
> the 5.4.3 minor release, and planned to package up a testing
> I have no opinion on the windows default terminal.
> If there is consensus that it should be changed,
> it would be good to make that change soon.
> 
> I was thinking that January 1 would be a good target date for
> the 5.4.3 minor release, and planned to package up a testing

> tarball 5.4.3-alpha next week. 
> 
> 
> 	Ethan
> 
> 
> 

Re: dafault terminal on windows

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

On Wednesday, 15 December 2021 13:38:24 PST Tatsuro MATSUOKA wrote:
> I realized that defalut terminal is qt on gnuplot windows on version 5.4.
> However, many plots of all.demo are still broken in qt terminal.

??
This is the first I have heard about broken demos.
Why does the terminal make a difference?
Is this because of UTF-8 encoding?  But that is not specific to qt.


> Why qt terminal becomes defaut from 5.4 (For 5.2 wxt is default)? 
> windows terminal is now improved.
> Is there possibility to go back where windows terminal is default?

I have no opinion on the windows default terminal.
If there is consensus that it should be changed,
it would be good to make that change soon.

I was thinking that January 1 would be a good target date for
the 5.4.3 minor release, and planned to package up a testing
tarball 5.4.3-alpha next week. 


	Ethan

dafault terminal on windows

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

I realized that defalut terminal is qt on gnuplot windows on version 5.4.
However, many plots of all.demo are still broken in qt terminal.
Why qt terminal becomes defaut from 5.4 (For 5.2 wxt is default)?

windows terminal is now improved.

Is there possibility to go back where windows terminal is default?

Tatsuro

Re: Inquiry for amos routine for expint

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

Ethan
Thank you for your reply

> 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.

For this problem I will struggle further.
With help by Bastian, I could build gnuplot with expint on native windows.
https://sourceforge.net/p/gnuplot/bugs/2475/
Comparing the results  on cygwin and native windows , build gnuplot with exint on cygwin was successful.
Wrong results in expint.dem come from my build ACM routine are not succcessful.

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

I took a little long time to find imformation about amos and acm and information for *1mach.
Therefore it will be grateful if you add Amos source in gnuplot repository.
However, Bastian tell me that ACM is allowed use for non-commercial.

> 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.

It would be grateful for me if send Makefiles and C version of *1mach files.

Tatsuro

> ----- Original Message -----
> 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

[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!