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

Re: Development version number should be replaced by 5.3

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

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

> From: Tatsuro MATSUOKA 
> To: gnuplot-beta
> Cc: 
> Date: 2017/6/26, Mon 07:12
> Subject: Development version number should be replaced by 5.3
> 
> Hello
> 
> Development version number in http://gnuplot.sourceforge.net/
> is still 5.1.
> 
> It should be replaced by 5.3.
> 
> Tatsuro


I have confirmed web page revise.
Thanks!

BTW, version number pdf document on the page is still 5.1.
Please update.

Tatsuro

Version number in the page "Ongoing development of gnuplot"

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

Version number in the page "Ongoing development of gnuplot"
(http://www.gnuplot.info/development/index.html)
is 5.0 alpha.
It should be 5.3.

Tatsuro

Development version number should be replaced by 5.3

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

Hello

Development version number in http://gnuplot.sourceforge.net/
is still 5.1.

It should be replaced by 5.3.

Tatsuro

Re: Ideas for development in 5.3

[Philipp K. J. <ja...@ie...>]

On Tue, 20 Jun 2017 13:33:05 -0700
Ethan A Merritt via gnuplot-beta <gnu...@li...>
wrote:

> The start of a new development version is an opportunity to experiment
> with code that may or may not make it into a supported release.

This is not a feature-level suggestions, but I want 
to raise it nevertheless:

Should we revisit the issue of reducing gnuplot's 
reliance on CVS and SourceForge?

I am concerned about long-term viability, both with
respect to CVS, but also with respect to SourceForge.
I seem to remember some talk from a few months back
that SourceForge might be changing their licensing
terms...

What's more, gnuplot's "no forking" clause prevents
individual versions from living on GitHub (or equivalent),
in case something DOES happen to SourceForge.

I think a few years went by since this whole repository
issue was last discussed - maybe it's time to revisit 
it? Has anything changed that might make it easier to
port to a new repository today?

Best,

		Ph.

>  
> What new stuff or major changes would you like to see in gnuplot?
> My list of vague ideas includes
> 
> Code cleanup
> ------------
> - remove the original axis_log/delog macros
>   (not needed since introduction of generic nonlinear axis code)
> - remove other obsolete macros.  HUGE? GPFAR?  MSDOS remnants?
> - refactor VMS conditionals so that all the code is in vms.c
> - look at using math function from libm rather than hard-coding
>   them in standard.c.  For example gnuplot's implementation of
>   besj0 claims accuracy to 1e-13 but the libm man page for j0
>   claims accuracy to 2e-16
> - matrix data should be stored as (double) not (float)
> - audit all FIXMEs, surely many of them are out of date
> - further optimization of STORE_WITH_LOG_AND_UPDATE_RANGE
>   to increase speed and reduce code size
> 
> Build system options
> --------------------
> - make OSX autoconf more reliable
> - offer all-qt or all-cairo build targets
> - offer emscriptem build target
> 
> Terminals
> ---------
> - canvas terminal overhaul (use browser's font support)
> - dxy (support newer version of the standard)
> - aquaterm (mousing!)
> - svg (animation)
> - latex terminals (gnuplot enhanced text => LaTeX conversion)
> 
> Fitting
> -------
> - Alternative algorithms (i.e. not Levenberg-Marquardt)
> 
> Core extensions
> -----------------
> - support 64-bit integer arithmetic for evaluation
> - isosurfaces (3D contouring of 4D data)
> - rethink the parallel plot implementation
> - builtin equivalent to "save '|gpsavediff > outfile'"
> - barycentric coordinate plots
> - bubble charts 
> - Q-Q plots
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Ideas for development in 5.3

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

The start of a new development version is an opportunity to experiment
with code that may or may not make it into a supported release.
 
What new stuff or major changes would you like to see in gnuplot?
My list of vague ideas includes

Code cleanup
------------
- remove the original axis_log/delog macros
  (not needed since introduction of generic nonlinear axis code)
- remove other obsolete macros.  HUGE? GPFAR?  MSDOS remnants?
- refactor VMS conditionals so that all the code is in vms.c
- look at using math function from libm rather than hard-coding
  them in standard.c.  For example gnuplot's implementation of
  besj0 claims accuracy to 1e-13 but the libm man page for j0
  claims accuracy to 2e-16
- matrix data should be stored as (double) not (float)
- audit all FIXMEs, surely many of them are out of date
- further optimization of STORE_WITH_LOG_AND_UPDATE_RANGE
  to increase speed and reduce code size

Build system options
--------------------
- make OSX autoconf more reliable
- offer all-qt or all-cairo build targets
- offer emscriptem build target

Terminals
---------
- canvas terminal overhaul (use browser's font support)
- dxy (support newer version of the standard)
- aquaterm (mousing!)
- svg (animation)
- latex terminals (gnuplot enhanced text => LaTeX conversion)

Fitting
-------
- Alternative algorithms (i.e. not Levenberg-Marquardt)

Core extensions
-----------------
- support 64-bit integer arithmetic for evaluation
- isosurfaces (3D contouring of 4D data)
- rethink the parallel plot implementation
- builtin equivalent to "save '|gpsavediff > outfile'"
- barycentric coordinate plots
- bubble charts 
- Q-Q plots

Gnuplot development version is now 5.3

[Ethan A M. <merritt@u.washington.edu>]

I have bumped the version number of the development source to 5.3.

No change to your cvs setup is necessary, but you may need to do
a complete "make install" for testing because the directory path
for shared files and executables is now   /usr/local/share/gnuplot/5.3 
rather than   /usr/local/share/gnuplot/5.1  and so on.

The status of the stable version remains unchanged.
5.2.rc1 testing has turned up a couple of bugs that affect normal use.
Extensive fuzz-testing has turned up a somewhat larger number of bugs
that can be triggered only by erroneous input commands or data.
All of these have been fixed in the stable and development cvs source.

My plan is to put together an -rc2 test package at the beginning of July.
If there is anything not already in cvs that you would like to see
included in -rc2 please let me know.

	Ethan

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

Re: set border polar with 5.2 RC1

[Ethan M. <merritt@u.washington.edu>]

On Saturday, 17 June 2017 09:09:21 sfeam via gnuplot-beta wrote:
> On Saturday, 17 June 2017 17:31:34 Christoph Bersch wrote:
> >
> > In general, if I have a polar plot with autoscaled radius I would expect 
> > the complete circle of radius <autoscaled r> to fit completely in the 
> > canvas.
> 
> The autoscaled maximum on r does fit within the canvas.
> The problem comes because of the gnuplot default policy to
> extend the axis range to the next major tic mark.
> The plot comes out as you would have expected if you first say
> "set auto noextend"  or  "set rrange [] noextend".
> 
> Exactly the same thing can happen with Cartesian coordinate plots.
> The only reason you don't notice is that usually enough space is 
> reserved in the margins for axis labels etc that the "too large"
> border is still on the screen.
> 
> For example:

Bleah. Never mind the example.
Sent before morning coffee and it makes no sense at all.

	sorry 

		Ethan

> 
>    set margin .01,.01, .99, .99
>    unset xtics
>    unset ytics
>    plot '-'
> input data ('e' ends) > 0 .99
> input data ('e' ends) > .99 0
> input data ('e' ends) > 0 -.99
> input data ('e' ends) > -.99 0
> input data ('e' ends) > e
> 
> 
> > This seems to me like "natural" behavior and would probably also work 
> > better together with positioning of the polar border.
> 
> Maybe the R axis should default to "noextend"?
> 
> 	Ethan
> 
>  
> > Best,
> > Christoph
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

Re: set border polar with 5.2 RC1

[sfeam <sf...@us...>]

On Saturday, 17 June 2017 17:31:34 Christoph Bersch wrote:
>
> In general, if I have a polar plot with autoscaled radius I would expect 
> the complete circle of radius <autoscaled r> to fit completely in the 
> canvas.

The autoscaled maximum on r does fit within the canvas.
The problem comes because of the gnuplot default policy to
extend the axis range to the next major tic mark.
The plot comes out as you would have expected if you first say
"set auto noextend"  or  "set rrange [] noextend".

Exactly the same thing can happen with Cartesian coordinate plots.
The only reason you don't notice is that usually enough space is 
reserved in the margins for axis labels etc that the "too large"
border is still on the screen.

For example:

   set margin .01,.01, .99, .99
   unset xtics
   unset ytics
   plot '-'
input data ('e' ends) > 0 .99
input data ('e' ends) > .99 0
input data ('e' ends) > 0 -.99
input data ('e' ends) > -.99 0
input data ('e' ends) > e


> This seems to me like "natural" behavior and would probably also work 
> better together with positioning of the polar border.

Maybe the R axis should default to "noextend"?

	Ethan

 
> Best,
> Christoph

Re: set border polar with 5.2 RC1

[Christoph B. <us...@be...>]

On 08.06.2017 06:26, sfeam wrote:
> On Wednesday, 07 June 2017 10:59:39 PM Christoph Bersch wrote:
>>
>> * That one doesn't plot a polar border, only when an explicit rrange is
>> set (uncomment the set rrange line).
>
> The polar border is only drawn if there is an explicit rrange (not autoscaled).
> The lack of a border for auto-scaled plots now seems like a bug to me,
> although from the code it apparently was intentional.
> I honestly cannot remember what was the reason for that.

I guess the reason is, that the circle with the autoscaled radius 
doesn't necessarily fit into the canvas and is cut off.

>> * The polar border overlaps with the outer grid circle
>
> Yes.  That seemed like the only well-defined place to draw it,
> but I'm open to other suggestions.

The position is correct, but I would omit the grid circle which is at 
the same radius as the polar border.

> I suppose there could be an entirely separate command
> "set polar border at <r value>", but in general how would you
> know in advance what to set it to?

In general, if I have a polar plot with autoscaled radius I would expect 
the complete circle of radius <autoscaled r> to fit completely in the 
canvas.
This seems to me like "natural" behavior and would probably also work 
better together with positioning of the polar border.

Best,
Christoph

Re: spamming of ML addresses

[Daniel J S. <dan...@ie...>]

On 06/10/2017 12:54 PM, pl...@pi... wrote:
> On 10/06/17 15:39, Mojca Miklavec wrote:
>> On 10 June 2017 at 16:01, Philipp K. Janert wrote:
>>> On Sat, 10 Jun 2017 09:02:12 +0100
>>> pl...@pi... wrote:
>>>
>>>> Hi,
>>>>
>>>> for the last three weeks I have been getting massive amounts of SPAM
>>>> from the address I use for this ML. I am going to have to shut down
>>>> the account.
>>>>
>>>> This is presumably because sourceforge mailman service archives this
>>>> as a public list exposing contact emails which have been trawled by
>>>> spammers.
>>>>
>>>> Is there  a way to prevent full addresses being exposed in that way?
>>>>
>>>> Are others having this problem?
>>>
>>> No, I haven't (fortunately!). Sorry to hear.
>>
>> I'm getting sufficient spam from all over the place (it ends in
>> spambox anyway), so generally I wouldn't be able to tell where exactly
>> the spam originates. (I would need a separate email address for each
>> mailing list for that.)

If it is actual spam, typically the original source isn't in the email. 
Somehow that info can be left out, even though there may be a short list 
of several places the email was routed.


> Which is exactly what I do ;)
>
> That is how I know the recent flurry is coming from the contact I put on
> this ML.
>
> BTW they come in volleys of three identical emails each from different
> bogus addresses.

These kind of things happen to me on occasion, but after a week or two 
they subside when the bot gets no activity.  I.e., if you follow links 
(never do so with a suspect email), it's a confirmation of a valid 
address and the site might get other information like cookies and such.

If I have a suspect email, I'll save it to a separate file (without 
viewing the email in an HTML device...which many email viewers are) then 
look at it with a generic ASCII editor.  If the file is mostly binary 
data at the end or I don't recognize the sender/text, I discard it.

