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

Re: Regression when using gnuplot and loops?

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

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

> From: Philipp K. Janert 
> To: gnuplot-beta
> Cc: 
> Date: 2017/3/7, Tue 01:02
> Subject: Re: Regression when using gnuplot and loops?
> 
> 
> [snip]
> 
>>  >  
>> 
>>  I made further test on qt and wxt terminal on gnuplot 5.0.5 windows
>>  and lubunutu 16.04.
>> 
>>  bind d "end=1"
>>  i=1; end=0; while (end==0) {plot i*x title "".i; i=i+1; pause 
> 0.1}
>> 
>>  press "d" on plot window of qt terminal can stop the loop for me.
>> 
>>  But above  loop is too simple so that it may not give a clue for this
>>  issue.
> 
> I think it depends rather critically on the length
> of the pause and the complexity of the plot. 
> 
> Apparently, qt is slower than wxt - timing that 
> worked for wxt did not work at all for qt.
> 

Perhaps it depends on environments.
On my lubunutu 16.04, concerning speed for all.dem at "make check", 
qt is faster than wxt.

(On windows, for all.dem execution, qt is rather faster than wxt. )

Back to the original issue, 

Gdk:ERROR:/build/gtk+2.0-KsZKkB/gtk+2.0-2.24.30/gdk/gdkregion-generic.c:337:miSetExtents:
assertion failed: (pExtents->y1 < pExtents->y2)

is not gnuplot specific after google search.

As you wrote in the first post

> They may be due to some form of library version skew 
> (I updated myLinux install in the meantime).  

Perhaps this is an issue of some form of library version skew.
There seems to be difficulty in libraries of GTK+2, wxGTK and gnuplot.

If you have a chance to build gnuplot by yourself,
--with-wx-single-threaded 
at configure sometimes changes the situation.
(However, it may reduce the speed.)

Tatsuro

Re: Regression when using gnuplot and loops?

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

[snip]

> >   
> 
> I made further test on qt and wxt terminal on gnuplot 5.0.5 windows
> and lubunutu 16.04.
> 
> bind d "end=1"
> i=1; end=0; while (end==0) {plot i*x title "".i; i=i+1; pause 0.1}
> 
> press "d" on plot window of qt terminal can stop the loop for me.
> 
> But above  loop is too simple so that it may not give a clue for this
> issue.

I think it depends rather critically on the length
of the pause and the complexity of the plot. 

Apparently, qt is slower than wxt - timing that 
worked for wxt did not work at all for qt.

Re: Regression when using gnuplot and loops?

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

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

> From: Philipp K. Janert 
> To: gnuplot-beta> Cc: 
> Date: 2017/3/6, Mon 15:09
> Subject: Re: Regression when using gnuplot and loops?
> 
> 
> [snip]
> 
>> 
>>  Gnuplot process and gnuplot_qt process communicates each other.
>>  Bind command code is implemented source code for qt terminal
>>  so it should work.
>> 
>>  I execute a simple test on gnuplot-5.0.5 on windows and lubuntu 16.04
>>  (built myself).
>> 
>>  gnuplot> bind d 'plot x*x'
>>  gnuplot> set term qt
>>  gnuplot> bind d  
>>   d              `plot x*x`
>>  gnuplot> plot x  
>> 
>>  On qt plot windows, press d key => plot x*x
>>  executed.
>> 
>>  Bind command works for me on qt at least in the above simple example.
> 
> Yes, you are right. This works for me.
> Thanks a lot.
> 

I made further test on qt and wxt terminal on gnuplot 5.0.5 windows and lubunutu 16.04.

bind d "end=1"
i=1; end=0; while (end==0) {plot i*x title "".i; i=i+1; pause 0.1}

press "d" on plot window of qt terminal can stop the loop for me.

But above  loop is too simple so that it may not give a clue for this issue.

Tatsuro

Re: Regression when using gnuplot and loops?

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

[snip]

> 
> Gnuplot process and gnuplot_qt process communicates each other.
> Bind command code is implemented source code for qt terminal
> so it should work.
> 
> I execute a simple test on gnuplot-5.0.5 on windows and lubuntu 16.04
> (built myself).
> 
> gnuplot> bind d 'plot x*x'
> gnuplot> set term qt
> gnuplot> bind d  
>  d              `plot x*x`
> gnuplot> plot x  
> 
> On qt plot windows, press d key => plot x*x
> executed.
> 
> Bind command works for me on qt at least in the above simple example.

Yes, you are right. This works for me.
Thanks a lot.

> 
> Tatsuro

Re: Regression when using gnuplot and loops?

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

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

> From: Philipp K. Janert
> To: gnuplot-beta
> Cc: 
> Date: 2017/3/6, Mon 14:10
> Subject: Re: Regression when using gnuplot and loops?
> 
> 
[snip]
>>  BTW, just from curiosity, how do you get Compile options?
> 
> show version long

Thanks a lot!

Tatsuro

Re: Regression when using gnuplot and loops?

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

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

> From: Philipp K. Janert 
> To: gnuplot-beta> Cc: 
> Date: 2017/3/6, Mon 14:10
> Subject: Re: Regression when using gnuplot and loops?
> 
> 
> [snip]
> 
>> 
>>  Is the below related for you ?
>>  https://sourceforge.net/p/gnuplot/bugs/1592/
>> 
> 
> Yes, I seem to have a problem similar to the
> bug report in the link. 
> 
> I am on Linux Mint 18 (debian/Ubuntu based), and
> I am using the gnuplot version that shipped with
> the distro.
> 
>> 
>>  BTW, just from curiosity, how do you get Compile options?
> 
> show version long
> 
> This leaves the behavior of the "bind" command when 
> using qt. I saw that the qt terminal does run in a 
> separate process - does this mean that I should not
> expect "bind" to work, because there is no good way
> to send a msg back to the gnuplot proc from the qt
> terminal?

> I saw that the qt terminal does run in a 
> separate process - does this mean that I should not
> expect "bind" to work, because there is no good way
> to send a msg back to the gnuplot proc from the qt
> terminal?

Gnuplot process and gnuplot_qt process communicates each other.
Bind command code is implemented source code for qt terminal
so it should work.

I execute a simple test on gnuplot-5.0.5 on windows and lubuntu 16.04 (built myself).

gnuplot> bind d 'plot x*x'
gnuplot> set term qt
gnuplot> bind d
 d              `plot x*x`
gnuplot> plot x

On qt plot windows, press d key => plot x*x
executed.

Bind command works for me on qt at least in the above simple example.

Tatsuro

Re: Regression when using gnuplot and loops?

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

[snip]

> 
> Is the below related for you ?
> https://sourceforge.net/p/gnuplot/bugs/1592/
> 

Yes, I seem to have a problem similar to the
bug report in the link. 

I am on Linux Mint 18 (debian/Ubuntu based), and
I am using the gnuplot version that shipped with
the distro.

> 
> BTW, just from curiosity, how do you get Compile options?

show version long

This leaves the behavior of the "bind" command when 
using qt. I saw that the qt terminal does run in a 
separate process - does this mean that I should not
expect "bind" to work, because there is no good way
to send a msg back to the gnuplot proc from the qt
terminal?

Re: Regression when using gnuplot and loops?

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

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

