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

Re: inquiry make documentation on native windows

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

On Sunday, 2 January 2022 05:20:28 PST Tatsuro MATSUOKA wrote:
> Ethan
> Thank you for your reply.
> > 
> I attached the above patch, situation will be better but is not complete yet,
> I met the error below in both MikTeX on windows and TeXLive2021 on the cygwin64.
> 
> ****************************************************************************
> (gpinsetfigure.tex
> 
> ! LaTeX Error: Command \gpinsetfigure already defined.
>                Or name \end... illegal, see p.192 of the manual.


I apologize.  The patch I gave was incomplete.
It should also have changed the previous two lines in the Makefile.
Here is a more complete patch:

	Ethan

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff --git a/config/mingw/Makefile b/config/mingw/Makefile
index 3c578b27e..cc0adcce5 100644
--- a/config/mingw/Makefile
+++ b/config/mingw/Makefile
@@ -953,8 +953,11 @@ gnuplot.ps: gnuplot.dvi
 
 gnuplot.pdf: gnuplot-figures.tex $(TOP)/VERSION $(D)toc_entr.sty $(D)titlepag.tex
 	cp gnuplot-figures.tex gp_tex2.tex
-	echo "\usepackage{graphicx}" > pdffigures.tex
-	echo "\usepackage{picins}" >> pdffigures.tex
+	echo "\usepackage{graphicx}" > gpinsetfigures.tex
+	echo "\usepackage{picins}" >> gpinsetfigures.tex
+	echo "\newcommand{\gpinsetfigure}[1]{" >> gpinsetfigure.tex ; \
+	echo "  \parpic[r][rt]{\includegraphics[width=3in,keepaspectratio]{#1}}" >> gpinsetfigure.tex ; \
+	echo "}" >> gpinsetfigure.tex
 	# Call LaTeX three times to get the toc right.
 	TEXINPUTS=.:$(TOP):$(D):${TEXINPUTS}: pdflatex gp_tex2.tex
 	TEXINPUTS=.:$(TOP):$(D):${TEXINPUTS}: pdflatex gp_tex2.tex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Re: inquiry make documentation on native windows

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

Ethan
Thank you for your reply.

> That would not surprise me. I broke it on linux also :-(
> See Bug #2453
> I tried to fix that, but it could be that I made things worse.
> 
> 
> Is it this file?
>    .../config/mingw/Makefile
> 
> How is that file generated?
> Is it automatically created or is it edited by hand?

On native windows, there are no mechanisms for automatic generation for Makefile 
and need to edit it by hand.
I usually store the changes into the diff file and restore the changes by patch command at each cloning file image.

> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> diff --git a/config/mingw/Makefile b/config/mingw/Makefile
> index 3c578b27e..80b4824c0 100644
> --- a/config/mingw/Makefile
> +++ b/config/mingw/Makefile
> @@ -955,6 +955,9 @@ gnuplot.pdf: gnuplot-figures.tex $(TOP)/VERSION $(D)toc_entr.sty $(D)titlepag.te
>  	cp gnuplot-figures.tex gp_tex2.tex
>  	echo "\usepackage{graphicx}" > pdffigures.tex
>  	echo "\usepackage{picins}" >> pdffigures.tex
> +	echo "\newcommand{\gpinsetfigure}[1]{" >> gpinsetfigure.tex ; \
> +	echo "  \parpic[r][rt]{\includegraphics[width=3in,keepaspectratio]{#1}}" >> gpinsetfigure.tex ; \
> +	echo "}" >> gpinsetfigure.tex
>  	# Call LaTeX three times to get the toc right.
>  	TEXINPUTS=.:$(TOP):$(D):${TEXINPUTS}: pdflatex gp_tex2.tex
>  	TEXINPUTS=.:$(TOP):$(D):${TEXINPUTS}: pdflatex gp_tex2.tex
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I attached the above patch, situation will be better but is not complete yet,
I met the error below in both MikTeX on windows and TeXLive2021 on the cygwin64.

****************************************************************************
(gpinsetfigure.tex

! LaTeX Error: Command \gpinsetfigure already defined.
               Or name \end... illegal, see p.192 of the manual.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

l.6 }

?
****************************************************************************

> 良いお年を

Year I am glad to hear your message and am happy spending good new year days.
A happy new year!

Tatsuro


 
> On Saturday, 1 January 2022 21:31:47 PST Tatsuro MATSUOKA wrote:
> > In development source (5.5), 'make docs' stops at the below
> > 
> > *********************************************
> >  ! Undefined control sequence.
> > l.1626 \gpinsetfigure
> >                      {figure_E0}
> > ?
> > *********************************************
> > 
> > All outputs are given
> > http://tmacchant33.starfree.jp/Files/latex-error.txt
> > 
> > The error does not occur in Cygwin build.
> > 
> > For native windows build, I have used the MikTeX that are usable  without problem until 5.4 sources.
> > 
> > Today I tried to use Cygwin's Texlive 2021 in the mingw build, the results are almost the same.
> >  
> > Any suggestions are welcome.
> 
> 
> At the very top of your log file are these lines
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>    $ PATH=/f/Programs/MiKTeX/miktex/bin/x64:$PATH make docs
>    cp gnuplot-figures.tex gp_tex2.tex
>    echo "\usepackage{graphicx}" > pdffigures.tex
>    echo "\usepackage{picins}" >> pdffigures.tex
>    # Call LaTeX three times to get the toc right.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> I think this means that your build path under Windows uses a Makefile
> I did not know about and therefore failed to include when modifying
> the mechanism for figure generation in commits    0a0a64   12aabd   
> 
> That would not surprise me. I broke it on linux also :-(
> See Bug #2453
> I tried to fix that, but it could be that I made things worse.
> 
> 
> Is it this file?
>    .../config/mingw/Makefile
> 
> How is that file generated?
> Is it automatically created or is it edited by hand?
> 
> I think that the patch below would fix the problem you show,
> but I don't know whether to apply it to that file directly or
> apply it to a higher-level Makefile.am or Makefile.in.
> 
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> diff --git a/config/mingw/Makefile b/config/mingw/Makefile
> index 3c578b27e..80b4824c0 100644
> --- a/config/mingw/Makefile
> +++ b/config/mingw/Makefile
> @@ -955,6 +955,9 @@ gnuplot.pdf: gnuplot-figures.tex $(TOP)/VERSION $(D)toc_entr.sty $(D)titlepag.te
>  	cp gnuplot-figures.tex gp_tex2.tex
>  	echo "\usepackage{graphicx}" > pdffigures.tex
>  	echo "\usepackage{picins}" >> pdffigures.tex
> +	echo "\newcommand{\gpinsetfigure}[1]{" >> gpinsetfigure.tex ; \
> +	echo "  \parpic[r][rt]{\includegraphics[width=3in,keepaspectratio]{#1}}" >> gpinsetfigure.tex ; \
> +	echo "}" >> gpinsetfigure.tex
>  	# Call LaTeX three times to get the toc right.
>  	TEXINPUTS=.:$(TOP):$(D):${TEXINPUTS}: pdflatex gp_tex2.tex
>  	TEXINPUTS=.:$(TOP):$(D):${TEXINPUTS}: pdflatex gp_tex2.tex
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> 良いお年を
> 
> Ethan
> 

Re: inquiry make documentation on native windows

[Hans-Bernhard B. <HBB...@t-...>]

Am 02.01.2022 um 08:56 schrieb Ethan A Merritt:

> Is it this file?
>     .../config/mingw/Makefile >
> How is that file generated?

It's not. All the actual makefiles in the "config" sub tree are 
hand-written, except for the source file lists they import from the 
generated src/makefile.all and src/makefile.awc.  The Makefile.am in 
there is just for organizing the tarball.

There's a case to be made that a CMake setup could replace a large part 
of those, particularly mingw, cygwin, msvc.  Among other things, that 
could reduce the extra work of maintaining them all.

I have a CMake script here that does most of what config/cygwin and 
config/msvc achieve.  I haven't yet tried to add the extra work as done 
by config/mingw: no TeX, no Japanese docs, etc.

Re: inquiry make documentation on native windows

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

On Saturday, 1 January 2022 21:31:47 PST Tatsuro MATSUOKA wrote:
> In development source (5.5), 'make docs' stops at the below
> 
> *********************************************
>  ! Undefined control sequence.
> l.1626 \gpinsetfigure
>                      {figure_E0}
> ?
> *********************************************
> 
> All outputs are given
> http://tmacchant33.starfree.jp/Files/latex-error.txt
> 
> The error does not occur in Cygwin build.
> 
> For native windows build, I have used the MikTeX that are usable  without problem until 5.4 sources.
> 
> Today I tried to use Cygwin's Texlive 2021 in the mingw build, the results are almost the same.
>  
> Any suggestions are welcome.


At the very top of your log file are these lines
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   $ PATH=/f/Programs/MiKTeX/miktex/bin/x64:$PATH make docs
   cp gnuplot-figures.tex gp_tex2.tex
   echo "\usepackage{graphicx}" > pdffigures.tex
   echo "\usepackage{picins}" >> pdffigures.tex
   # Call LaTeX three times to get the toc right.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I think this means that your build path under Windows uses a Makefile
I did not know about and therefore failed to include when modifying
the mechanism for figure generation in commits    0a0a64   12aabd   

That would not surprise me. I broke it on linux also :-(
See Bug #2453
I tried to fix that, but it could be that I made things worse.


Is it this file?
   .../config/mingw/Makefile

How is that file generated?
Is it automatically created or is it edited by hand?

I think that the patch below would fix the problem you show,
but I don't know whether to apply it to that file directly or
apply it to a higher-level Makefile.am or Makefile.in.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff --git a/config/mingw/Makefile b/config/mingw/Makefile
index 3c578b27e..80b4824c0 100644
--- a/config/mingw/Makefile
+++ b/config/mingw/Makefile
@@ -955,6 +955,9 @@ gnuplot.pdf: gnuplot-figures.tex $(TOP)/VERSION $(D)toc_entr.sty $(D)titlepag.te
 	cp gnuplot-figures.tex gp_tex2.tex
 	echo "\usepackage{graphicx}" > pdffigures.tex
 	echo "\usepackage{picins}" >> pdffigures.tex
+	echo "\newcommand{\gpinsetfigure}[1]{" >> gpinsetfigure.tex ; \
+	echo "  \parpic[r][rt]{\includegraphics[width=3in,keepaspectratio]{#1}}" >> gpinsetfigure.tex ; \
+	echo "}" >> gpinsetfigure.tex
 	# Call LaTeX three times to get the toc right.
 	TEXINPUTS=.:$(TOP):$(D):${TEXINPUTS}: pdflatex gp_tex2.tex
 	TEXINPUTS=.:$(TOP):$(D):${TEXINPUTS}: pdflatex gp_tex2.tex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

良いお年を

Ethan

inquiry make documentation on native windows

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

In development source (5.5), 'make docs' stops at the below

*********************************************
 ! Undefined control sequence.
l.1626 \gpinsetfigure
                     {figure_E0}
?
*********************************************

All outputs are given
http://tmacchant33.starfree.jp/Files/latex-error.txt

The error does not occur in Cygwin build.

For native windows build, I have used the MikTeX that are usable  without problem until 5.4 sources.

Today I tried to use Cygwin's Texlive 2021 in the mingw build, the results are almost the same.
 
Any suggestions are welcome.

Tatsuro

Re: Beta-testing version of 5.4.3

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

On Friday, 24 December 2021 03:25:21 PST Tatsuro MATSUOKA wrote:
> I also build gnuplot on cygwin64.
> Build and make check went  well.

Thank you for the report.

	Ethan


> 
> Tatsuro
> 
> > ----- Original Message -----
> > 
> > From: "Ethan A Merritt" 
> > To: "Gnuplot Beta" 
> > Date: 2021/12/24 金 13:20
> > Subject: Beta-testing version of 5.4.3
> > 
> > 
> > I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
> > Please report any problems or requests for inclusion by the end of this year.
> > 
> > There is nothing special in this minor release. Mostly small fixes to
> > individual terminals, configuration of byte-array data for little-endian
> > platforms, and a few items back-ported from the development version.
> > For a slightly more complete list of changes see the Release Notes.
> > 
> >   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.3beta.tar.gz
> > 
> > My plan is to put out the 5.4.3 release version in the first week of January.
> > 
> > 	happy gnuplotting,
> > 
> > 		Ethan
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 
> 
> _______________________________________________
> 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: Beta-testing version of 5.4.3

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

I also build gnuplot on cygwin64.
Build and make check went  well.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" 
> To: "Gnuplot Beta" 
> Date: 2021/12/24 金 13:20
> Subject: Beta-testing version of 5.4.3
> 
> 
> I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
> Please report any problems or requests for inclusion by the end of this year.
> 
> There is nothing special in this minor release. Mostly small fixes to
> individual terminals, configuration of byte-array data for little-endian
> platforms, and a few items back-ported from the development version.
> For a slightly more complete list of changes see the Release Notes.
> 
>   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.3beta.tar.gz
> 
> My plan is to put out the 5.4.3 release version in the first week of January.
> 
> 	happy gnuplotting,
> 
> 		Ethan
> 
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Re: Beta-testing version of 5.4.3

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

I forgot to mention another bug #2476 (font problem on qt terminal on windows) and 
a topic on windows :  default encoding on Japanese windows environment
https://sourceforge.net/p/gnuplot/mailman/message/37402920/

Both might be be treated as the windows installer setting.

Tatsuro

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA" 
> To: "merritt Gnuplot Beta"
> Date: 2021/12/24 金 19:35
> Subject: Re: Beta-testing version of 5.4.3
> 
> 
> I could build 5.4.3b on windows.
> The bug #2412 (pipe issue) is fixed in 5.4.3b.
> 
> Further investigation might  be carried out by Bastian.
> 
> Tatsuro
> 
> > ----- Original Message -----
> > 
> > From: "Ethan A Merritt" 
> > To: "Gnuplot Beta" >
> > Date: 2021/12/24 金 13:20
> > Subject: Beta-testing version of 5.4.3
> > 
> > 
> > I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
> > Please report any problems or requests for inclusion by the end of this year.
> > 
> > There is nothing special in this minor release. Mostly small fixes to
> > individual terminals, configuration of byte-array data for little-endian
> > platforms, and a few items back-ported from the development version.
> > For a slightly more complete list of changes see the Release Notes.
> > 
> >   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.3beta.tar.gz
> > 
> > My plan is to put out the 5.4.3 release version in the first week of January.
> > 
> > 	happy gnuplotting,
> > 
> > 		Ethan
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Beta-testing version of 5.4.3

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

I could build 5.4.3b on windows.
The bug #2412 (pipe issue) is fixed in 5.4.3b.

Further investigation might  be carried out by Bastian.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" 
> To: "Gnuplot Beta" >
> Date: 2021/12/24 金 13:20
> Subject: Beta-testing version of 5.4.3
> 
> 
> I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
> Please report any problems or requests for inclusion by the end of this year.
> 
> There is nothing special in this minor release. Mostly small fixes to
> individual terminals, configuration of byte-array data for little-endian
> platforms, and a few items back-ported from the development version.
> For a slightly more complete list of changes see the Release Notes.
> 
>   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.3beta.tar.gz
> 
> My plan is to put out the 5.4.3 release version in the first week of January.
> 
> 	happy gnuplotting,
> 
> 		Ethan
> 
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Beta-testing version of 5.4.3

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

I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
Please report any problems or requests for inclusion by the end of this year.

There is nothing special in this minor release. Mostly small fixes to
individual terminals, configuration of byte-array data for little-endian
platforms, and a few items back-ported from the development version.
For a slightly more complete list of changes see the Release Notes.

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

My plan is to put out the 5.4.3 release version in the first week of January.

	happy gnuplotting,

		Ethan

Re: spurious messages at first plot on qt terminal on Cygwin

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

Sorry I found my old post.
https://sourceforge.net/p/gnuplot/mailman/gnuplot-beta/thread/211253.49218.qm%40web103117.mail.kks.yahoo.co.jp/

Tatsuro

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA" <tma...@ya...>
> To: "beta" <gnu...@li...>
> Date: 2021/12/19 日 14:14
> Subject: spurious messages at first plot on qt terminal on Cygwin
> 
> 
> As far as I remenber, I made the similar question on the phenomena.
> 
> After workaround by  by  Enrico Forestieri 
> https://sourceforge.net/p/gnuplot/mailman/gnuplot-beta/thread/160...@we.../
> I could use qt termninal on Cygwin again.
> 
> At first plot in the interactive mode, spurious messages appear.
> 
> Terminal type is now 'qt'
> gnuplot> plot x
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user'
> libGL error: Windows-DRI extension not available
> libGL error: No matching fbConfigs or visuals found
> libGL error: failed to load driver: swrast
> gnuplot> QXcbShmImage: shmget() failed (88: Function not implemented) for size 1394424 (642x543)
> 
> From the second plot the above messages do not appear.
> 
> It will be grateful for me is someone will give me suggestions and comments.
> 
> Tatsuro
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

spurious messages at first plot on qt terminal on Cygwin

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

As far as I remenber, I made the similar question on the phenomena.

After workaround by  by  Enrico Forestieri 
https://sourceforge.net/p/gnuplot/mailman/gnuplot-beta/thread/160...@we.../
I could use qt termninal on Cygwin again.

At first plot in the interactive mode, spurious messages appear.

Terminal type is now 'qt'
gnuplot> plot x
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user'
libGL error: Windows-DRI extension not available
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
gnuplot> QXcbShmImage: shmget() failed (88: Function not implemented) for size 1394424 (642x543)

>From the second plot the above messages do not appear.

It will be grateful for me is someone will give me suggestions and comments.

Tatsuro

windows binary package distribution is upadated. (Now qt terminal is available.)

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

Packaging issue for the qt terminal is solved.

A new package with qt terminal is avaiable the below :
http://tmacchant33.starfree.jp/gnuplot_bin.html

Important information is also described.

Tatsuro

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA" <tma...@ya...>
> To: "gnu...@li..." <gnu...@li...>
> Date: 2021/12/17 金 03:52
> Subject: windows binary package distribution  of the development version is resumed.
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: AW: Re: default encoding on Japanese windows environment

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

> Changing the default for gnuplot is as easy as adding "set encoding utf8" to "gnuplot.ini".  We could add an option to the installer to make utf8 the default instead of the "ANSI" codepage, though, similar to the selection of the default terminal.

Your idea of addtion of an option to the installer is really good!

Tatsuro 


> ----- Original Message -----
> 
> From: "Bastian Märkisch" <bma...@we...>
> To: "'Tatsuro MATSUOKA'" <tma...@ya...>; "eam...@gm..." <eam...@gm...>; "'beta'" <gnu...@li...>
> Date: 2021/12/17 金 17:29
> Subject: AW: Re: default encoding on Japanese windows environment
> 
> 
> Please note that setting the default process code page to UTF-8 is a new (beta) feature (1903) which might not be supported by LTS installations yet (mine doesn't). (Setting an environment variable won't do the trick though).
> 
> Changing the default for gnuplot is as easy as adding "set encoding utf8" to "gnuplot.ini".  We could add an option to the installer to make utf8 the default instead of the "ANSI" codepage, though, similar to the selection of the default terminal.
> 
>   Bastian
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Tatsuro MATSUOKA <tma...@ya...>
> > Gesendet: Donnerstag, 16. Dezember 2021 23:57
> > An: eam...@gm...; beta <gnu...@li...>
> > Betreff: Re: Re: default encoding on Japanese windows environment
> > 
> > Ethan
> > 
> > Thank you for your detailed explanation.
> > I surely have misunderstood the situation.
> > 
> > > 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?
> > 
> > Behavior cp65001 of current windows 10 is changed before.
> >   past :Japanese font cannot be selected .IME input of Japanese characters is
> > impossible
> >   now : Japanese font can be selected. IME input Japanese characters is
> > possible.
> > I do not know when the above change ocurr.
> > 
> > I think that the user manual is appropriate.
> > 
> > Tatsuro
> > 
> > > ----- Original Message -----
> > >
> > >
> > > 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?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via:
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

AW: Re: default encoding on Japanese windows environment

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

Please note that setting the default process code page to UTF-8 is a new (beta) feature (1903) which might not be supported by LTS installations yet (mine doesn't). (Setting an environment variable won't do the trick though).

Changing the default for gnuplot is as easy as adding "set encoding utf8" to "gnuplot.ini".  We could add an option to the installer to make utf8 the default instead of the "ANSI" codepage, though, similar to the selection of the default terminal.

  Bastian

> -----Ursprüngliche Nachricht-----
> Von: Tatsuro MATSUOKA <tma...@ya...>
> Gesendet: Donnerstag, 16. Dezember 2021 23:57
> An: eam...@gm...; beta <gnu...@li...>
> Betreff: Re: Re: default encoding on Japanese windows environment
> 
> Ethan
> 
> Thank you for your detailed explanation.
> I surely have misunderstood the situation.
> 
> > 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?
> 
> Behavior cp65001 of current windows 10 is changed before.
>   past :Japanese font cannot be selected .IME input of Japanese characters is
> impossible
>   now : Japanese font can be selected. IME input Japanese characters is
> possible.
> I do not know when the above change ocurr.
> 
> I think that the user manual is appropriate.
> 
> Tatsuro
> 
> > ----- Original Message -----
> >
> >
> > 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?
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Re: default encoding on Japanese windows environment

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

Ethan

Thank you for your detailed explanation.
I surely have misunderstood the situation.

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

Behavior cp65001 of current windows 10 is changed before.
  past :Japanese font cannot be selected .IME input of Japanese characters is impossible
  now : Japanese font can be selected. IME input Japanese characters is possible.
I do not know when the above change ocurr.

I think that the user manual is appropriate.

Tatsuro

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