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

Re: Aw: Re: README-Windows.txt

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

> I found strage plot on jitter.dem on qt terminal gnuplot on windows.

> I will file it as a bug.


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

Please discuss at the above.


Tatsuro

Re: Unreleased fixes in master

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

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

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

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.

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.

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". After much discussion,
https://www.endoflineblog.com/gitflow-considered-harmful
happened. 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.

Re: Aw: Re: README-Windows.txt

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

> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA 
>>  To: bmaerkisch
>>  Cc: gnuplot-beta
>>  Date: 2019/2/22, Fri 03:08
>>  Subject: Re: Aw: Re: README-Windows.txt
>> 
> 
>>  Dear Bastian
>> 
>>   
>>>   I am a bit confused about your mail as it - in my view - adresses many
>>>   different somewh t independent topics. I will try to provide 
> information
>>>   on all of them below.
>>> 
>>> 
>>>   * 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.
> 
> 
> This seem to be race condition.
> I execute all.dem
> GNUPLOT_LIB=../../demo GNUTERM=qt ./gnuplot all.dem < ../../../y.dat
> 
> y.dat is a file that contains many [CR].
> 
> 
> In this case, plot is broken.
> However we execute all.dem manually, ugly plot does not happen.
> 
> 
I found strage plot on jitter.dem on qt terminal gnuplot on windows.
I will file it as a bug.

Tatsuro

Re: Unreleased fixes in master

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

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?


>> 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. I am seriously considering to switch back to a model where
> changes are fully described in a separate ChangeLog and all git
> commits simply say "see ChangeLog". That would require some automated
> way to insert the appropriate git hash indices into the text of the
> ChangeLog. I have tried a couple of git add-ons that looked like they
> might help, but so far with no success.

OK. I use git heavily, but never to do anything with lots of branching,
so I wasn't sure what you're doing. Things like "git master..feature"
(i.e. tell me what's on the feature branch that isn't on the master
branch) is exactly the thing that git is supposed to do well, so I
suspect we're doing something incorrectly here.

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:

  dima@scrawny:~/projects/gnuplot$ comm -12 <(git log master..5.2.6 --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) <(git log 5.2.6..master --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) | wc -l
  224

  dima@scrawny:~/projects/gnuplot$ comm -23 <(git log master..5.2.6 --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) <(git log 5.2.6..master --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) | wc -l
  156

  dima@scrawny:~/projects/gnuplot$ comm -13 <(git log master..5.2.6 --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) <(git log 5.2.6..master --oneline | cut -d' ' -f 2- | sed 's/ /_/g' | sort) | wc -l
  635

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?
Maybe that confuses "git log" a bit?


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

pause in make check

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

I have been noticed that make check at qt terminal 
on Ubuntu 18.04 on WSL(Windows Subsystem for Linux)
causes sometimes ugly plot (wrong aspect ratio in multiplot mode etcs.)

However, if I execute all.dem by hand, all graph appears correctly.
Perhaps this is timing issue.

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

Tatsuro

Re: Aw: Re: README-Windows.txt

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

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

> From: Tatsuro MATSUOKA 
> To: bmaerkisch
> Cc: gnuplot-beta
> Date: 2019/2/22, Fri 03:08
> Subject: Re: Aw: Re: README-Windows.txt
> 

> Dear Bastian
> 
>  
>>  I am a bit confused about your mail as it - in my view - adresses many
>>  different somewh t independent topics. I will try to provide information
>>  on all of them below.
>> 
>> 
>>  * 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.


This seem to be race condition.
I execute all.dem
GNUPLOT_LIB=../../demo GNUTERM=qt ./gnuplot all.dem < ../../../y.dat

y.dat is a file that contains many [CR].


In this case, plot is broken.
However we execute all.dem manually, ugly plot does not happen.


Sorry for noise.

Tatsuro

Re: Unreleased fixes in master

[Allin C. <cot...@wf...>]

On Thu, 21 Feb 2019, Ethan A Merritt via gnuplot-beta wrote:

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

Sounds like a sane policy to me.

The project I'm most involved with has a more "aggressive" 
development policy. The upside is that genuine fixes get out to 
users more quickly. The downside is that "fixes" with nasty 
unintended side effects also get out, in some cases requiring 
"emergency" releases and engendering regrets.

