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

Re: nonlinear3.dem is very slow on aqua terminal

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

Brief summary:

The command "plot <foo> with image pixels" tells gnuplot to render
individual pixels rather than sending a bitmap of the entire image.
This has a number of uses.  The current bug report comes from demo
nonlinear3.dem, in which pixels must be rendered individually because
they are not of uniform size.

Bug:  This demo is horribly slow (8 minutes) using the aqua terminal


On Tuesday, 19 July, 2016 22:18:09 Jun T. wrote:
> 
> I did some profiling, and has found that gnuplot uses lots of CPU time at
> 
>   [adapter eraseRect:scaledRect];	aquaterm.trm, line 662                                   
> 
> and Aquaterm.app spends most of the CPU time processing these eraseRect
> requests from gnuplot.
> 
> AQUA_filled_polygon() does not (can not) have this eraseRect call, so it
> is not slow.
> 
> If I comment out the line 662 of aquaterm.trm, then nonlinear3.dem takes
> about 8 to 10 seconds (instead of 8 minutes), and it *seems* to give
> the same plot. But I guess eraseRect has been added intentionally to get
> better results in some cases, and rather hesitate to remove this line.
> 
> Another possibility is to include TERM_POLYGON_PIXELS in term->flags of
> aqua terminal. I also tried this, and it was virtually as fast as
> removing the line 662.
> Maybe this would be safe enough? TERM_POLYGON_PIXELS is not used other
> than at line 4977 of graphics.c.

It is fine to set set TERM_POLYGON_PIXELS.  That flag is an advisory to
the core code that the term->filled_polygon() routine is prefered to the
term->boxfill() routine for whatever reason.  In this case the reason is
execution speed.

I do not know why the aqua boxfill() routine calls eraseRect.
Other terminals do not have an equivalent call.
Perhaps the original author remembers why
	(cc-ed to Per Persson)

For now I will add the TERM_POLYGON_PIXELS flag, but it would be nice to
fix/improve AQUA_boxfill() also.

> 
> NOTE:
> I *guess* the eraseRect is slow due to the following reason. Suppose there
> is already a rectangle R0 with 4 corners at (0,0)-(0,100)-(100,100)-(100,0).
> If eraseRect is called with a rectangle Rx=(50,50)-(50,150)-(150,150)-(150,50)
> then it needs to modify R0 into a polygon with 6 vertices at
> (0,0)-(100,0)-(100,50)-(50,50)_(50,100)-(0,100).
> If there are many rectangles/polygons already in the plot, then eraseRect
> must find *all* the intersections of these pre-existing rectangles/polygons
> with the rectangle Rx.

	Ethan

Re: nonlinear3.dem is very slow on aqua terminal

[Jun T. <tak...@kb...>]

On 2016/07/19, at 15:29, Daniel J Sebald <dan...@ie...> wrote:
>> 
>> They don't use the 'pixels' option for plot.
> 
> That's true.  But they do use the same polygon code ultimately.

If 'pixels' is not specified, then process_image() calls AQUA_image(), while with
'pixels' it calls AQUA_boxfill(), which is very slow.

> How long does the following plot take?:
> 
> plot 'blutux.rgb' binary array=(128,128) flipy rotation=30d format='%uchar' with rgbimage

It takes just a few seconds.
As you know, AQUA_filled_polygon() is called in this case.


On 2016/07/19, at 16:28, Daniel J Sebald <dan...@ie...> wrote:
> Is there some way of undefining LOGGING and recompile?:

LOGGING is not defined by default.


I did some profiling, and has found that gnuplot uses lots of CPU time at

  [adapter eraseRect:scaledRect];	aquaterm.trm, line 662                                   

and Aquaterm.app spends most of the CPU time processing these eraseRect
requests from gnuplot.

AQUA_filled_polygon() does not (can not) have this eraseRect call, so it
is not slow.

If I comment out the line 662 of aquaterm.trm, then nonlinear3.dem takes
about 8 to 10 seconds (instead of 8 minutes), and it *seems* to give
the same plot. But I guess eraseRect has been added intentionally to get
better results in some cases, and rather hesitate to remove this line.

Another possibility is to include TERM_POLYGON_PIXELS in term->flags of
aqua terminal. I also tried this, and it was virtually as fast as
removing the line 662.
Maybe this would be safe enough? TERM_POLYGON_PIXELS is not used other
than at line 4977 of graphics.c.