For any email that requests logging into some type of account, I don't 
follow any direct links from the email.  Instead, I go to the site in my 
browser by typing the address I know for that site.  That avoids going 
to some kind of mimic page.

Dan

Re: spamming of ML addresses

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

Am 10.06.2017 um 19:54 schrieb pl...@pi...:
>>> pl...@pi... wrote:

>>>> for the last three weeks I have been getting massive amounts of SPAM
>>>> from the address I use for this ML. 

Strange --- I didn't.  But maybe my mail provider's spam filter is 
tougher than yours...

And just out of curiosity: what do you consider "massive amounts"?

>>>> This is presumably because sourceforge mailman service archives this
>>>> as a public list exposing contact emails which have been trawled by
>>>> spammers.

Did you even look at the archives before making such an accusation?

>>>> Is there  a way to prevent full addresses being exposed in that way?

Ultimately, no, there isn't.  If an address harvester subscribes, they 
will get the address of each posted mail, pretty much by necessity.

> I also got the renew subscription msg , which I also thought looked 
> rather phishy, so I did not do anything about it.

The message is, to the best I can tell, genuine.  Go directly to the 
project's Mailing List pages (not via any link from that mail, if you're 
worried), and see for yourself.

Re: spamming of ML addresses

[<pl...@pi...>]