Given how widely gnuplot is used, I'm with Ethan on this.

Allin Cottrell

Re: Unreleased fixes in master

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

On Thursday, February 21, 2019 9:52:17 AM PST Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > That's a tough call.  I see somewhere on the order of 20-30 commits over
> > a period of 8 months that are related to that change, touching core files
> > as well as individual terminal drivers.  That is far more extensive than
> > I ever used to consider for back-porting from the development version to
> > the stable source.
> 
> Hmmm. I guess this was done long-enough ago that I assumed the latest
> release would include it, especially since it fixes a real problem.

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.


> By the way, how are you keeping track of what's in the release and what isn't? 

Changes to the stable branch are tracked in ChangeLog and in NEWS.
I use the bullet-point summary in NEWS to prepare release notes.

In the development branch, the top section of NEWS is a bullet-point list of
what went into 5.3 but not 5.2.

I haven't been updating ChangeLog for the development branch because
people told me that the "git way" was to use commit messages instead.
I have been doing that, but see below.


> 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.  I am seriously considering to switch back to a model where
changes are fully described in a separate ChangeLog and all git commits
simply say "see ChangeLog".  That would require some automated way to
insert the appropriate git hash indices into the text of the ChangeLog.
I have tried a couple of git add-ons that looked like they might help, 
but so far with no success.

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. 

	Ethan

Re: Aw: Re: README-Windows.txt

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

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

> From: Bastian Märkisch 
> To: tmacchant3
> Cc: gnuplot-beta
> Date: 2019/2/21, Thu 18:14
> Subject: Aw: Re: README-Windows.txt
>
Dear Bastian

 
> I am a bit confused about your mail as it - in my view - adresses many
> different somewh t 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.

This was discussed at appearance of 5.2.
http://gnuplot.10905.n7.nabble.com/default-terminal-for-version-5-2-on-Windows-td20671.html




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



PC at home is very old (2010 but works on win10), qt seems not to work.
(See attachment file.)
This does not happen on PC at University. 
I will report qt issue from university.

> 
> * 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.
I know the above issue of fontconfig on windows.
Current GNU octave for windows initialize font cache at install process
as you pointed the above.

The gd based terminal uses fontconfig to support modern font specification.
Without fontconfig, the gd based terminal can have only old syntax for font specification.


BTW, I use wxt terminal usually on windows and linux. 
I did not noticed the slight differences until see the bug #2048

https://sourceforge.net/p/gnuplot/bugs/2048/#f63e

Setting PANGOCAIRO_BACKEND=fc seems to change the situation for wxt on windows.



> 
> * 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.)
Yes. Ethan's support is a good solution and it was also implemented in 5.2 
in addition to 5.3

This new syntax will be supported in the next release.
However, this topic is not windows specific.

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

This usually does not happen frequently and I cannot reproduced the issue.
Takeno has met this issue a few month before but that was not un-reproducible.
So we cannot make a bug ticket and I got an idea to delete wgnuplot.ini to reset setting as a tip.

Tatsuro

Re: Unreleased fixes in master

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

Ethan A Merritt <sf...@us...> writes:

> That's a tough call.  I see somewhere on the order of 20-30 commits over
> a period of 8 months that are related to that change, touching core files
> as well as individual terminal drivers.  That is far more extensive than
> I ever used to consider for back-porting from the development version to
> the stable source.

Hmmm. I guess this was done long-enough ago that I assumed the latest
release would include it, especially since it fixes a real problem. By
the way, how are you keeping track of what's in the release and what
isn't? 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.

Thanks
dima

Aw: Re: README-Windows.txt

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

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: README-Windows.txt

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

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

> From: Tatsuro MATSUOKA 
> To: gnuplot-beta; bmaerkisch
> Cc: 
> Date: 2019/2/9, Sat 15:03
> Subject: README-Windows.txt
> 
> 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: Unreleased fixes in master

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

On Tuesday, February 19, 2019 10:50:46 AM PST Dima Kogan wrote:
> Hi.
> 
> I'm using the 5.2.6 release, and I just hit a gnuplot bug that we
> already fixed back in 2017/11:
> 
>   https://sourceforge.net/p/gnuplot/mailman/gnuplot-beta/thread/2603217.PItpvUgmjs%40stonelion/#msg36096047
> 
> It looks like this fix is in place in the master branch, but not in the
> latest release. Is this intentional? Can we release it?