NOTE:
I *guess* the eraseRect is slow due to the following reason. Suppose there
is already a rectangle R0 with 4 corners at (0,0)-(0,100)-(100,100)-(100,0).
If eraseRect is called with a rectangle Rx=(50,50)-(50,150)-(150,150)-(150,50)
then it needs to modify R0 into a polygon with 6 vertices at
(0,0)-(100,0)-(100,50)-(50,50)_(50,100)-(0,100).
If there are many rectangles/polygons already in the plot, then eraseRect
must find *all* the intersections of these pre-existing rectangles/polygons
with the rectangle Rx.

Re: nonlinear3.dem is very slow on aqua terminal

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

On 07/19/2016 01:29 AM, Daniel J Sebald wrote:
> On 07/19/2016 12:04 AM, Jun T. wrote:
>
>>>> It seems gnuplot uses about 0.5GB of memory for nonlinear3.dem.
>>
>> qt or wxt uses much smaller amount of memory.
>>
>> As for the CPU usage, Aquaterm.app uses about 95% of cpu while gnuplot uses 5 to 10%
>> (100% means one cpu core is fully used). So it seems gnuplot creates large amount
>> of data and send it to Aquaterm.app, while the latter uses large amount of cpu
>> to process the data.
>>
>> I will do some profiling later (if I have some time).
>>
>>> I'm still surprised that this takes so long.  If none of the demos in 'image.dem' and 'image2.dem' are glacial-pace slow,
>>
>> They don't use the 'pixels' option for plot.
>
> That's true.  But they do use the same polygon code ultimately.
>
>
>> Just the following command (without any scaling etc.) takes a long time:
>>
>> plot 'blutux.rgb' binary array=(128,128) flipy format='%uchar' with rgbimage pixels
>
> How long does the following plot take?:
>
> plot 'blutux.rgb' binary array=(128,128) flipy rotation=30d
> format='%uchar' with rgbimage

If the above isn't as slow as your example using "pixels" option, then 
the difference is that one is using parallelograms and the other 
rectangles.  The example that uses rectangles (the slow example), calls 
(*term->fillbox).  In the aquaterm.c file fillbox has a log message at 
the front that filled_polygon does not, i.e.,

   LOG(@"\nstyle=%d\nstyle & 0xf = %d\nfillpar=%d\n", style, style & 
0xf, style >> 4);

Whenever some numbers are changed to ASCII it expands the data quite a 
bit.  Could it be that for each pixel one of the log messages is being 
put in some type of AQUA debugger?  And that debugger could be 
processing a lot of data, and it might have to dynamically build a list 
of log messages so could be inefficient.  All a guess.  Do you know if 
you have debugging active?

http://www.roseindia.net/tutorial/iphone/examples/nslog/index.html

Is there some way of undefining LOGGING and recompile?:

#ifdef LOGGING
#define LOG  NSLog
#else
#define LOG  NOOP_
#endif	/* LOGGING */

Dan

Re: nonlinear3.dem is very slow on aqua terminal

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

On 07/19/2016 12:04 AM, Jun T. wrote:

>>> It seems gnuplot uses about 0.5GB of memory for nonlinear3.dem.
>
> qt or wxt uses much smaller amount of memory.
>
> As for the CPU usage, Aquaterm.app uses about 95% of cpu while gnuplot uses 5 to 10%
> (100% means one cpu core is fully used). So it seems gnuplot creates large amount
> of data and send it to Aquaterm.app, while the latter uses large amount of cpu
> to process the data.
>
> I will do some profiling later (if I have some time).
>
>> I'm still surprised that this takes so long.  If none of the demos in 'image.dem' and 'image2.dem' are glacial-pace slow,
>
> They don't use the 'pixels' option for plot.

That's true.  But they do use the same polygon code ultimately.


> Just the following command (without any scaling etc.) takes a long time:
>
> plot 'blutux.rgb' binary array=(128,128) flipy format='%uchar' with rgbimage pixels

How long does the following plot take?:

plot 'blutux.rgb' binary array=(128,128) flipy rotation=30d 
format='%uchar' with rgbimage

Dan

Re: nonlinear3.dem is very slow on aqua terminal

[Jun T. <tak...@kb...>]

On 2016/07/18, at 2:08, Daniel J Sebald <dan...@ie...> wrote:
> 
> Ah, yes, the vector-based pixels, but that is contrary to what you had concluded.  In that mode, gnuplot is not using bitmap graphics, but vector graphics

Yes, gnuplot creates the image as a vector graphics, but I've been thinking
that other terminals, such as qt, internally convert it into a bitmap while
aqua treats it as a vector graphics. But yes, even if this is the case,
I don't know why aqua is so slow.

>> It seems gnuplot uses about 0.5GB of memory for nonlinear3.dem.

qt or wxt uses much smaller amount of memory.

As for the CPU usage, Aquaterm.app uses about 95% of cpu while gnuplot uses 5 to 10%
(100% means one cpu core is fully used). So it seems gnuplot creates large amount
of data and send it to Aquaterm.app, while the latter uses large amount of cpu
to process the data.