> From: Philipp K. Janert 
> To: gnuplot-beta
> Cc: 
> Date: 2017/3/6, Mon 06:18
> Subject: Regression when using gnuplot and loops?
> 
> 
> I am encountering problems when running gnuplot in
> a loop (to update the graph based on changing data,
> "poor man's animation").
> 
> When using the wxt terminal, I intermittently run 
> into a failed assertion:
> 
> Gdk:ERROR:/build/gtk+2.0-KsZKkB/gtk+2.0-2.24.30/gdk/gdkregion-generic.c:337:miSetExtents:
> assertion failed: (pExtents->y1 < pExtents->y2)
> 
> When using the qt terminal, I can't stop the loop,
> because the "bind" command does not seem to work.
> 
> These problems seem new to me. They may be due to
> some form of library version skew (I updated my
> Linux install in the meantime). 
> 
> The essential commands are:
> 
> end=0
> while( end==0 ) {
>     splot "file" i 1 matrix w p lc pal
>     pause 0.1
> }
> 
> Version info:
> 
>         G N U P L O T
>         Version 5.0 patchlevel 3    last modified 2016-02-21 
> 
>         Copyright (C) 1986-1993, 1998, 2004, 2007-2016
>         Thomas Williams, Colin Kelley and many others
> 
>         gnuplot home:    http://www.gnuplot.info
>         faq, bugs, etc:   type "help FAQ"
>         immediate help:   type "help"  (plot window: hit 'h')
> Compile options:
> -READLINE  +LIBEDITLINE  +HISTORY  
> -BACKWARDS_COMPATIBILITY  +BINARY_DATA  
> +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
> -USE_CWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE
>         +HIDDEN3D_QUADTREE +DATASTRINGS  +HISTOGRAMS  +OBJECTS
>         +STRINGVARS  +MACROS  +THIN_SPLINES  +IMAGE  +USER_LINETYPES
>         +STATS +EXTERNAL_FUNCTIONS MAX_PARALLEL_AXES=7
> 
> GNUPLOT_DRIVER_DIR = "/usr/lib/gnuplot5"
> GNUPLOT_PS_DIR     = "/usr/share/gnuplot5/gnuplot/5.0/PostScript"
> HELPFILE           = "/usr/share/gnuplot5/gnuplot.gih"

Is the below related for you ?
https://sourceforge.net/p/gnuplot/bugs/1592/

Or do you use "regression" related something like this?
 

BTW, just from curiosity, how do you get Compile options?

Tatsuro  

More info (was: Regression when using gnuplot and loops?)

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

I have also encountered the following stacktrace
(w/o apparent user interaction):