That's a tough call.  I see somewhere on the order of 20-30 commits over
a period of 8 months that are related to that change, touching core files
as well as individual terminal drivers.  That is far more extensive than
I ever used to consider for back-porting from the development version to
the stable source.

I realize that now we are using git, for better or worse.   That probably
makes it more feasible than previously to back-port a large set of changes,
if only because it is easier to back them out again if things break.

But is it a reasonable use of effort?  At some point I think you just have
to say "yeah, there are lot of nice new features and improvements in the
development version that won't appear in an official release until the next
major version (5.4)". 

Anyhow, I guess the answer is "maybe".

			Ethan

Unreleased fixes in master

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

Hi.

I'm using the 5.2.6 release, and I just hit a gnuplot bug that we
already fixed back in 2017/11:

  https://sourceforge.net/p/gnuplot/mailman/gnuplot-beta/thread/2603217.PItpvUgmjs%40stonelion/#msg36096047

It looks like this fix is in place in the master branch, but not in the
latest release. Is this intentional? Can we release it?

Thanks!

README-Windows.txt

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

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

Re: "with image" and "using"

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

sfeam <me...@uw...> writes:

> My thoughts are that it's worse than you describe.
>
> A related limitation is that it is not possible to combine 'using' with
> reading an image data from a binary file for any purpose other than
> "with image".  Not for generic binary files and not for specific known file types.
>
> For example you might want to plot a histogram of intensity values in the
> blue component of an RGB image file.  Logically this would mean extracting
> the values in "column 5", assuming a mapping to x:y:R:G:B as documented.
> The logical gnuplot command would be something like
>
>     plot 'foo.jpg' binary filetype=jpeg using 5 smooth freq with boxes
>
> Nothing of the sort works.
>
> I see no consistency in the mapping of binary data to "columns". This
> has annoyed me for a long time but the problem seems so intrinsic to
> the way the program currently works that I don't see a way to change
> it.

That's too bad. I just played with the code a bit, and indeed it doesn't
behave in an obvious way, and I can't figure it out without dumping more
time into it. I might do that at some later point, but in the meantime I
guess the current behavior will do.

Thanks for looking into it.
dima

Re: "with image" and "using"

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

On Wednesday, 30 January 2019 10:01:00 Dima Kogan wrote:
> Hi. I'm seeing a strange behavior. I THINK it's a bug, but maybe not?
> Note that the below is about "with image": we have z vs. (x,y) and NOT
> "with rgbimage" where we have (r,g,b) vs (x,y).
> 
> I can plot a simple 3x3 grid of data:
> 
>   set view map
>   splot '-' matrix notitle with image
>   0.0 1.0 4.0
>   1.0 2.0 5.0
>   4.0 5.0 8.0
> 
>   e
> 
> This works, and uses the default implicit x and y ranges: integers
> starting at 0. I can adjust this with "using". For instance I can
> linearly scale the x axis like this:
> 
>   set view map
>   splot '-' matrix using ($1*10):2:3 notitle with image
>   0.0 1.0 4.0
>   1.0 2.0 5.0
>   4.0 5.0 8.0
> 
>   e
> 
> This works too. I can also feed in binary data instead of ascii. The
> example without "using" looks like this:
> 
>   set view map
>   splot '-' binary array=(3,3) format="%double" notitle with image
>   [ binary data ]
> 
> (I'm omitting the actual data here; the functional version including the
> data is in the attachment). This works too, and produces the same plot,
> as expected. However, if I try to scale the x axis with the "using"
> clause as before, it does NOT work:
> 
>   set view map
>   splot '-' binary array=(3,3) format="%double" using ($1*10):2:3 notitle with image
>   [ binary data ]
> 
> (again, the full script is attached). In the binary-no-using case I see
> gnuplot try to read 72 bytes of binary data. This makes sense since 72 =
> 3*3*sizeof(double). In the binary-using case, however, I see gnuplot try
> to read 216 bytes intead. this is 72*3. But there aren't that many bytes
> available, so it barfs.
> 
> As I user I was not expecting this, especially since the other 3 cases
> work. Thoughts?