I will do some profiling later (if I have some time).

> I'm still surprised that this takes so long.  If none of the demos in 'image.dem' and 'image2.dem' are glacial-pace slow,

They don't use the 'pixels' option for plot.

> What happens if you temporarily make this change in probably_tux.dem:
> 
> #f(x) = norm((x-center)/sigma)
> #g(x) = sigma*invnorm(x)+center
> f(x) = x
> g(x) = x

Just the following command (without any scaling etc.) takes a long time:

plot 'blutux.rgb' binary array=(128,128) flipy format='%uchar' with rgbimage pixels

Re: nonlinear3.dem is very slow on aqua terminal

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

On 07/17/2016 12:08 PM, Daniel J Sebald wrote:
> On 07/17/2016 11:34 AM, Jun T. wrote:
>>
[snip]
> I'm still surprised that this takes so long.  If none of the demos in
> 'image.dem' and 'image2.dem' are glacial-pace slow, then I wonder if
> something is happening in which the nonlinearity creates a rectangular
> with peculiar coordinates that causes an algorithm aqua is using to veer
> off course.
>
> What happens if you temporarily make this change in probably_tux.dem:
>
> #f(x) = norm((x-center)/sigma)
> #g(x) = sigma*invnorm(x)+center
> f(x) = x
> g(x) = x

I'm guessing that is pretty much the same as leaving off nonlinear x and 
nonlinear y.  We should probably create a bug report for this Jun. 
Maybe a NaN or something odd is being sent to the Aqua terminal that it 
doesn't like.

Dan

Re: nonlinear3.dem is very slow on aqua terminal

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

On 07/17/2016 11:34 AM, Jun T. wrote:
>
> 2016/07/16 15:20, Daniel J Sebald <dan...@ie...> wrote:
>
>> Does the 'image.dem' example take so long as well?,
>
> No, it works normally.
>
> I think use of the 'pixels' keyword in probably_tux.dem is causing
> the slowness. If I remove the 'pixels' from the last line of
> probably_tux.dem then nonlinear3.dem ends quickly, but the nonlinear
> axis scaling does not work anymore.

Ah, yes, the vector-based pixels, but that is contrary to what you had 
concluded.  In that mode, gnuplot is not using bitmap graphics, but 
vector graphics (think of a pixel as being a rectangle...or 
parallelogram if rotated in space).  But why so long?  There is an 
example in image.dem that I think falls back to vector-based.  Also 
'image2.dem' has several of those.  Anything where the image is 
projected non-parallel to the viewing plane will fall back to drawing 
polygons for pixels.


>> Could your computer be running low on memory causing your system to use disk swap?
>
> No, my Mac has enough free memory while running the demos.
> It seems gnuplot uses about 0.5GB of memory for nonlinear3.dem.

Right.  That isn't the issue.

I'm still surprised that this takes so long.  If none of the demos in 
'image.dem' and 'image2.dem' are glacial-pace slow, then I wonder if 
something is happening in which the nonlinearity creates a rectangular 
with peculiar coordinates that causes an algorithm aqua is using to veer 
off course.

What happens if you temporarily make this change in probably_tux.dem:

#f(x) = norm((x-center)/sigma)
#g(x) = sigma*invnorm(x)+center
f(x) = x
g(x) = x

Dan

Re: nonlinear3.dem is very slow on aqua terminal

[Jun T. <tak...@kb...>]

2016/07/16 15:20, Daniel J Sebald <dan...@ie...> wrote:

> Does the 'image.dem' example take so long as well?,

No, it works normally.

I think use of the 'pixels' keyword in probably_tux.dem is causing
the slowness. If I remove the 'pixels' from the last line of
probably_tux.dem then nonlinear3.dem ends quickly, but the nonlinear
axis scaling does not work anymore.

> Could your computer be running low on memory causing your system to use disk swap?

No, my Mac has enough free memory while running the demos.
It seems gnuplot uses about 0.5GB of memory for nonlinear3.dem.

Re: nonlinear3.dem is very slow on aqua terminal

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

On 07/16/2016 01:05 AM, Jun T. wrote:
> With terminal aqua, nonlinear3.dem takes *very* long time.
> It took about 8 minutes on my Mac.
>
> This is a problem of Aquaterm.app (or its API); it is designed
> for vector graphics (and works very well for vector graphics),
> but can't handle bitmap graphics properly (slow, and uses
> lots of memory).

Does the 'image.dem' example take so long as well?

Could your computer be running low on memory causing your system to use 
disk swap?

Dan

nonlinear3.dem is very slow on aqua terminal

