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

Aw: Re: Couldn't find `ps.cfg' while processing FAQ.tex on native Windows

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

Dear Tatsuro,

Please make sure that you have the "times", "mathptmx" and "symbol" packages installed.  This can be easily done using the "MiKTeX Console" (or the package manager if your installation is old). Typically MiKTeX would ask you if it should install packages which are missing during a run of e.g. pdflatex. Why it does not succeed in doing so on your system I do not know.

  Bastian

> Gesendet: Donnerstag, 25. April 2019 um 11:18 Uhr
> Von: "Tatsuro MATSUOKA" <tma...@ya...>
> An: tma...@ya..., gnu...@li...
> Betreff: Re: Couldn't find `ps.cfg' while processing FAQ.tex on native Windows
>
> I could process the faq.tex on Cygwin using texlive.
> I once tried texlive for windows for config/mingw/Makefile build 
> 
> but was in failure.
> 
> I will struggle it.
> At the moment I copy faq.pdf generated on Cygwin.
> 
> 
> 
> ----- Original Message -----
> > From: Tatsuro MATSUOKA 
> > To: gnuplot-beta
> > Cc: 
> > Date: 2019/4/24, Wed 18:32
> > Subject: Couldn't find `ps.cfg' while processing FAQ.tex on native Windows
> > 
> > Commit [bbf941]
> > 
> > 
> > pdflatex ../../faq/faq.tex
> > This is pdfTeX, Version 3.14159265-2.6-1.40.16 (MiKTeX 2.9 64-bit)
> > entering extended mode
> > (../../faq/faq.tex
> > LaTeX2e <2015/10/01> patch level 2
> > Babel <3.9n> and hyphenation patterns for 69 languages loaded.
> > (C:\Programs\MiKTeX_2.9\tex\latex\base\article.cls
> > Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
> > (C:\Programs\MiKTeX_2.9\tex\latex\base\size11.clo))
> > (C:\Programs\MiKTeX_2.9\tex\latex\geometry\geometry.sty
> > (C:\Programs\MiKTeX_2.9\tex\latex\graphics\keyval.sty)
> > (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\ifpdf.sty)
> > (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\ifvtex.sty)
> > (C:\Programs\MiKTeX_2.9\tex\generic\ifxetex\ifxetex.sty)
> > (C:\Programs\MiKTeX_2.9\tex\latex\geometry\geometry.cfg))
> > (C:\Programs\MiKTeX_2.9\tex\latex\base\fontenc.sty
> > (C:\Programs\MiKTeX_2.9\tex\latex\base\t1enc.def))
> > (C:\Programs\MiKTeX_2.9\tex\latex\url\url.sty)
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\times.sty)
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\mathptmx.sty)
> > (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\hyperref.sty
> > (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\hobsub-hyperref.sty
> > (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\hobsub-generic.sty))
> > (C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\auxhook.sty)
> > (C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\kvoptions.sty)
> > (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\pd1enc.def)
> > (C:\Programs\MiKTeX_2.9\tex\latex\00miktex\hyperref.cfg))
> > 
> > Package hyperref Message: Driver (autodetected): hpdftex.
> > 
> > (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\hpdftex.def
> > (C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\rerunfilecheck.sty))
> > (C:\Programs\MiKTeX_2.9\tex\latex\graphics\color.sty
> > (C:\Programs\MiKTeX_2.9\tex\latex\00miktex\color.cfg)
> > (C:\Programs\MiKTeX_2.9\tex\latex\pdftex-def\pdftex.def))
> > No file faq.aux.
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1ptm.fd)
> > *geometry* driver: auto-detecting
> > *geometry* detected driver: pdftex
> > (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\nameref.sty
> > (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\gettitlestring.sty))
> > (C:\Programs\MiKTeX_2.9\tex\context\base\supp-pdf.mkii
> > [Loading MPS to PDF converter (version 2006.09.02).]
> > ) (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\ot1ztmcm.fd)
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omlztmcm.fd)
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omsztmcm.fd)
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omxztmcm.fd)
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\ot1ptm.fd) 
> > [1{C:/Users/MATSUOKA LAB/Ap
> > pData/Local/MiKTeX/2.9/pdftex/config/pdftex.map}]
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1phv.fd)
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omsptm.fd) [2] 
> > [3]
> > (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1pcr.fd) [4] 
> > [5] [6] [7] [8] [9]
> > [10] [11] [12
> > ======================================================================
> > 
> > Unfortunately, the package symbol could not be installed.Please check the log 
> > file:
> > C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/pdflatex.log
> > ======================================================================
> > 
> > ======================================================================
> > 
> > Unfortunately, the package symbol could not be installed.Please check the log 
> > file:
> > C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-maketfm.log
> > ======================================================================
> > Running miktex-makemf.exe...
> > 
> > Sorry, but miktex-makemf did not succeed for the following reason:
> > 
> >   The psyr source file could not be found.
> > 
> > The log file hopefully contains the information to get MiKTeX going again:
> > 
> >   C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-makemf.log
> > 
> > You may want to visit the MiKTeX project page, if you need help.
> > Running hbf2gf.exe...
> > 
> > hbf2gf (CJK ver. 4.8.4)
> > 
> > Couldn't find `ps.cfg'
> > 
> > Sorry, but miktex-maketfm did not succeed for the following reason:
> > 
> >   No creation rule for font psyr.
> > 
> > The log file hopefully contains the information to get MiKTeX going again:
> > 
> >   C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-maketfm.log
> > 
> > You may want to visit the MiKTeX project page, if you need help.
> > 
> > ! Font \csname\endcsname=psyr at 10.95pt not loadable: Metric (TFM) file 
> > not fo
> > und.
> > \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
> >                                                   \fi \fi
> > l.923
> > 
> > ?
> > 
> > 
> > 
> > I seldom use LaTeX. Please give me a hint to overcome the issue.
> > 
> > Tatsuro
> > 
> > 
> > 
> > _______________________________________________
> > 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: Couldn't find `ps.cfg' while processing FAQ.tex on native Windows

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

I could process the faq.tex on Cygwin using texlive.
I once tried texlive for windows for config/mingw/Makefile build 

but was in failure.

I will struggle it.
At the moment I copy faq.pdf generated on Cygwin.



----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: gnuplot-beta
> Cc: 
> Date: 2019/4/24, Wed 18:32
> Subject: Couldn't find `ps.cfg' while processing FAQ.tex on native Windows
> 
> Commit [bbf941]
> 
> 
> pdflatex ../../faq/faq.tex
> This is pdfTeX, Version 3.14159265-2.6-1.40.16 (MiKTeX 2.9 64-bit)
> entering extended mode
> (../../faq/faq.tex
> LaTeX2e <2015/10/01> patch level 2
> Babel <3.9n> and hyphenation patterns for 69 languages loaded.
> (C:\Programs\MiKTeX_2.9\tex\latex\base\article.cls
> Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
> (C:\Programs\MiKTeX_2.9\tex\latex\base\size11.clo))
> (C:\Programs\MiKTeX_2.9\tex\latex\geometry\geometry.sty
> (C:\Programs\MiKTeX_2.9\tex\latex\graphics\keyval.sty)
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\ifpdf.sty)
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\ifvtex.sty)
> (C:\Programs\MiKTeX_2.9\tex\generic\ifxetex\ifxetex.sty)
> (C:\Programs\MiKTeX_2.9\tex\latex\geometry\geometry.cfg))
> (C:\Programs\MiKTeX_2.9\tex\latex\base\fontenc.sty
> (C:\Programs\MiKTeX_2.9\tex\latex\base\t1enc.def))
> (C:\Programs\MiKTeX_2.9\tex\latex\url\url.sty)
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\times.sty)
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\mathptmx.sty)
> (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\hyperref.sty
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\hobsub-hyperref.sty
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\hobsub-generic.sty))
> (C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\auxhook.sty)
> (C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\kvoptions.sty)
> (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\pd1enc.def)
> (C:\Programs\MiKTeX_2.9\tex\latex\00miktex\hyperref.cfg))
> 
> Package hyperref Message: Driver (autodetected): hpdftex.
> 
> (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\hpdftex.def
> (C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\rerunfilecheck.sty))
> (C:\Programs\MiKTeX_2.9\tex\latex\graphics\color.sty
> (C:\Programs\MiKTeX_2.9\tex\latex\00miktex\color.cfg)
> (C:\Programs\MiKTeX_2.9\tex\latex\pdftex-def\pdftex.def))
> No file faq.aux.
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1ptm.fd)
> *geometry* driver: auto-detecting
> *geometry* detected driver: pdftex
> (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\nameref.sty
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\gettitlestring.sty))
> (C:\Programs\MiKTeX_2.9\tex\context\base\supp-pdf.mkii
> [Loading MPS to PDF converter (version 2006.09.02).]
> ) (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\ot1ztmcm.fd)
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omlztmcm.fd)
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omsztmcm.fd)
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omxztmcm.fd)
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\ot1ptm.fd) 
> [1{C:/Users/MATSUOKA LAB/Ap
> pData/Local/MiKTeX/2.9/pdftex/config/pdftex.map}]
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1phv.fd)
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omsptm.fd) [2] 
> [3]
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1pcr.fd) [4] 
> [5] [6] [7] [8] [9]
> [10] [11] [12
> ======================================================================
> 
> Unfortunately, the package symbol could not be installed.Please check the log 
> file:
> C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/pdflatex.log
> ======================================================================
> 
> ======================================================================
> 
> Unfortunately, the package symbol could not be installed.Please check the log 
> file:
> C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-maketfm.log
> ======================================================================
> Running miktex-makemf.exe...
> 
> Sorry, but miktex-makemf did not succeed for the following reason:
> 
>   The psyr source file could not be found.
> 
> The log file hopefully contains the information to get MiKTeX going again:
> 
>   C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-makemf.log
> 
> You may want to visit the MiKTeX project page, if you need help.
> Running hbf2gf.exe...
> 
> hbf2gf (CJK ver. 4.8.4)
> 
> Couldn't find `ps.cfg'
> 
> Sorry, but miktex-maketfm did not succeed for the following reason:
> 
>   No creation rule for font psyr.
> 
> The log file hopefully contains the information to get MiKTeX going again:
> 
>   C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-maketfm.log
> 
> You may want to visit the MiKTeX project page, if you need help.
> 
> ! Font \csname\endcsname=psyr at 10.95pt not loadable: Metric (TFM) file 
> not fo
> und.
> \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
>                                                   \fi \fi
> l.923
> 
> ?
> 
> 
> 
> I seldom use LaTeX. Please give me a hint to overcome the issue.
> 
> Tatsuro
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta 
> 

Couldn't find `ps.cfg' while processing FAQ.tex on native Windows

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

Commit [bbf941]


pdflatex ../../faq/faq.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (MiKTeX 2.9 64-bit)
entering extended mode
(../../faq/faq.tex
LaTeX2e <2015/10/01> patch level 2
Babel <3.9n> and hyphenation patterns for 69 languages loaded.
(C:\Programs\MiKTeX_2.9\tex\latex\base\article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(C:\Programs\MiKTeX_2.9\tex\latex\base\size11.clo))
(C:\Programs\MiKTeX_2.9\tex\latex\geometry\geometry.sty
(C:\Programs\MiKTeX_2.9\tex\latex\graphics\keyval.sty)
(C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\ifpdf.sty)
(C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\ifvtex.sty)
(C:\Programs\MiKTeX_2.9\tex\generic\ifxetex\ifxetex.sty)
(C:\Programs\MiKTeX_2.9\tex\latex\geometry\geometry.cfg))
(C:\Programs\MiKTeX_2.9\tex\latex\base\fontenc.sty
(C:\Programs\MiKTeX_2.9\tex\latex\base\t1enc.def))
(C:\Programs\MiKTeX_2.9\tex\latex\url\url.sty)
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\times.sty)
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\mathptmx.sty)
(C:\Programs\MiKTeX_2.9\tex\latex\hyperref\hyperref.sty
(C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\hobsub-hyperref.sty
(C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\hobsub-generic.sty))
(C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\auxhook.sty)
(C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\kvoptions.sty)
(C:\Programs\MiKTeX_2.9\tex\latex\hyperref\pd1enc.def)
(C:\Programs\MiKTeX_2.9\tex\latex\00miktex\hyperref.cfg))