My thoughts are that it's worse than you describe.

A related limitation is that it is not possible to combine 'using' with
reading an image data from a binary file for any purpose other than
"with image".  Not for generic binary files and not for specific known file types.
  
For example you might want to plot a histogram of intensity values in the
blue component of an RGB image file.  Logically this would mean extracting
the values in "column 5", assuming a mapping to x:y:R:G:B as documented.
The logical gnuplot command would be something like

    plot 'foo.jpg' binary filetype=jpeg using 5 smooth freq with boxes

Nothing of the sort works.

I see no consistency in the mapping of binary data to "columns".
This has annoyed me for a long time but the problem seems so intrinsic
to the way the program currently works that I don't see a way to change it.  

	Ethan

"with image" and "using"

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

Hi. I'm seeing a strange behavior. I THINK it's a bug, but maybe not?
Note that the below is about "with image": we have z vs. (x,y) and NOT
"with rgbimage" where we have (r,g,b) vs (x,y).

I can plot a simple 3x3 grid of data:

  set view map
  splot '-' matrix notitle with image
  0.0 1.0 4.0
  1.0 2.0 5.0
  4.0 5.0 8.0

  e

This works, and uses the default implicit x and y ranges: integers
starting at 0. I can adjust this with "using". For instance I can
linearly scale the x axis like this:

  set view map
  splot '-' matrix using ($1*10):2:3 notitle with image
  0.0 1.0 4.0
  1.0 2.0 5.0
  4.0 5.0 8.0

  e

This works too. I can also feed in binary data instead of ascii. The
example without "using" looks like this:

  set view map
  splot '-' binary array=(3,3) format="%double" notitle with image
  [ binary data ]

(I'm omitting the actual data here; the functional version including the
data is in the attachment). This works too, and produces the same plot,
as expected. However, if I try to scale the x axis with the "using"
clause as before, it does NOT work:

  set view map
  splot '-' binary array=(3,3) format="%double" using ($1*10):2:3 notitle with image
  [ binary data ]

(again, the full script is attached). In the binary-no-using case I see
gnuplot try to read 72 bytes of binary data. This makes sense since 72 =
3*3*sizeof(double). In the binary-using case, however, I see gnuplot try
to read 216 bytes intead. this is 72*3. But there aren't that many bytes
available, so it barfs.

As I user I was not expecting this, especially since the other 3 cases
work. Thoughts?

Re: Web site for windows binaries of develoment version is moved.

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

> From: sfeam

> To: gnuplot-beta; Tatsuro MATSUOKA 
> Cc: 
> Date: 2019/1/6, Sun 14:30
> Subject: Re: Web site for windows binaries of develoment version is moved.
> 
> On Saturday, 05 January 2019 08:11:22 Tatsuro MATSUOKA wrote:
>>  Web site for windows binaries of develoment version is moved.
>> 
>>  MinGW
>>  http://tmacchant3.starfree.jp/gnuplot/Eng/winbin/ 
>> 
>>  Cygwin
>>  http://tmacchant3.starfree.jp/gnuplot/Eng/cygbin/ 
>> 
>>  Please change URL on
>>  http://gnuplot.sourceforge.net/download.html 
>> 
>>  Development version:
>>      Windows binaries built by Tatsuro Matsuoka: (cygwin) and (MinGW) 
> 
>     Done.
> 
>         Ethan
> 


I have confirmed.
Thanks!

Tatsuro

Re: Web site for windows binaries of develoment version is moved.

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

On Saturday, 05 January 2019 08:11:22 Tatsuro MATSUOKA wrote:
> Web site for windows binaries of develoment version is moved.
> 
> MinGW
> http://tmacchant3.starfree.jp/gnuplot/Eng/winbin/
> 
> Cygwin
> http://tmacchant3.starfree.jp/gnuplot/Eng/cygbin/
> 
> Please change URL on
> http://gnuplot.sourceforge.net/download.html
> 
> Development version:
>     Windows binaries built by Tatsuro Matsuoka: (cygwin) and (MinGW) 

    Done.

		Ethan

Web site for windows binaries of develoment version is moved.

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

Web site for windows binaries of develoment version is moved.