[Jun T. <tak...@kb...>]

With terminal aqua, nonlinear3.dem takes *very* long time.
It took about 8 minutes on my Mac.

This is a problem of Aquaterm.app (or its API); it is designed
for vector graphics (and works very well for vector graphics),
but can't handle bitmap graphics properly (slow, and uses
lots of memory).

Since most Mac users would think gnuplot has gone into an
infinite loop and try to kill gnuplot (or Aquaterm) before
the demo finishes, I think it would better to skip this
demo in all.dem, as in the attached patch.

No vertical grid lines parallel with z-axis

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

I'm just curious why there are no vertical grid lines for splot.  For 
example,

set grid xtics noytics ztics
splot sin(sqrt(x**2+y**2))/sqrt(x**2+y**2)

shows no vertical grid lines aligned with the x-axis on the back right 
vertical plane.

Dan

gnuplot 5.0.4 release candidates for windows are uploaded

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

Hello

The source of release candidate of gnuplot-5.0.4 on the sourceforge site.
I have built testing windows binaries and uploaded to the below:

https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/

Feedbacks are welcome!

Happy gnuplotting.

Tatsuro

Re: Planned release of gnuplot version 5.0 Patchlevel 4

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

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

> From: Tatsuro MATSUOKA 
> To: tmacchant3 Merritt Ethan ; gnuplot-beta; bmaerkisch
> Cc: 
> Date: 2016/7/15, Fri 18:31
> Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA <tma...@ya...>
>>  To: tma...@ya...; Merritt Ethan 
> <sf...@us...>; gnu...@li...; 
> bma...@we...
>>  Cc: 
>>  Date: 2016/7/15, Fri 18:23
>>  Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
>> 
>>  ----- Original Message -----
>> 
>>>   From: Tatsuro MATSUOKA <tma...@ya...>
>>>   To: tma...@ya...; Merritt Ethan 
>>  <sf...@us...>; gnu...@li...; 
>>  bma...@we...
>>>   Cc: 
>>>   Date: 2016/7/15, Fri 18:10
>>>   Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
>>> 
>>>   ----- Original Message -----
>>> 
>>>>    From: Tatsuro MATSUOKA 
>>>>    To: Merritt Ethan ; gnuplot-beta bmaerkisch> Cc: 
>>>>    Date: 2016/7/15, Fri 17:20
>>>>    Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
>>>> 
>>>> 
>>>>    I have tried to build gnuplot 5.0.4 on MinGW64 64 bit on windows.
>>>> 
>>>>    Build itself is fine.
>>>> 
>>>>    I have noticed that I could not specify install directory by 
> installer 
>> 
>>>   install.
>>>>    This is also true on cvs version that I have not been noticed.
>>>> 
>>>>    Bastian
>>>> 
>>>>    Have you ever seen such fault?
>>>> 
>>>   Seem to be an issue inno setup unicode version.
>>>   I have uninstalled unicode version and install regular version 
>>>   and transfer codinf utf-8 with BOM to Sjis and built installer again.
>>> 
>>>   Selection of install directory screen appeared this time.
>>> 
>>>   Hmmm
>>> 
>>>   Tatsuro
>> 
>>  It seems that modpath.iss is ignored in unicode version.
>> 
>>  Tatsuro
> 
> Sorry repeated post.
> The origin is not related unicode.
> Perhaps version change of Inno Setup causes a problem.
> 
> Tatsuro

Version down of Inno Setup from 5.5.9 (latest) to 5.4.3 solve the issue.
However, it is better to modify the setting to work on the latest version.

I at the moment understand what is wrong at latest version.

Tatsuro  

Re: Planned release of gnuplot version 5.0 Patchlevel 4

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

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

> From: Tatsuro MATSUOKA <tma...@ya...>
> To: tma...@ya...; Merritt Ethan <sf...@us...>; gnu...@li...; bma...@we...
> Cc: 
> Date: 2016/7/15, Fri 18:23
> Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA <tma...@ya...>
>>  To: tma...@ya...; Merritt Ethan 
> <sf...@us...>; gnu...@li...; 
> bma...@we...
>>  Cc: 
>>  Date: 2016/7/15, Fri 18:10
>>  Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
>> 
>>  ----- Original Message -----
>> 
>>>   From: Tatsuro MATSUOKA 
>>>   To: Merritt Ethan ; gnuplot-beta bmaerkisch> Cc: 
>>>   Date: 2016/7/15, Fri 17:20
>>>   Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
>>> 
>>> 
>>>   I have tried to build gnuplot 5.0.4 on MinGW64 64 bit on windows.
>>> 
>>>   Build itself is fine.
>>> 
>>>   I have noticed that I could not specify install directory by installer 
> 
>>  install.
>>>   This is also true on cvs version that I have not been noticed.
>>> 
>>>   Bastian
>>> 
>>>   Have you ever seen such fault?
>>> 
>>  Seem to be an issue inno setup unicode version.
>>  I have uninstalled unicode version and install regular version 
>>  and transfer codinf utf-8 with BOM to Sjis and built installer again.
>> 
>>  Selection of install directory screen appeared this time.
>> 
>>  Hmmm
>> 
>>  Tatsuro
> 
> It seems that modpath.iss is ignored in unicode version.
> 
> Tatsuro

