Menu
▾
▴
gnuplot-beta — Developers and beta testers of new gnuplot code
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(83) |
Nov
(57) |
Dec
(111) |
| 2004 |
Jan
(38) |
Feb
(121) |
Mar
(107) |
Apr
(241) |
May
(102) |
Jun
(190) |
Jul
(239) |
Aug
(158) |
Sep
(184) |
Oct
(193) |
Nov
(47) |
Dec
(68) |
| 2005 |
Jan
(190) |
Feb
(105) |
Mar
(99) |
Apr
(65) |
May
(92) |
Jun
(250) |
Jul
(197) |
Aug
(128) |
Sep
(101) |
Oct
(183) |
Nov
(186) |
Dec
(42) |
| 2006 |
Jan
(102) |
Feb
(122) |
Mar
(154) |
Apr
(196) |
May
(181) |
Jun
(281) |
Jul
(310) |
Aug
(198) |
Sep
(145) |
Oct
(188) |
Nov
(134) |
Dec
(90) |
| 2007 |
Jan
(134) |
Feb
(181) |
Mar
(157) |
Apr
(57) |
May
(81) |
Jun
(204) |
Jul
(60) |
Aug
(37) |
Sep
(17) |
Oct
(90) |
Nov
(122) |
Dec
(72) |
| 2008 |
Jan
(130) |
Feb
(108) |
Mar
(160) |
Apr
(38) |
May
(83) |
Jun
(42) |
Jul
(75) |
Aug
(16) |
Sep
(71) |
Oct
(57) |
Nov
(59) |
Dec
(152) |
| 2009 |
Jan
(73) |
Feb
(213) |
Mar
(67) |
Apr
(40) |
May
(46) |
Jun
(82) |
Jul
(73) |
Aug
(57) |
Sep
(108) |
Oct
(36) |
Nov
(153) |
Dec
(77) |
| 2010 |
Jan
(42) |
Feb
(171) |
Mar
(150) |
Apr
(6) |
May
(22) |
Jun
(34) |
Jul
(31) |
Aug
(38) |
Sep
(32) |
Oct
(59) |
Nov
(13) |
Dec
(62) |
| 2011 |
Jan
(114) |
Feb
(139) |
Mar
(126) |
Apr
(51) |
May
(53) |
Jun
(29) |
Jul
(41) |
Aug
(29) |
Sep
(35) |
Oct
(87) |
Nov
(42) |
Dec
(20) |
| 2012 |
Jan
(111) |
Feb
(66) |
Mar
(35) |
Apr
(59) |
May
(71) |
Jun
(32) |
Jul
(11) |
Aug
(48) |
Sep
(60) |
Oct
(87) |
Nov
(16) |
Dec
(38) |
| 2013 |
Jan
(5) |
Feb
(19) |
Mar
(41) |
Apr
(47) |
May
(14) |
Jun
(32) |
Jul
(18) |
Aug
(68) |
Sep
(9) |
Oct
(42) |
Nov
(12) |
Dec
(10) |
| 2014 |
Jan
(14) |
Feb
(139) |
Mar
(137) |
Apr
(66) |
May
(72) |
Jun
(142) |
Jul
(70) |
Aug
(31) |
Sep
(39) |
Oct
(98) |
Nov
(133) |
Dec
(44) |
| 2015 |
Jan
(70) |
Feb
(27) |
Mar
(36) |
Apr
(11) |
May
(15) |
Jun
(70) |
Jul
(30) |
Aug
(63) |
Sep
(18) |
Oct
(15) |
Nov
(42) |
Dec
(29) |
| 2016 |
Jan
(37) |
Feb
(48) |
Mar
(59) |
Apr
(28) |
May
(30) |
Jun
(43) |
Jul
(47) |
Aug
(14) |
Sep
(21) |
Oct
(26) |
Nov
(10) |
Dec
(2) |
| 2017 |
Jan
(26) |
Feb
(27) |
Mar
(44) |
Apr
(11) |
May
(32) |
Jun
(28) |
Jul
(75) |
Aug
(45) |
Sep
(35) |
Oct
(285) |
Nov
(99) |
Dec
(16) |
| 2018 |
Jan
(8) |
Feb
(8) |
Mar
(42) |
Apr
(35) |
May
(23) |
Jun
(12) |
Jul
(16) |
Aug
(11) |
Sep
(8) |
Oct
(16) |
Nov
(5) |
Dec
(8) |
| 2019 |
Jan
(9) |
Feb
(28) |
Mar
(4) |
Apr
(10) |
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(23) |
Dec
(3) |
| 2020 |
Jan
(19) |
Feb
(3) |
Mar
(22) |
Apr
(17) |
May
(10) |
Jun
(69) |
Jul
(18) |
Aug
(23) |
Sep
(25) |
Oct
(11) |
Nov
(20) |
Dec
(9) |
| 2021 |
Jan
(1) |
Feb
(7) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(6) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(23) |
| 2022 |
Jan
(23) |
Feb
(9) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(6) |
Aug
(8) |
Sep
(30) |
Oct
(5) |
Nov
(4) |
Dec
(6) |
| 2023 |
Jan
(2) |
Feb
(5) |
Mar
(7) |
Apr
(3) |
May
(8) |
Jun
(45) |
Jul
(8) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(7) |
Dec
(2) |
| 2024 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(4) |
Dec
(14) |
| 2025 |
Jan
(22) |
Feb
(6) |
Mar
(5) |
Apr
(14) |
May
(6) |
Jun
(11) |
Jul
(19) |
Aug
|
Sep
(17) |
Oct
(1) |
Nov
(2) |
Dec
(18) |
| 2026 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <pl...@pi...> - 2016-09-17 10:28:59
|
Hi,
the iteration in gnupllot is an excellent feature but can not take an
irregular sequence of numerical variables.
it's either a straight integer series or a list of _string_ variables.
Is there any reason why it can not take a list of numbers ?
eg. if I want vertical arrows at x= 11,13,17 it does not seem
possible with the existing iteration.
help tells me:
Two forms of iteration clause are currently supported:
for [intvar = start:end{:increment}]
for [stringvar in "A B C D"]
why not for [intvar = 11,13,17] ?
is there a trick to a string value in set arrow ?
set for [stringvar in "11 13 17"] arrow from ???, 0 to ???,1
Is there a problem to specify intvar with a list of values instead of a
regular series?
Thanks, Peter.
|
|
From: Tatsuro M. <tma...@ya...> - 2016-08-18 23:09:34
|
> From: Ethan Merritt > To: gnuplot-beta Tatsuro MATSUOKA > Cc: > Date: 2016/8/18, Thu 15:00 > Subject: Re: cvs ChangeLog date > > On Thursday, 18 August 2016 02:07:04 PM Tatsuro MATSUOKA wrote: >> Top of current ChangeLog of latest cvs (2016-08-18) >> >> >> 2015-08-24 Dima Kogan <di...@se...> * src/gp_types.h > src/interpol.c src/plot2d.c src/tables.c docs/gnuplot.doc: New option > "smooth fnormal" plots normalize frequency, analogous to plot foo > using 1:(1./total) smooth freq" >> >> 2015-08-24? >> >> Is it correct? > > Obviously not. > A consequence of cut-and-pasting attributions from previous patches. > > thanks, > > Ethan > I have confirmed the fix. Thanks. Tatsuro |
|
From: Ethan M. <merritt@u.washington.edu> - 2016-08-18 06:16:23
|
On Thursday, 18 August 2016 02:07:04 PM Tatsuro MATSUOKA wrote:
> Top of current ChangeLog of latest cvs (2016-08-18)
>
>
> 2015-08-24 Dima Kogan <di...@se...> * src/gp_types.h src/interpol.c src/plot2d.c src/tables.c docs/gnuplot.doc: New option "smooth fnormal" plots normalize frequency, analogous to plot foo using 1:(1./total) smooth freq"
>
> 2015-08-24?
>
> Is it correct?
Obviously not.
A consequence of cut-and-pasting attributions from previous patches.
thanks,
Ethan
--
mail: Biomolecular Structure Center, K-428 Health Sciences Bldg
MS 357742, University of Washington, Seattle 98195-7742
|
|
From: Tatsuro M. <tma...@ya...> - 2016-08-18 05:07:14
|
Top of current ChangeLog of latest cvs (2016-08-18) 2015-08-24 Dima Kogan <di...@se...> * src/gp_types.h src/interpol.c src/plot2d.c src/tables.c docs/gnuplot.doc: New option "smooth fnormal" plots normalize frequency, analogous to plot foo using 1:(1./total) smooth freq" 2015-08-24? Is it correct? Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2016-08-12 09:42:45
|
> From: sfeam > To: gnuplot-beta; Tatsuro MATSUOKA > Cc: > Date: 2016/8/12, Fri 13:30 > Subject: Re: minus sign implemetation on sjis > > On Friday, 12 August 2016 09:59:04 AM Tatsuro MATSUOKA wrote: >> >> set minussign is a very nice new feature! >> This is what I want to use for a long time! >> >> >> In sjis encoding, minussign code is 0x817c. >> This is a Japanese Kanji character with wide width. >> >> >From Ethan suggestion, I tried this in windows, qt, and wxt. >> Looking are not good compared to those on utf8. >> >> In my opinion, it is better that this feature is not implemented in sjis > encoding. >> Utf8 is now widely used even on windows in Japanese. >> >> Therefore Japanese people who want to use this feature will use utf8 > encoding >> if this feature will dropped on sjis encoding. > > OK. I will disable the character mapping for SJIS and add a comment explaining > that the half-width/full-width nature of the Japanese character set makes the > special minus sign look bad. > >> In addition using this option in sjis encoding, + character represent half > width while >> - character represent full width. > > The "set minus" command only affects the unary minus, > that is, the character in front of a negative number. > It does not affect the arithmetic operation symbol for subtraction. > > thanks for testing, > > Ethan > > >> >> Tatsuro I have confirmed that cvs source tree has been revised and confirmed that "set minussign" does not affect gnuplot behavior if the encoding is SJIS. Thanks a lot. Tatsuro |
|
From: sfeam <sf...@us...> - 2016-08-12 04:31:52
|
On Friday, 12 August 2016 09:59:04 AM Tatsuro MATSUOKA wrote: > > set minussign is a very nice new feature! > This is what I want to use for a long time! > > > In sjis encoding, minussign code is 0x817c. > This is a Japanese Kanji character with wide width. > > >From Ethan suggestion, I tried this in windows, qt, and wxt. > Looking are not good compared to those on utf8. > > In my opinion, it is better that this feature is not implemented in sjis encoding. > Utf8 is now widely used even on windows in Japanese. > > Therefore Japanese people who want to use this feature will use utf8 encoding > if this feature will dropped on sjis encoding. OK. I will disable the character mapping for SJIS and add a comment explaining that the half-width/full-width nature of the Japanese character set makes the special minus sign look bad. > In addition using this option in sjis encoding, + character represent half width while > - character represent full width. The "set minus" command only affects the unary minus, that is, the character in front of a negative number. It does not affect the arithmetic operation symbol for subtraction. thanks for testing, Ethan > > Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2016-08-12 00:59:14
|
set minussign is a very nice new feature! This is what I want to use for a long time! In sjis encoding, minussign code is 0x817c. This is a Japanese Kanji character with wide width. From Ethan suggestion, I tried this in windows, qt, and wxt. Looking are not good compared to those on utf8. In addition using this option in sjis encoding, + character represent half width while - character represent full width. The looking is not good. In my opinion, it is better that this feature is not implemented in sjis encoding. Utf8 is now widely used even on windows in Japanese. Therefore Japanese people who want to use this feature will use utf8 encoding if this feature will dropped on sjis encoding. Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2016-08-09 22:05:17
|
----- Original Message ----- > From: Tatsuro MATSUOKA > To: gnuplot-beta > Cc: > Date: 2016/8/9, Tue 15:53 > Subject: config/mingw/Makefile MinGW64 bug ? > > Bastian > > 2016-08-08 Bastian Maerkisch <bma...@we...> > > * config/mingw/Makefile: Avoid warning messages when using clang. > Omit C++ flags when building gp_cairo.c. Japanese help file was > missing a graph from the demos. Execute lua via the cmd.exe shell > in order to avoid errors when redirecting its output (Seems to be > a lua bug in Mingw64). > > The lua build using MinGW64 on the sourceforge site (gcc-5.3.0) does not have > this bug. > Perhaps this is a bug on mingw64 on the msys2. > If you have a chance, please correct the description. > > > Tatsuro I have confirmed the ChangeLog has been revised. Thanks. Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2016-08-09 06:53:47
|
Bastian 2016-08-08 Bastian Maerkisch <bma...@we...> * config/mingw/Makefile: Avoid warning messages when using clang. Omit C++ flags when building gp_cairo.c. Japanese help file was missing a graph from the demos. Execute lua via the cmd.exe shell in order to avoid errors when redirecting its output (Seems to be a lua bug in Mingw64). The lua build using MinGW64 on the sourceforge site (gcc-5.3.0) does not have this bug. Perhaps this is a bug on mingw64 on the msys2. If you have a chance, please correct the description. Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2016-08-04 07:55:32
|
----- Original Message ----- > From: Tatsuro MATSUOKA > To: tmacchant3 > Cc: > Date: 2016/8/4, Thu 16:01 > Subject: Re: wxt hang on 5.0.4 and recent cvs on ubuntu 14.04 amd64 > > ----- Original Message ----- > >> From: Tatsuro MATSUOKA >> To: gnuplot-beta> Cc: >> Date: 2016/8/4, Thu 15:52 >> Subject: wxt hang on 5.0.4 and recent cvs on ubuntu 14.04 amd64 >> >> I have built gnuplot 5.0.4 or recent 5.1.0 on Ubunutu 14.04 amd64. >> The wxt terminals hangs. >> >> (On 5.0.3, wxt terminal works correctly.) >> >> G N U P L O T >> Version 5.0 patchlevel 4 last modified 2016-07-21 >> >> >> gnuplot> set term wxt >> Terminal type set to 'wxt' >> Options are '0 enhanced' >> gnuplot> pl x >> terminated (core dump) >> >> On recent 14.04, I have met the same hang. >> >> >> Running on gdb, >> gnuplot> pl x >> >> Program received signal SIGABRT, Aborted. >> 0x00007ffff3eecc37 in __GI_raise (sig=sig@entry=6) >> at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >> 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. >> (gdb) bt >> #0 0x00007ffff3eecc37 in __GI_raise (sig=sig@entry=6) >> at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >> #1 0x00007ffff3ef0028 in __GI_abort () at abort.c:89 >> #2 0x00007ffff6e61eda in wxVLogFatalError(wchar_t const*, __va_list_tag*) > () >> from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 >> #3 0x00007ffff6e61fac in wxLogFatalError(wchar_t const*, ...) () >> from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 >> #4 0x00007ffff6e274f1 in wxAppConsole::CheckBuildOptions(char const*, char > >> const*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 >> #5 0x0000000000509289 in wxCreateApp () >> at ../../gnuplot-5.0.4/src/wxterminal/wxt_gui.cpp:271 >> #6 0x00007ffff6e56a61 in wxEntryStart(int&, wchar_t**) () >> from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 >> #7 0x00007ffff6e56cfc in wxInitialize(int, wchar_t**) () >> from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 >> #8 0x0000000000510901 in wxt_init () >> at ../../gnuplot-5.0.4/src/wxterminal/wxt_gui.cpp:1792 >> #9 0x00000000004f6942 in term_initialise () >> at ../../gnuplot-5.0.4/src/term.c:501 >> #10 0x0000000000452a28 in do_plot (plots=0x801c40, pcount=pcount@entry=1) >> at ../../gnuplot-5.0.4/src/graphics.c:525 >> #11 0x0000000000479120 in eval_plots () >> at ../../gnuplot-5.0.4/src/plot2d.c:3367 >> ---Type <return> to continue, or q <return> to quit--- >> >> >> If I use this version of gnuplot for octave >> >>>> setenv GNUTERM wxt >>>> graphics_toolkit gnuplot >>>> plot (1:10) >> >> Fatal Error: Mismatch between the program and library build versions > detected. >> The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx >> containers,compatible with 2.6), >> and yo>> ur program used 2.8 (no debug,Unicode,compiler with C++ ABI >> 1009,wx containers,compatible with 2.6). >> >> Seems to be mismatch of ABI of wx 2.8. >> >> I do not thing that this is a bug of gnuplot. But some new codes of gnuplot > >> trigger the faults on my system. >> >> Any suggestions? >> >> Tatsuro > > Sorry. Origin is not code change. > I have back to the build tree where 5.0.3 is built. > make install forces to recompile and built 5.0.3 hang in the same way. > > Perhaps on my ubuntu system something wrong with libwxgtk at some moment. > > MMMMMM > > I will try to build wxGTK by myself. > > Tatsuro I have built wxGTK-2.8 by myself and used it gnuplot 5.0.4 build. Then the wxt terminal works well. Sorry for the noise. Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2016-08-04 07:01:47
|
----- Original Message ----- > From: Tatsuro MATSUOKA > To: gnuplot-beta> Cc: > Date: 2016/8/4, Thu 15:52 > Subject: wxt hang on 5.0.4 and recent cvs on ubuntu 14.04 amd64 > > I have built gnuplot 5.0.4 or recent 5.1.0 on Ubunutu 14.04 amd64. > The wxt terminals hangs. > > (On 5.0.3, wxt terminal works correctly.) > > G N U P L O T > Version 5.0 patchlevel 4 last modified 2016-07-21 > > > gnuplot> set term wxt > Terminal type set to 'wxt' > Options are '0 enhanced' > gnuplot> pl x > terminated (core dump) > > On recent 14.04, I have met the same hang. > > > Running on gdb, > gnuplot> pl x > > Program received signal SIGABRT, Aborted. > 0x00007ffff3eecc37 in __GI_raise (sig=sig@entry=6) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > (gdb) bt > #0 0x00007ffff3eecc37 in __GI_raise (sig=sig@entry=6) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > #1 0x00007ffff3ef0028 in __GI_abort () at abort.c:89 > #2 0x00007ffff6e61eda in wxVLogFatalError(wchar_t const*, __va_list_tag*) () > from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 > #3 0x00007ffff6e61fac in wxLogFatalError(wchar_t const*, ...) () > from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 > #4 0x00007ffff6e274f1 in wxAppConsole::CheckBuildOptions(char const*, char > const*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 > #5 0x0000000000509289 in wxCreateApp () > at ../../gnuplot-5.0.4/src/wxterminal/wxt_gui.cpp:271 > #6 0x00007ffff6e56a61 in wxEntryStart(int&, wchar_t**) () > from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 > #7 0x00007ffff6e56cfc in wxInitialize(int, wchar_t**) () > from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 > #8 0x0000000000510901 in wxt_init () > at ../../gnuplot-5.0.4/src/wxterminal/wxt_gui.cpp:1792 > #9 0x00000000004f6942 in term_initialise () > at ../../gnuplot-5.0.4/src/term.c:501 > #10 0x0000000000452a28 in do_plot (plots=0x801c40, pcount=pcount@entry=1) > at ../../gnuplot-5.0.4/src/graphics.c:525 > #11 0x0000000000479120 in eval_plots () > at ../../gnuplot-5.0.4/src/plot2d.c:3367 > ---Type <return> to continue, or q <return> to quit--- > > > If I use this version of gnuplot for octave > >>> setenv GNUTERM wxt >>> graphics_toolkit gnuplot >>> plot (1:10) > > Fatal Error: Mismatch between the program and library build versions detected. > The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx > containers,compatible with 2.6), > and yo>> ur program used 2.8 (no debug,Unicode,compiler with C++ ABI > 1009,wx containers,compatible with 2.6). > > Seems to be mismatch of ABI of wx 2.8. > > I do not thing that this is a bug of gnuplot. But some new codes of gnuplot > trigger the faults on my system. > > Any suggestions? > > Tatsuro Sorry. Origin is not code change. I have back to the build tree where 5.0.3 is built. make install forces to recompile and built 5.0.3 hang in the same way. Perhaps on my ubuntu system something wrong with libwxgtk at some moment. MMMMMM I will try to build wxGTK by myself. Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2016-08-04 06:52:20
|
I have built gnuplot 5.0.4 or recent 5.1.0 on Ubunutu 14.04 amd64. The wxt terminals hangs. (On 5.0.3, wxt terminal works correctly.) G N U P L O T Version 5.0 patchlevel 4 last modified 2016-07-21 gnuplot> set term wxt Terminal type set to 'wxt' Options are '0 enhanced' gnuplot> pl x terminated (core dump) On recent 14.04, I have met the same hang. Running on gdb, gnuplot> pl x Program received signal SIGABRT, Aborted. 0x00007ffff3eecc37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff3eecc37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff3ef0028 in __GI_abort () at abort.c:89 #2 0x00007ffff6e61eda in wxVLogFatalError(wchar_t const*, __va_list_tag*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 #3 0x00007ffff6e61fac in wxLogFatalError(wchar_t const*, ...) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 #4 0x00007ffff6e274f1 in wxAppConsole::CheckBuildOptions(char const*, char const*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 #5 0x0000000000509289 in wxCreateApp () at ../../gnuplot-5.0.4/src/wxterminal/wxt_gui.cpp:271 #6 0x00007ffff6e56a61 in wxEntryStart(int&, wchar_t**) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 #7 0x00007ffff6e56cfc in wxInitialize(int, wchar_t**) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0 #8 0x0000000000510901 in wxt_init () at ../../gnuplot-5.0.4/src/wxterminal/wxt_gui.cpp:1792 #9 0x00000000004f6942 in term_initialise () at ../../gnuplot-5.0.4/src/term.c:501 #10 0x0000000000452a28 in do_plot (plots=0x801c40, pcount=pcount@entry=1) at ../../gnuplot-5.0.4/src/graphics.c:525 #11 0x0000000000479120 in eval_plots () at ../../gnuplot-5.0.4/src/plot2d.c:3367 ---Type <return> to continue, or q <return> to quit--- If I use this version of gnuplot for octave >> setenv GNUTERM wxt >> graphics_toolkit gnuplot >> plot (1:10) Fatal Error: Mismatch between the program and library build versions detected. The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6), and yo>> ur program used 2.8 (no debug,Unicode,compiler with C++ ABI 1009,wx containers,compatible with 2.6). Seems to be mismatch of ABI of wx 2.8. I do not thing that this is a bug of gnuplot. But some new codes of gnuplot trigger the faults on my system. Any suggestions? Tatsuro |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2016-08-02 16:38:22
|
Am 01.08.2016 um 10:12 schrieb Robert von Knobloch: > On 29/07/16 21:23, Hans-Bernhard Bröker wrote: >> In that case you'll have to decide on an x axis range beforehand, tell >> gnuplot about your choice, > I cannot fix the x-axis (it grows). I didn's say you have to fix it. But _someone_ has to decide what the common axis range for all those data sets is going to be. Since you defined the boundary conditions of the job such there's no way left for gnuplot to do it, that someone has to be you, or some program/script you write for the job. gnuplot can only do it across one plot's collection of data sets --- but you're dead set on having a multi-plot, so that's out. And there's no way gnuplot can guess what the data in the 5th plot in a mulit-plot will look like, to scale the first plot accordingly, so gnuplot doing it automatically for the multiplot is clearly out, too. So _you_ have to make the decision, before you issue the first plot command. How you arrive at the range to use is for you to figure out. The 'stat' command might help, if the data sets remain stable for at least as long as the entire command multiplot sequence takes. Or maybe the programs generating those files could put that knowledge somewhere for gnuplot to get at. You may have to make snapshot copies of the data files for the duration. |
|
From: Mojca M. <moj...@gm...> - 2016-08-02 15:45:49
|
On 22 July 2016 at 20:39, Tait wrote: > >> > I'm sorry for not having it tested earlier, but my compiler doesn't >> > seem to be happy. >> >> Proving once again that no change is too small to cause problems. >> I've uploaded an amended tarball that contains the other half of the >> aquaterm fix. > > It's history at this point, but there seems to be confusion and some > mild alarm about two gnuplot-5.0.4.tar.gz files floating around with > different SHA checksums. I imagine that for those who aren't aware > of this thread, the first assumption may be that the distribution > was compromised. If it happens again, it might be less confusing to > just say "oops" and bump the version (e.g. to 5.0.5 in this case). Indeed, this is a bit of a problem and it's generally not advised to quietly change the tarballs with the same name. I kept postponing an upgrade in MacPorts because I knew that people would end up with the wrong file even after it was already fixed (the mirrors still had the old file) and it would be difficult to get rid of that one. Then again, we got a bug report today from users who are unable to install the software. It seems that some mirrors still hold the old file: $ wget http://heanet.dl.sourceforge.net/project/gnuplot/gnuplot/5.0.4/gnuplot-5.0.4.tar.gz $ shasum -a 256 gnuplot-5.0.4.tar.gz 27897103153ec5c8efd517df9bbe690246aaaa9a59a2ce18eb88d08228ac7723 gnuplot-5.0.4.tar.gz $ wget http://vorboss.dl.sourceforge.net/project/gnuplot/gnuplot/5.0.4/gnuplot-5.0.4.tar.gz $ shasum -a 256 gnuplot-5.0.4.tar.gz 151cb845728bde75eb9d1561b35140114a05a7c52a52bd35b4b2b3d944e0c31e gnuplot-5.0.4.tar.gz Mojca |
|
From: Robert v. K. <bo...@en...> - 2016-08-01 08:13:30
|
On 29/07/16 21:23, Hans-Bernhard Bröker wrote: > In that case you'll have to decide on an x axis range beforehand, tell > gnuplot about your choice, fix the left and right margins, and then you > can use > > set multiplot layout 3, 1 > > But for plots with at most two incommensurable types of y data, a > single, multi-dataset plot with a secondary y axis will make better use > of the available plotting surface, and allow for a much clearer view of > correlations, and it'll be a whole lot easier to create. This is my problem. I cannot fix the x-axis (it grows). I have 5 or 6 different Y-data so a plot on one set of axes looks a real mess. Bob |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2016-07-29 19:23:49
|
Am 29.07.2016 um 09:12 schrieb Robert von Knobloch: > I _think_ that I _do_ want multiplot. Then gnuplot cannot figure out the shared axis range all by itself, like you said you wanted. It's a case of either having the cake, or eating it. The individual plots in a multiplot are done independently, so there's just no way for the x data range of later plots to have any influence on the x axis range of earlier ones, because by the time the second plot is made, the first one is completely done. No going back to make its x axis range match the latter ones. > I want the temperature plot to be framed in its own axes, just on the > same page (screen), with the same x-axis (date/time) as the other data. > My screen has then 3 (or more with each having different Y units) plots > with their own y axes, but with the same x scale and labels, one above > the other, so that it is easy to see correlations. In that case you'll have to decide on an x axis range beforehand, tell gnuplot about your choice, fix the left and right margins, and then you can use set multiplot layout 3, 1 But for plots with at most two incommensurable types of y data, a single, multi-dataset plot with a secondary y axis will make better use of the available plotting surface, and allow for a much clearer view of correlations, and it'll be a whole lot easier to create. |
|
From: Tait <gnu...@t4...> - 2016-07-22 19:05:31
|
> > I'm sorry for not having it tested earlier, but my compiler doesn't > > seem to be happy. > > Proving once again that no change is too small to cause problems. > I've uploaded an amended tarball that contains the other half of the > aquaterm fix. It's history at this point, but there seems to be confusion and some mild alarm about two gnuplot-5.0.4.tar.gz files floating around with different SHA checksums. I imagine that for those who aren't aware of this thread, the first assumption may be that the distribution was compromised. If it happens again, it might be less confusing to just say "oops" and bump the version (e.g. to 5.0.5 in this case). |
|
From: Tatsuro M. <tma...@ya...> - 2016-07-21 23:13:27
|
> From: sfeam > To: gnuplot-beta > Cc: > Date: 2016/7/21, Thu 14:24 > Subject: Release announcement: gnuplot version 5.0 patchlevel 4 > >T he source package and release notes for gnuplot 5.0.4 are now available for > download: > > https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.4/ > > The 5.0.4 source package contains only a single change from the testing packages > made available last week. This was a fix for slow pixel image rendering by > aquaterm, > relevant only to OSX. > > Happy gnuplotting, > > Ethan Merritt (sf...@us...) > on behalf of the gnuplot development team > I have uploaded windows binaries on the sourceforge site. I have a question. Why ChangeLog the below does not appear in 5.0.4 one? 2016-07-15 Bastian Maerkisch <bma...@we...> * src/win/wgdiplus.cpp (W_enhanced_text): Apply text color to enhanced text. Bug #1829 Tatsuro |
|
From: Mojca M. <moj...@gm...> - 2016-07-21 16:31:58
|
On 21 July 2016 at 17:57, sfeam wrote: > On Thursday, 21 July 2016 10:47:26 AM Mojca Miklavec wrote: >> Hi, >> >> On 21 July 2016 at 07:24, sfeam wrote: >> > The source package and release notes for gnuplot 5.0.4 are now available for download: >> > >> > https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.4/ >> > >> > The 5.0.4 source package contains only a single change from the testing packages >> > made available last week. This was a fix for slow pixel image rendering by aquaterm, >> > relevant only to OSX. >> >> I'm sorry for not having it tested earlier, but my compiler doesn't >> seem to be happy. > > Proving once again that no change is too small to cause problems. > I've uploaded an amended tarball that contains the other half of the > aquaterm fix. Thank you. It seems better now. Mojca |
|
From: sfeam <sf...@us...> - 2016-07-21 16:00:27
|
On Thursday, 21 July 2016 10:47:26 AM Mojca Miklavec wrote: > Hi, > > On 21 July 2016 at 07:24, sfeam wrote: > > The source package and release notes for gnuplot 5.0.4 are now available for download: > > > > https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.4/ > > > > The 5.0.4 source package contains only a single change from the testing packages > > made available last week. This was a fix for slow pixel image rendering by aquaterm, > > relevant only to OSX. > > I'm sorry for not having it tested earlier, but my compiler doesn't > seem to be happy. Proving once again that no change is too small to cause problems. I've uploaded an amended tarball that contains the other half of the aquaterm fix. Ethan > > > In file included from term.c:1348: > In file included from ./term.h:156: > ../term/aquaterm.trm:963:55: error: use of undeclared identifier > 'TERM_POLYGON_PIXELS' > TERM_CAN_MULTIPLOT|TERM_NO_OUTPUTFILE|TERM_CAN_DASH|TERM_POLYGON_PIXELS, > ^ > term.c:1359:19: error: invalid application of 'sizeof' to an > incomplete type 'struct TERMENTRY []' > int sort_idxs[TERMCOUNT]; > ^~~~~~~~~ > term.c:1352:26: note: expanded from macro 'TERMCOUNT' > #define TERMCOUNT (sizeof(term_tbl) / sizeof(term_tbl[0])) > ^~~~~~~~~~ > term.c:1362:21: error: invalid application of 'sizeof' to an > incomplete type 'struct TERMENTRY []' > for( i = 0; i < TERMCOUNT; i++ ) > ^~~~~~~~~ > term.c:1352:26: note: expanded from macro 'TERMCOUNT' > > Mojca > > ------------------------------------------------------------------------------ > 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 |
|
From: Mojca M. <moj...@gm...> - 2016-07-21 08:47:33
|
Hi, On 21 July 2016 at 07:24, sfeam wrote: > The source package and release notes for gnuplot 5.0.4 are now available for download: > > https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.4/ > > The 5.0.4 source package contains only a single change from the testing packages > made available last week. This was a fix for slow pixel image rendering by aquaterm, > relevant only to OSX. I'm sorry for not having it tested earlier, but my compiler doesn't seem to be happy. In file included from term.c:1348: In file included from ./term.h:156: ../term/aquaterm.trm:963:55: error: use of undeclared identifier 'TERM_POLYGON_PIXELS' TERM_CAN_MULTIPLOT|TERM_NO_OUTPUTFILE|TERM_CAN_DASH|TERM_POLYGON_PIXELS, ^ term.c:1359:19: error: invalid application of 'sizeof' to an incomplete type 'struct TERMENTRY []' int sort_idxs[TERMCOUNT]; ^~~~~~~~~ term.c:1352:26: note: expanded from macro 'TERMCOUNT' #define TERMCOUNT (sizeof(term_tbl) / sizeof(term_tbl[0])) ^~~~~~~~~~ term.c:1362:21: error: invalid application of 'sizeof' to an incomplete type 'struct TERMENTRY []' for( i = 0; i < TERMCOUNT; i++ ) ^~~~~~~~~ term.c:1352:26: note: expanded from macro 'TERMCOUNT' Mojca |
|
From: sfeam <sf...@us...> - 2016-07-21 05:25:03
|
The source package and release notes for gnuplot 5.0.4 are now available for download: https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.4/ The 5.0.4 source package contains only a single change from the testing packages made available last week. This was a fix for slow pixel image rendering by aquaterm, relevant only to OSX. Happy gnuplotting, Ethan Merritt (sf...@us...) on behalf of the gnuplot development team |
|
From: Per P. <per...@ma...> - 2016-07-20 20:48:04
|
(Away from computer, decade old code, etc., ...) IIRC, I hesitantly added the erase rect code since some demo(?) relied on "overprinting" to erase previously drawn stuff, or possibly edge effect occurring when drawing multiple layers under anti-aliasing. My guess is that taking out the call to erase rect is safe for 99.99% of the use cases. That said, building an image using individual "pixels" is never going to be fast with the aqua terminal since it will create an object graph of all individual items so that the can be manipulated "post drawing". For speed, a better strategy is to create a bitmap image in the driver an push that as a unit to aquaterm. (Think that's how it's done elsewhere in the driver for som other command?) Hope this helps, Per > 19 juli 2016 kl. 19:17 skrev Ethan A Merritt <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 |
|
From: Daniel J S. <dan...@ie...> - 2016-07-19 20:01:37
|
On 07/19/2016 12:36 PM, Daniel J Sebald wrote:
> For example, an N pixel image will take on the order
>
> SUM_{i=1}^N i * (i-1)
Make that
SUM_{i=1}^N (i-1) = (N-1) * N/2
so that's 1.342e8. Still a large number.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2016-07-19 17:36:34
|
On 07/19/2016 08:18 AM, Jun T. wrote: >> 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. OK, I think you've found the CPU drain. Erasing the rectangles is probably second order growth because for each rectangle drawn, the AQUA driver probably goes through the whole list of elements to see if there is overlap. I conclude that from this comment in the aquaterm code: https://sourceforge.net/p/aquaterm/mailman/aquaterm-commit/?viewmonth=200308 /*" Add a filled rectangle. Should normally be preceeded with #eraseRect: to remove any objects that will be covered by aRect."*/ For example, an N pixel image will take on the order SUM_{i=1}^N i * (i-1) For small N this probably isn't too bad, but for N = 128*128 = 16384 this probably gets to be a huge number, actually 1.4660e+12, evaluating the sum via loop in Octave. So there is probably a lot of comparison code that needs to be run that many times (and most of the time in this case it isn't doing anything). I think that eraseRect can be removed. We generally don't use this approach in other terminals, but instead just allow things to overlap and let the terminal's renderer deal with what is visible for a given output pixel and what is not. In the case of an image using rectangles for pixels, we at least know that individual pixels don't overlap. Of course, that doesn't account for anything else that has already been drawn from some other plot feature or will be drawn after, but if we want to use such an approach, gnuplot can probably do a more optimum job of it because of apriori knowledge concerning depth ordering in hidden line removal and so on. Interestingly, Qt has a similar type of routine, QPainter::eraseRect, but it approaches things slightly different. It simply draws a filled rectangle using the background color. That's not as computationally demanding. There is one other erase in aquaterm, but it is in the initialization routine AQUA_graphics(). That should stay because its role is to simply clear the whole screen of any drawing elements. Ethan can think this one over and make the change for you if it seems innocuous enough. Dan |
28 messages has been excluded from this view by a project administrator.