Package hyperref Message: Driver (autodetected): hpdftex.

(C:\Programs\MiKTeX_2.9\tex\latex\hyperref\hpdftex.def
(C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\rerunfilecheck.sty))
(C:\Programs\MiKTeX_2.9\tex\latex\graphics\color.sty
(C:\Programs\MiKTeX_2.9\tex\latex\00miktex\color.cfg)
(C:\Programs\MiKTeX_2.9\tex\latex\pdftex-def\pdftex.def))
No file faq.aux.
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1ptm.fd)
*geometry* driver: auto-detecting
*geometry* detected driver: pdftex
(C:\Programs\MiKTeX_2.9\tex\latex\hyperref\nameref.sty
(C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\gettitlestring.sty))
(C:\Programs\MiKTeX_2.9\tex\context\base\supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\ot1ztmcm.fd)
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omlztmcm.fd)
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omsztmcm.fd)
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omxztmcm.fd)
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\ot1ptm.fd) [1{C:/Users/MATSUOKA LAB/Ap
pData/Local/MiKTeX/2.9/pdftex/config/pdftex.map}]
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1phv.fd)
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omsptm.fd) [2] [3]
(C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1pcr.fd) [4] [5] [6] [7] [8] [9]
[10] [11] [12
======================================================================

Unfortunately, the package symbol could not be installed.Please check the log file:
C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/pdflatex.log
======================================================================

======================================================================

Unfortunately, the package symbol could not be installed.Please check the log file:
C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-maketfm.log
======================================================================
Running miktex-makemf.exe...

Sorry, but miktex-makemf did not succeed for the following reason:

  The psyr source file could not be found.

The log file hopefully contains the information to get MiKTeX going again:

  C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-makemf.log

You may want to visit the MiKTeX project page, if you need help.
Running hbf2gf.exe...

hbf2gf (CJK ver. 4.8.4)

Couldn't find `ps.cfg'

Sorry, but miktex-maketfm did not succeed for the following reason:

  No creation rule for font psyr.

The log file hopefully contains the information to get MiKTeX going again:

  C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-maketfm.log

You may want to visit the MiKTeX project page, if you need help.

! Font \csname\endcsname=psyr at 10.95pt not loadable: Metric (TFM) file not fo
und.
\AtBegShi@Output ...ipout \box \AtBeginShipoutBox
                                                  \fi \fi
l.923

?



I seldom use LaTeX. Please give me a hint to overcome the issue.

Tatsuro

Re: Dead link in FAQ

[Матвей З. <mat...@gm...>]

Thank you for the quick fix Ethan!

пн, 15 апр. 2019 г. в 06:31, Ethan A Merritt <eam...@gm...>:

> On Sunday, 14 April 2019 17:25:39 Матвей Захарченко wrote:
>
> > Hello there,
>
> > you have a dead link in your FAQ:
>
> > http://www.gnuplot.info/faq/faq.html#x1-290003.6 (3.6 Can I animate my
>
> > graphs?):
>
> > > Have a look at http://gnuplot.sourceforge.net/demo/animate.html in the
>
> > demo collection.
>
> > This link returns 404.
>
> > Thank you for maintaining this project.
>
> >
>
> > Regards,
>
> > Matvey Zakharchenko.
>
>
>
> Fixed now. Tank you.
>
>
>
> Sigh.
>
> The FAQ is so out of date that I wonder if it does more harm than good.
>
> The html version on the web site is dated 2014.
>
>
>
> Worse, I now see that the FAQ version that was captured by the conversion
>
> from cvs -> git was the original 1999 FAQ for gnuplot version 3.7.
>
>
>
> The PDF copy included in the 5.2.6 source package is dated 2017.
>
> I will have to hunt around to find the corresponding LaTeX source file.
>
>
>
> Any volunteers to resurrect and update the FAQ?
>
>
>
> Ethan
>
>
>
> --
>
> entia non sunt multiplicanda praeter necessitatem
>