Sorry repeated post.
The origin is not related unicode.
Perhaps version change of Inno Setup causes a problem.

Tatsuro

Re: Planned release of gnuplot version 5.0 Patchlevel 4

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

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

> From: Tatsuro MATSUOKA <tma...@ya...>
> To: tma...@ya...; Merritt Ethan <sf...@us...>; gnu...@li...; bma...@we...
> Cc: 
> Date: 2016/7/15, Fri 18:23
> Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA <tma...@ya...>
>>  To: tma...@ya...; Merritt Ethan 
> <sf...@us...>; gnu...@li...; 
> bma...@we...
>>  Cc: 
>>  Date: 2016/7/15, Fri 18:10
>>  Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
>> 
>>  ----- Original Message -----
>> 
>>>   From: Tatsuro MATSUOKA 
>>>   To: Merritt Ethan ; gnuplot-beta bmaerkisch> Cc: 
>>>   Date: 2016/7/15, Fri 17:20
>>>   Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
>>> 
>>> 
>>>   I have tried to build gnuplot 5.0.4 on MinGW64 64 bit on windows.
>>> 
>>>   Build itself is fine.
>>> 
>>>   I have noticed that I could not specify install directory by installer 
> 
>>  install.
>>>   This is also true on cvs version that I have not been noticed.
>>> 
>>>   Bastian
>>> 
>>>   Have you ever seen such fault?
>>> 
>>  Seem to be an issue inno setup unicode version.
>>  I have uninstalled unicode version and install regular version 
>>  and transfer codinf utf-8 with BOM to Sjis and built installer again.
>> 
>>  Selection of install directory screen appeared this time.
>> 
>>  Hmmm
>> 
>>  Tatsuro
> 
> It seems that modpath.iss is ignored in unicode version.
> 
> Tatsuro
> 

Re: Planned release of gnuplot version 5.0 Patchlevel 4

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

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

> From: Tatsuro MATSUOKA <tma...@ya...>
> To: tma...@ya...; Merritt Ethan <sf...@us...>; gnu...@li...; bma...@we...
> Cc: 
> Date: 2016/7/15, Fri 18:10
> Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA 
>>  To: Merritt Ethan ; gnuplot-beta bmaerkisch> Cc: 
>>  Date: 2016/7/15, Fri 17:20
>>  Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
>> 
>> 
>>  I have tried to build gnuplot 5.0.4 on MinGW64 64 bit on windows.
>> 
>>  Build itself is fine.
>> 
>>  I have noticed that I could not specify install directory by installer 
> install.
>>  This is also true on cvs version that I have not been noticed.
>> 
>>  Bastian
>> 
>>  Have you ever seen such fault?
>> 
> Seem to be an issue inno setup unicode version.
> I have uninstalled unicode version and install regular version 
> and transfer codinf utf-8 with BOM to Sjis and built installer again.
> 
> Selection of install directory screen appeared this time.
> 
> Hmmm
> 
> Tatsuro

It seems that modpath.iss is ignored in unicode version.

Tatsuro

Re: Planned release of gnuplot version 5.0 Patchlevel 4

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

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

> From: Tatsuro MATSUOKA 
> To: Merritt Ethan ; gnuplot-beta bmaerkisch> Cc: 
> Date: 2016/7/15, Fri 17:20
> Subject: Re: Planned release of gnuplot version 5.0 Patchlevel 4
> 
> 
> I have tried to build gnuplot 5.0.4 on MinGW64 64 bit on windows.
> 
> Build itself is fine.
> 
> I have noticed that I could not specify install directory by installer install.
> This is also true on cvs version that I have not been noticed.
> 
> Bastian
> 
> Have you ever seen such fault?
> 
Seem to be an issue inno setup unicode version.
I have uninstalled unicode version and install regular version 
and transfer codinf utf-8 with BOM to Sjis and built installer again.

Selection of install directory screen appeared this time.

Hmmm

Tatsuro

Re: Planned release of gnuplot version 5.0 Patchlevel 4

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

> From: Ethan A Merritt 