On 10/06/17 15:39, Mojca Miklavec wrote:
> On 10 June 2017 at 16:01, Philipp K. Janert wrote:
>> On Sat, 10 Jun 2017 09:02:12 +0100
>> pl...@pi... wrote:
>>
>>> Hi,
>>>
>>> for the last three weeks I have been getting massive amounts of SPAM
>>> from the address I use for this ML. I am going to have to shut down
>>> the account.
>>>
>>> This is presumably because sourceforge mailman service archives this
>>> as a public list exposing contact emails which have been trawled by
>>> spammers.
>>>
>>> Is there  a way to prevent full addresses being exposed in that way?
>>>
>>> Are others having this problem?
>>
>> No, I haven't (fortunately!). Sorry to hear.
> 
> I'm getting sufficient spam from all over the place (it ends in
> spambox anyway), so generally I wouldn't be able to tell where exactly
> the spam originates. (I would need a separate email address for each
> mailing list for that.)

Which is exactly what I do ;)

That is how I know the recent flurry is coming from the contact I put on 
this ML.

BTW they come in volleys of three identical emails each from different 
bogus addresses.

I also got the renew subscription msg , which I also thought looked 
rather phishy, so I did not do anything about it.  This prompted me to 
consider killing this address and subscribing with a new one, but 
chances are the same thing will happen.