Re: Dead link in FAQ

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

On Sunday, 14 April 2019 17:25:39 Матвей Захарченко wrote:
> Hello there,
> you have a dead link in your FAQ:
> http://www.gnuplot.info/faq/faq.html#x1-290003.6 (3.6 Can I animate my
> graphs?):
> > Have a look at http://gnuplot.sourceforge.net/demo/animate.html in the
> demo collection.
> This link returns 404.
> Thank you for maintaining this project.
> 
> Regards,
> Matvey Zakharchenko.

Fixed now. Tank you.

Sigh.  
The FAQ is so out of date that I wonder if it does more harm than good.
The html version on the web site is dated 2014.

Worse, I now see that the FAQ version that was captured by the conversion
from cvs -> git was the original 1999 FAQ for gnuplot version 3.7.

The PDF copy included in the 5.2.6 source package is dated 2017.
I will have to hunt around to find the corresponding LaTeX source file.

Any volunteers to resurrect and update the FAQ?

	Ethan

-- 
entia non sunt multiplicanda praeter necessitatem

Dead link in FAQ

[Матвей З. <mat...@gm...>]

Hello there,
you have a dead link in your FAQ:
http://www.gnuplot.info/faq/faq.html#x1-290003.6 (3.6 Can I animate my
graphs?):
> Have a look at http://gnuplot.sourceforge.net/demo/animate.html in the
demo collection.
This link returns 404.
Thank you for maintaining this project.

Regards,
Matvey Zakharchenko.

Re: Is 5.2.7 comming soon?

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

----- Original Message -----
>From: Ethan Merritt (UW) 
>To: gnuplot-beta Tatsuro MATSUOKA  
>Date: 2019/4/13, Sat 14:09
>Subject: Re: Is 5.2.7 comming soon?
> 
>
>On Saturday, 13 April 2019 13:58:56 Tatsuro MATSUOKA wrote:
>> Hello
>> 
>> I noticed the below
>> https://sourceforge.net/p/gnuplot/gnuplot-main/ci/82df0e8f60ff9f624cd1d49412eff58a23808c9a/
>> Commit [82df0e]，Update NEWS and RELEASE_NOTES (This is for 5.2.7).
>> 
>> Tatsuro
> 
>The spacing has been roughly two releases per year.
>So the tentative plan is for the 5.2.7 release in June.
> 
>But I don't mind moving it to earlier if there is some reason.
> 
>Ethan 
>

OK. I understand.

Re: Is 5.2.7 comming soon?

[Ethan M. (UW) <me...@uw...>]

On Saturday, 13 April 2019 13:58:56 Tatsuro MATSUOKA wrote:
> Hello
> 
> I noticed the below
> https://sourceforge.net/p/gnuplot/gnuplot-main/ci/82df0e8f60ff9f624cd1d49412eff58a23808c9a/
> Commit [82df0e]，Update NEWS and RELEASE_NOTES (This is for 5.2.7).
> 
> Tatsuro

The spacing has been roughly two releases per year.
So the tentative plan is for the 5.2.7 release in June.

But I don't mind moving it to earlier if there is some reason.

	Ethan 

Is 5.2.7 comming soon?

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

Hello

I noticed the below
https://sourceforge.net/p/gnuplot/gnuplot-main/ci/82df0e8f60ff9f624cd1d49412eff58a23808c9a/
Commit [82df0e]，Update NEWS and RELEASE_NOTES (This is for 5.2.7).

Tatsuro

Re: About your patch for qt5 for gnuplot for Cygwin

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

I have created the bug ticket.

https://sourceforge.net/p/gnuplot/bugs/2147/

Tatsuro