> To: gnuplot-beta
> Cc: 
> Date: 2016/7/13, Wed 08:02
> Subject: Planned release of gnuplot version 5.0 Patchlevel 4
> 
> I plan to prepare a 5.0.4 release package later this week.
> Is anyone aware of unresolved problems or bugs that should
> be fixed before release?
> 
> Short list of fixes/changes that will appear in 5.0.4
> ===============================================================================
> * CHANGE minimum linewidth of all cairo terminals is now 0.2 pt
> * CHANGE in-line datablock lines are not limited to 1024 characters
> * CHANGE do not truncate or renumber history items in the active session
> * CHANGE (Windows only) open piped output using mode "wb" rather than 
> "w"
> * CHANGE backport 5.1 use of "lc variable" to color boxplot factors
> * CHANGE gnuplot_svg.js now remaps coords for svg image embedded in larger 
> object
> * CHANGE disallow "set palette maxcolors 1" (which has never worked)
> * CHANGE data-input errors in "stats" now generate a warning rather 
> than an error
> * FIX placement of objects and labels using linked secondary axis coordinates
> * FIX 'set term qt <N> close' acts immediately rather than after 
> next mouse event
> * FIX emf terminal could lose track of bold/italic/etc font properties
> * FIX emf terminal text placement of UTF-8 strings
> * FIX regression that caused "set log x; plot '-'; replot" to 
> mess up autoscaling
> * FIX regression in v5 that mangled 3D arrows defined by "from ... rto 
> ..."
> * FIX transposition of row/column count in plotting ascii x/y/z data "with 
> image"
> * FIX 7-column input to "splot ... with vectors"
> * FIX ignore incomplete "every" spec for image plots
> * FIX placement of xyplane does not depend on having tics or grid lines enabled
> * FIX early program exit on replot+resize with inline data
> * FIX bad plot iteration with negative increment, e.g. plot for [i=9:1:-1] 
> foo(i)
> * FIX smoothed curves could not be plotted as filledcurves; now they can be
> ===============================================================================
> 
> No new features.
> 
>     Ethan

I have tried to build gnuplot 5.0.4 on MinGW64 64 bit on windows.

Build itself is fine.

I have noticed that I could not specify install directory by installer install.
This is also true on cvs version that I have not been noticed.

Bastian

Have you ever seen such fault?

Tatsuro

Tatsuro

Re: Planned release of gnuplot version 5.0 Patchlevel 4

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

On Wednesday, 13 July 2016 12:18:38 PM Daniel J Sebald wrote:
> On 07/12/2016 06:02 PM, Ethan A Merritt wrote:
> > I plan to prepare a 5.0.4 release package later this week.
> > Is anyone aware of unresolved problems or bugs that should
> > be fixed before release?

> Yes.  Something has come up with a Windows-only bug interpreting 
> formating characters like "a_b" that would be nice to investigate before 
> another release.

I have uploaded a pre-release copy of gnuplot-5.0.4.tar.gz 
to the "Release Candidates" area on Sourceforge.

https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0 release candidates/


It contains Bastian's fix for the bug you mention above. 


	Ethan

Re: Planned release of gnuplot version 5.0 Patchlevel 4

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

Yes.  Something has come up with a Windows-only bug interpreting 
formating characters like "a_b" that would be nice to investigate before 
another release.  I don't have a means of testing or creating a patch 
for Windows.  Sourceforge has been offline so I'm unable to post a bug.

Dan


On 07/12/2016 06:02 PM, Ethan A Merritt wrote:
> I plan to prepare a 5.0.4 release package later this week.
> Is anyone aware of unresolved problems or bugs that should
> be fixed before release?
>
> Short list of fixes/changes that will appear in 5.0.4
> ===============================================================================
> * CHANGE minimum linewidth of all cairo terminals is now 0.2 pt
> * CHANGE in-line datablock lines are not limited to 1024 characters
> * CHANGE do not truncate or renumber history items in the active session
> * CHANGE (Windows only) open piped output using mode "wb" rather than "w"
> * CHANGE backport 5.1 use of "lc variable" to color boxplot factors
> * CHANGE gnuplot_svg.js now remaps coords for svg image embedded in larger object
> * CHANGE disallow "set palette maxcolors 1" (which has never worked)
> * CHANGE data-input errors in "stats" now generate a warning rather than an error
> * FIX placement of objects and labels using linked secondary axis coordinates
> * FIX 'set term qt <N> close' acts immediately rather than after next mouse event
> * FIX emf terminal could lose track of bold/italic/etc font properties
> * FIX emf terminal text placement of UTF-8 strings
> * FIX regression that caused "set log x; plot '-'; replot" to mess up autoscaling
> * FIX regression in v5 that mangled 3D arrows defined by "from ... rto ..."
> * FIX transposition of row/column count in plotting ascii x/y/z data "with image"
> * FIX 7-column input to "splot ... with vectors"
> * FIX ignore incomplete "every" spec for image plots
> * FIX placement of xyplane does not depend on having tics or grid lines enabled
> * FIX early program exit on replot+resize with inline data
> * FIX bad plot iteration with negative increment, e.g. plot for [i=9:1:-1] foo(i)
> * FIX smoothed curves could not be plotted as filledcurves; now they can be
> ===============================================================================
>
> No new features.
>
> 	Ethan
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: Expecting support for multiple keys

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