Thanks for comments.

Peter.


> 
>> But the other day I got an email, apparently from
>> Sourceforge, to confirm that I want to be subscribed
>> to the two gnuplot email lists. I don't recall ever
>> receiving such an email before, but it looked legit,
>> and so I confirmed. Have others gotten similar emails?
> 
> Yes, I got that one as well.
> 
> The list of mailing lists looks OK. So either they have so many
> spammers subscribed on various lists that they had to do this to get
> rid of spammers. Or some spammers got hold of their complete database
> and are now sending emails themselves :) I guess it's the first in
> this case, but it would be nice if they wrote this somewhere on the
> web page as it looks suspicious in any case. Usually such emails are
> phishing attacks, I don't remember getting a similar legitimate email
> like that one in the past.
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: spamming of ML addresses

[Mojca M. <moj...@gm...>]

On 10 June 2017 at 16:01, Philipp K. Janert wrote:
> On Sat, 10 Jun 2017 09:02:12 +0100
> pl...@pi... wrote:
>
>> Hi,
>>
>> for the last three weeks I have been getting massive amounts of SPAM
>> from the address I use for this ML. I am going to have to shut down
>> the account.
>>
>> This is presumably because sourceforge mailman service archives this
>> as a public list exposing contact emails which have been trawled by
>> spammers.
>>
>> Is there  a way to prevent full addresses being exposed in that way?
>>
>> Are others having this problem?
>
> No, I haven't (fortunately!). Sorry to hear.

I'm getting sufficient spam from all over the place (it ends in
spambox anyway), so generally I wouldn't be able to tell where exactly
the spam originates. (I would need a separate email address for each
mailing list for that.)

> But the other day I got an email, apparently from
> Sourceforge, to confirm that I want to be subscribed
> to the two gnuplot email lists. I don't recall ever
> receiving such an email before, but it looked legit,
> and so I confirmed. Have others gotten similar emails?

Yes, I got that one as well.

The list of mailing lists looks OK. So either they have so many
spammers subscribed on various lists that they had to do this to get
rid of spammers. Or some spammers got hold of their complete database
and are now sending emails themselves :) I guess it's the first in
this case, but it would be nice if they wrote this somewhere on the
web page as it looks suspicious in any case. Usually such emails are
phishing attacks, I don't remember getting a similar legitimate email
like that one in the past.

Mojca

Re: spamming of ML addresses

[Philipp K. J. <ja...@ie...>]

On Sat, 10 Jun 2017 09:02:12 +0100
pl...@pi... wrote:

> Hi,
> 
> for the last three weeks I have been getting massive amounts of SPAM 
> from the address I use for this ML. I am going to have to shut down
> the account.
> 
> This is presumably because sourceforge mailman service archives this
> as a public list exposing contact emails which have been trawled by
> spammers.
> 
> Is there  a way to prevent full addresses being exposed in that way?
> 
> Are others having this problem?

No, I haven't (fortunately!). Sorry to hear.

But the other day I got an email, apparently from
Sourceforge, to confirm that I want to be subscribed
to the two gnuplot email lists. I don't recall ever
receiving such an email before, but it looked legit,
and so I confirmed. Have others gotten similar emails?

> 
> Peter.
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

spamming of ML addresses

[<pl...@pi...>]

Hi,

for the last three weeks I have been getting massive amounts of SPAM 
from the address I use for this ML. I am going to have to shut down the 
account.

This is presumably because sourceforge mailman service archives this as 
a public list exposing contact emails which have been trawled by spammers.

Is there  a way to prevent full addresses being exposed in that way?

Are others having this problem?

Peter.

Re: default terminal for version 5.2 on Windows

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

Hello Bastian

I have confirmed that now wxt is default 
even if I drop  -DDEFAULTTERM=\"wxt\" to CFLAGS in Makefile.

Tatsuro