MinGW
http://tmacchant3.starfree.jp/gnuplot/Eng/winbin/

Cygwin
http://tmacchant3.starfree.jp/gnuplot/Eng/cygbin/

Please change URL on
http://gnuplot.sourceforge.net/download.html

Development version:
    Windows binaries built by Tatsuro Matsuoka: (cygwin) and (MinGW) 


The above movement was doen due to service stop of the current web server.


Tatsuro

Binary version 5.2.6 for OS X / macOS

[Erik L. <eri...@gm...>]

Dear all,

A binary version of gnuplot 5.2.6 is now available at

https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X

Please let me know if you encounter any problems.

Regards,

Erik

Windows binary packages for 5.2.6 (Re: Release 5.2.6)

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

Windows binary packages for 5.2.6 are now available at


https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.6/ 

Tatsuro

----- Original Message -----
> From: sfeam <me...@uw...>
> To: gnu...@li...
> Cc: 
> Date: 2019/1/3, Thu 03:41
> Subject: Release 5.2.6
> 
> A new gnuplot for the New Year
> 
> I have uploaded the release 5.2.6 tarball to Sourceforge:
> 
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.6/ 
> 
> There are no changes since last month's testing version.
> 
> 
>                 GNUPLOT Version 5.2.6 Release Notes
>                 ===================================
> 
> These release notes are for version 5.2 patchlevel 6 (5.2.6).
> This release contains bug-fixes, a few changes back-ported from the
> development version, and two new features.  The most notable fixes are for
> problems with the "pause mouse" command in the x11, wxt, and qt 
> terminals.
> 
> Please see the ChangeLog file for a complete list of changes made during the
> course of development from 5.0 to 5.2.
> 
> Release Notes date: 24-December-2018
> 
> Changes in 5.2.6
> ================
> * NEW keyword "keyentry" places an entry in the key without actually 
> plotting
> * NEW "set style boxplot medianlinewidth <lw>"
> * CHANGE drop non-working support for CIE/XYZ color space
> * CHANGE strptime ignores content read with format a/A/w/W
> * FIX various corner-case bugs and overruns found by fuzzing
> * FIX revise waitforinput in x11 terminal
> * FIX revise waitforinput and terminal close events in qt terminal
> * FIX revise waitforinput and new window events in monothreaded wxt terminal
> * FIX lua.trm compatibility with lua version 5.3
> * FIX error line reporting inside an if/else bracketed clause
> * FIX error in date conversion for times within a nanosecond of a year boundary
> 
> 
>         happy New Year and happy gnuplotting,
> 
>             Ethan
> 

Re: Release 5.2.6

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

sfeam <me...@uw...> writes:

> A new gnuplot for the New Year
>
> I have uploaded the release 5.2.6 tarball to Sourceforge:
>
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.6/

Just want to say thanks for working on this. Happy new year!

Release 5.2.6

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

A new gnuplot for the New Year

I have uploaded the release 5.2.6 tarball to Sourceforge:

    https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.6/

There are no changes since last month's testing version.


                GNUPLOT Version 5.2.6 Release Notes
                ===================================

These release notes are for version 5.2 patchlevel 6 (5.2.6).
This release contains bug-fixes, a few changes back-ported from the
development version, and two new features.  The most notable fixes are for
problems with the "pause mouse" command in the x11, wxt, and qt terminals.

Please see the ChangeLog file for a complete list of changes made during the
course of development from 5.0 to 5.2.

Release Notes date: 24-December-2018

Changes in 5.2.6
================
* NEW keyword "keyentry" places an entry in the key without actually plotting
* NEW "set style boxplot medianlinewidth <lw>"
* CHANGE drop non-working support for CIE/XYZ color space
* CHANGE strptime ignores content read with format a/A/w/W
* FIX various corner-case bugs and overruns found by fuzzing
* FIX revise waitforinput in x11 terminal
* FIX revise waitforinput and terminal close events in qt terminal
* FIX revise waitforinput and new window events in monothreaded wxt terminal
* FIX lua.trm compatibility with lua version 5.3
* FIX error line reporting inside an if/else bracketed clause
* FIX error in date conversion for times within a nanosecond of a year boundary


		happy New Year and happy gnuplotting,

			Ethan