On Wednesday, 13 July, 2016 18:49:41 Liu Guibin wrote:
> I still expect the support for multiple keys.
> 
> Using labels is too complicated and inconvenient.
> Label is only suitable for adding text, but incapable of adding lines, 
> points, linepoints, histograms, etc.
> For example, I don't know how to use label to mimic the key in the 
> following plot statement:
> 
> plot  'data1'  t 'test1'  w p pt 7 ps 2, \
>          'data2'  t 'test2'  w l  lw 2 lt 3,\
>          'data3'  t 'test3'  w lp  lt 1 lw 2 pt 6 ps 2,\
>          'data4'  t 'test4'  w histograms
> 
> 
> 在 2015-12-11 7:43, Tait 写道:
> >> <1>.  Multiple keys
> >> ...
> >> set key 1 top right
> >> set key 2 bottom left
> >> plot 'data' key 1, '' key 1, '' key 2, '' key 2
> >>
> >> Thus, if I have many legends and there's no space to put them together,
> >> I can divide them into two groups
> >> "key 1" and "key 2" and put them at different places.
> > Don't labels (as in, "help set label") offer a more flexible and
> > comprehensive solution to this problem?

Current cvs (version 5.1) supports individual placement of 
key items.

Demo is here:
	http://gnuplot.sourceforge.net/demo_cvs/custom_key.html

Help text is here:

gnuplot> help plot title

 By default each plot is listed in the key by the corresponding function or file
 name. You can give an explicit plot title instead using the `title` option.

 Syntax:
       title <text> | notitle [<ignored text>]
       title columnheader | title columnheader(N)
             {at {beginning|end}} {{no}enhanced}

 [...]

 The `at` keyword allows you to place the plot title somewhere outside the
 auto-generated key box. The title can be placed immediately before or after the
 line in the graph itself by using `at {beginning|end}`.  This option may be
 useful when plotting `with lines` but makes little sense for most other styles.

 To place the plot title at an arbitrary location on the page, use the form
 `at <x-position>,<y-position>`.  By default the position is interpreted in
 screen coordinates; e.g. `at 0.5, 0.5` is always the middle of the screen 
 regardless of plot axis scales or borders.  The format of titles placed in
 this way is still affected by key options.  See `set key`.

   Ethan

Re: Expecting support for multiple keys

[Liu G. <goo...@gm...>]

I still expect the support for multiple keys.

Using labels is too complicated and inconvenient.
Label is only suitable for adding text, but incapable of adding lines, 
points, linepoints, histograms, etc.
For example, I don't know how to use label to mimic the key in the 
following plot statement:

plot  'data1'  t 'test1'  w p pt 7 ps 2, \
         'data2'  t 'test2'  w l  lw 2 lt 3,\
         'data3'  t 'test3'  w lp  lt 1 lw 2 pt 6 ps 2,\
         'data4'  t 'test4'  w histograms


在 2015-12-11 7:43, Tait 写道:
>> <1>.  Multiple keys
>> ...
>> set key 1 top right
>> set key 2 bottom left
>> plot 'data' key 1, '' key 1, '' key 2, '' key 2
>>
>> Thus, if I have many legends and there's no space to put them together,
>> I can divide them into two groups
>> "key 1" and "key 2" and put them at different places.
> Don't labels (as in, "help set label") offer a more flexible and
> comprehensive solution to this problem?
>

History numbering is now off-by-one due to some recent change

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

In current cvs (5.1) the numbering shown by the "history" command
is off by one, in the sense that trying to retrieve a command by number
results in execution of the command immediately prior to the one equested.

I think this is because of a change to history.c (write_history_list) on 20 June.
The corresponding entry in ChangeLog seems to be

2016-06-20  Bastian Maerkisch  <bma...@we...>
        * src/readline.c (write_history_list):  Avoid adding extra leading
        spaces when saving to a file.  Index of history_get is zero-based
        relative to history_base.

although it does not mention a change to history.c.

Can someone (Bastian?) clarify whether that change was a fix for
a real problem?  If not I think it should be reverted.