----- Original Message -----
>From: ""Bastian Märkisch"" <bma...@we...>
>To: Tatsuro MATSUOKA <tma...@ya...>; gnuplot beta list <gnu...@li...> 
>Date: 2017/6/8, Thu 15:42
>Subject: Aw: Re: default terminal for version 5.2 on Windows
> 
>
>The default terminal on Windows was changed to wxt for 5.2 in term.c yesterday.
>
>Bastian
>
>Am 08.06.17, 02:06, Tatsuro MATSUOKA <tma...@ya...> schrieb:
>----- Original Message -----
>>
>>> From: Tatsuro MATSUOKA 
>>> To: bmaerkisch; gnuplot-beta
>>> Cc: 
>>> Date: 2017/6/2, Fri 18:25
>>> Subject: Re: default terminal for version 5.2 on Windows
>>> ----- Original Message -----
>>>>  From: ""Bastian Märkisch"" 
>>>>  To: gnuplot beta list 
>>>>  Cc: 
>>>>  Date: 2017/6/2, Fri 13:42
>>>>  Subject: default terminal for version 5.2 on Windows
>>>> 
>>>>  In version 5.0 on Windows, the wxt terminal is still the default terminal - 
>>> in 
>>>>  contrast to other platforms where it is "qt". Before version 4.2 
>>> the 
>>>>  default used to be the "windows" terminal. As is, the new default 
>>> on 
>>>>  Windows would be "qt", too.  But on Windows "qt" is 
>>> still 
>>>>  somewhat buggy (e.g. "replot-on-resize" just does not work) or is 
>>> 
>>>>  missing features compared to "wxt" or "windows" 
>>> (printing, 
>>>>  screendump, emf, docked windows). Also, the persist behaviour of 
>>> "qt" 
>>>>  is different (terminal in separate process), so this at least would have to 
>>> be 
>>>>  documented. Start-up time for the first plot is considerably longer for 
>>>>  "qt". On the other hand "wxt" has been extended to 
>>> support 
>>>>  printing and emf export in version 5.2 and drawing is somewhat faster, too. 
>>> The 
>>>>  "windows" terminal is now on par concerning the quality of the 
>>> plots, 
>>>>  and also supports printing, export of emf and "docked graphs". 
>>> The new 
>>>>  (experimental) Direct2D backend of the terminal is currently the fastest 
>>>>  plotting option on Windows (except for pattern fills). The 
>>> "docking" 
>>>>  of graph windows to the wgnuplot text window is useful e.g. when in 
>>>>  "tablet-mode" (only maximised applications).
>>>>  My suggestion for 5.2 would hence be to either stick with "wxt" 
>>> as the 
>>>>  default terminal on Windows, or to switch to "windows" instead of 
>>> 
>>>>  "qt".
>>>>  The installer offers the user to change the GNUTERM environment variable to 
>>> 
>>>>  "windows", "wxt", or "qt" already.
>>>> 
>>>>    Bastian
>>> 
>>> I agree with your proposal as a one of gnuplot for widnows user.
>>> 
>>> Tatsuro
>>> 
>>
>>
>>I am using -DDEFAULTTERM=\"wxt\" to CFLAGS in Makefile 
>>to make the wxt terminal default for my binary distribution.
>>
>>Are you planing the above by Makefile modification 
>>or rewrite source code using ifdef?
>>
>>The above question just comes from my curiosity.
>>I do have any opinion what you will do for windows terminal to be default.
>>
>>Tatsuro
>>
>
>

Aw: Re: default terminal for version 5.2 on Windows

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

<html><head/><body><html><head><meta name="viewport" content="width=device-width" /><meta http-equiv="Content-Type" content="text/vnd.ui.secure+html;charset=utf-8" /></head><body style="overflow-wrap:break-word; word-break: break-word;"><div class="mail_android_message" style="line-height: 1; padding: 0.5em">The default terminal on Windows was changed to wxt for 5.2 in term.c yesterday.<br>
<br>
  Bastian<br>