*** Error in `gnuplot': double free or corruption (out):
0x0000000002a7e4d0 *** ======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f7de4cd4725]
/lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f7de4cdcf4a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f7de4ce0abc]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(gdk_region_destroy+0x1b)[0x7f7de2b24adb]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5cfc8)[0x7f7de2b4efc8]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5d10a)[0x7f7de2b4f10a]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5d39c)[0x7f7de2b4f39c]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x3e6df)[0x7f7de2b306df]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(gdk_window_process_all_updates+0x118)[0x7f7de2b30fa8]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x3f009)[0x7f7de2b31009]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x1dd57)[0x7f7de2b0fd57]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x15a)[0x7f7de6d9e05a]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4a400)[0x7f7de6d9e400]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xc2)[0x7f7de6d9e722]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xb7)[0x7f7de2ed76a7]
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0(_ZN14wxGUIEventLoop5DoRunEv+0x25)[0x7f7de7e09ed5]
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN15wxEventLoopBase3RunEv+0xa3)[0x7f7de77b3343]
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN16wxAppConsoleBase8MainLoopEv+0x56)[0x7f7de7778666]
gnuplot[0x50ef2f]
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(_ZN8wxThread9CallEntryEv+0xa2)[0x7f7de78c54a2]
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0(+0x1bae93)[0x7f7de78cbe93]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7f7de502d6fa]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f7de4d63b5d]
======= Memory map: ========
00400000-0058b000 r-xp 00000000 08:01
1455844                            /usr/bin/gnuplot5-qt
0078a000-0078f000 r--p 0018a000 08:01
1455844                            /usr/bin/gnuplot5-qt
0078f000-0079f000 rw-p 0018f000 08:01
1455844                            /usr/bin/gnuplot5-qt
0079f000-007b0000 rw-p 00000000 00:00 0 017cf000-02dcb000 rw-p 00000000
00:00 0                                  [heap]
7f7dd0000000-7f7dd0210000 rw-p 00000000 00:00 0
7f7dd0210000-7f7dd4000000 ---p 00000000 00:00 0
7f7dd76ec000-7f7dd774c000 rw-s 00000000 00:05
43581466                   /SYSV00000000 (deleted)
7f7dd774c000-7f7dd774f000 rw-s 00000000 00:05
43483161                   /SYSV00000000 (deleted)
7f7dd774f000-7f7dd776b000 r--p 00000000 08:01
3057718                    /usr/share/icons/gnome/icon-theme.cache
7f7dd776b000-7f7dd7773000 r--p 00000000 08:01
3057720                    /usr/share/icons/hicolor/icon-theme.cache
7f7dd7773000-7f7dd782c000 r--p 00000000 08:01
2624884                    /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
7f7dd782c000-7f7dd7833000 r--s 00000000 08:01
6177870                    /var/cache/fontconfig/4be9850f182b35c1350b6bbf2e42601c-le64.cache-6
7f7dd7833000-7f7dd7835000 r--s 00000000 08:01
6177869                    /var/cache/fontconfig/30a99c4256905863f7aa12b5e873c27c-le64.cache-6
7f7dd7835000-7f7dd7836000 r--s 00000000 08:01
6175392                    /var/cache/fontconfig/087e1975ba9a574b140bb1df193bf770-le64.cache-6
7f7dd7836000-7f7dd783a000 r--s 00000000 08:01
6177868                    /var/cache/fontconfig/6aa41aa22e18b8fa06a12da28ea9c28b-le64.cache-6
7f7dd783a000-7f7dd7845000 r--s 00000000 08:01
6160490                    /var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-le64.cache-6
7f7dd7845000-7f7dd7847000 r--s 00000000 08:01
6160492                    /var/cache/fontconfig/99e8ed0e538f840c565b6ed5dad60d56-le64.cache-6
7f7dd7847000-7f7dd784c000 r--s 00000000 08:01
6174294                    /var/cache/fontconfig/0fafd173547752dce4dee1a69e0b3c95-le64.cache-6
7f7dd784c000-7f7dd7852000 r--s 00000000 08:01
6160462                    /var/cache/fontconfig/2cd17615ca594fa2959ae173292e504c-le64.cache-6
7f7dd7852000-7f7dd7853000 r--s 00000000 08:01
6160455                    /var/cache/fontconfig/0d8c3b2ac0904cb8a57a757ad11a4a08-le64.cache-6
7f7dd7853000-7f7dd7857000 r--s 00000000 08:01
6868555                    /var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-le64.cache-6
7f7dd7857000-7f7dd785b000 r--s 00000000 08:01
6178045                    /var/cache/fontconfig/de156ccd2eddbdc19d37a45b8b2aac9c-le64.cache-6
7f7dd785b000-7f7dd7870000 r--s 00000000 08:01
6160452                    /var/cache/fontconfig/04aabc0a78ac019cf9454389977116d2-le64.cache-6
7f7dd7870000-7f7dd7871000 r--s 00000000 08:01
6160459                    /var/cache/fontconfig/1ac9eb803944fde146138c791f5cc56a-le64.cache-6
7f7dd7871000-7f7dd7872000 r--s 00000000 08:01
6177867                    /var/cache/fontconfig/b95bc8ffbebda2bbdae4265e45b8178d-le64.cache-6
7f7dd7872000-7f7dd7876000 r--s 00000000 08:01
6160466                    /var/cache/fontconfig/385c0604a188198f04d133e54aba7fe7-le64.cache-6
7f7dd7876000-7f7dd7877000 r--s 00000000 08:01
6177866                    /var/cache/fontconfig/9c956a7723ca69a44b382d9179c9802f-le64.cache-6
7f7dd7877000-7f7dd7878000 r--s 00000000 08:01
6160511                    /var/cache/fontconfig/dc05db6664285cc2f12bf69c139ae4c3-le64.cache-6
7f7dd7878000-7f7dd787a000 r--s 00000000 08:01
6160456                    /var/cache/fontconfig/14a5e22175779b556eaa434240950366-le64.cache-6
7f7dd787a000-7f7dd787b000 r--s 00000000 08:01
6160482                    /var/cache/fontconfig/660208299946a285a940457d1287da33-le64.cache-6
7f7dd787b000-7f7dd787c000 r--s 00000000 08:01
6177864                    /var/cache/fontconfig/5d1cca7074f29429a8d18692746c2426-le64.cache-6
7f7dd787c000-7f7dd787e000 r--s 00000000 08:01
6160473                    /var/cache/fontconfig/4f3e3037c9980c83b53a9351efadef62-le64.cache-6
7f7dd787e000-7f7dd7881000 r--s 00000000 08:01
6160486                    /var/cache/fontconfig/767a8244fc0220cfb567a839d0392e0b-le64.cache-6
7f7dd7881000-7f7dd7882000 r--s 00000000 08:01
6160468                    /var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-le64.cache-6
7f7dd7882000-7f7dd7883000 r--s 00000000 08:01
6177863                    /var/cache/fontconfig/9eae20f1ff8cc0a7d125749e875856bd-le64.cache-6
7f7dd7883000-7f7dd78c3000 r--s 00000000 08:01
6160453                    /var/cache/fontconfig/0bd3dc0958fa2205aaaa8ebb13e2872b-le64.cache-6
7f7dd78c3000-7f7dd78c6000 r--s 00000000 08:01
6177862                    /var/cache/fontconfig/bf2c1853a9e9b00bb02fe2e9bcf1e201-le64.cache-6
7f7dd78c6000-7f7dd78cb000 r--s 00000000 08:01
6160489                    /var/cache/fontconfig/8801497958630a81b71ace7c5f9b32a8-le64.cache-6
7f7dd78cb000-7f7dd78ce000 r--s 00000000 08:01
6160495                    /var/cache/fontconfig/a015930274ffcd967d2ca1b57da47cc7-le64.cache-6
7f7dd78ce000-7f7dd78d2000 r--s 00000000 08:01
6178486                    /var/cache/fontconfig/c57959a16110560c8d0fcea73374aeeb-le64.cache-6
7f7dd78d2000-7f7dd78d3000 r--s 00000000 08:01
6160499                    /var/cache/fontconfig/b872e6e592da6075ffa4ab0a1fcc0c75-le64.cache-6
7f7dd78d3000-7f7dd78d4000 r--s 00000000 08:01
6160516                    /var/cache/fontconfig/f6d4eedfaab2589bde49f7a3ff831d22-le64.cache-6
7f7dd78d4000-7f7dd78d5000 r--s 00000000 08:01
6160480                    /var/cache/fontconfig/589f83ef4c36d296ce6e1c846f468f08-le64.cache-6
7f7dd78d5000-7f7dd78d6000 r--s 00000000 08:01
6160501                    /var/cache/fontconfig/bab58bb527bb656aaa9f116d68a48d89-le64.cache-6
7f7dd78d6000-7f7dd78d7000 r--s 00000000 08:01
6160460                    /var/cache/fontconfig/2171a34dccabdb6bcbbc728186263178-le64.cache-6
7f7dd78d7000-7f7dd78d8000 r--s 00000000 08:01
6160502                    /var/cache/fontconfig/c5c45a61289222e0d30b1a26ef4effbe-le64.cache-6
7f7dd78d8000-7f7dd78d9000 r--s 00000000 08:01
6160497                    /var/cache/fontconfig/aec30016f93e1b46d1a973dce0d74068-le64.cache-6
7f7dd78d9000-7f7dd78da000 r--s 00000000 08:01
6160467                    /var/cache/fontconfig/3f589640d34b7dc9042c8d453f7c8b9c-le64.cache-6
7f7dd78da000-7f7dd78db000 r--s 00000000 08:01
6160457                    /var/cache/fontconfig/16c2fda60d1b4b719f4b3d06fd951d25-le64.cache-6
7f7dd78db000-7f7dd78dc000 r--s 00000000 08:01
6160496                    /var/cache/fontconfig/a48eab177a16e4f3713381162db2f3e9-le64.cache-6
7f7dd78dc000-7f7dd78dd000 r--s 00000000 08:01
6160476                    /var/cache/fontconfig/564b2e68ac9bc4e36a6f7f6d6125ec1c-le64.cache-6
7f7dd78dd000-7f7dd78e4000 r--s 00000000 08:01
6160463                    /var/cache/fontconfig/3047814df9a2f067bd2d96a2b9c36e5a-le64.cache-6
7f7dd78e4000-7f7dd78ec000 r--s 00000000 08:01
6174439                    /var/cache/fontconfig/bf3b770c553c462765856025a94f1ce6-le64.cache-6
7f7dd78ec000-7f7dd78ed000 r--s 00000000 08:01
6160477                    /var/cache/fontconfig/56cf4f4769d0f4abc89a4895d7bd3ae1-le64.cache-6
7f7dd78ed000-7f7dd78ee000 r--s 00000000 08:01
6160500                    /var/cache/fontconfig/b9d506c9ac06c20b433354fa67a72993-le64.cache-6
7f7dd78ee000-7f7dd78f4000 r--s 00000000 08:01
6160498                    /var/cache/fontconfig/b47c4e1ecd0709278f4910c18777a504-le64.cache-6
7f7dd78f4000-7f7dd78f7000 r--s 00000000 08:01
6177861                    /var/cache/fontconfig/14d493b97896515cad3840ba4896e372-le64.cache-6
7f7dd78f7000-7f7dd78fa000 r--s 00000000 08:01
6177860                    /var/cache/fontconfig/e49e89034d371f0f9de17aab02136486-le64.cache-6
7f7dd78fa000-7f7dd78fc000 r--s 00000000 08:01
6177859                    /var/cache/fontconfig/4b14b093aebc79c320de5e86ae1d3314-le64.cache-6
7f7dd78fc000-7f7dd78fd000 r--s 00000000 08:01
6177858                    /var/cache/fontconfig/8aec10f4cc8391dcef22ca549f1e4354-le64.cache-6
7f7dd78fd000-7f7dd7910000 r--s 00000000 08:01
6160508                    /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-le64.cache-6
7f7dd7910000-7f7dd7911000 r--s 00000000 08:01
6160464                    /var/cache/fontconfig/370e5b74bf5dafc30834de68e24a87a4-le64.cache-6
7f7dd7911000-7f7dd7912000 r--s 00000000 08:01
6160484                    /var/cache/fontconfig/6b2c5944714ca7831b25bed9e85cb5c8-le64.cache-6
7f7dd7912000-7f7dd7913000 r--s 00000000 08:01
6160507                    /var/cache/fontconfig/d5178ab6d91b49bf20a416737dcea9e8-le64.cache-6
7f7dd7913000-7f7dd7914000 r--s 00000000 08:01
6160475                    /var/cache/fontconfig/551ecf3b0e8b0bca0f25c0944f561853-le64.cache-6
7f7dd7914000-7f7dd7917000 r--s 00000000 08:01
6160515                    /var/cache/fontconfig/f259c2cffa685e28062317905db73c4a-le64.cache-6
7f7dd7917000-7f7dd7919000 r--s 00000000 08:01
6160474                    /var/cache/fontconfig/550f3886151c940c12a5ed35f6a00586-le64.cache-6
7f7dd7919000-7f7dd791c000 r--s 00000000 08:01
6160483                    /var/cache/fontconfig/674d1711f2d1d2a09646eb0bdcadee49-le64.cache-6
7f7dd791c000-7f7dd791d000 r--s 00000000 08:01
6175391                    /var/cache/fontconfig/8a687c406b77f27d99abfeeba937fcce-le64.cache-6
7f7dd791d000-7f7dd7922000 r--s 00000000 08:01
6177857                    /var/cache/fontconfig/75ad6aa2358a85f0de2c8ee4837e8227-le64.cache-6
7f7dd7922000-7f7dd7923000 r--s 00000000 08:01
6177856                    /var/cache/fontconfig/ac2cf712d852da827a87a9baf682f5b9-le64.cache-6
7f7dd7923000-7f7dd7925000 r--s 00000000 08:01
6177855                    /var/cache/fontconfig/65f976e5259cbe6dc7697b8648396239-le64.cache-6
7f7dd7925000-7f7dd7930000 r--s 00000000 08:01
6160509                    /var/cache/fontconfig/d589a48862398ed80a3d6066f4f56f4c-le64.cache-6
7f7dd7930000-7f7dd7934000 r--s 00000000 08:01
6177854                    /var/cache/fontconfig/246184dc75a16901ca37d96895904249-le64.cache-6
7f7dd7934000-7f7dd7935000 r--s 00000000 08:01
6177853                    /var/cache/fontconfig/94f7fe9bd33aadfac165873bd010d595-le64.cache-6
7f7dd7935000-7f7dd7937000 r--s 00000000 08:01
6177852                    /var/cache/fontconfig/423767150eb258c59035de29db6fca84-le64.cache-6
7f7dd7937000-7f7dd7938000 r--s 00000000 08:01
6177851                    /var/cache/fontconfig/845c20fd2c4814bcec78e05d37a63ccc-le64.cache-6
7f7dd7938000-7f7dd7939000 r--s 00000000 08:01
6177850                    /var/cache/fontconfig/e7de81b01590fb7e12b38e274e17d0db-le64.cache-6
7f7dd7939000-7f7dd793a000 r--s 00000000 08:01
6177849                    /var/cache/fontconfig/406a1d2d2bf3ed7664fbadefac0b2f66-le64.cache-6
7f7dd793a000-7f7dd793c000 r--s 00000000 08:01
6177848                    /var/cache/fontconfig/67709b7835c0f764c1135060c9575660-le64.cache-6
7f7dd793c000-7f7dd794a000 r--s 00000000 08:01
6177847                    /var/cache/fontconfig/198d8fcf01c96d0cf813f74fd759bdb7-le64.cache-6
7f7dd794a000-7f7dd794b000 r--s 00000000 08:01
6160454                    /var/cache/fontconfig/0c9eb80ebd1c36541ebe2852d3bb0c49-le64.cache-6
7f7dd794b000-7f7dd794c000 r--s 00000000 08:01
6160461                    /var/cache/fontconfig/22368d551a680bfe5a62c02760edf4ea-le64.cache-6
7f7dd794c000-7f7dd794d000 r--s 00000000 08:01
6160472                    /var/cache/fontconfig/4d9c95eba1cb85bbcf2878543262124a-le64.cache-6
7f7dd794d000-7f7dd794e000 r--s 00000000 08:01
6160488                    /var/cache/fontconfig/85e0a52ce643a7ba2ae53e5d6949cead-le64.cache-6
7f7dd794e000-7f7dd794f000 r--s 00000000 08:01
6160469                    /var/cache/fontconfig/49f0de54bdd920fe4f0dfd4cbac43e6b-le64.cache-6
7f7dd794f000-7f7dd7952000 r--s 00000000 08:01
6177846                    /var/cache/fontconfig/75114ca45c98e8a441da0ff356701271-le64.cache-6
7f7dd7952000-7f7dd795d000 r--s 00000000 08:01
6177845                    /var/cache/fontconfig/83bf95040141907cd45bb53cf7c1c148-le64.cache-6
7f7dd795d000-7f7dd796f000 r--s 00000000 08:01
6160493                    /var/cache/fontconfig/9b89f8e3dae116d678bbf48e5f21f69b-le64.cache-6
7f7dd796f000-7f7dd7978000 r--s 00000000 08:01
6160505                    /var/cache/fontconfig/d0972c3d32f097851eb916381fc38920-le64.cache-6
7f7dd7978000-7f7dd797f000 r--s 00000000 08:01
6177842                    /var/cache/fontconfig/53d14c92082a93e67d5078324eb314ca-le64.cache-6
7f7dd797f000-7f7dd7983000 r--s 00000000 08:01
6177841                    /var/cache/fontconfig/6c08beecf0dac481ec92e759e0c2e6d7-le64.cache-6
7f7dd7983000-7f7dd7987000 r--s 00000000 08:01
6177840                    /var/cache/fontconfig/4d6aee6d44eccb37054d3216e945f618-le64.cache-6
7f7dd7987000-7f7dd799a000 r--s 00000000 08:01
6177836                    /var/cache/fontconfig/4ac51e5cfbc76fc3f983e470323a16d3-le64.cache-6Abort



On Sun, 5 Mar 2017 13:18:57 -0800
"Philipp K. Janert" <ja...@ie...> wrote:

> I am encountering problems when running gnuplot in
> a loop (to update the graph based on changing data,
> "poor man's animation").
> 
> When using the wxt terminal, I intermittently run 
> into a failed assertion:
> 
> Gdk:ERROR:/build/gtk+2.0-KsZKkB/gtk+2.0-2.24.30/gdk/gdkregion-generic.c:337:miSetExtents:
> assertion failed: (pExtents->y1 < pExtents->y2)
> 
> When using the qt terminal, I can't stop the loop,
> because the "bind" command does not seem to work.
> 
> These problems seem new to me. They may be due to
> some form of library version skew (I updated my
> Linux install in the meantime). 
> 
> The essential commands are:
> 
> end=0
> while( end==0 ) {
>     splot "file" i 1 matrix w p lc pal
>     pause 0.1
> }
> 
> Version info:
> 
>         G N U P L O T
>         Version 5.0 patchlevel 3    last modified 2016-02-21 
> 
>         Copyright (C) 1986-1993, 1998, 2004, 2007-2016
>         Thomas Williams, Colin Kelley and many others
> 
>         gnuplot home:     http://www.gnuplot.info
>         faq, bugs, etc:   type "help FAQ"
>         immediate help:   type "help"  (plot window: hit 'h')
> Compile options:
> -READLINE  +LIBEDITLINE  +HISTORY  
> -BACKWARDS_COMPATIBILITY  +BINARY_DATA  
> +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
> -USE_CWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE
>         +HIDDEN3D_QUADTREE +DATASTRINGS  +HISTOGRAMS  +OBJECTS
>         +STRINGVARS  +MACROS  +THIN_SPLINES  +IMAGE  +USER_LINETYPES
>         +STATS +EXTERNAL_FUNCTIONS MAX_PARALLEL_AXES=7
> 
> GNUPLOT_DRIVER_DIR = "/usr/lib/gnuplot5"
> GNUPLOT_PS_DIR     = "/usr/share/gnuplot5/gnuplot/5.0/PostScript"
> HELPFILE           = "/usr/share/gnuplot5/gnuplot.gih"
> 
> ------------------------------------------------------------------------------
> 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

Regression when using gnuplot and loops?

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

I am encountering problems when running gnuplot in
a loop (to update the graph based on changing data,
"poor man's animation").

When using the wxt terminal, I intermittently run 
into a failed assertion:

Gdk:ERROR:/build/gtk+2.0-KsZKkB/gtk+2.0-2.24.30/gdk/gdkregion-generic.c:337:miSetExtents:
assertion failed: (pExtents->y1 < pExtents->y2)

When using the qt terminal, I can't stop the loop,
because the "bind" command does not seem to work.

These problems seem new to me. They may be due to
some form of library version skew (I updated my
Linux install in the meantime). 

The essential commands are:

end=0
while( end==0 ) {
    splot "file" i 1 matrix w p lc pal
    pause 0.1
}

Version info:

        G N U P L O T
        Version 5.0 patchlevel 3    last modified 2016-02-21 

        Copyright (C) 1986-1993, 1998, 2004, 2007-2016
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')
Compile options:
-READLINE  +LIBEDITLINE  +HISTORY  
-BACKWARDS_COMPATIBILITY  +BINARY_DATA  
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
-USE_CWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE
        +HIDDEN3D_QUADTREE +DATASTRINGS  +HISTOGRAMS  +OBJECTS
        +STRINGVARS  +MACROS  +THIN_SPLINES  +IMAGE  +USER_LINETYPES
        +STATS +EXTERNAL_FUNCTIONS MAX_PARALLEL_AXES=7

GNUPLOT_DRIVER_DIR = "/usr/lib/gnuplot5"
GNUPLOT_PS_DIR     = "/usr/share/gnuplot5/gnuplot/5.0/PostScript"
HELPFILE           = "/usr/share/gnuplot5/gnuplot.gih"

Re: (5.0.6pre source and windows binary)

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

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

> From: Tatsuro MATSUOKA 
> To: tmacchant3; Merritt Ethan ; gnuplot-beta
> Cc: bmaerkisch
> Date: 2017/3/1, Wed 10:25
> Subject: Re: (5.0.6pre source and windows binary)
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA 
>>  To: Merritt Ethan ; gnuplot-beta
>>  Cc: bmaerkisch
>>  Date: 2017/3/1, Wed 09:45
>>  Subject: Re: (5.0.6pre for windows)
>> 
>>> 
>> 
>>>   You guys are so quick!  
>>> 
>>>   I have bumped the date string in version.c to today' (28 Feb 2017)
>>>   and uploaded a source tarball to the release candidate area of 
> SourceForge.
>>> 
>>>   If there are no problem reports or requests for additional changes, I 
> will
>>>   replace the "6pre" source tarball with a  5.0.6 release 
> tarball 
>>  after 
>>>   1-2 weeks.
>>>   The 5.0.6 release announcement would follow by the end of March.
>>> 
>>>   Does that sound OK?
>>> 
>>>       Ethan
>>> 
>> 
>>  I think that the release plan is OK.
>> 
>>  I found a typo in version.c
>> 
>>  --- a/src/version.c    2017-03-01 02:21:01.000000000 +0900
>>  +++ b/src/version.c    2017-03-01 08:39:41.379137800 +0900
>>  @@ -44,7 +44,7 @@
>>   #ifdef DEVELOPMENT_VERSION
>>   #include "timestamp.h"
>>   #else
>>  -const char gnuplot_date[] = "2017-01-28";
>>  +const char gnuplot_date[] = "2017-02-28";
>>   #endif
>>   const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 
> 2004, 
>>  2007-2017";
>> 
>> 
>>  Tatsuro
>> 
> 
> Also ere windows build is OK.
> I upload 32 bit binary to 
> https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
> for those who use 32 bit version windows.
> 
> Tatsuro

I have confirmed that the typo in version.c is corrected in the current source file.

Thanks!

Tatsuro

Re: (5.0.6pre source and windows binary)

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

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

> From: Tatsuro MATSUOKA 
> To: Merritt Ethan ; gnuplot-beta
> Cc: bmaerkisch
> Date: 2017/3/1, Wed 09:45
> Subject: Re: (5.0.6pre for windows)
> 
>> 
> 
>>  You guys are so quick!  
>> 
>>  I have bumped the date string in version.c to today' (28 Feb 2017)
>>  and uploaded a source tarball to the release candidate area of SourceForge.
>> 
>>  If there are no problem reports or requests for additional changes, I will
>>  replace the "6pre" source tarball with a  5.0.6 release tarball 
> after 
>>  1-2 weeks.
>>  The 5.0.6 release announcement would follow by the end of March.
>> 
>>  Does that sound OK?
>> 
>>      Ethan
>> 
> 
> I think that the release plan is OK.
> 
> I found a typo in version.c
> 
> --- a/src/version.c    2017-03-01 02:21:01.000000000 +0900
> +++ b/src/version.c    2017-03-01 08:39:41.379137800 +0900
> @@ -44,7 +44,7 @@
>  #ifdef DEVELOPMENT_VERSION
>  #include "timestamp.h"
>  #else
> -const char gnuplot_date[] = "2017-01-28";
> +const char gnuplot_date[] = "2017-02-28";
>  #endif
>  const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
> 2007-2017";
> 
> 
> Tatsuro
> 

Also ere windows build is OK.
I upload 32 bit binary to 
https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
for those who use 32 bit version windows.

Tatsuro

Re: (5.0.6pre for windows)

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

On Wednesday, 01 March, 2017 09:45:28 Tatsuro MATSUOKA wrote:
> > 
> 
> > You guys are so quick!  
> > 
> > I have bumped the date string in version.c to today' (28 Feb 2017)
> > and uploaded a source tarball to the release candidate area of SourceForge.
> > 
> > If there are no problem reports or requests for additional changes, I will
> > replace the "6pre" source tarball with a  5.0.6 release tarball after 
> > 1-2 weeks.
> > The 5.0.6 release announcement would follow by the end of March.
> > 
> > Does that sound OK?
> > 
> >     Ethan
> >
> 
> I think that the release plan is OK.
> 
> I found a typo in version.c
> 
> --- a/src/version.c    2017-03-01 02:21:01.000000000 +0900
> +++ b/src/version.c    2017-03-01 08:39:41.379137800 +0900
> @@ -44,7 +44,7 @@
>  #ifdef DEVELOPMENT_VERSION
>  #include "timestamp.h"
>  #else
> -const char gnuplot_date[] = "2017-01-28";
> +const char gnuplot_date[] = "2017-02-28";
>  #endif
>  const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 2007-2017";
> 
> 
> Tatsuro

Proving one more time that no change is too simple to get wrong.
I've made that one character change and uploaded a new tarball.

  thanks!

	Ethan

Re: (5.0.6pre for windows)

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

> 

> You guys are so quick!  
> 
> I have bumped the date string in version.c to today' (28 Feb 2017)
> and uploaded a source tarball to the release candidate area of SourceForge.
> 
> If there are no problem reports or requests for additional changes, I will
> replace the "6pre" source tarball with a  5.0.6 release tarball after 
> 1-2 weeks.
> The 5.0.6 release announcement would follow by the end of March.
> 
> Does that sound OK?
> 
>     Ethan
>

I think that the release plan is OK.

I found a typo in version.c

--- a/src/version.c    2017-03-01 02:21:01.000000000 +0900
+++ b/src/version.c    2017-03-01 08:39:41.379137800 +0900
@@ -44,7 +44,7 @@
 #ifdef DEVELOPMENT_VERSION
 #include "timestamp.h"
 #else
-const char gnuplot_date[] = "2017-01-28";
+const char gnuplot_date[] = "2017-02-28";
 #endif
 const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 2007-2017";


Tatsuro

Re: (5.0.6pre for windows)

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

On Tuesday, 28 February 2017 06:00:17 PM Tatsuro MATSUOKA wrote:
> ----- Original Message -----
> 
> > From: ""Bastian Märkisch""
> > To: gnuplot beta list 
> > Cc: 
> > Date: 2017/2/28, Tue 16:53
> > Subject: 
> > 
> > In order to allow testing of the next version 5.0 release, you can now 
> > find a build of the current version (5.0.6pre) for Windows64 at
> > https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
> > 
> > Happy testing,
> >   Bastian
> >   
> 
> I am happy to hear that pre-release of 5.0.6.
> Thanks for your extensive work.
> 
> I confirmed all.dem works fine!
> 
> The last modified date of the executable is  2017-01-21
> but latest ChangeLog date is 2017-02-28.
> 
> I think that binary is up to date (2017-02-28.).
> 
> Is there a source code for pre-release?
> If not I will check out from cvs.
> 
> Tatsuro

You guys are so quick!  

I have bumped the date string in version.c to today' (28 Feb 2017)
and uploaded a source tarball to the release candidate area of SourceForge.

If there are no problem reports or requests for additional changes, I will
replace the "6pre" source tarball with a  5.0.6 release tarball after 1-2 weeks.
The 5.0.6 release announcement would follow by the end of March.

Does that sound OK?

	Ethan

Re: Is gp_exit() used at exit in current gnuplot?

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

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

> From: sfeam 
> To: gnuplot-beta Tatsuro MATSUOKA 
> Cc: 
> Date: 2017/2/28, Tue 15:54
> Subject: Re: Is gp_exit() used at exit in current gnuplot?
> 
>>  Thank you for your comprehensive explanation.
>>  I hope that message  in debug_exit_handler will be modified as you 
> indicaded
>> 
>>  "Gnuplot not exiting normally. Exit handlers may not work 
> correctly!"
> 
> 
> OK.  It now says:
>     "Gnuplot exiting abnormally. Trying to execute exit handlers 
> anyway."
> 
> So far as I can see, the only purpose of this message is to help debug
> the exit sequence, like you are doing with Bug 1913.
> 
>     Ethan
>

I have confirmed the change of message.

Thanks!

Tatsuro

Re: (5.0.6pre for windows)

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

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

> From: ""Bastian Märkisch""
> To: gnuplot beta list 
> Cc: 
> Date: 2017/2/28, Tue 16:53
> Subject: 
> 
> In order to allow testing of the next version 5.0 release, you can now 
> find a build of the current version (5.0.6pre) for Windows64 at
> https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/
> 
> Happy testing,
>   Bastian
>   

I am happy to hear that pre-release of 5.0.6.
Thanks for your extensive work.

I confirmed all.dem works fine!

The last modified date of the executable is  2017-01-21
but latest ChangeLog date is 2017-02-28.

I think that binary is up to date (2017-02-28.).

Is there a source code for pre-release?
If not I will check out from cvs.

Tatsuro

None

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

In order to allow testing of the next version 5.0 release, you can now 
find a build of the current version (5.0.6pre) for Windows64 at
https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/

Happy testing,
  Bastian
  

Re: Is gp_exit() used at exit in current gnuplot?

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

On Tuesday, 28 February 2017 02:57:46 PM Tatsuro MATSUOKA wrote:
> ----- Original Message -----
> 
> > From: sfeam 
> > To: gnuplot-beta Tatsuro MATSUOKA 
> > Cc: 
> > Date: 2017/2/28, Tue 13:51
> > Subject: Re: Is gp_exit() used at exit in current gnuplot?
> > 
> > On Tuesday, 28 February 2017 10:38:04 AM Tatsuro MATSUOKA wrote:
> >>  This is related to bug #1913.
> >> 
> >>  In stdfn.c
> >> 
> >>  there stated
> >> 
> >> 
> >>  /* Calls the cleanup functions registered using gp_atexit().
> >>   * Normally gnuplot should be exited using gp_exit(). In some cases, this 
> > is not
> >>   * possible (notably when returning from main(), where some compilers get
> >>   * confused because they expect a return statement at the very end. In that
> >>   * case, gp_exit_cleanup() should be called before the return statement.
> >>   */
> >> 
> >> 
> >>  *****************************
> >>  Normally gnuplot should be exited using gp_exit().
> >>  ***************************
> > 
> > I think the intended meaning is
> > "If you were going to terminate the program by calling exit(), don't do 
> > that.
> > Instead call gp_exit()."  
> > 
> > However the normal exit from main() in a C language program is by 
> > "return", not "exit()". 
> > So gnuplot's main() routine does not  call either exit() or gp_exit().  
> > Instead it calls
> > gp_exit_cleanup() followed by "return". 
> > Thus it does exactly what the comment describes.  
> > 
> >>  Excuse me for my writing without reading the code in detail.
> >>  gp_exit() seems to be used in many place in the code.
> >>  Therefore gp_exit() is surely used in current gnuplot.
> > 
> > Yes.  For example If you say
> > gnuplot>  exit gnuplot
> > then it calls gp_exit().
> > 
> >>  However, "gnuplot> exit" does not use gp_exit() as written in 
> > the
> >>  previous post.
> >> 
> >>  I feel that the message
> >> 
> >>  Gnuplot not exited using gp_exit(). Exit handlers may not work correctly!
> >> 
> >>  in debug_exit_handler in stdfn.c is better to be modified.
> > 
> > I think you are correct that the message is not accurate.
> > It would be better to say 
> > "Gnuplot not exiting normally. Exit handlers may not work correctly!"
> > gp_exit() is one way of exiting normally, but exiting by return from main()
> > is also a way of exiting normally.
> > 
> > In your case (Bug 1913) I guess neither of these normal ways to exit is 
> > happening.
> > Instead gnuplot is killed by the operating system because you hit  the "X 
> > button".
> > 
> >     Ethan
> > 
> > 
> > 
> Thank you for your comprehensive explanation.
> I hope that message  in debug_exit_handler will be modified as you indicaded
> 
> "Gnuplot not exiting normally. Exit handlers may not work correctly!"


OK.  It now says:
    "Gnuplot exiting abnormally. Trying to execute exit handlers anyway."

So far as I can see, the only purpose of this message is to help debug
the exit sequence, like you are doing with Bug 1913.

	Ethan

Re: Is gp_exit() used at exit in current gnuplot?

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

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

> From: sfeam 
> To: gnuplot-beta Tatsuro MATSUOKA 
> Cc: 
> Date: 2017/2/28, Tue 13:51
> Subject: Re: Is gp_exit() used at exit in current gnuplot?
> 
> On Tuesday, 28 February 2017 10:38:04 AM Tatsuro MATSUOKA wrote:
>>  This is related to bug #1913.
>> 
>>  In stdfn.c
>> 
>>  there stated
>> 
>> 
>>  /* Calls the cleanup functions registered using gp_atexit().
>>   * Normally gnuplot should be exited using gp_exit(). In some cases, this 
> is not
>>   * possible (notably when returning from main(), where some compilers get
>>   * confused because they expect a return statement at the very end. In that
>>   * case, gp_exit_cleanup() should be called before the return statement.
>>   */
>> 
>> 
>>  *****************************
>>  Normally gnuplot should be exited using gp_exit().
>>  ***************************
> 
> I think the intended meaning is
> "If you were going to terminate the program by calling exit(), don't do 
> that.
> Instead call gp_exit()."  
> 
> However the normal exit from main() in a C language program is by 
> "return", not "exit()". 
> So gnuplot's main() routine does not  call either exit() or gp_exit().  
> Instead it calls
> gp_exit_cleanup() followed by "return". 
> Thus it does exactly what the comment describes.  
> 
>>  Excuse me for my writing without reading the code in detail.
>>  gp_exit() seems to be used in many place in the code.
>>  Therefore gp_exit() is surely used in current gnuplot.
> 
> Yes.  For example If you say
> gnuplot>  exit gnuplot
> then it calls gp_exit().
> 
>>  However, "gnuplot> exit" does not use gp_exit() as written in 
> the
>>  previous post.
>> 
>>  I feel that the message
>> 
>>  Gnuplot not exited using gp_exit(). Exit handlers may not work correctly!
>> 
>>  in debug_exit_handler in stdfn.c is better to be modified.
> 
> I think you are correct that the message is not accurate.
> It would be better to say 
> "Gnuplot not exiting normally. Exit handlers may not work correctly!"
> gp_exit() is one way of exiting normally, but exiting by return from main()
> is also a way of exiting normally.
> 
> In your case (Bug 1913) I guess neither of these normal ways to exit is 
> happening.
> Instead gnuplot is killed by the operating system because you hit  the "X 
> button".
> 
>     Ethan
> 
> 
> 
Thank you for your comprehensive explanation.
I hope that message  in debug_exit_handler will be modified as you indicaded

"Gnuplot not exiting normally. Exit handlers may not work correctly!"

Tatsuro

Re: Is gp_exit() used at exit in current gnuplot?

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

On Tuesday, 28 February 2017 10:38:04 AM Tatsuro MATSUOKA wrote:
> This is related to bug #1913.
> 
> In stdfn.c
> 
> there stated
> 
> 
> /* Calls the cleanup functions registered using gp_atexit().
>  * Normally gnuplot should be exited using gp_exit(). In some cases, this is not
>  * possible (notably when returning from main(), where some compilers get
>  * confused because they expect a return statement at the very end. In that
>  * case, gp_exit_cleanup() should be called before the return statement.
>  */
> 
> 
> *****************************
> Normally gnuplot should be exited using gp_exit().
> ***************************

I think the intended meaning is
"If you were going to terminate the program by calling exit(), don't do that.
Instead call gp_exit()."  

However the normal exit from main() in a C language program is by "return", not "exit()". 
So gnuplot's main() routine does not  call either exit() or gp_exit().  Instead it calls
gp_exit_cleanup() followed by "return". 
Thus it does exactly what the comment describes.  

> Excuse me for my writing without reading the code in detail.
> gp_exit() seems to be used in many place in the code.
> Therefore gp_exit() is surely used in current gnuplot.

Yes.  For example If you say
gnuplot>  exit gnuplot
then it calls gp_exit().

> However, "gnuplot> exit" does not use gp_exit() as written in the
> previous post.
> 
> I feel that the message
> 
> Gnuplot not exited using gp_exit(). Exit handlers may not work correctly!
> 
> in debug_exit_handler in stdfn.c is better to be modified.

I think you are correct that the message is not accurate.
It would be better to say 
"Gnuplot not exiting normally. Exit handlers may not work correctly!"
gp_exit() is one way of exiting normally, but exiting by return from main()
is also a way of exiting normally.

In your case (Bug 1913) I guess neither of these normal ways to exit is happening.
Instead gnuplot is killed by the operating system because you hit  the "X button".

	Ethan





 
> Tatsuro

Re: Is gp_exit() used at exit in current gnuplot?

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

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

> From: Tatsuro MATSUOKA 
> To: gnu...@li...
> Cc: 
> Date: 2017/2/28, Tue 10:38
> Subject: Is gp_exit() used at exit in current gnuplot?
> 
>T his is related to bug #1913.
> 
> In stdfn.c
> 
> there stated
> 
> 
> /* Calls the cleanup functions registered using gp_atexit().
>  * Normally gnuplot should be exited using gp_exit(). In some cases, this is not
>  * possible (notably when returning from main(), where some compilers get
>  * confused because they expect a return statement at the very end. In that
>  * case, gp_exit_cleanup() should be called before the return statement.
>  */
> 
> 
> *****************************
> 
> Normally gnuplot should be exited using gp_exit().
> ***************************
> 
> 
> However, quick test by gdb
> 
> gdb gnuplot
> b gp_exit_cleanup
> b gp_exit
> b debug_exit_handler
> r
> 
> At gnuplot prompt
> 
> gnuplot> exit
> 
> gdb tells that gnuplot does not end by gp_exit but by debug_exit_handler.
> by exit command value of exit_handlers
> 
> 
> On  cygwin
> 
> Breakpoint 1, gp_exit_cleanup () at ../../gnuplot/src/stdfn.c:440
> 440     {
> (gdb) n
> [New Thread 8120.0x26b8]
> 447         while (exit_handlers) {
> (gdb) n
> 449             (*handler->function)();
> (gdb) n
> [New Thread 8120.0x27cc]
> 451             exit_handlers = handler->next;
> (gdb) n
> 452             free(handler);
> (gdb) n
> 451             exit_handlers = handler->next;
> (gdb) n
> 452             free(handler);
> (gdb) n
> 447         while (exit_handlers) {
> (gdb) n
> 449             (*handler->function)();
> (gdb) n
> 451             exit_handlers = handler->next;
> (gdb) n
> 452             free(handler);
> (gdb) n
> 451             exit_handlers = handler->next;
> (gdb) n
> 452             free(handler);
> (gdb) n
> 447         while (exit_handlers) {
> (gdb) n
> 454     }
> (gdb) n
> main (argc=<optimized out>, argv=<optimized out>)
>     at ../../gnuplot/src/plot.c:694
> 694         return exit_status;
> (gdb) n
> 695     }
> (gdb) n
> 0x61007acf in cygwin_exit_return () from /usr/bin/cygwin1.dll
> (gdb) c
> Continuing.
> 
> Breakpoint 3, debug_exit_handler () at ../../gnuplot/src/stdfn.c:461
> 461         if (exit_handlers) {
> (gdb) p exit_handlers
> $1 = (struct EXIT_HANDLER *) 0x0
> (gdb) c
> Continuing.
> [Thread 8120.0x1708 exited with code 0]
> [Thread 8120.0x26b8 exited with code 0]
> [Thread 8120.0x1094 exited with code 0]
> [Thread 8120.0x27cc exited with code 0]
> [Thread 8120.0x22c8 exited with code 0]
> [Inferior 1 (process 8120) exited normally]
> 
> 
> The above also happens on lubuntu.
> 
> Similar behavior is observed on windows
> 
> 
> Entering exit command 
> gp_exit_cleanup () is called in main in plot.c on Cygwin and lubuntu. 
> gp_exit_cleanup () is called in WinMain (wgnuplot) or main (gnuplot) in 
> wimmain.c on windows. 
> 
> 
> Even exit command, gp_exit() seems not to be used.
> 
> Is 
> 
> *****************************
> 
> Normally gnuplot should be exited using gp_exit().
> ***************************
> 
> true at present ?
> 
> Tatsuro
> 

Excuse me for my writing without reading the code in detail.
gp_exit() seems to be used in many place in the code.
Therefore gp_exit() is surely used in current gnuplot.
However, "gnuplot> exit" does not use gp_exit() as written in the previous post.

I feel that the message
 
Gnuplot not exited using gp_exit(). Exit handlers may not work correctly!

in debug_exit_handler in stdfn.c is better to be modified.

Tatsuro

Is gp_exit() used at exit in current gnuplot?

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

This is related to bug #1913.

In stdfn.c

there stated


/* Calls the cleanup functions registered using gp_atexit().
 * Normally gnuplot should be exited using gp_exit(). In some cases, this is not
 * possible (notably when returning from main(), where some compilers get
 * confused because they expect a return statement at the very end. In that
 * case, gp_exit_cleanup() should be called before the return statement.
 */


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

Normally gnuplot should be exited using gp_exit().
***************************


However, quick test by gdb

gdb gnuplot
b gp_exit_cleanup
b gp_exit
b debug_exit_handler
r

At gnuplot prompt

gnuplot> exit

gdb tells that gnuplot does not end by gp_exit but by debug_exit_handler.
by exit command value of exit_handlers


On  cygwin

Breakpoint 1, gp_exit_cleanup () at ../../gnuplot/src/stdfn.c:440
440     {
(gdb) n
[New Thread 8120.0x26b8]
447         while (exit_handlers) {
(gdb) n
449             (*handler->function)();
(gdb) n
[New Thread 8120.0x27cc]
451             exit_handlers = handler->next;
(gdb) n
452             free(handler);
(gdb) n
451             exit_handlers = handler->next;
(gdb) n
452             free(handler);
(gdb) n
447         while (exit_handlers) {
(gdb) n
449             (*handler->function)();
(gdb) n
451             exit_handlers = handler->next;
(gdb) n
452             free(handler);
(gdb) n
451             exit_handlers = handler->next;
(gdb) n
452             free(handler);
(gdb) n
447         while (exit_handlers) {
(gdb) n
454     }
(gdb) n
main (argc=<optimized out>, argv=<optimized out>)
    at ../../gnuplot/src/plot.c:694
694         return exit_status;
(gdb) n
695     }
(gdb) n
0x61007acf in cygwin_exit_return () from /usr/bin/cygwin1.dll
(gdb) c
Continuing.

Breakpoint 3, debug_exit_handler () at ../../gnuplot/src/stdfn.c:461
461         if (exit_handlers) {
(gdb) p exit_handlers
$1 = (struct EXIT_HANDLER *) 0x0
(gdb) c
Continuing.
[Thread 8120.0x1708 exited with code 0]
[Thread 8120.0x26b8 exited with code 0]
[Thread 8120.0x1094 exited with code 0]
[Thread 8120.0x27cc exited with code 0]
[Thread 8120.0x22c8 exited with code 0]
[Inferior 1 (process 8120) exited normally]


The above also happens on lubuntu.

Similar behavior is observed on windows


Entering exit command 
gp_exit_cleanup () is called in main in plot.c on Cygwin and lubuntu. 
gp_exit_cleanup () is called in WinMain (wgnuplot) or main (gnuplot) in wimmain.c on windows. 


Even exit command, gp_exit() seems not to be used.

Is 

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

Normally gnuplot should be exited using gp_exit().
***************************

true at present ?

Tatsuro

Re: Undocumented behaviour of "smooth" options

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

On Thu, 23 Feb 2017, Hans-Bernhard Bröker wrote:

> Am 22.02.2017 um 00:21 schrieb Ethan A Merritt:
>
>> On the bug tracker    <https://sourceforge.net/p/gnuplot/bugs/1911/>
>> Rainald Koch points out that when a data set contains some points with
>> invalid y values, the result of smoothing is unexpected.
>
> Expectations can be deceiving.  :-)
>
>> I can't find any mention of it in the documentation, but it seems that
>> this is intentional.  The "smooth" code has a pre-processing step that
>> splits the input data into N subsets separated by one or more "undefined"
>> points.
>
> Well, what else was the code to do with actual blank lines in the input,
> or otherwise missing/unusable data?  And back in the day, invalid data
> _was_ often treated as being the same thing as missing data.  Plotting a
> spline across a hole in its input data would IMHO be at least as wrong
> as the lack of documentation of the current behaviour.
>
> The behaviour of the smoothing code is not that wildly different from
> that of the normal 'with lines' behaviour, really: a missing entry
> breaks the polyline, so it's not entirely unepected that it breaks the
> smoothed curve, too.

That seems reasonable. If the user has reason to believe the missing 
data can be interpolated in some way, she could do that before 
smoothing.

Allin Cottrell

Re: Undocumented behaviour of "smooth" options

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

Am 22.02.2017 um 00:21 schrieb Ethan A Merritt:

> On the bug tracker    <https://sourceforge.net/p/gnuplot/bugs/1911/>
> Rainald Koch points out that when a data set contains some points with
> invalid y values, the result of smoothing is unexpected.

Expectations can be deceiving.  :-)

> I can't find any mention of it in the documentation, but it seems that
> this is intentional.  The "smooth" code has a pre-processing step that
> splits the input data into N subsets separated by one or more "undefined"
> points.

Well, what else was the code to do with actual blank lines in the input, 
or otherwise missing/unusable data?  And back in the day, invalid data 
_was_ often treated as being the same thing as missing data.  Plotting a 
spline across a hole in its input data would IMHO be at least as wrong 
as the lack of documentation of the current behaviour.

The behaviour of the smoothing code is not that wildly different from 
that of the normal 'with lines' behaviour, really: a missing entry 
breaks the polyline, so it's not entirely unepected that it breaks the 
smoothed curve, too.