On the other hand if it did fix something then a corresponding 
change needs to be made in command.c (history_command)
so that the command
   history !<lineno>
retrieves <lineno + 1> instead.

Or something like that.  

Sourceforge is currently down so I can't confirm the change history
or possible reversion.


	Ethan

Planned release of gnuplot version 5.0 Patchlevel 4

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

I plan to prepare a 5.0.4 release package later this week.
Is anyone aware of unresolved problems or bugs that should
be fixed before release?

Short list of fixes/changes that will appear in 5.0.4
===============================================================================
* CHANGE minimum linewidth of all cairo terminals is now 0.2 pt
* CHANGE in-line datablock lines are not limited to 1024 characters
* CHANGE do not truncate or renumber history items in the active session
* CHANGE (Windows only) open piped output using mode "wb" rather than "w"
* CHANGE backport 5.1 use of "lc variable" to color boxplot factors
* CHANGE gnuplot_svg.js now remaps coords for svg image embedded in larger object
* CHANGE disallow "set palette maxcolors 1" (which has never worked)
* CHANGE data-input errors in "stats" now generate a warning rather than an error
* FIX placement of objects and labels using linked secondary axis coordinates
* FIX 'set term qt <N> close' acts immediately rather than after next mouse event
* FIX emf terminal could lose track of bold/italic/etc font properties
* FIX emf terminal text placement of UTF-8 strings
* FIX regression that caused "set log x; plot '-'; replot" to mess up autoscaling
* FIX regression in v5 that mangled 3D arrows defined by "from ... rto ..."
* FIX transposition of row/column count in plotting ascii x/y/z data "with image"
* FIX 7-column input to "splot ... with vectors"
* FIX ignore incomplete "every" spec for image plots
* FIX placement of xyplane does not depend on having tics or grid lines enabled
* FIX early program exit on replot+resize with inline data
* FIX bad plot iteration with negative increment, e.g. plot for [i=9:1:-1] foo(i)
* FIX smoothed curves could not be plotted as filledcurves; now they can be
===============================================================================

No new features.

	Ethan

Re: Key documentation consistency

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

On 07/08/2016 11:08 PM, Daniel J Sebald wrote:
> On 07/08/2016 04:23 PM, Ethan A Merritt wrote:
>> On Friday, 08 July, 2016 15:17:25 Daniel J Sebald wrote:
>>> The documentation for key indicates:
>>>
>>>     The defaults for `set key` are `on`, `right`, `top`, `vertical`, `Right`,
>>>     `noreverse`, `noinvert`, `samplen 4`, `spacing 1.25`, `title ""`, and
>>>     `nobox`.  The default <linetype> is the same as that used for the plot
>>>     borders.  Entering `set key default` returns the key to its default
>>>     configuration.
>>>
>>> and when I do the following:
>>>
>>> gnuplot> plot x, -x
>>> gnuplot> show key
>>>
>>> 	key is ON, position: top right vertical inside
>>> 	key is right justified, not reversed, not inverted, enhanced and not boxed
>>> 	sample length is 4 characters
>>> 	vertical spacing is 1 characters
>>> 	width adjustment is 0 characters
>>> 	height adjustment is 0 characters
>>> 	curves are automatically titled with filename
>>> 	maximum number of columns is calculated automatically
>>> 	maximum number of rows is calculated automatically
>>>
>>> 	key title is ""
>>>
>>> The vertical spacing says 1 character, not 1.25.  Mistake?  Change in
>>> code without change in documentation?
>>
>> The default vertical spacing is 1 * (1.25 characters)
>
> That's 1.25 characters.  The printout from show key indicates 1
> characters.  The lack of consistency is
>
> default                 value in character units
> -------                 ------------------------
> `samplen 4`    => 'sample length is 4 characters'
> `spacing 1.25` => 'vertical spacing is 1 characters'
>
> If the printout indicated 'vertical space is 1', i.e., unitless, then it
> could be a scale factor.  But then it would make sense that samplen
> should be a scale factor as well.

Something else that comes to mind looking at the key is that it would be 
nice if there were a more object-oriented approach to its design.  That 
is, one can look at the key as a being a subplot, but with more keywords 
to aid its layout.  That is, if one viewed a key as a plot, all of the 
methods for laying out a plot would apply, e.g., the line type control, 
the fill/patch control, the sizing control, etc.

Right now it looks like only character sizes can be used to control a 
sample length, e.g., "set key samplen 5" where 5 refers to characters. 
I assume that means character widths.  Does character width units change 
with a change in font?  How about if someone specified the size of the 
key and then wanted to use relative units?  For example, "set key 
samplen graph 0.3" might do.  The point is to try and use existing code, 
which also aids the user's understanding of how things work.

Dan