</div><div class="mail_android_quote" style="line-height: 1; padding: 0.3em">Am 08.06.17, 02:06, Tatsuro MATSUOKA &lt;tma...@ya...&gt; schrieb:<blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
----- Original Message -----<br />
<br />
&gt; From: Tatsuro MATSUOKA <br />
&gt; To: bmaerkisch; gnuplot-beta<br />
&gt; Cc: <br />
&gt; Date: 2017/6/2, Fri 18:25<br />
&gt; Subject: Re: default terminal for version 5.2 on Windows<br />
&gt; ----- Original Message -----<br />
&gt;&gt;&nbsp; From: &quot;&quot;Bastian M&auml;rkisch&quot;&quot; <br />
&gt;&gt;&nbsp; To: gnuplot beta list <br />
&gt;&gt;&nbsp; Cc: <br />
&gt;&gt;&nbsp; Date: 2017/6/2, Fri 13:42<br />
&gt;&gt;&nbsp; Subject: default terminal for version 5.2 on Windows<br />
&gt;&gt; <br />
&gt;&gt;&nbsp; In version 5.0 on Windows, the wxt terminal is still the default terminal - <br />
&gt; in <br />
&gt;&gt;&nbsp; contrast to other platforms where it is &quot;qt&quot;. Before version 4.2 <br />
&gt; the <br />
&gt;&gt;&nbsp; default used to be the &quot;windows&quot; terminal. As is, the new default <br />
&gt; on <br />
&gt;&gt;&nbsp; Windows would be &quot;qt&quot;, too.&nbsp; But on Windows &quot;qt&quot; is <br />
&gt; still <br />
&gt;&gt;&nbsp; somewhat buggy (e.g. &quot;replot-on-resize&quot; just does not work) or is <br />
&gt; <br />
&gt;&gt;&nbsp; missing features compared to &quot;wxt&quot; or &quot;windows&quot; <br />
&gt; (printing, <br />
&gt;&gt;&nbsp; screendump, emf, docked windows). Also, the persist behaviour of <br />
&gt; &quot;qt&quot; <br />
&gt;&gt;&nbsp; is different (terminal in separate process), so this at least would have to <br />
&gt; be <br />
&gt;&gt;&nbsp; documented. Start-up time for the first plot is considerably longer for <br />
&gt;&gt;&nbsp; &quot;qt&quot;. On the other hand &quot;wxt&quot; has been extended to <br />
&gt; support <br />
&gt;&gt;&nbsp; printing and emf export in version 5.2 and drawing is somewhat faster, too. <br />
&gt; The <br />
&gt;&gt;&nbsp; &quot;windows&quot; terminal is now on par concerning the quality of the <br />
&gt; plots, <br />
&gt;&gt;&nbsp; and also supports printing, export of emf and &quot;docked graphs&quot;. <br />
&gt; The new <br />
&gt;&gt;&nbsp; (experimental) Direct2D backend of the terminal is currently the fastest <br />
&gt;&gt;&nbsp; plotting option on Windows (except for pattern fills). The <br />
&gt; &quot;docking&quot; <br />
&gt;&gt;&nbsp; of graph windows to the wgnuplot text window is useful e.g. when in <br />
&gt;&gt;&nbsp; &quot;tablet-mode&quot; (only maximised applications).<br />
&gt;&gt;&nbsp; My suggestion for 5.2 would hence be to either stick with &quot;wxt&quot; <br />
&gt; as the <br />
&gt;&gt;&nbsp; default terminal on Windows, or to switch to &quot;windows&quot; instead of <br />
&gt; <br />
&gt;&gt;&nbsp; &quot;qt&quot;.<br />
&gt;&gt;&nbsp; The installer offers the user to change the GNUTERM environment variable to <br />
&gt; <br />
&gt;&gt;&nbsp; &quot;windows&quot;, &quot;wxt&quot;, or &quot;qt&quot; already.<br />
&gt;&gt; <br />
&gt;&gt;&nbsp; &nbsp; Bastian<br />
&gt; <br />
&gt; I agree with your proposal as a one of gnuplot for widnows user.<br />
&gt; <br />
&gt; Tatsuro<br />
&gt; <br />
<br />
<br />
I am using -DDEFAULTTERM=\&quot;wxt\&quot; to CFLAGS in Makefile <br />
to make the wxt terminal default for my binary distribution.<br />
<br />
Are you planing the above by Makefile modification <br />
or rewrite source code using ifdef?<br />
<br />
The above question just comes from my curiosity.<br />
I do have any opinion what you will do for windows terminal to be default.<br />
<br />
Tatsuro<br />
</blockquote></div></body></html></body></html>

Re: set border polar with 5.2 RC1

[sfeam <sf...@us...>]

On Wednesday, 07 June 2017 10:59:39 PM Christoph Bersch wrote:
> Hi,
> 
> I'm testing a bit the new features in 5.2 RC1. I had some problems with 
> `set border polar`
> 
> Consider the following script:
> 
> reset
> set polar
> set grid polar lw 2
> unset xtics
> unset ytics
> set size square
> unset key
> # set rrange [0:6.5]
> set border 0 polar
> plot t lt 3 lw 2, -t lt 4 lw 2
> 
> * That one doesn't plot a polar border, only when an explicit rrange is 
> set (uncomment the set rrange line).

The polar border is only drawn if there is an explicit rrange (not autoscaled).
The lack of a border for auto-scaled plots now seems like a bug to me,
although from the code it apparently was intentional.
I honestly cannot remember what was the reason for that.

> * The polar border overlaps with the outer grid circle

Yes.  That seemed like the only well-defined place to draw it,
but I'm open to other suggestions.

I suppose there could be an entirely separate command
"set polar border at <r value>", but in general how would you
know in advance what to set it to?

> * Another observation is, that the polar grid is not clipped at the 
> original square border (like it is done in 5.0), but drawn until the 
> canvas border.

That is definitely intentional.  Clipping off the "corners" of a circle looks
really strange.

It would be nice if you could clip lines to RMAX instead, but the existing
clipping code is not designed for this.  It's on my long-term wishlist to
find an efficient way to do radial clipping.

	Ethan

> Thank you,
> Christoph

Re: default terminal for version 5.2 on Windows

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

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