----- Original Message -----
> From: Tatsuro MATSUOKA <tma...@ya...>
> To: Merritt Ethan <sf...@us...>; gnu...@li...; Enrico Forestieri <fo...@ly...>
> Cc: 
> Date: 2019/3/5, Tue 08:39
> Subject: Re: About your patch for qt5 for gnuplot for Cygwin
> 
>>  Is there a gnuplot bug assigned for this?
>> 
>>  It seems very unusual to prefer a blocking socket to a non-blocking socket.
> 
> 
> Ethan. Thanks for the reply.
> 
> 
> I cannot remember correctly, long ago (two or three), I report this issue.
> But situation seems to be changing.
> 
> I will file a bug.
> 
> Tatsuro
> 
> ----- Original Message -----
> 
>>  From: Ethan A Merritt <sf...@us...>
>>  To: gnu...@li...; Tatsuro MATSUOKA 
> <tma...@ya...>
>>  Cc: 
>>  Date: 2019/3/5, Tue 08:21
>>  Subject: Re: About your patch for qt5 for gnuplot for Cygwin
>> 
>>  Is there a gnuplot bug assigned for this?
>> 
>>  It seems very unusual to prefer a blocking socket to a non-blocking socket.
>> 
>>      Ethan
>> 
>>  On Monday, March 4, 2019 2:37:48 PM PST Tatsuro MATSUOKA wrote:
>>>   > From: Enrico Forestieri 
>>> 
>>>   > To: Tatsuro MATSUOKA 
>>>   > Cc: 
>>>   > Date: 2018/3/12, Mon 17:17
>>>   > Subject: Re: qt terminal on Cygwin
>>>   > 
>>>   > On Mon, Mar 12, 2018 at 10:27:31AM +0900, Tatsuro MATSUOKA wrote:
>>>   > 
>>>   >>  > You should simply avoid using O_NONBLOCK. Please, try 
> the 
>>  following 
>>>   > patch:
>>>   >> 
>>>   >>  > 
>>>   >>  > --- 
>>>   > 
>>  a/qtbase-everywhere-src-5.10.1/src/network/socket/qlocalsocket_unix.cpp
>>>   >>  > +++ 
>>>   > 
>>  b/qtbase-everywhere-src-5.10.1/src/network/socket/qlocalsocket_unix.cpp
>>>   >>  > @@ -239,7 +239,7 @@ void 
> QLocalSocket::connectToServer(OpenM
>>>   >>  >      }
>>>   >>  > 
>>>   >>  >      // create the socket
>>>   >>  > -    if (-1 == (d->connectingSocket = 
>>  qt_safe_socket(PF_UNIX, 
>>>   > SOCK_STREAM, 0, 
>>>   >>  > O_NONBLOCK))) {
>>>   >>  > +    if (-1 == (d->connectingSocket = 
>>  qt_safe_socket(PF_UNIX, 
>>>   > SOCK_STREAM, 
>>>   >>  > 0))) {
>>>   >>  >          
>>  d->errorOccurred(UnsupportedSocketOperationError,
>>>   >>  >                        
>>>   >>  > 
> QLatin1String("QLocalSocket::connectToServer"));
>>>   >>  >          return;
>>>   >>  > 
>>>   >> 
>>>   >>  Enrico
>>>   >> 
>>>   >>  What do you think about proposal of the above patch to 
> cygwin 
>>  list?
>>>   >> 
>>>   >>  If it's allowed, I will make a propasal to cygwin list.
>>>   >>  (Of course I mention that patch is made by you.)
>>>   > 
>>>   > You can try, but I am not sure it will be accepted.
>>> 
>>>   Dear Enrico
>>> 
>>>   I proposed your patch about one year before and recently.
>>>   For second proposal, I have gotten the reply qt maintainer on Cygwin.
>>> 
>> 
> http://cygwin.1069669.n5.nabble.com/Patch-request-to-qt-5-9-4-Re-ANNOUNCEMENT-Qt-5-9-4-td144620.html 
> 
>> 
>>> 
>>>   ************************************************
>>>   > Dear Yaakov Selkowitz
>>>   >
>>>   > I ask alpply a patch the below which enables to use qt terminal 
> on 
>>  gnuplot for Cygwin.
>>>   > (cygQt5Network-5.dll is affected.)
>>>   >
>>>   > --- 
>>  a/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
>>>   > +++ 
>>  b/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
>>>   > @@ -239,7 +239,7 @@ void QLocalSocket::connectToServer(OpenM
>>>   >     }
>>>   >     // create the socket
>>>   > -    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, 
>>  SOCK_STREAM, 0, O_NONBLOCK))) {
>>>   > +    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, 
>>  SOCK_STREAM, 0))) {
>>>   >         d->errorOccurred(UnsupportedSocketOperationError,
>>>   >                        
>>  QLatin1String("QLocalSocket::connectToServer"));
>>>   >         return;
>>>   >
>>> 
>>>   It seems we keep going in circles on this point.  If there is a bug in
>>>   O_NONBLOCK, then please either narrow it down to an STC, or provide a
>>>   patch to Cygwin.
>>> 
>>>   ************************************************
>>> 
>>>   Can you do this or provide hint for me to rearch the answer?
>>> 
>>>   Thank you in advance your kind consideration.
>>> 
>>>   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
>> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta 
> 

Re: About your patch for qt5 for gnuplot for Cygwin

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

> Is there a gnuplot bug assigned for this?
> 
> It seems very unusual to prefer a blocking socket to a non-blocking socket.


Ethan. Thanks for the reply.


I cannot remember correctly, long ago (two or three), I report this issue.
But situation seems to be changing.

I will file a bug.

Tatsuro

----- Original Message -----

> From: Ethan A Merritt <sf...@us...>
> To: gnu...@li...; Tatsuro MATSUOKA <tma...@ya...>
> Cc: 
> Date: 2019/3/5, Tue 08:21
> Subject: Re: About your patch for qt5 for gnuplot for Cygwin
> 
> Is there a gnuplot bug assigned for this?
> 
> It seems very unusual to prefer a blocking socket to a non-blocking socket.
> 
>     Ethan
> 
> On Monday, March 4, 2019 2:37:48 PM PST Tatsuro MATSUOKA wrote:
>>  > From: Enrico Forestieri 
>> 
>>  > To: Tatsuro MATSUOKA 
>>  > Cc: 
>>  > Date: 2018/3/12, Mon 17:17
>>  > Subject: Re: qt terminal on Cygwin
>>  > 
>>  > On Mon, Mar 12, 2018 at 10:27:31AM +0900, Tatsuro MATSUOKA wrote:
>>  > 
>>  >>  > You should simply avoid using O_NONBLOCK. Please, try the 
> following 
>>  > patch:
>>  >> 
>>  >>  > 
>>  >>  > --- 
>>  > 
> a/qtbase-everywhere-src-5.10.1/src/network/socket/qlocalsocket_unix.cpp
>>  >>  > +++ 
>>  > 
> b/qtbase-everywhere-src-5.10.1/src/network/socket/qlocalsocket_unix.cpp
>>  >>  > @@ -239,7 +239,7 @@ void QLocalSocket::connectToServer(OpenM
>>  >>  >      }
>>  >>  > 
>>  >>  >      // create the socket
>>  >>  > -    if (-1 == (d->connectingSocket = 
> qt_safe_socket(PF_UNIX, 
>>  > SOCK_STREAM, 0, 
>>  >>  > O_NONBLOCK))) {
>>  >>  > +    if (-1 == (d->connectingSocket = 
> qt_safe_socket(PF_UNIX, 
>>  > SOCK_STREAM, 
>>  >>  > 0))) {
>>  >>  >          
> d->errorOccurred(UnsupportedSocketOperationError,
>>  >>  >                        
>>  >>  > QLatin1String("QLocalSocket::connectToServer"));
>>  >>  >          return;
>>  >>  > 
>>  >> 
>>  >>  Enrico
>>  >> 
>>  >>  What do you think about proposal of the above patch to cygwin 
> list?
>>  >> 
>>  >>  If it's allowed, I will make a propasal to cygwin list.
>>  >>  (Of course I mention that patch is made by you.)
>>  > 
>>  > You can try, but I am not sure it will be accepted.
>> 
>>  Dear Enrico
>> 
>>  I proposed your patch about one year before and recently.
>>  For second proposal, I have gotten the reply qt maintainer on Cygwin.
>> 
> http://cygwin.1069669.n5.nabble.com/Patch-request-to-qt-5-9-4-Re-ANNOUNCEMENT-Qt-5-9-4-td144620.html 
> 
>> 
>>  ************************************************
>>  > Dear Yaakov Selkowitz
>>  >
>>  > I ask alpply a patch the below which enables to use qt terminal on 
> gnuplot for Cygwin.
>>  > (cygQt5Network-5.dll is affected.)
>>  >
>>  > --- 
> a/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
>>  > +++ 
> b/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
>>  > @@ -239,7 +239,7 @@ void QLocalSocket::connectToServer(OpenM
>>  >     }
>>  >     // create the socket
>>  > -    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, 
> SOCK_STREAM, 0, O_NONBLOCK))) {
>>  > +    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, 
> SOCK_STREAM, 0))) {
>>  >         d->errorOccurred(UnsupportedSocketOperationError,
>>  >                        
> QLatin1String("QLocalSocket::connectToServer"));
>>  >         return;
>>  >
>> 
>>  It seems we keep going in circles on this point.  If there is a bug in
>>  O_NONBLOCK, then please either narrow it down to an STC, or provide a
>>  patch to Cygwin.
>> 
>>  ************************************************
>> 
>>  Can you do this or provide hint for me to rearch the answer?
>> 
>>  Thank you in advance your kind consideration.
>> 
>>  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: About your patch for qt5 for gnuplot for Cygwin

[Ethan A M. <sf...@us...>]

Is there a gnuplot bug assigned for this?

It seems very unusual to prefer a blocking socket to a non-blocking socket.

	Ethan

On Monday, March 4, 2019 2:37:48 PM PST Tatsuro MATSUOKA wrote:
> > From: Enrico Forestieri 
> 
> > To: Tatsuro MATSUOKA 
> > Cc: 
> > Date: 2018/3/12, Mon 17:17
> > Subject: Re: qt terminal on Cygwin
> > 
> > On Mon, Mar 12, 2018 at 10:27:31AM +0900, Tatsuro MATSUOKA wrote:
> > 
> >>  > You should simply avoid using O_NONBLOCK. Please, try the following 
> > patch:
> >> 
> >>  > 
> >>  > --- 
> > a/qtbase-everywhere-src-5.10.1/src/network/socket/qlocalsocket_unix.cpp
> >>  > +++ 
> > b/qtbase-everywhere-src-5.10.1/src/network/socket/qlocalsocket_unix.cpp
> >>  > @@ -239,7 +239,7 @@ void QLocalSocket::connectToServer(OpenM
> >>  >      }
> >>  > 
> >>  >      // create the socket
> >>  > -    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, 
> > SOCK_STREAM, 0, 
> >>  > O_NONBLOCK))) {
> >>  > +    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, 
> > SOCK_STREAM, 
> >>  > 0))) {
> >>  >          d->errorOccurred(UnsupportedSocketOperationError,
> >>  >                         
> >>  > QLatin1String("QLocalSocket::connectToServer"));
> >>  >          return;
> >>  > 
> >> 
> >>  Enrico
> >> 
> >>  What do you think about proposal of the above patch to cygwin list?
> >> 
> >>  If it's allowed, I will make a propasal to cygwin list.
> >>  (Of course I mention that patch is made by you.)
> > 
> > You can try, but I am not sure it will be accepted.
> 
> Dear Enrico
> 
> I proposed your patch about one year before and recently.
> For second proposal, I have gotten the reply qt maintainer on Cygwin.
> http://cygwin.1069669.n5.nabble.com/Patch-request-to-qt-5-9-4-Re-ANNOUNCEMENT-Qt-5-9-4-td144620.html
> 
> ************************************************
> > Dear Yaakov Selkowitz
> >
> > I ask alpply a patch the below which enables to use qt terminal on gnuplot for Cygwin.
> > (cygQt5Network-5.dll is affected.)
> >
> > --- a/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
> > +++ b/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
> > @@ -239,7 +239,7 @@ void QLocalSocket::connectToServer(OpenM
> >     }
> >     // create the socket
> > -    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, SOCK_STREAM, 0, O_NONBLOCK))) {
> > +    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, SOCK_STREAM, 0))) {
> >         d->errorOccurred(UnsupportedSocketOperationError,
> >                         QLatin1String("QLocalSocket::connectToServer"));
> >         return;
> >
> 
> It seems we keep going in circles on this point.  If there is a bug in
> O_NONBLOCK, then please either narrow it down to an STC, or provide a
> patch to Cygwin.
> 
> ************************************************
> 
> Can you do this or provide hint for me to rearch the answer?
> 
> Thank you in advance your kind consideration.
> 
> 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

About your patch for qt5 for gnuplot for Cygwin

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

> From: Enrico Forestieri 

> To: Tatsuro MATSUOKA 
> Cc: 
> Date: 2018/3/12, Mon 17:17
> Subject: Re: qt terminal on Cygwin
> 
> On Mon, Mar 12, 2018 at 10:27:31AM +0900, Tatsuro MATSUOKA wrote:
> 
>>  > You should simply avoid using O_NONBLOCK. Please, try the following 
> patch:
>> 
>>  > 
>>  > --- 
> a/qtbase-everywhere-src-5.10.1/src/network/socket/qlocalsocket_unix.cpp
>>  > +++ 
> b/qtbase-everywhere-src-5.10.1/src/network/socket/qlocalsocket_unix.cpp
>>  > @@ -239,7 +239,7 @@ void QLocalSocket::connectToServer(OpenM
>>  >      }
>>  > 
>>  >      // create the socket
>>  > -    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, 
> SOCK_STREAM, 0, 
>>  > O_NONBLOCK))) {
>>  > +    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, 
> SOCK_STREAM, 
>>  > 0))) {
>>  >          d->errorOccurred(UnsupportedSocketOperationError,
>>  >                         
>>  > QLatin1String("QLocalSocket::connectToServer"));
>>  >          return;
>>  > 
>>  > -- 
>>  > Enrico
>> 
>>  Enrico
>> 
>>  What do you think about proposal of the above patch to cygwin list?
>> 
>>  If it's allowed, I will make a propasal to cygwin list.
>>  (Of course I mention that patch is made by you.)
> 
> You can try, but I am not sure it will be accepted.

Dear Enrico

I proposed your patch about one year before and recently.
For second proposal, I have gotten the reply qt maintainer on Cygwin.
http://cygwin.1069669.n5.nabble.com/Patch-request-to-qt-5-9-4-Re-ANNOUNCEMENT-Qt-5-9-4-td144620.html

************************************************
> Dear Yaakov Selkowitz
>
> I ask alpply a patch the below which enables to use qt terminal on gnuplot for Cygwin.
> (cygQt5Network-5.dll is affected.)
>
> --- a/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
> +++ b/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
> @@ -239,7 +239,7 @@ void QLocalSocket::connectToServer(OpenM
>     }
>     // create the socket
> -    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, SOCK_STREAM, 0, O_NONBLOCK))) {
> +    if (-1 == (d->connectingSocket = qt_safe_socket(PF_UNIX, SOCK_STREAM, 0))) {
>         d->errorOccurred(UnsupportedSocketOperationError,
>                         QLatin1String("QLocalSocket::connectToServer"));
>         return;
>

It seems we keep going in circles on this point.  If there is a bug in
O_NONBLOCK, then please either narrow it down to an STC, or provide a
patch to Cygwin.

************************************************

Can you do this or provide hint for me to rearch the answer?

Thank you in advance your kind consideration.

Tatsuro

AW: Unreleased fixes in master

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

> If there's just one take-away from this, it's try to avoid using
cherry-pick.

cherry-pick is what I used. The reason behind this is probably that
it resembles what we had been doing with the previous versioning
system CVS.  That is OK for developers closely following gnuplot
development but might be difficult for others indeed.

Let me note that for the past decade (or longer) on the order of 3 out
of 4 commits were done by Ethan. So it's really him who has to be
comfortable with the process.  A more "modern style" way of
handling merges etc. might still make it easier in particular for new
contributors.

  Bastian

Re: README-Windows.txt

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

Dear Bastian

I rearange the issue.

Choice of default terminal on Windows

 Bastein's choice is "windows"
 I do not against it. Perhaps I personally set wxt which is also my choice in linux.
 From the next major release (perhaps 5.4), it is a good chance windows terminal 
 will come back as default.


Status of the qt terminal on Windows
 What I saw was almost was a timing issue not essential.
 But strange jitter plots only happen qt terminal on native windows.
 
 https://sourceforge.net/p/gnuplot/bugs/2138/


Issues with or without fontconfig
 The ticket "kerning in vertical text of cairo-based terminals "

  https://sourceforge.net/p/gnuplot/bugs/2048/
 If I set PANGOCAIRO_BACKEND=fc, the behaviors are changed.
 I guess that differences in win32 and fontconfig for pangocairo backend
 is reltated. 


Bug report #2121 on font names with spaces (or hyphens)
 In my opinion, Ethan's modification solved the issue.

windows terminal bug related to wgnuplot.ini
 This is unreporducible and happens as very rare case
 Thus we cannot easy to fix it.
 Deleting it or edit it by editor is to be described as a tip.

Tatsuro


> Dear Tatsuro,
> 
> I am a bit confused about your mail as it - in my view - adresses many
> different somewhat independent topics. I will try to provide information
> on all of them below.
> 
> 
> * Choice of default terminal on Windows
> 
> The current default terminal on Windows is 'wxt'.  As far as I remember 
> it's been like that since the initial commit of the wxt terminal to CVS
> in 2006.  It has been a rather stable and reliable terminal since then.  
> It is cross-platform and has pdf/png siblings which guarantee simlar-
> looking output.  On Windows, it can produce EMF data, which is nice
> for exchange e.g. with office programs. Also printing works. It's not 
> an "outboard" driver, which means that there are no interprocess 
> communnication problems, but support for "persist" is not available in
> the same sense as on other platforms. (No "fork" on  Windows)
> 
> The previous default (and only visual) terminal was "windows". That
> had fallen behind in terms of features (and speed) at that time when wxt
> was introduced. With the Direct2D backend that has certainly changed. 
> It is clearly faster than wxt and qt (which does not currently use the 
> D2D interface, although Qt supports that). It exports EMF and bitmap 
> data to  the clipboard. Export to PDF can be done via the Windows PDF 
> printer, but no pdf/png export from command line (yet). Graphs can be 
> embedded in the main window.  
> 
> "qt" is the default on most other platforms. It is cross-platform, but 
> does
> not (yet) have pdf/png counterparts. (But you can do save as pdf/png/...)
> It is an "outboard" driver, i.e. persist works the same way on Windows
> as it does on other platforms. It is fast and supports printing.
> qt still has a few issues on Windows, see below.
> 
> Users are given a choice to change GNUTERM and hence the default terminal
> during installation.  One's preferences certainly depend on your needs and
> opinion. My choice is "windows". As for the default, I would only 
> consider 
> "windows" or "wxt" at this time.
> 
> 
> * Status of the qt terminal on Windows
> 
> qt is quite usable on Windows. It is definitively not "broken". It 
> does
> have some quirks, though.  One of them is related to fontconfig. For 
> whatever reason, the experience with fontconfig on Windows with gnuplot
> has its difficulties: it reinitializes its cache very often, leading to
> a simingly indefinitely delayed opening of the window (wxt used with 
> fontconfig) or an error message ("slow font initialisation" - qt). 
> This 
> is unsatisfactory and cannot be the "default" behaviour. So far I 
> could
> not identify a remidy. We are certainly open to patches! Another issue
> is Bug #1081: Qt: resizing makes plot "tremble/​shake" which still 
> persists on Windows at least. Also we still have issues with detecting
> the loss of communication with the outboard driver (or vice versa) in
> some cases.
> 
> If there are more issues with "qt" (which warrant to call it 
> "broken)
> please let us know, so we can fix these issues.
> 
> 
> * Issues with or without fontconfig
> 
> There's no single fontconfig library on Windows. Every applications ships
> its own version. There are reports on the net of interference between 
> these different versions, but I am not sure that this is our problem. The
> font cache init is slow and for gnuplot does not run in the background,
> but delays user interaction.  This leads to timeouts (qt) or windows
> not appearing for a long time (wxt).  We got a number of "gnuplot 
> hangs"
> reports when wxt used fontconfig by default. So we changed that.
> 
> I sould note that fontconfig is somewhat redundant on Windows. There
> are other "native" means to find fonts on Windows. No need to maintain
> a separate list - at least not for what concerns gnuplot.
> 
> Several solutions are possible, maybe in combination:
> - We could try to reduce the caching problem by "fixing" our 
> fontconfig 
> setup files (in case that's the issue).
> - We could init the fontconfig cache during installation of gnuplot.
>   I have seen that for other installers on Windows.
> - We could have fontconfig do the cache init in the background or when
>   gnuplot is idle.
> - We could detect when fontconfig (re-)inits its cache and provide the 
>   user with that information ("Please wait - looking for fonts"). If 
>   that is possible.
> - We could avoid to use fontconfig on Windows, i.e. ask Qt to use the 
>   native font API on Windows (if that is supported).
> 
> We should move further discussion to the bug tracker.  Help with 
> fontconfig and Qt is very welcome, as I do not know much about either 
> of them.
> 
> 
> * Bug report #2121 on font names with spaces (or hyphens)
> 
> Given the above, I personally would not recommend to use fontconfig with
> gnuplot on Windows. But it's a work-around. So maybe a question for the 
> FAQ. 
> Ethan has added support for font-names-in-quotes to git in response
> to this bug report which is a cross-platform and cross-terminal solution.
> (Another proposed solution was to uniformly convert dashes to spaces in
> font name before sending them to the terminal.)
> 
> 
> * windows terminal bug related to wgnuplot.ini
> 
>>  > Sometimes wgnuplot.ini will break and plot window will  be strage.
>>  > In the case, one can reset broken setting by deleting wgnuplot.ini.
> 
> I don't remember having to delete wgnuplot.ini in 20 years or so of using 
> gnuplot on Windows.  Instead of adding that to README, we should much rather
> have a proper bug report, including examples of those ini files and - if 
> possible - info on how to reproduce the failure. It should be fixed in the 
> code asap.
> One should note that "wgnuplot.ini" is only used by the wgnuplot text 
> window
> and the "windows" terminal.
> 
>   Bastian
> 
> 
>>  > In the bug #2121, Bastian wrote, we can select pango-cairo backend : 
> win32, 
>>  > 
>>  > fc (fontconfig).
>>  > 
>>  > The bug #2048, the behaviors seems to be different depending on 
> backend.
>>  > 
>>  > Will the selection backend to be wrietten in README-Windows.txt?
>>  > 
>>  > Sometimes wgnuplot.ini will break and plot window will  be strage.
>>  > In the case, one can reset broken setting by deleting wgnuplot.ini.
>>  > 
>>  > I think that this is prefferablly described in README-Windows.txt.]
>>  > 
>>  > Tatsuro
>> 
>>  After some discussion BBS in Japan, I put  README-Windows.txt to 
> Files/5.2.6.
>> 
>>  The original question is why wxt terminal is default.
>>  On native windows qt is broken and is is not recommeded.
>> 
>>  However, there is no descrition for this topic.
>> 
>>  I will open a bug ticket that is for additional information for gnuplot on 
> windows
>>  on this weekend.
>> 
>>  Tatsuro
>> 
>> 
> 

Re: pause in make check

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

----- Original Message -----

> From: Hans-Bernhard Bröker 
> To: gnuplot-beta
> Cc: 
> Date: 2019/2/23, Sat 10:09
> Subject: Re: pause in make check
> 
> Am 22.02.2019 um 03:42 schrieb Tatsuro MATSUOKA:
> 
>>  Can I insert something like "pause" each run in make check?
> 
> No need; there are already "pause"s after every plot (the same ones 
> you
> see when just loading all.dem in an interactive gnuplot session).
> 
> The "make check" rules explictly skip all these pauses by redirecting
> stdin from /dev/null.  But for when one does want to single-step the
> plots, there's a second target, "check-interactive", that does 
> just that.
> 
> So, in a nutshell:
> 
>     make -C demo check-interactive


On qt terminal on Ubuntu 18.04 on WS, make check is too fast so that
size and/or aspect ratio almost the case.

make -C demo check-interactive

is one of the solution but I want change pause length during make check
or some other altatative way automatic check a little bit slower.

Tatsuro

Re: Unreleased fixes in master

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

Ethan A Merritt <sf...@us...> said (on 2019/02/22):
> After some delving I have discovered that [cherry-pick -x] used to be the
> default in git but for some reason it was removed!   
> 
> The current documentation suggests that "git cherry-pick -x" may save the
> history I want.  So I will use that going forward.

A cherry-pick could come from an entirely different repository
(added as a remote), and with -n and the possibility of
conflict, what's committed might not be the same as what was
picked, so I'd speculate that's why -x was dropped from being a
default.

The -x adds a "(cherry picked from commit hhhh...)" to the
commit message. It may be useful for humans, but I'm not aware
of anything that automatically processes the added comment. That
is, git log will still show the cherry-picked commit in both
master..stable and stable..master.

There is another tool, though, and I should have mentioned it
earlier but forgot it until now: git cherry. I think it's
exactly what Dima wants. And in poking at git-cherry, I learned
that git-log actually has options for this, too, now. So I think
we could have solved the problem without even needing this
discussion.

I'll let you read about git-cherry, but here's the git-log
version:
  git log --left-right --graph --cherry-mark --date-order \
      --oneline branch-5-2-stable...master
  # note, three dots, not two. See "dotted range notations"
  # under man git-rev-parse for details

  = 0a7b9a57e (origin/branch-5-2-stable, branch-5-2-stable)
              pm: restore binary backward compatibility for s...
  = 4146f1db2 pm: ignore alpha channel of RGBA colors
  = e73c08cb2 pm: reinitialize font on codepage change
  = 017c230c6 pm: remove help text of obsolete options
  = ca06c4ea1 Add a block for OS/2 code
  = fad43b5ad Fix glitch in toolbar icons on qt terminal
  | = 7bd40380f (HEAD -> master, origin/master, origin/HEAD)
  |             Fix glitch in toolbar icons on qt terminal
  | > ef90e907b new function trim(" padded string ") strips l...
  | > b83c88bb8 Parse numeric timezone UTC offset (format %z)...
  < | f5585bdb0 Extend the conditions under which ungetc() is...
  | = 32c048991 pm: restore binary backward compatibility for...
  | = 28d0fe668 pm: ignore alpha channel of RGBA colors
  | = 2446baa32 pm: reinitialize font on codepage change
  | > 6ac277288 pm: the EAM_BOXED_TEXT conditional is gone
  | = 47d2f151e pm: remove help text of obsolete options
  ... etc ...

You'll notice all the common cherry-picked commits are now
marked with =. By changing --cherry-mark to --cherry-pick
--right-only, they will be entirely excluded and only the
un-picked commits on the master side will be shown:

  * ef90e907b new function trim(" padded string ") strips lea...
  * b83c88bb8 Parse numeric timezone UTC offset (format %z) ...
  * 6ac277288 pm: the EAM_BOXED_TEXT conditional is gone
  ...

In all, I believe that makes 831 commits on master not on branch-5-2-stable.

Commit [b83c88] breaks windows build (time.c)

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

Commit [b83c88] breaks windows build (time.c) 


See;
https://sourceforge.net/p/gnuplot/bugs/2141/

Tatsuro

Re: pause in make check

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

> From: Hans-Bernhard Bröker e>

> To: gnuplot-beta
> Cc: 
> Date: 2019/2/23, Sat 10:09
> Subject: Re: pause in make check
> 
> Am 22.02.2019 um 03:42 schrieb Tatsuro MATSUOKA:
> 
>>  Can I insert something like "pause" each run in make check?
> 
> No need; there are already "pause"s after every plot (the same ones 
> you
> see when just loading all.dem in an interactive gnuplot session).
> 
> The "make check" rules explictly skip all these pauses by redirecting
> stdin from /dev/null.  But for when one does want to single-step the
> plots, there's a second target, "check-interactive", that does 
> just that.
> 
> So, in a nutshell:
> 
>     make -C demo check-interactive


Thanks!

Tatsuro

Re: pause in make check

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

Am 22.02.2019 um 03:42 schrieb Tatsuro MATSUOKA:

> Can I insert something like "pause" each run in make check?

No need; there are already "pause"s after every plot (the same ones you
see when just loading all.dem in an interactive gnuplot session).

The "make check" rules explictly skip all these pauses by redirecting
stdin from /dev/null.  But for when one does want to single-step the
plots, there's a second target, "check-interactive", that does just that.

So, in a nutshell:

	make -C demo check-interactive

Re: Unreleased fixes in master

[Ethan A M. <sf...@us...>]

On Friday, February 22, 2019 1:57:37 PM PST Ethan A Merritt via gnuplot-beta wrote:

> Exactly.
> This seems like a hint either that "git log" is the wrong tool
> or that it could be improved by tracking a bit more history.
> Can't the cherry-pick operation itself be recorded as a transaction?
> Then a hypothetical command option "git log --show-origin"
> would list  entries as
> 
> %%%
> [4] git status
> On branch branch-5-2-stable
> 
> [5] git log --show-origin HEAD~1..HEAD
> 
> commit d83adc16f5a572f5d004963ead8326591498dd41
> Author: Ethan A Merritt <merritt@u.washington.edu>
> Date:   Tue Feb 19 23:10:08 2019 -0800
> Origin:  cherry-pick from master/83a349a07b3f30d3f0c11ff80152f3cb96ff3c77
> 
>     <body of commit message text>
> %%%

After some delving I have discovered that this used to be the default in git
but for some reason it was removed!   

The current documentation suggests that "git cherry-pick -x" may save the
history I want.  So I will use that going forward.

    thanks for putting up with my incomplete progress as a git user

		Ethan

Re: Unreleased fixes in master

[Ethan A M. <sf...@us...>]

On Friday, February 22, 2019 12:52:24 PM PST Tait wrote:
> > ...
> > Back to my original question - why would I ever want to
> > merge the stable and development branches?
> > That was never the plan.
> > ...
> > 
> > > Let me add a couple "git work flow" history highlights for
> > > further background. It all started with
> > > https://nvie.com/posts/a-successful-git-branching-model/, and
> > > this is called "Git Flow". 
> > 
> > I have just read that.
> > I don't like it at all.
> > 
> > > After much discussion,
> > > https://www.endoflineblog.com/gitflow-considered-harmful
> > > happened. 
> > 
> > That one is much closer to my way of thinking.
> > Except that I do not see any reason to merge a release branch
> > back into master (or development or whatever you want to call it).
> > What would be gained by merging?  
> > That is a serious question - what is the rationale for even wanting
> > to do a merge?
> 
> The rationale is exactly the present example. Just as one would
> rather make, then call a function from two places instead of
> copy-and-paste the code in both places, it's preferable to make
> a commit only once. The notion is that once created, the stable
> branch contains mostly fixes and updates that should apply in
> both places (stable and master)

This has already diverged from my notion of "stable branch".
For me, anything in "stable" either is already in the master or will
never be there.  In no case will something move from stable to
master.

[snip]
 
> When merging, git looks at the tip of branch A, tip of branch B,
> and history back to the common ancestor of A and B (called the
> merge-base). It doesn't offer a way to indicate,
> commit-by-commit, "merge this and this and not that and then
> this..." That makes it difficult to work the way you want, where
> all work happens on master and then different bits and pieces
> filter back to other places. As you've found, it can be done
> with cherry-pick, but then some of the other utilities, like git
> log, become less useful. 

Exactly.
This seems like a hint either that "git log" is the wrong tool
or that it could be improved by tracking a bit more history.
Can't the cherry-pick operation itself be recorded as a transaction?
Then a hypothetical command option "git log --show-origin"
would list  entries as

%%%
[4] git status
On branch branch-5-2-stable

[5] git log --show-origin HEAD~1..HEAD

commit d83adc16f5a572f5d004963ead8326591498dd41
Author: Ethan A Merritt <merritt@u.washington.edu>
Date:   Tue Feb 19 23:10:08 2019 -0800
Origin:  cherry-pick from master/83a349a07b3f30d3f0c11ff80152f3cb96ff3c77

    <body of commit message text>
%%%

Compared to everything else being tracked already, that seems
like it would be a trivial change with nice benefits. 

[snip]

> Anticipating the "why is git this way?" question, remember one
> of git's design imperatives was to have a single small token be
> enough to ensure all of history was intact and unaltered
> (including by a possibly malicious actor). Other systems don't
> deliver that guarantee, and as a result they can be more free
> with their history.

I assumed this was the case.
But the thing is, security measures only make sense in the context
of a particular threat model.   I am far less concerned about the
possibility of authorized but malicious contributors corrupting the
history than I am about the presence of typos, errors, and outdated
or mistaken information in the history that cannot be corrected. 
To me the benefit from being able to edit the commit messages
outways the risk of deliberate corruption.
The edit history itself could be tracked, reviewed, and undone if
necessary in the case of corruption.  


> > > If there's just one take-away from this, it's try to avoid using
> > > cherry-pick.
> > 
> > All I can say at this point is that "git cherry-pick" is the thing
> > that made git usable for me.  If I can't use that then I think
> > I'd rather go back to CVS.
> 
> Anything but CVS. The biggest issue with CVS is versioning each
> file separately, rather than having commits and a uniform state
> across the whole repository.

I have to concede that point.  Consistent synchronization at the level
of the entire project definitely beats timestamps on individual files.

	Ethan

Re: Unreleased fixes in master

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

> ...
> Back to my original question - why would I ever want to
> merge the stable and development branches?
> That was never the plan.
> ...
> 
> > Let me add a couple "git work flow" history highlights for
> > further background. It all started with
> > https://nvie.com/posts/a-successful-git-branching-model/, and
> > this is called "Git Flow". 
> 
> I have just read that.
> I don't like it at all.
> 
> > After much discussion,
> > https://www.endoflineblog.com/gitflow-considered-harmful
> > happened. 
> 
> That one is much closer to my way of thinking.
> Except that I do not see any reason to merge a release branch
> back into master (or development or whatever you want to call it).
> What would be gained by merging?  
> That is a serious question - what is the rationale for even wanting
> to do a merge?

The rationale is exactly the present example. Just as one would
rather make, then call a function from two places instead of
copy-and-paste the code in both places, it's preferable to make
a commit only once. The notion is that once created, the stable
branch contains mostly fixes and updates that should apply in
both places (stable and master), so it makes sense to pull those
fixes and updates from stable into master (which a merge does).
It doesn't usually go the other way because fixes on master may
not be relevant to stable because they apply to new features and
other changes that stable doesn't have.

When merging, git looks at the tip of branch A, tip of branch B,
and history back to the common ancestor of A and B (called the
merge-base). It doesn't offer a way to indicate,
commit-by-commit, "merge this and this and not that and then
this..." That makes it difficult to work the way you want, where
all work happens on master and then different bits and pieces
filter back to other places. As you've found, it can be done
with cherry-pick, but then some of the other utilities, like git
log, become less useful. Pragmatically for gnuplot, that means
"git log" can provide the change log for a given branch, but
comparisons across branches have to be done manually, just as
would be the case with a manually-maintained ChangeLog file.

When I started with git, I wanted to do what you're doing. I
learned to accommodate my work flow to git and actually like it,
now. I don't know much about darcs, but I think it would be a
much better fit for how you want to work. (Unfortunately,
SourceForge probably doesn't support it?) Darcs embraces the
concept of creating a patch, and then moving/copying it around.
Critically unlike git, that does not change the patch
identity.

Anticipating the "why is git this way?" question, remember one
of git's design imperatives was to have a single small token be
enough to ensure all of history was intact and unaltered
(including by a possibly malicious actor). Other systems don't
deliver that guarantee, and as a result they can be more free
with their history.

> > If there's just one take-away from this, it's try to avoid using
> > cherry-pick.
> 
> All I can say at this point is that "git cherry-pick" is the thing
> that made git usable for me.  If I can't use that then I think
> I'd rather go back to CVS.

Anything but CVS. The biggest issue with CVS is versioning each
file separately, rather than having commits and a uniform state
across the whole repository. There are so many other issues
though, including that since nobody uses CVS anymore, support
for it is hard to come by for a Windows application. TortoiseCVS
is basically not functional anymore on Win10, and while WinCVS
still works if you can find the installer, it's a constant
frustration working around its various quirks and bugs.

Re: Unreleased fixes in master

[sfeam <me...@uw...>]

On Thursday, 21 February 2019 23:48:53 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > That's not the development model we have been using.
> >
> > Trivial bug-fixes are applied for both the stable and development branches
> > immediately as they are found.
> >
> > Non-trivial changes, even bug fixes, are applied only to the
> > development branch. Often people using the development branch then
> > report related issues that require additional fixes or re-thinking of
> > the original fix. After sufficient testing in the development version
> > the original fix and any follow-ups developed during testing may or
> > may not be back-ported to the stable branch. This particular change
> > was non-trivial to begin with and engendered many follow-up fixes.
> 
> OK. Is your thinking to include this in a 5.4 release at some point in
> the future?

Sure.  
The development model is that at some point a branch-5-4-stable
is created from the development branch (_not_ from branch-5-2-stable).
It will obviously contain everything that has gone into the development
branch prior to that point.
- The old stable branch becomes a dead end.
- The new stable branch is used to prepare release packages.
- Development continues in the main branch.


[snip]
> i.e. there were 224 commits that appear in both master..5.2.6 AND in
> 5.2.6..master. Taking a random one. Look at this:
> 
>   gitk 1f7160945 fb107d74e
> 
> These are clearly the same commit, so ideally it should appear on
> neither "git log master..5.2.6" nor "git log 5.2.6..master", but it
> appears on both. Those commits aren't in a merge, and their immediate
> parents aren't the same. How did we get here? Did we cherry-pick it?

Yes.  Patch applied and tested in the development branch, later cherry-picked
for the stable branch.

> > The thing is, you can't go back to edit old commit messages like you
> > can edit a ChangeLog. That means you cannot fix typos, cannot clarify
> > or expand bad descriptions, cannot update or redact Email addresses,
> > cannot forward-link to eventual reversion or to subsequent related
> > patches etc.
> >
> > My #1 suggestion for improving git would be to move all the commit
> > messages to a parallel data structure so that they can be edited
> > without invalidating the orginal commit hash.
> 
> Are you really proposing to have a hand-curated NEWS file AND a
> hand-curated ChangeLog AND version control?

I would much rather that git maintained the ChangeLog automatically,
but so far as I have been able to learn it cannot be persuaded to do that.
The NEWS file is a bullet-point summary where each bullet point may
summarize many commits.  How would you get that other than manual
curation?  It might be more conventional to call it ReleaseNotes rather than NEWS.

	still willing to learn

		Ethan

Re: Unreleased fixes in master

[sfeam <me...@uw...>]

On Friday, 22 February 2019 09:36:40 Tait wrote:
> >>> I can ask git about the difference in branches (git log
> >>> 5.2.6..master), but they're very diverged, and that command isn't
> >>> entirely helpful.
> >>
> >> Tracking changes via commit messages is one of the things I like least
> >> about git.
> > 
> > The reason that 'git log master..5.2.6' wasn't entirely useful is that
> > there was way too much noise. And THAT happened because there were many
> > commits that appear in both master and 5.2.6, but that the above command
> > isn't recognizing as being on both:
> 
> I almost suggested "git log master..5.2.6" but looking at the
> repository, Dima is exactly right. It's a little easier to parse
> for me in gitk if you enable the "strictly sort by date" option
> under View -> edit view. In this view, it's clear that commits
> like 1a25a2 / d34da7 are the same. But they're not the same to
> git, because they got cherry-picked (rather than merged) from
> master over to branch-5-2-stable. 

> In fact, the merge-base
> between master and branch-5-2-stable is way back at 07e374 --
> the initial split from master!

That was the intent.
Sorry if my brain is on a different planet from the git designers,
but I don't see why I would ever want to merge the stable
and development branches.  The entire _point_ of having a development
branch is to try things out and only carry back only a few of the 
successful changes into the stable branch.


> To keep things simple for now, I'd recommend that commits
> destined for a -stable branch be made by checking out that
> branch and committing to it. Then merge the -stable branch into
> master. 

No. That is backwards from the gnuplot development model.
Nothing ever goes into stable first and then into master.

> This will have the effect of "copying" the commit into
> master without the log noise of duplicate commits. Commits
> destined for master that will not go to -stable simply get
> committed on master and left there.

Sorry, my mind just doesn't work that way.
I have had no luck with "merge".
"git cherry-pick" is the only mechanism that works for me.
 
> Now the first time you try to merge -stable into master, it's
> going to be ugly because git is having to reconcile everything
> from 07e374 up to the tip of each branch. If you're sure that
> everything in 5-2-stable is already in master, you can use an
> "ours" merge strategy to make the merge a no-op placeholder.
> (NB: That's "ours" if you have master checked out and say "git
> merge branch-5-2-stable". Don't confuse which way the merge goes
> or you'll revert changes you didn't mean to.) Subsequent merges
> will look to the most recent merge-base between 5-2-stable and
> master, so making a commit on branch-5-2-stable and merging
> 5-2-stable to master will only bring over that commit, even if
> other commits have happened on master in the meantime. I hope
> I'm explaining that clearly enough.

Back to my original question - why would I ever want to
merge the stable and development branches?
That was never the plan.

> That work flow will make the git log commands Dima suggested
> work the way they ought -- to show what's changed in one
> direction or the other without all the noise of duplicated
> commits.

In my world-view of the process there is no such "direction".
The changes go neither from A->B or B->A.  Instead A and B
progress in parallel, sharing a common core that was the point
of the branching.
 
> Let me add a couple "git work flow" history highlights for
> further background. It all started with
> https://nvie.com/posts/a-successful-git-branching-model/, and
> this is called "Git Flow". 

I have just read that.
I don't like it at all.

> After much discussion,
> https://www.endoflineblog.com/gitflow-considered-harmful
> happened. 

That one is much closer to my way of thinking.
Except that I do not see any reason to merge a release branch
back into master (or development or whatever you want to call it).
What would be gained by merging?  
That is a serious question - what is the rationale for even wanting
to do a merge?

> That second article has been rewritten, without the
> rant, as https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow.
> And you can read about "GitHub flow" and "GitLab flow" and "Git
> Ship" and on if you still haven't found a model that fits quite
> right. The tldr is they're all variations on how to choose where
> to commit and how to merge.
> 
> If you've read at least the git flow link, what I'm recommending
> is essentially the "develop" (which is master for gnuplot) and
> "release branches" portion of that model. I'm ignoring "feature
> branches" and "hotfixes" and their idea of how "master" should
> work because that's just extra complication at this stage.
> 
> If there's just one take-away from this, it's try to avoid using
> cherry-pick.

All I can say at this point is that "git cherry-pick" is the thing
that made git usable for me.  If I can't use that then I think
I'd rather go back to CVS.

	call me a luddite, or an old-fogie, or whatever you choose

		Ethan