> From: Tatsuro MATSUOKA 
> To: bmaerkisch; gnuplot-beta
> Cc: 
> Date: 2017/6/2, Fri 18:25
> Subject: Re: default terminal for version 5.2 on Windows
> ----- Original Message -----
>>  From: ""Bastian Märkisch"" 
>>  To: gnuplot beta list 
>>  Cc: 
>>  Date: 2017/6/2, Fri 13:42
>>  Subject: default terminal for version 5.2 on Windows
>> 
>>  In version 5.0 on Windows, the wxt terminal is still the default terminal - 
> in 
>>  contrast to other platforms where it is "qt". Before version 4.2 
> the 
>>  default used to be the "windows" terminal. As is, the new default 
> on 
>>  Windows would be "qt", too.  But on Windows "qt" is 
> still 
>>  somewhat buggy (e.g. "replot-on-resize" just does not work) or is 
> 
>>  missing features compared to "wxt" or "windows" 
> (printing, 
>>  screendump, emf, docked windows). Also, the persist behaviour of 
> "qt" 
>>  is different (terminal in separate process), so this at least would have to 
> be 
>>  documented. Start-up time for the first plot is considerably longer for 
>>  "qt". On the other hand "wxt" has been extended to 
> support 
>>  printing and emf export in version 5.2 and drawing is somewhat faster, too. 
> The 
>>  "windows" terminal is now on par concerning the quality of the 
> plots, 
>>  and also supports printing, export of emf and "docked graphs". 
> The new 
>>  (experimental) Direct2D backend of the terminal is currently the fastest 
>>  plotting option on Windows (except for pattern fills). The 
> "docking" 
>>  of graph windows to the wgnuplot text window is useful e.g. when in 
>>  "tablet-mode" (only maximised applications).
>>  My suggestion for 5.2 would hence be to either stick with "wxt" 
> as the 
>>  default terminal on Windows, or to switch to "windows" instead of 
> 
>>  "qt".
>>  The installer offers the user to change the GNUTERM environment variable to 
> 
>>  "windows", "wxt", or "qt" already.
>> 
>>    Bastian
> 
> I agree with your proposal as a one of gnuplot for widnows user.
> 
> Tatsuro
> 


I am using -DDEFAULTTERM=\"wxt\" to CFLAGS in Makefile 
to make the wxt terminal default for my binary distribution.

Are you planing the above by Makefile modification 
or rewrite source code using ifdef?

The above question just comes from my curiosity.
I do have any opinion what you will do for windows terminal to be default.

Tatsuro

set border polar with 5.2 RC1

[Christoph B. <us...@be...>]

Hi,

I'm testing a bit the new features in 5.2 RC1. I had some problems with 
`set border polar`

Consider the following script:

reset
set polar
set grid polar lw 2
unset xtics
unset ytics
set size square
unset key
# set rrange [0:6.5]
set border 0 polar
plot t lt 3 lw 2, -t lt 4 lw 2

* That one doesn't plot a polar border, only when an explicit rrange is 
set (uncomment the set rrange line).

* The polar border overlaps with the outer grid circle

* Another observation is, that the polar grid is not clipped at the 
original square border (like it is done in 5.0), but drawn until the 
canvas border.

Are those changes intended, or bugs?

Thank you,
Christoph

Re: default terminal for version 5.2 on Windows

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

----- Original Message -----
> From: ""Bastian Märkisch"" 
> To: gnuplot beta list 
> Cc: 
> Date: 2017/6/2, Fri 13:42
> Subject: default terminal for version 5.2 on Windows
> 
> In version 5.0 on Windows, the wxt terminal is still the default terminal - in 
> contrast to other platforms where it is "qt". Before version 4.2 the 
> default used to be the "windows" terminal. As is, the new default on 
> Windows would be "qt", too.  But on Windows "qt" is still 
> somewhat buggy (e.g. "replot-on-resize" just does not work) or is 
> missing features compared to "wxt" or "windows" (printing, 
> screendump, emf, docked windows). Also, the persist behaviour of "qt" 
> is different (terminal in separate process), so this at least would have to be 
> documented. Start-up time for the first plot is considerably longer for 
> "qt". On the other hand "wxt" has been extended to support 
> printing and emf export in version 5.2 and drawing is somewhat faster, too. The 
> "windows" terminal is now on par concerning the quality of the plots, 
> and also supports printing, export of emf and "docked graphs". The new 
> (experimental) Direct2D backend of the terminal is currently the fastest 
> plotting option on Windows (except for pattern fills). The "docking" 
> of graph windows to the wgnuplot text window is useful e.g. when in 
> "tablet-mode" (only maximised applications).
> My suggestion for 5.2 would hence be to either stick with "wxt" as the 
> default terminal on Windows, or to switch to "windows" instead of 
> "qt".
> The installer offers the user to change the GNUTERM environment variable to 
> "windows", "wxt", or "qt" already.
> 
>   Bastian

I agree with your proposal as a one of gnuplot for widnows user.

Tatsuro

default terminal for version 5.2 on Windows

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

In version 5.0 on Windows, the wxt terminal is still the default terminal - in contrast to other platforms where it is "qt". Before version 4.2 the default used to be the "windows" terminal. As is, the new default on Windows would be "qt", too.  But on Windows "qt" is still somewhat buggy (e.g. "replot-on-resize" just does not work) or is missing features compared to "wxt" or "windows" (printing, screendump, emf, docked windows). Also, the persist behaviour of "qt" is different (terminal in separate process), so this at least would have to be documented. Start-up time for the first plot is considerably longer for "qt". On the other hand "wxt" has been extended to support printing and emf export in version 5.2 and drawing is somewhat faster, too. The "windows" terminal is now on par concerning the quality of the plots, and also supports printing, export of emf and "docked graphs". The new (experimental) Direct2D backend of the terminal is currently the fastest plotting option on Windows (except for pattern fills). The "docking" of graph windows to the wgnuplot text window is useful e.g. when in "tablet-mode" (only maximised applications).
My suggestion for 5.2 would hence be to either stick with "wxt" as the default terminal on Windows, or to switch to "windows" instead of "qt".
The installer offers the user to change the GNUTERM environment variable to "windows", "wxt", or "qt" already.

  Bastian

Re: 5.2.rc1 : segfault with initial line style setting

[KH.Moriyama <khm...@gm...>]

> Thanks for the bug report.
>
> The issue seems to be that "set style line" tries to query the current
> terminal, and in your configuration that hasn't been initialized yet.
>
> For now an easy work-around is to add a first line to ~/.gnuplot
>
>         set term unknown   # or anything else, just to have something set
>
> That will allow the "set style" commands to execute, and the real
> terminal type  will still be initialized normally after the ~./gnuplot file is read.
>
>         Ethan
>

Yes. It worked. Thanks :-)

Kiyofumi

Re: 5.2.rc1 : segfault with initial line style setting

[sfeam <sf...@us...>]

On Thursday, 01 June 2017 10:22:55 PM KH.Moriyama wrote:
> Hi!
> 
> Thanks for the 5.2 rc1 source tar ball :-)
> I am testing it on Linux Mint 17.3 MATE (64 bit).
> I compile with the following configure options.
> 
> ./configure --with-x --prefix=/usr \
>      --without-latex --without-lua --without-lisp-files \
>      --with-readline=gnu \
>      --enable-backwards-compatibility
> 
> When I start gnuplot with my personal initialization file ".gnuplot"
> that includes line style definitions like
> 
> set style line  1  lt  1  lc rgbcolor "red"            pt 1
> set style line  2  lt  2  lc rgbcolor "dark-green"     pt 2
> set style line  3  lt  3  lc rgbcolor "blue"           pt 3
> set style line  4  lt  4  lc rgbcolor "magenta"        pt 4
> ...
> 
> it dies with "Segmentation fault".

Thanks for the bug report.

The issue seems to be that "set style line" tries to query the current
terminal, and in your configuration that hasn't been initialized yet.

For now an easy work-around is to add a first line to ~/.gnuplot

        set term unknown   # or anything else, just to have something set

That will allow the "set style" commands to execute, and the real
terminal type  will still be initialized normally after the ~./gnuplot file is read.

	Ethan

> When those line style definitions are eliminated, gnuplot runs well.
> And, once started up, I can load the same line style definitions
> with no problem.
> It seems that initialization commands other than the line style
> definition do no harm.
> I did not have such a problem with earlier versions.
> 
> Does anyone find the same problem?
> 
> Kiyofumi
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: 5.2.rc1 : segfault with initial line style setting

[Dmitri A. S. <das...@gm...>]

On Thu, Jun 1, 2017 at 8:22 AM, KH.Moriyama <khm...@gm...> wrote:

> Hi!
>
> Thanks for the 5.2 rc1 source tar ball :-)
> I am testing it on Linux Mint 17.3 MATE (64 bit).
> I compile with the following configure options.
>
> ./configure --with-x --prefix=/usr \
>      --without-latex --without-lua --without-lisp-files \
>      --with-readline=gnu \
>      --enable-backwards-compatibility
>
> When I start gnuplot with my personal initialization file ".gnuplot"
> that includes line style definitions like
>
> set style line  1  lt  1  lc rgbcolor "red"            pt 1
> set style line  2  lt  2  lc rgbcolor "dark-green"     pt 2
> set style line  3  lt  3  lc rgbcolor "blue"           pt 3
> set style line  4  lt  4  lc rgbcolor "magenta"        pt 4
> ...
>
> it dies with "Segmentation fault".
> When those line style definitions are eliminated, gnuplot runs well.
> And, once started up, I can load the same line style definitions
> with no problem.
> It seems that initialization commands other than the line style
> definition do no harm.
> I did not have such a problem with earlier versions.
>
> Does anyone find the same problem?
>

​I can confirm that on Fedora.
Gnuplot built with default options.​




>
> Kiyofumi
>
>
​Dmitri.
-- 
​