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

"noreverse" is listed as option to xrange when it is no longer interpreted

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

I notice that even though "reverse/noreverse" has been deprecated, the 
option setting "noreverse" appears in the list, i.e.:

Terminal type set to 'qt'
gnuplot> show xrange

	set xrange [ * : * ] noreverse nowriteback  # (currently 
[-10.0000:10.0000] )

Might it be better to leave out the "noreverse" value?  It would be a 
good "feature check" if the "noreverse" were no longer printed.

Of course, now that some versions have been released that do print 
"noreverse", that sort of destroys the integrity of such a feature check.

However, even this is problematic:

gnuplot> set xrange [0:1] reverse
gnuplot> show xrange

	set xrange [ 0.00000 : 1.00000 ] reverse nowriteback

gnuplot> plot x

The "show" function is indicating xrange is reversed when clearly it 
isn't.  So one can't rely on a set/show combination to determine if 
reverse/noreverse is an acceptable syntax.

Well, don't use "reverse" keyword is the lesson, but gnuplot still 
keeping track of reverse/noreverse and showing the option seems superfluous.

Dan

Re: Peculiarities in demo plots

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

On Saturday, 16 May 2015 11:43:48 PM Daniel J Sebald wrote:
> On 04/20/2015 02:00 AM, Daniel J Sebald wrote:
> 
> > In other words, the QGraphicsItem class might be similar to the failsafe
> > mode of x11, as far as its operation is concerned--I'm assuming failsafe
> > is where an image is created by drawing squares on the canvas.
> >
> > For that example, if I turn on failsafe mode, i.e.,
> >
> > plot $DATA with image failsafe
> >
> > that example with "NaN should appear as background" and "Negative values
> > become NaN with a log-scale color mapping" looks similar in x11 and Qt
> > terminals. In fact, shrinking down the image I can see in both cases
> > that "NaN should appear as background" is actually in front of the
> > pixmap while "Negative values become NaN with a log-scale color mapping".
> >
> > I'm fine with the demo, but now that I understand it I don't see the
> > terminal type as being highly responsible for the feature. (Partial
> > transparency is a different issue. That's something more significant.
> > Could probably do alpha-blending in X11, but I don't think anyone wants
> > to tackle that.) The "failsafe" option is somewhat vague. Given what I
> > suspect about the image being actually drawn with individual rectangles
> > (something that "image" defaults to when cast into a 3D
> > non-perpendicular view), it might have been nicer to force this mode
> > with a different type, say "pixmap" as opposed to "image".
> 
> Has anyone put more thought into this failsafe option?  I don't think it 
> is urgent to change, but I do think in the long run the failsafe option 
> would be better as its own plot type, e.g., pixmap.  It's more 
> distinctive that way. 

I may be overly influenced by knowing what's underneath the hood,
but I don't see it that way.  The original failsafe option was purely
an internal accommodation for terminals that didn't support 
term->image().  The core code for drawing images could test for whether
the terminal had dedicated support, and if not it could fall back to 
the failsafe mode.   It turned out that for certain purposes it
was useful to force that same pixel-by-pixel mode on demand even for
terminals that do support term->image().  For instance svg applies
color-smoothing to images, so if you want a clean heatmap it is better
to use "with image pixels".

   http://gnuplot.sourceforge.net/demo_svg_5.0/heatmaps.html

The NaN business is just a distraction.  It is nice to have some
well-defined behaviour in the presence of NaN, but that depends
on what is possible to support in each terminal's term->image() 
code.  The failsafe code is terminal-independent, so it is easier
to be consistent.   But this is was never driving creation of
the failsafe/fallback/pixels mode, and indeed was only added
later.

	Ethan

> In other words, pixmap and image would have the 
> same underlying construction but the difference would be that "pixmap" 
> is assured to be pixel-based in the sense that NAN can remove the 
> pixels.  "image" would only be pixel based in the case there is no 
> support for images (2D/3D) in the terminal.  The point is to attempt to 
> use more efficient image capabilities when possible with "image".
> 
> Making failsafe (i.e., pixmap) a type would also mean an additional 
> option variable isn't needed.  Also, more significantly, if hidden 
> surfaces ever arise there is a big distinction between treating an image 
> as pixels and as a whole image.  Individual pixels treated as simple 
> polygons falls naturally into the hidden surface routine, whereas a 
> whole image doesn't.  Depth order would be the only thing for obscuring 
> the hidden portion of a whole image.
> 
> Dan

Re: Peculiarities in demo plots

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

On 04/20/2015 02:00 AM, Daniel J Sebald wrote:

> In other words, the QGraphicsItem class might be similar to the failsafe
> mode of x11, as far as its operation is concerned--I'm assuming failsafe
> is where an image is created by drawing squares on the canvas.
>
> For that example, if I turn on failsafe mode, i.e.,
>
> plot $DATA with image failsafe
>
> that example with "NaN should appear as background" and "Negative values
> become NaN with a log-scale color mapping" looks similar in x11 and Qt
> terminals. In fact, shrinking down the image I can see in both cases
> that "NaN should appear as background" is actually in front of the
> pixmap while "Negative values become NaN with a log-scale color mapping".
>
> I'm fine with the demo, but now that I understand it I don't see the
> terminal type as being highly responsible for the feature. (Partial
> transparency is a different issue. That's something more significant.
> Could probably do alpha-blending in X11, but I don't think anyone wants
> to tackle that.) The "failsafe" option is somewhat vague. Given what I
> suspect about the image being actually drawn with individual rectangles
> (something that "image" defaults to when cast into a 3D
> non-perpendicular view), it might have been nicer to force this mode
> with a different type, say "pixmap" as opposed to "image".

Has anyone put more thought into this failsafe option?  I don't think it 
is urgent to change, but I do think in the long run the failsafe option 
would be better as its own plot type, e.g., pixmap.  It's more 
distinctive that way.  In other words, pixmap and image would have the 
same underlying construction but the difference would be that "pixmap" 
is assured to be pixel-based in the sense that NAN can remove the 
pixels.  "image" would only be pixel based in the case there is no 
support for images (2D/3D) in the terminal.  The point is to attempt to 
use more efficient image capabilities when possible with "image".

Making failsafe (i.e., pixmap) a type would also mean an additional 
option variable isn't needed.  Also, more significantly, if hidden 
surfaces ever arise there is a big distinction between treating an image 
as pixels and as a whole image.  Individual pixels treated as simple 
polygons falls naturally into the hidden surface routine, whereas a 
whole image doesn't.  Depth order would be the only thing for obscuring 
the hidden portion of a whole image.

Dan

"pause" and "print" command for windows version revised for character encoding

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

Hello

A feature request:
Improve utf-8 treatment in interactive session on gnuplot for windows

http://sourceforge.net/p/gnuplot/feature-requests/415/


In response to the above request, Shigeharu Takeno the made a patch to realize it.
Although the patch  is written for many encodings but it has been tested only for the utf8 encoded Japanese characters.

The patch was applied to the cvs (5.0 and 5.1) tree very recently and the windows binaries used the patch can be available from:
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/


If you are interested, please test on your own environments and report the results on
http://sourceforge.net/p/gnuplot/feature-requests/415/


Regards

Tatsuro

question of copyright

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

Hello

I would like to distribute the cvs release with patch in reply to the feature request 415.

https://sourceforge.net/p/gnuplot/feature-requests/415/


Copyright says:

 *   1. distribute the corresponding source modifications from the
 *    released version in the form of a patch file along with the binaries,
 *   2. add special version identification to distinguish your version
 *    in addition to the base release version number,
 *   3. provide your name and address as the primary contact for the
 *    support of your modified version, and
 *   4. retain our contact information in regard to use of the base
 *    software.
 * Permission to distribute the released version of the source code along
 * with corresponding source modifications in the form of a patch file is
 * granted with same provisions 2 through 4 for binary distributions.
 
1. Is the patch should be included in an installer or a zip archive?
 Can I provide the patch in the distribution page?

2. is OK

3. Does "provide your name and address as the primary contact for the support of your modified version,"
 means that information should be addressed startup screen ?
 Is not enough to show contact information on the distribution site? 

4. is OK

Tatsuro

Re: CVS update and the compile file

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

Am 07.05.2015 um 19:38 schrieb Daniel J Sebald:
> Whenever I do an update I see:
>
> cvs update: move away ./compile; it is in the way
> C compile
>
> The contents of compile looks as though it is a file maintained by
> autotools.  Is 'compile' a file that should be in the list inside
> .cvsignore?

Absolutely not.  compile is to be _controlled_ by CVS, not to be ignored 
by it.  Odds are you have something else named "compile" sitting in its 
place; possibly a symlink to a local automake installation's master copy 
of the file.

Just do what CVS suggested: move it away!  Then cvs update to get the 
proper working file.

CVS update and the compile file

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

Whenever I do an update I see:

cvs update: move away ./compile; it is in the way
C compile

The contents of compile looks as though it is a file maintained by 
autotools.  Is 'compile' a file that should be in the list inside 
.cvsignore?

Dan

Re: Re: Cygwin build fails at in compling wxt_gui.cpp

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

--- Hans-Bernhard Bröker  wrote:
> Am 5.2015 um 19:20 schrieb sfeam:
> 
> > The call to select() is inside a block marked #ifdef WXT_MULTITHREADED
> > Maybe the new cygwin version now supports multithreading but the older
> > one did not?
> 
> Unlikely.  The key problem is that the code has completely failed to 
> #include the necessary header for select().  It was only included 
> indirectly, by sheer happenstance.  That's a bona fide bug, which just 
> happened not to trigger until now.  Now, after a change to the header 
> files of cygwin, it does.
> 
> I've checked in an improved fix already.
> 
> 
> 
I confirmed the fix.

Thanks.

Tatsuro

Re: Cygwin build fails at in compling wxt_gui.cpp

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

Am 03.05.2015 um 19:20 schrieb sfeam:

> The call to select() is inside a block marked #ifdef WXT_MULTITHREADED
> Maybe the new cygwin version now supports multithreading but the older
> one did not?

Unlikely.  The key problem is that the code has completely failed to 
#include the necessary header for select().  It was only included 
indirectly, by sheer happenstance.  That's a bona fide bug, which just 
happened not to trigger until now.  Now, after a change to the header 
files of cygwin, it does.

I've checked in an improved fix already.

Re: Cygwin build fails at in compling wxt_gui.cpp

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

On Sunday, 03 May 2015 08:02:17 AM Tatsuro MATSUOKA wrote:
> ----- Original Message -----
> 
> > From: Tatsuro MATSUOKA 
> > To: tmacchant3; gnuplot-beta
> > Cc: 
> > Date: 2015/5/3, Sun 07:39
> > Subject: Re: Cygwin build fails at in compling wxt_gui.cpp
> > 
> > ----- Original Message -----
> > 
> >>  From: Tatsuro MATSUOKA
> >>  To: gnuplot-beta
> >>  Cc: 
> >>  Date: 2015/5/3, Sun 07:35
> >>  Subject: Cygwin build fails at in compling wxt_gui.cpp
> >> 
> >>  Hello
> >> 
> >>  The cygwin version was bumped up to  ver. 2.0.0 recently.
> >>>  From the version up, the build of gnuplot on cygwin (32 and 64 bit) 
> > fails 
> >>  at compiling  wxt_gui.cpp
> >> 
> >>  ../../gnuplot/src/wxterminal/wxt_gui.cpp: In function 'int 
> >>  wxt_waitforinput(int)':
> >>  ../../gnuplot/src/wxterminal/wxt_gui.cpp:3710:20: error: 'select' 
> > was 
> >>  not declared in this scope
> >>              timeout );
> >> 
> >>  Any suggestions?
> > 
> > 
> > I forgot to mention what source was used.
> > The source used is cvs version (ChangeLog 2015-05-02.)
> > 
> 
> 
> 
> The patch below
> 
> #*******************************
> --- wxt_gui.orig.h      2014-12-27 08:21:48.000000000 +0900
> +++ wxt_gui.h   2015-05-03 07:53:12.766815500 +0900
> @@ -201,6 +201,12 @@
>   * only needed here when using WXGTK
>   * (or at least not needed on Windows) */
>  # include <signal.h>
> +/* cygwin*/
> +/* According to POSIX.1-2001 */
> +#ifdef __CYGWIN__
> +#include <sys/select.h>
> +#endif
> +
>  }
> #***********************************
> 
> makes the compiling successful.
> However, select function is used in other places in the gnuplot code.
> I cannot figure out why the above is required for the current cygwin + wxwidgtes 2.8.
> 
> Tatsuro 

The call to select() is inside a block marked #ifdef WXT_MULTITHREADED
Maybe the new cygwin version now supports multithreading but the older
one did not?

Does the patch fix it also?  It seems to me that other platforms in 
addition to cygwin also may want this change.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff -urp gnuplot/src/wxterminal/wxt_gui.h gnuplot-cvs/src/wxterminal/wxt_gui.h
--- gnuplot/src/wxterminal/wxt_gui.h    2014-12-26 15:21:48.000000000 -0800
+++ gnuplot-cvs/src/wxterminal/wxt_gui.h        2015-05-03 10:17:01.984135939 -0700
@@ -201,6 +201,12 @@ extern "C" {
  * only needed here when using WXGTK
  * (or at least not needed on Windows) */
 # include <signal.h>
+
+/* Needed for cygwin v2.0.0 and maybe others */
+#if defined(HAVE_SYS_SELECT_H) && defined(WXT_MULTITHREADED)
+#include <sys/select.h>
+#endif
+
 }
 
 /* interaction with wxt.trm(wxt_options) : plot number, enhanced state.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


	Ethan

Re: Cygwin build fails at in compling wxt_gui.cpp

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

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

> From: Tatsuro MATSUOKA 
> To: tmacchant3; gnuplot-beta
> Cc: 
> Date: 2015/5/3, Sun 07:39
> Subject: Re: Cygwin build fails at in compling wxt_gui.cpp
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA
>>  To: gnuplot-beta
>>  Cc: 
>>  Date: 2015/5/3, Sun 07:35
>>  Subject: Cygwin build fails at in compling wxt_gui.cpp
>> 
>>  Hello
>> 
>>  The cygwin version was bumped up to  ver. 2.0.0 recently.
>>>  From the version up, the build of gnuplot on cygwin (32 and 64 bit) 
> fails 
>>  at compiling  wxt_gui.cpp
>> 
>>  ../../gnuplot/src/wxterminal/wxt_gui.cpp: In function 'int 
>>  wxt_waitforinput(int)':
>>  ../../gnuplot/src/wxterminal/wxt_gui.cpp:3710:20: error: 'select' 
> was 
>>  not declared in this scope
>>              timeout );
>> 
>>  Any suggestions?
> 
> 
> I forgot to mention what source was used.
> The source used is cvs version (ChangeLog 2015-05-02.)
> 



The patch below

#*******************************
--- wxt_gui.orig.h      2014-12-27 08:21:48.000000000 +0900
+++ wxt_gui.h   2015-05-03 07:53:12.766815500 +0900
@@ -201,6 +201,12 @@
  * only needed here when using WXGTK
  * (or at least not needed on Windows) */
 # include <signal.h>
+/* cygwin*/
+/* According to POSIX.1-2001 */
+#ifdef __CYGWIN__
+#include <sys/select.h>
+#endif
+
 }
#***********************************

makes the compiling successful.
However, select function is used in other places in the gnuplot code.
I cannot figure out why the above is required for the current cygwin + wxwidgtes 2.8.

Tatsuro 

Re: Cygwin build fails at in compling wxt_gui.cpp

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

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

> From: Tatsuro MATSUOKA
> To: gnuplot-beta
> Cc: 
> Date: 2015/5/3, Sun 07:35
> Subject: Cygwin build fails at in compling wxt_gui.cpp
> 
> Hello
> 
> The cygwin version was bumped up to  ver. 2.0.0 recently.
>> From the version up, the build of gnuplot on cygwin (32 and 64 bit) fails 
> at compiling  wxt_gui.cpp
> 
> ../../gnuplot/src/wxterminal/wxt_gui.cpp: In function 'int 
> wxt_waitforinput(int)':
> ../../gnuplot/src/wxterminal/wxt_gui.cpp:3710:20: error: 'select' was 
> not declared in this scope
>             timeout );
> 
> Any suggestions?


I forgot to mention what source was used.
The source used is cvs version (ChangeLog 2015-05-02.)

Tatsuro

Cygwin build fails at in compling wxt_gui.cpp

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

Hello

The cygwin version was bumped up to  ver. 2.0.0 recently.
From the version up, the build of gnuplot on cygwin (32 and 64 bit) fails 
at compiling  wxt_gui.cpp

../../gnuplot/src/wxterminal/wxt_gui.cpp: In function 'int wxt_waitforinput(int)':
../../gnuplot/src/wxterminal/wxt_gui.cpp:3710:20: error: 'select' was not declared in this scope
            timeout );

Any suggestions?

Tatsuro


Full log
**************************************
depbase=`echo wxterminal/wxt_gui.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
c++ -DHAVE_CONFIG_H -I. -I../../gnuplot/src -I..  -I../term -I../../gnuplot/term -DBINDIR=\"/opt/gp510/bin\" -DX11_DRIVER_DIR=\"/opt/gp510/libexec/gnuplot/5.1\" -DQT_DRIVER_DIR=\"/opt/gp510/libexec/gnuplot/5.1\" -DGNUPLOT_SHARE_DIR=\"/opt/gp510/share/gnuplot/5.1\" -DGNUPLOT_PS_DIR=\"/opt/gp510/share/gnuplot/5.1/PostScript\" -DGNUPLOT_JS_DIR=\"/opt/gp510/share/gnuplot/5.1/js\" -DGNUPLOT_LUA_DIR=\"/opt/gp510/share/gnuplot/5.1/lua\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/opt/gp510/share/gnuplot/5.1/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`.exe\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\"  -I/usr/local/include  -I/usr/include  -D_REENTRANT -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2
 -I/usr/include/libpng16  -D_REENTRANT -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -g -O2 -I/usr/local/lib/wx/include/gtk2-ansi-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DWXUSINGDLL -D__WXGTK__  -D_REENTRANT -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16  -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo
 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16  -MT wxterminal/wxt_gui.o -MD -MP -MF $depbase.Tpo -c -o wxterminal/wxt_gui.o ../../gnuplot/src/wxterminal/wxt_gui.cpp &&\
mv -f $depbase.Tpo $depbase.Po
In file included from /usr/local/include/wx-2.8/wx/wx.h:18:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/list.h:506:35: warning: type attributes ignored after type is already defined [-Wattributes]
 friend class WXDLLIMPEXP_FWD_BASE wxNodeBase; // should be able to call DetachNode()
                                   ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:19:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/hash.h:117:40: warning: attributes ignored on elaborated-type-specifier that is not a forward declaration [-Wattributes]
     typedef class WXDLLIMPEXP_FWD_BASE wxHashTableBase_Node _Node;
                                        ^
/usr/local/include/wx-2.8/wx/hash.h:157:39: warning: type attributes ignored after type is already defined [-Wattributes]
     friend class WXDLLIMPEXP_FWD_BASE wxHashTableBase_Node;
                                       ^
In file included from /usr/local/include/wx-2.8/wx/event.h:21:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:25,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/gdicmn.h:39:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxString;
                            ^
In file included from /usr/local/include/wx-2.8/wx/cursor.h:41:0,
                 from /usr/local/include/wx-2.8/wx/event.h:22,
                 from /usr/local/include/wx-2.8/wx/wx.h:25,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/utils.h:26:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxArrayString;
                            ^
/usr/local/include/wx-2.8/wx/utils.h:27:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxArrayInt;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:25:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/event.h:33:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxList;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:26:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/app.h:28:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxLog;
                            ^
/usr/local/include/wx-2.8/wx/app.h:29:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxMessageOutput;
                            ^
In file included from /usr/local/include/wx-2.8/wx/app.h:570:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:26,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/gtk/app.h:18:24: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_BASE wxLog;
                        ^
In file included from /usr/local/include/wx-2.8/wx/window.h:24:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:36,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/font.h:30:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxSize;
                            ^
In file included from /usr/local/include/wx-2.8/wx/window.h:26:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:36,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/region.h:19:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxColour;
                            ^
In file included from /usr/local/include/wx-2.8/wx/window.h:37:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:36,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/accel.h:23:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxKeyEvent;
                            ^
In file included from /usr/local/include/wx-2.8/wx/gtk/accel.h:15:0,
                 from /usr/local/include/wx-2.8/wx/accel.h:154,
                 from /usr/local/include/wx-2.8/wx/window.h:37,
                 from /usr/local/include/wx-2.8/wx/wx.h:36,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/generic/accel.h:13:19: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLEXPORT wxKeyEvent;
                   ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:36:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/window.h:58:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxCursor;
                            ^
/usr/local/include/wx-2.8/wx/window.h:1424:40: warning: attributes ignored on elaborated-type-specifier that is not a forward declaration [-Wattributes]
     static struct WXDLLIMPEXP_FWD_CORE wxWindowNext *ms_winCaptureNext;
                                        ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:37:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/containr.h:16:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxFocusEvent;
                            ^
/usr/local/include/wx-2.8/wx/containr.h:17:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxNavigationKeyEvent;
                            ^
/usr/local/include/wx-2.8/wx/containr.h:18:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxWindow;
                            ^
/usr/local/include/wx-2.8/wx/containr.h:19:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxWindowBase;
                            ^
In file included from /usr/local/include/wx-2.8/wx/panel.h:15:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:38,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/generic/panelg.h:22:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxControlContainer;
                            ^
In file included from /usr/local/include/wx-2.8/wx/toplevel.h:22:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:39,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/iconbndl.h:20:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxString;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:44:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/bitmap.h:28:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxPalette;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:45:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/image.h:66:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxPalette;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:45:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/image.h:426:39: warning: type attributes ignored after type is already defined [-Wattributes]
     friend class WXDLLIMPEXP_FWD_CORE wxImageHandler;
                                       ^
In file included from /usr/local/include/wx-2.8/wx/brush.h:38:0,
                 from /usr/local/include/wx-2.8/wx/dc.h:26,
                 from /usr/local/include/wx-2.8/wx/wx.h:48,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/gtk/brush.h:13:24: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_CORE wxBitmap;
                        ^
/usr/local/include/wx-2.8/wx/gtk/brush.h:14:24: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_CORE wxColour;
                        ^
In file included from /usr/local/include/wx-2.8/wx/dcclient.h:24:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:49,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/gtk/dcclient.h:16:24: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_CORE wxWindow;
                        ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:53:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/button.h:48:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxBitmap;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:54:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/menuitem.h:29:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxAcceleratorEntry;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:55:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/menu.h:33:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxMenuItem;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:63:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/settings.h:18:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxWindow;
                            ^
In file included from /usr/local/include/wx-2.8/wx/checklst.h:17:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:72,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/listbox.h:26:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxArrayInt;
                            ^
/usr/local/include/wx-2.8/wx/listbox.h:27:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxArrayString;
                            ^
In file included from /usr/local/include/wx-2.8/wx/choice.h:75:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:73,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/gtk/choice.h:13:24: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_BASE wxSortedArrayString;
                        ^
/usr/local/include/wx-2.8/wx/gtk/choice.h:14:24: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_BASE wxArrayString;
                        ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:84:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/scrolwin.h:18:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxTimer;
                            ^
In file included from /usr/local/include/wx-2.8/wx/gtk/dirdlg.h:13:0,
                 from /usr/local/include/wx-2.8/wx/dirdlg.h:110,
                 from /usr/local/include/wx-2.8/wx/wx.h:85,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/generic/dirdlgg.h:19:19: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLEXPORT wxTextCtrl;
                   ^
In file included from /usr/local/include/wx-2.8/wx/toolbar.h:67:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:86,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/tbarbase.h:29:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxImage;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:88:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/layout.h:35:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxWindowBase;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:89:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/sizer.h:23:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxButton;
                            ^
/usr/local/include/wx-2.8/wx/sizer.h:788:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxStaticBox;
                            ^
In file included from /usr/local/include/wx-2.8/wx/choicdlg.h:17:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:92,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/generic/choicdgg.h:18:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxListBoxBase;
                            ^
In file included from /usr/local/include/wx-2.8/wx/textdlg.h:15:0,
                 from /usr/local/include/wx-2.8/wx/wx.h:93,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/generic/textdlgg.h:25:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxTextCtrl;
                            ^
In file included from /usr/local/include/wx-2.8/wx/gtk/filedlg.h:13:0,
                 from /usr/local/include/wx-2.8/wx/filedlg.h:210,
                 from /usr/local/include/wx-2.8/wx/wx.h:94,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/generic/filedlgg.h:24:19: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLEXPORT wxBitmapButton;
                   ^
/usr/local/include/wx-2.8/wx/generic/filedlgg.h:25:19: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLEXPORT wxCheckBox;
                   ^
/usr/local/include/wx-2.8/wx/generic/filedlgg.h:26:19: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLEXPORT wxChoice;
                   ^
/usr/local/include/wx-2.8/wx/generic/filedlgg.h:30:19: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLEXPORT wxListEvent;
                   ^
/usr/local/include/wx-2.8/wx/generic/filedlgg.h:31:19: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLEXPORT wxListItem;
                   ^
/usr/local/include/wx-2.8/wx/generic/filedlgg.h:32:19: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLEXPORT wxStaticText;
                   ^
/usr/local/include/wx-2.8/wx/generic/filedlgg.h:33:19: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLEXPORT wxTextCtrl;
                   ^
In file included from ../../gnuplot/src/wxterminal/wxt_gui.h:82:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/clipbrd.h:23:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxDataFormat;
                            ^
/usr/local/include/wx-2.8/wx/clipbrd.h:24:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_CORE wxDataObject;
                            ^
In file included from /usr/local/include/wx-2.8/wx/config.h:15:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:97,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/confbase.h:20:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxArrayString;
                            ^
In file included from /usr/local/include/wx-2.8/wx/config.h:28:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:97,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
/usr/local/include/wx-2.8/wx/fileconf.h:97:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxInputStream;
                            ^
/usr/local/include/wx-2.8/wx/fileconf.h:98:28: warning: type attributes ignored after type is already defined [-Wattributes]
 class WXDLLIMPEXP_FWD_BASE wxOutputStream;
                            ^
In file included from /usr/local/include/wx-2.8/wx/wx.h:25:0,
                 from ../../gnuplot/src/wxterminal/wxt_gui.h:77,
                 from ../../gnuplot/src/wxterminal/wxt_gui.cpp:97:
../../gnuplot/src/wxterminal/wxt_gui.h:241:19: warning: 'wxExitLoopEvent' redeclared without dllimport attribute after being referenced with dll linkage
 DEFINE_EVENT_TYPE(wxExitLoopEvent)
                   ^
/usr/local/include/wx-2.8/wx/event.h:106:51: note: in definition of macro 'DEFINE_EVENT_TYPE'
 #define DEFINE_EVENT_TYPE(name) const wxEventType name = wxNewEventType();
                                                   ^
../../gnuplot/src/wxterminal/wxt_gui.h:244:19: warning: 'wxCreateWindowEvent' redeclared without dllimport attribute after being referenced with dll linkage
 DEFINE_EVENT_TYPE(wxCreateWindowEvent)
                   ^
/usr/local/include/wx-2.8/wx/event.h:106:51: note: in definition of macro 'DEFINE_EVENT_TYPE'
 #define DEFINE_EVENT_TYPE(name) const wxEventType name = wxNewEventType();
                                                   ^
../../gnuplot/src/wxterminal/wxt_gui.h:248:19: warning: 'wxStatusTextEvent' redeclared without dllimport attribute after being referenced with dll linkage
 DEFINE_EVENT_TYPE(wxStatusTextEvent)
                   ^
/usr/local/include/wx-2.8/wx/event.h:106:51: note: in definition of macro 'DEFINE_EVENT_TYPE'
 #define DEFINE_EVENT_TYPE(name) const wxEventType name = wxNewEventType();
                                                   ^
../../gnuplot/src/wxterminal/wxt_gui.cpp: In function 'int wxt_waitforinput(int)':
../../gnuplot/src/wxterminal/wxt_gui.cpp:3710:20: error: 'select' was not declared in this scope
            timeout );
                    ^
Makefile:912: recipe for target 'wxterminal/wxt_gui.o' failed
make[4]: *** [wxterminal/wxt_gui.o] Error 1
make[4]: Leaving directory '/cygdrive/e/usr/Tatsu/cyg64work/gnuplotcvs/build-release/src'
Makefile:955: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/cygdrive/e/usr/Tatsu/cyg64work/gnuplotcvs/build-release/src'
Makefile:630: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/cygdrive/e/usr/Tatsu/cyg64work/gnuplotcvs/build-release/src'
Makefile:417: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/cygdrive/e/usr/Tatsu/cyg64work/gnuplotcvs/build-release'
Makefile:355: recipe for target 'all' failed
make: *** [all] Error 2

Re: Are gnuplot 4.6.7 windows binaries required?

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

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

> From: Tatsuro MATSUOKA 
> To: gnuplot-beta
> Cc: 
> Date: 2015/4/29, Wed 18:31
> Subject: Are gnuplot 4.6.7 windows binaries required?
> 
> I found that gnuplot 4.6.7 was uploaded.
> http://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.7/
> 
> 
> According the page above,
> 
> ***************************************************************
> Version 4.6.7 is intended as a source-only release of interest 
> only to those who for whatever reason choose to continue using 
> the 4.6 series rather than moving to version 5.
> ***************************************************************
> 
> However, most windows users will not be able to build binaries 
> of them. I can provide the binaries if windows users would like 
> to get them.
> 
> If the main developers does not hope the binary release for 
> windows, I personally use it for the octave purpose.
> (The current octave does not support gnuplot ver.5).
> 
> Any suggestions are appreciated.
> 
> Tatsuro


I built 4.6.7 windows binaries (32 and 64 bit) in installer and zip styles.
And I installed them to my PC and confirmed they work.

I will be able to upload them to my web site.
But I will not want to it unless affirmative response will appear.

Tatsuro

Are gnuplot 4.6.7 windows binaries required?

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

I found that gnuplot 4.6.7 was uploaded.
http://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.7/


According the page above,

***************************************************************
Version 4.6.7 is intended as a source-only release of interest 
only to those who for whatever reason choose to continue using 
the 4.6 series rather than moving to version 5.
***************************************************************

However, most windows users will not be able to build binaries 
of them. I can provide the binaries if windows users would like 
to get them.

If the main developers does not hope the binary release for 
windows, I personally use it for the octave purpose.
(The current octave does not support gnuplot ver.5).

Any suggestions are appreciated.

Tatsuro

Typo in dynarray.c error message

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

Simple typo attached...

Dan

Re: Peculiarities in demo plots

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

On Sunday, 19 April, 2015 23:08:17 Daniel J Sebald wrote:
> I stepped through the demos to see what is new and test whether a change 
> I made affected anything.  Below is a list of items that seem like 
> bugs/flaws compared to what I recall of the demos from years ago.  I 
> haven't investigated any of these issues.  Should we break these up into 
> bug reports somehow?
> 
> Dan
> 
> 
> random.dem:
>    (Clarification, this is only for Qt, x11 looks as I remember)
>    Lattice test for random numbers: blank (or points are single pixel 
> which I can't see amongst the dust on my monitor)
>    Lattice test for random numbers: blank
>    Gaussian 3D cloud of 3000 random samples: blank

Yeah the default size of "dots" is pretty small.

> scatter.dem:
> Hit return to continue (5)
>           "scatter.dem", line 45: warning: Cannot contour non grid data. 
> Please use "set dgrid3d".

I thought this was intentional?  Not sure.

> pm3d.dem:
>    (Let me clarify the following: all of these cases are for the Qt 
> terminal,
>     the x11 terminal has the file name front-most in the plot)
>    Datafile with different nb of points in scans; pm3d flush begin: file 
> name is behind the plot element (reads 'gle.dat')
>    Datafile with different nb of points in scans; pm3d flush center: 
> file name is behind the plot element (reads 'dat')
>    Datafile with different nb of points in scans; pm3d flush scans: file 
> name is obscured by the plot element
>    Datafile with different nb of points in scans; pm3d ftriangles flush 
> begin: file name is obscured by the plot element
>    Datafile with different nb of points in scans; pm3d ftriangles flush 
> center: file name is obscured by the plot element
>    Datafile with different nb of points in scans; pm3d ftriangles flush 
> end: file name is obscured by the plot element
>    Using interpolate with datafile; pm3d map interpolate 2,1: file name 
> is behind the plot element (reads 'gle.dat')
>    Using interpolate with datafile; pm3d map ftriangles interpolate 
> 10,1: name is obscured by the plot element

That has always been the documented behaviour.
The default is to draw the key first, which means it can be obscured by
the plot elements.  Version 4.something introduced an option "set key opaque"
that redraws the key legends on top of the plot elements after blanking out
the key box.


>    color lines: 'splot sin(y)/(y) with lines palette': The color bar 
> text goes off the window screen.  I see that quite often and don't 
> recall this from years back...maybe font is bigger

Not for me, but as you say it may depend on the font size.


> heatmaps.dem
>    Heat Map generated from a file containing Z values only: blank, color 
> bar correct (this is only for Qt terminal, x11 looks good)
>    Compare 'image' and 'image pixels' mode: On my system, there are 
> white spaces between pixels (this is only for Qt terminal, x11 looks 
> good, I think I've encountered this before as a graphics driver 
> implementation of OpenGL (Mesa) issue)

The artifactual introduction of white lines between fill areas has
been a recurring problem for many of the terminals.  It was, for example,
a known problem with ghostscript - so any of the terminal output viewed
in a ghostscript-based viewer would suffer from this.   The artifact
did not appear when the same file was printed or inspected in a different
viewer.  The artifact in Qt is obviously not due to ghostscript bugs, but
it's probably the same sort of thing.     

> 
> hypertext.dem
>    Sweet!
>    While the Qt terminal has yellow filled circle with slightly darker 
> yellow/brown outline, the x11 terminal has yellow filled circles with 
> black outline and a black dot at the center of each circle (not the best 
> looking circle either, but that's x11's problem, I guess).

Pretty sure that difference is just the effect of anti-aliasing.

> Image Formats
>    As with 3d color surfaces, a color box may be added to the plot: 
> blank, color box goes off edge of screen  (Appears to be Qt only)
>    Matrix binary data (gnuplot binary) translated: the box around the 
> key extends so far to the left, wish that font-size issue could be fixed 
> somehow
> 
>    The two images after "End of image demo...": can't see key amongst 
> black background
> 
>    Same thing in 3D mode (First column contains various odd values): 
> blank and only two borders visible
>    3D image with pixel value in 4th column: blank and only two borders 
> visible
> 
> ellipses_style.dem
>    Four-column form: x y major_diameter: The _d of two "diameter"s is 
> treated as subscript and doesn't read easily
>    Five-column form:  The _d of two "diameter"s is treated as subscript 
> and doesn't read easily

This is a consequence of the version 5 switch to enabling enhanced
text by default.
The "set title" command should be marked "noenhanced" in this demo.
(now fixed in CVS).

There may be other similar examples in the demo set.
 
> key.dem
>    Key (<manual> vert left top): The plot border appears to be the 
> top-most element, while all other plot elements appear behind the key. 
> I don't recall this from the past.
> 
> rectangle.dem
>    There are the following differences between Qt temrinal and x11 terminal:
>    Qt: The rectangle labeled "There should be a clipped rectangle here" 
> has a white fill background
>    x11: The said rectangle has no white fill, just the biege of the plot 
> showing through
>    Qt: The hashmark fill pattern box from (2,-3) to (0,-2) has no 
> background (biege shows through)
>    x11: Said pattern box has a white fill background showing through the 
> hash pattern

Not sure what is going on here.  Note that the x11 terminal doesn't
do transparency, but in this case the result is opposite to what I would
have expected.

Re: core dump on Mac: this_axis->ticfmt is freed twice

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

On Tuesday, 21 April, 2015 00:19:14 Jun T. wrote:
> On Mac OS X,
> 
> gnuplot> set term wxt
> gnuplot> plot sin(x)
> 
> and on the plot window, use the arrow keys to move the plot,
> and hit the 'u' key to unzoom. Then gnuplot core dumps as follows:
> 
> gnuplot(3264,0x7fff71afa310) malloc: *** error for object 0x7fdd21f5d5b0: pointer being freed was not allocated
> 
> The back trace is:
> 
> #0  0x00007fff84104866 in __pthread_kill ()
> #1  0x00007fff8444235c in pthread_kill ()
> #2  0x00007fff8bed8b1a in abort ()
> #3  0x00007fff81c5f07f in free ()
> #4  0x0000000107fb4ad1 in copy_or_invent_formatstring (this_axis=0x1081b1948) at axis.c:516
> #5  0x0000000107fb5700 in setup_tics (this=0x1081b1948, max=20) at axis.c:886
> #6  0x0000000107fbe2ac in boundary (plots=0x7fdd21fce620, count=1) at boundary.c:417
> #7  0x0000000107fffa1f in do_plot (plots=0x7fdd21fce620, pcount=1) at graphics.c:533
> #8  0x000000010804a30c in eval_plots () at plot2d.c:3335
> #9  0x0000000108042b57 in plotrequest () at plot2d.c:271
> #10 0x0000000107fc7033 in replotrequest () at command.c:2299
> #11 0x0000000107fc6090 in do_string_replot (s=0x7fff57c4af10 "") at command.c:495
> #12 0x00000001080397f1 in apply_zoom (z=0x7fdd21de8f80) at mouse.c:702
> #13 0x000000010803a003 in ZoomUnzoom () at mouse.c:779
> #14 0x000000010803835f in builtin_unzoom (ge=0x7fff57c4b468) at mouse.c:1242
> ...
> 
> The core dump is at
> 
> axis.c:516:    free(this_axis->ticfmt);
> 
> and the above error indicates that the memory pointed to by ticfmt has
> already been freed.
> 
> This is due to that the value of this_axis->ticfmt is restored to the
> saved value at
> 
> mouse.c:683:    memcpy(axis_array, axis_array_copy, sizeof(axis_array));
> 
> but the memory pointed to by the saved value of ticfmt has already been
> freed.
> 
> On Linux, gnuplot may not core dump, but I believe it is just by sheer
> luck. ticfmt is freed and allocated at
> 
> axis.c:516:    free(this_axis->ticfmt);
> axis.c:517:    this_axis->ticfmt = strdup(tempfmt);
> 
> and, on Linux, I guess strdup() allocates the string in the memory which
> has just been freed, and the value of ticfmt does not change.
> 
> The following would be a simple fix; i.e., do not restore ticfmt (and
> formatstring) in apply_zoom().
> 
> 
> Index: mouse.c
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/src/mouse.c,v
> retrieving revision 1.179
> diff -u -r1.179 mouse.c
> --- mouse.c	24 Mar 2015 21:35:13 -0000	1.179
> +++ mouse.c	20 Apr 2015 14:15:00 -0000
> @@ -679,6 +679,8 @@
>  	    axis_array_copy[i].label = axis_array[i].label;
>  	    axis_array_copy[i].ticdef.def.user = axis_array[i].ticdef.def.user;
>  	    axis_array_copy[i].ticdef.font = axis_array[i].ticdef.font;
> +	    axis_array_copy[i].formatstring = axis_array[i].formatstring;
> +	    axis_array_copy[i].ticfmt = axis_array[i].ticfmt;
>  	}
>  	memcpy(axis_array, axis_array_copy, sizeof(axis_array));
>  	s[0] = '\0';	/* FIXME:  Is this better than calling replotrequest()? */


Yes, you are quite correct and I think the fix is correct also.

	thanks,

		Ethan

core dump on Mac: this_axis->ticfmt is freed twice

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

On Mac OS X,

gnuplot> set term wxt
gnuplot> plot sin(x)

and on the plot window, use the arrow keys to move the plot,
and hit the 'u' key to unzoom. Then gnuplot core dumps as follows:

gnuplot(3264,0x7fff71afa310) malloc: *** error for object 0x7fdd21f5d5b0: pointer being freed was not allocated

The back trace is:

#0  0x00007fff84104866 in __pthread_kill ()
#1  0x00007fff8444235c in pthread_kill ()
#2  0x00007fff8bed8b1a in abort ()
#3  0x00007fff81c5f07f in free ()
#4  0x0000000107fb4ad1 in copy_or_invent_formatstring (this_axis=0x1081b1948) at axis.c:516
#5  0x0000000107fb5700 in setup_tics (this=0x1081b1948, max=20) at axis.c:886
#6  0x0000000107fbe2ac in boundary (plots=0x7fdd21fce620, count=1) at boundary.c:417
#7  0x0000000107fffa1f in do_plot (plots=0x7fdd21fce620, pcount=1) at graphics.c:533
#8  0x000000010804a30c in eval_plots () at plot2d.c:3335
#9  0x0000000108042b57 in plotrequest () at plot2d.c:271
#10 0x0000000107fc7033 in replotrequest () at command.c:2299
#11 0x0000000107fc6090 in do_string_replot (s=0x7fff57c4af10 "") at command.c:495
#12 0x00000001080397f1 in apply_zoom (z=0x7fdd21de8f80) at mouse.c:702
#13 0x000000010803a003 in ZoomUnzoom () at mouse.c:779
#14 0x000000010803835f in builtin_unzoom (ge=0x7fff57c4b468) at mouse.c:1242
...

The core dump is at

axis.c:516:    free(this_axis->ticfmt);

and the above error indicates that the memory pointed to by ticfmt has
already been freed.

This is due to that the value of this_axis->ticfmt is restored to the
saved value at

mouse.c:683:    memcpy(axis_array, axis_array_copy, sizeof(axis_array));

but the memory pointed to by the saved value of ticfmt has already been
freed.

On Linux, gnuplot may not core dump, but I believe it is just by sheer
luck. ticfmt is freed and allocated at

axis.c:516:    free(this_axis->ticfmt);
axis.c:517:    this_axis->ticfmt = strdup(tempfmt);

and, on Linux, I guess strdup() allocates the string in the memory which
has just been freed, and the value of ticfmt does not change.

The following would be a simple fix; i.e., do not restore ticfmt (and
formatstring) in apply_zoom().


Index: mouse.c
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/mouse.c,v
retrieving revision 1.179
diff -u -r1.179 mouse.c
--- mouse.c	24 Mar 2015 21:35:13 -0000	1.179
+++ mouse.c	20 Apr 2015 14:15:00 -0000
@@ -679,6 +679,8 @@
 	    axis_array_copy[i].label = axis_array[i].label;
 	    axis_array_copy[i].ticdef.def.user = axis_array[i].ticdef.def.user;
 	    axis_array_copy[i].ticdef.font = axis_array[i].ticdef.font;
+	    axis_array_copy[i].formatstring = axis_array[i].formatstring;
+	    axis_array_copy[i].ticfmt = axis_array[i].ticfmt;
 	}
 	memcpy(axis_array, axis_array_copy, sizeof(axis_array));
 	s[0] = '\0';	/* FIXME:  Is this better than calling replotrequest()? */

Re: Peculiarities in demo plots

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

On 04/20/2015 12:02 AM, sfeam wrote:
> On Sunday, 19 April 2015 11:51:22 PM Daniel J Sebald wrote:
>> Forgot one:
>>
>> imageNaN.dem
>>     Treatment of missing/undefined/NaN/Inf data: Qt and x11 plots look
>> similar except for first column.
>>                Qt: (top to bottom) black, yellow, white, blue, white, blue
>>                x11: (top to bottom) black, yellow, black, blue, black, blue
>>     image from non-matrix data: The x11 plot has a black pixel left,
>> second from top so the text "NaN should appear as background" is not
>> visible.
>>     negative values mapped to log-scale colorbar: Same sort of thing for
>> x11, the "Negative values become NaN..." is not visible.
>
> Right. That's the point of having the demos - they serve as unit tests
> for the various code features.  In this case it shows that the x11 terminal
> does not handle NaN in image data optimally.  That's at least partly because
> the x11 terminal doesn't handle transparency, so there is not the option
> of mapping NaN to "all-transparent".
>
> The PostScript terminal exhibits the same deficiency.
> In both cases the terminal is just showing it's age.
> The newer options (qt/cairo) are more capable.
>
> 	Ethan

Are we talking 100% transparent "pixel"?  Or partially transparent?

I've not worked with any of the Qt QGraphicsItem classes, but I'm 
wondering if this QGraphicsPixmapItem class is handling images as a 
collective of pixels, as opposed to an image of data that is sent to a 
driver.  That might explain the slowness of the Qt terminal.  Qt is much 
slower than x11 when working with the image data--a factor of five or more.

In other words, the QGraphicsItem class might be similar to the failsafe 
mode of x11, as far as its operation is concerned--I'm assuming failsafe 
is where an image is created by drawing squares on the canvas.

For that example, if I turn on failsafe mode, i.e.,

plot $DATA with image failsafe

that example with "NaN should appear as background" and "Negative values 
become NaN with a log-scale color mapping" looks similar in x11 and Qt 
terminals.  In fact, shrinking down the image I can see in both cases 
that "NaN should appear as background" is actually in front of the 
pixmap while "Negative values become NaN with a log-scale color mapping".

I'm fine with the demo, but now that I understand it I don't see the 
terminal type as being highly responsible for the feature.  (Partial 
transparency is a different issue.  That's something more significant. 
Could probably do alpha-blending in X11, but I don't think anyone wants 
to tackle that.)  The "failsafe" option is somewhat vague.  Given what I 
suspect about the image being actually drawn with individual rectangles 
(something that "image" defaults to when cast into a 3D 
non-perpendicular view), it might have been nicer to force this mode 
with a different type, say "pixmap" as opposed to "image".

I'm not too quick to dismiss x11 terminal.  Yes, I know maintenance is 
an issue, and alpha blending is missing, antialiasing for nice lines is 
missing, etc.  But it wouldn't surprise me if ultimately Qt terminal 
(i.e., QGraphicsItem) is using X11 in some form.

Dan

Re: Peculiarities in demo plots

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

On Sunday, 19 April 2015 11:51:22 PM Daniel J Sebald wrote:
> Forgot one:
> 
> imageNaN.dem
>    Treatment of missing/undefined/NaN/Inf data: Qt and x11 plots look 
> similar except for first column.
>               Qt: (top to bottom) black, yellow, white, blue, white, blue
>               x11: (top to bottom) black, yellow, black, blue, black, blue
>    image from non-matrix data: The x11 plot has a black pixel left, 
> second from top so the text "NaN should appear as background" is not 
> visible.
>    negative values mapped to log-scale colorbar: Same sort of thing for 
> x11, the "Negative values become NaN..." is not visible.

Right. That's the point of having the demos - they serve as unit tests
for the various code features.  In this case it shows that the x11 terminal
does not handle NaN in image data optimally.  That's at least partly because
the x11 terminal doesn't handle transparency, so there is not the option
of mapping NaN to "all-transparent".

The PostScript terminal exhibits the same deficiency.
In both cases the terminal is just showing it's age.
The newer options (qt/cairo) are more capable.

	Ethan



> 
> 
> On 04/19/2015 11:08 PM, Daniel J Sebald wrote:
> > I stepped through the demos to see what is new and test whether a change
> > I made affected anything.  Below is a list of items that seem like
> > bugs/flaws compared to what I recall of the demos from years ago.  I
> > haven't investigated any of these issues.  Should we break these up into
> > bug reports somehow?
> >
> > Dan
> >
> >
> > random.dem:
> >     (Clarification, this is only for Qt, x11 looks as I remember)
> >     Lattice test for random numbers: blank (or points are single pixel
> > which I can't see amongst the dust on my monitor)
> >     Lattice test for random numbers: blank
> >     Gaussian 3D cloud of 3000 random samples: blank
> >
> > scatter.dem:
> > Hit return to continue (5)
> >            "scatter.dem", line 45: warning: Cannot contour non grid data.
> > Please use "set dgrid3d".
> >
> > pm3d.dem:
> >     (Let me clarify the following: all of these cases are for the Qt
> > terminal,
> >      the x11 terminal has the file name front-most in the plot)
> >     Datafile with different nb of points in scans; pm3d flush begin: file
> > name is behind the plot element (reads 'gle.dat')
> >     Datafile with different nb of points in scans; pm3d flush center:
> > file name is behind the plot element (reads 'dat')
> >     Datafile with different nb of points in scans; pm3d flush scans: file
> > name is obscured by the plot element
> >     Datafile with different nb of points in scans; pm3d ftriangles flush
> > begin: file name is obscured by the plot element
> >     Datafile with different nb of points in scans; pm3d ftriangles flush
> > center: file name is obscured by the plot element
> >     Datafile with different nb of points in scans; pm3d ftriangles flush
> > end: file name is obscured by the plot element
> >     Using interpolate with datafile; pm3d map interpolate 2,1: file name
> > is behind the plot element (reads 'gle.dat')
> >     Using interpolate with datafile; pm3d map ftriangles interpolate
> > 10,1: name is obscured by the plot element
> >     color lines: 'splot sin(y)/(y) with lines palette': The color bar
> > text goes off the window screen.  I see that quite often and don't
> > recall this from years back...maybe font is bigger
> >
> > heatmaps.dem
> >     Heat Map generated from a file containing Z values only: blank, color
> > bar correct (this is only for Qt terminal, x11 looks good)
> >     Compare 'image' and 'image pixels' mode: On my system, there are
> > white spaces between pixels (this is only for Qt terminal, x11 looks
> > good, I think I've encountered this before as a graphics driver
> > implementation of OpenGL (Mesa) issue)
> >
> > hypertext.dem
> >     Sweet!
> >     While the Qt terminal has yellow filled circle with slightly darker
> > yellow/brown outline, the x11 terminal has yellow filled circles with
> > black outline and a black dot at the center of each circle (not the best
> > looking circle either, but that's x11's problem, I guess).
> >
> > Image Formats
> >     As with 3d color surfaces, a color box may be added to the plot:
> > blank, color box goes off edge of screen  (Appears to be Qt only)
> >     Matrix binary data (gnuplot binary) translated: the box around the
> > key extends so far to the left, wish that font-size issue could be fixed
> > somehow
> >
> >     The two images after "End of image demo...": can't see key amongst
> > black background
> >
> >     Same thing in 3D mode (First column contains various odd values):
> > blank and only two borders visible
> >     3D image with pixel value in 4th column: blank and only two borders
> > visible
> >
> > ellipses_style.dem
> >     Four-column form: x y major_diameter: The _d of two "diameter"s is
> > treated as subscript and doesn't read easily
> >     Five-column form:  The _d of two "diameter"s is treated as subscript
> > and doesn't read easily
> >
> > key.dem
> >     Key (<manual>  vert left top): The plot border appears to be the
> > top-most element, while all other plot elements appear behind the key.
> > I don't recall this from the past.
> >
> > rectangle.dem
> >     There are the following differences between Qt temrinal and x11 terminal:
> >     Qt: The rectangle labeled "There should be a clipped rectangle here"
> > has a white fill background
> >     x11: The said rectangle has no white fill, just the biege of the plot
> > showing through
> >     Qt: The hashmark fill pattern box from (2,-3) to (0,-2) has no
> > background (biege shows through)
> >     x11: Said pattern box has a white fill background showing through the
> > hash pattern
> >
> >
> > ------------------------------------------------------------------------------
> > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> > Develop your own process in accordance with the BPMN 2 standard
> > Learn Process modeling best practices with Bonita BPM through live exercises
> > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> 
> 

Re: Peculiarities in demo plots

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

Forgot one:

imageNaN.dem
   Treatment of missing/undefined/NaN/Inf data: Qt and x11 plots look 
similar except for first column.
              Qt: (top to bottom) black, yellow, white, blue, white, blue
              x11: (top to bottom) black, yellow, black, blue, black, blue
   image from non-matrix data: The x11 plot has a black pixel left, 
second from top so the text "NaN should appear as background" is not 
visible.
   negative values mapped to log-scale colorbar: Same sort of thing for 
x11, the "Negative values become NaN..." is not visible.


On 04/19/2015 11:08 PM, Daniel J Sebald wrote:
> I stepped through the demos to see what is new and test whether a change
> I made affected anything.  Below is a list of items that seem like
> bugs/flaws compared to what I recall of the demos from years ago.  I
> haven't investigated any of these issues.  Should we break these up into
> bug reports somehow?
>
> Dan
>
>
> random.dem:
>     (Clarification, this is only for Qt, x11 looks as I remember)
>     Lattice test for random numbers: blank (or points are single pixel
> which I can't see amongst the dust on my monitor)
>     Lattice test for random numbers: blank
>     Gaussian 3D cloud of 3000 random samples: blank
>
> scatter.dem:
> Hit return to continue (5)
>            "scatter.dem", line 45: warning: Cannot contour non grid data.
> Please use "set dgrid3d".
>
> pm3d.dem:
>     (Let me clarify the following: all of these cases are for the Qt
> terminal,
>      the x11 terminal has the file name front-most in the plot)
>     Datafile with different nb of points in scans; pm3d flush begin: file
> name is behind the plot element (reads 'gle.dat')
>     Datafile with different nb of points in scans; pm3d flush center:
> file name is behind the plot element (reads 'dat')
>     Datafile with different nb of points in scans; pm3d flush scans: file
> name is obscured by the plot element
>     Datafile with different nb of points in scans; pm3d ftriangles flush
> begin: file name is obscured by the plot element
>     Datafile with different nb of points in scans; pm3d ftriangles flush
> center: file name is obscured by the plot element
>     Datafile with different nb of points in scans; pm3d ftriangles flush
> end: file name is obscured by the plot element
>     Using interpolate with datafile; pm3d map interpolate 2,1: file name
> is behind the plot element (reads 'gle.dat')
>     Using interpolate with datafile; pm3d map ftriangles interpolate
> 10,1: name is obscured by the plot element
>     color lines: 'splot sin(y)/(y) with lines palette': The color bar
> text goes off the window screen.  I see that quite often and don't
> recall this from years back...maybe font is bigger
>
> heatmaps.dem
>     Heat Map generated from a file containing Z values only: blank, color
> bar correct (this is only for Qt terminal, x11 looks good)
>     Compare 'image' and 'image pixels' mode: On my system, there are
> white spaces between pixels (this is only for Qt terminal, x11 looks
> good, I think I've encountered this before as a graphics driver
> implementation of OpenGL (Mesa) issue)
>
> hypertext.dem
>     Sweet!
>     While the Qt terminal has yellow filled circle with slightly darker
> yellow/brown outline, the x11 terminal has yellow filled circles with
> black outline and a black dot at the center of each circle (not the best
> looking circle either, but that's x11's problem, I guess).
>
> Image Formats
>     As with 3d color surfaces, a color box may be added to the plot:
> blank, color box goes off edge of screen  (Appears to be Qt only)
>     Matrix binary data (gnuplot binary) translated: the box around the
> key extends so far to the left, wish that font-size issue could be fixed
> somehow
>
>     The two images after "End of image demo...": can't see key amongst
> black background
>
>     Same thing in 3D mode (First column contains various odd values):
> blank and only two borders visible
>     3D image with pixel value in 4th column: blank and only two borders
> visible
>
> ellipses_style.dem
>     Four-column form: x y major_diameter: The _d of two "diameter"s is
> treated as subscript and doesn't read easily
>     Five-column form:  The _d of two "diameter"s is treated as subscript
> and doesn't read easily
>
> key.dem
>     Key (<manual>  vert left top): The plot border appears to be the
> top-most element, while all other plot elements appear behind the key.
> I don't recall this from the past.
>
> rectangle.dem
>     There are the following differences between Qt temrinal and x11 terminal:
>     Qt: The rectangle labeled "There should be a clipped rectangle here"
> has a white fill background
>     x11: The said rectangle has no white fill, just the biege of the plot
> showing through
>     Qt: The hashmark fill pattern box from (2,-3) to (0,-2) has no
> background (biege shows through)
>     x11: Said pattern box has a white fill background showing through the
> hash pattern
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

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

Peculiarities in demo plots

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

I stepped through the demos to see what is new and test whether a change 
I made affected anything.  Below is a list of items that seem like 
bugs/flaws compared to what I recall of the demos from years ago.  I 
haven't investigated any of these issues.  Should we break these up into 
bug reports somehow?

Dan


random.dem:
   (Clarification, this is only for Qt, x11 looks as I remember)
   Lattice test for random numbers: blank (or points are single pixel 
which I can't see amongst the dust on my monitor)
   Lattice test for random numbers: blank
   Gaussian 3D cloud of 3000 random samples: blank

scatter.dem:
Hit return to continue (5)
          "scatter.dem", line 45: warning: Cannot contour non grid data. 
Please use "set dgrid3d".

pm3d.dem:
   (Let me clarify the following: all of these cases are for the Qt 
terminal,
    the x11 terminal has the file name front-most in the plot)
   Datafile with different nb of points in scans; pm3d flush begin: file 
name is behind the plot element (reads 'gle.dat')
   Datafile with different nb of points in scans; pm3d flush center: 
file name is behind the plot element (reads 'dat')
   Datafile with different nb of points in scans; pm3d flush scans: file 
name is obscured by the plot element
   Datafile with different nb of points in scans; pm3d ftriangles flush 
begin: file name is obscured by the plot element
   Datafile with different nb of points in scans; pm3d ftriangles flush 
center: file name is obscured by the plot element
   Datafile with different nb of points in scans; pm3d ftriangles flush 
end: file name is obscured by the plot element
   Using interpolate with datafile; pm3d map interpolate 2,1: file name 
is behind the plot element (reads 'gle.dat')
   Using interpolate with datafile; pm3d map ftriangles interpolate 
10,1: name is obscured by the plot element
   color lines: 'splot sin(y)/(y) with lines palette': The color bar 
text goes off the window screen.  I see that quite often and don't 
recall this from years back...maybe font is bigger

heatmaps.dem
   Heat Map generated from a file containing Z values only: blank, color 
bar correct (this is only for Qt terminal, x11 looks good)
   Compare 'image' and 'image pixels' mode: On my system, there are 
white spaces between pixels (this is only for Qt terminal, x11 looks 
good, I think I've encountered this before as a graphics driver 
implementation of OpenGL (Mesa) issue)

hypertext.dem
   Sweet!
   While the Qt terminal has yellow filled circle with slightly darker 
yellow/brown outline, the x11 terminal has yellow filled circles with 
black outline and a black dot at the center of each circle (not the best 
looking circle either, but that's x11's problem, I guess).

Image Formats
   As with 3d color surfaces, a color box may be added to the plot: 
blank, color box goes off edge of screen  (Appears to be Qt only)
   Matrix binary data (gnuplot binary) translated: the box around the 
key extends so far to the left, wish that font-size issue could be fixed 
somehow

   The two images after "End of image demo...": can't see key amongst 
black background

   Same thing in 3D mode (First column contains various odd values): 
blank and only two borders visible
   3D image with pixel value in 4th column: blank and only two borders 
visible

ellipses_style.dem
   Four-column form: x y major_diameter: The _d of two "diameter"s is 
treated as subscript and doesn't read easily
   Five-column form:  The _d of two "diameter"s is treated as subscript 
and doesn't read easily

key.dem
   Key (<manual> vert left top): The plot border appears to be the 
top-most element, while all other plot elements appear behind the key. 
I don't recall this from the past.

rectangle.dem
   There are the following differences between Qt temrinal and x11 terminal:
   Qt: The rectangle labeled "There should be a clipped rectangle here" 
has a white fill background
   x11: The said rectangle has no white fill, just the biege of the plot 
showing through
   Qt: The hashmark fill pattern box from (2,-3) to (0,-2) has no 
background (biege shows through)
   x11: Said pattern box has a white fill background showing through the 
hash pattern

Fwd: Re: [Gnuplot-info] How to disable grid-data mode with splot ?

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

[Forgot to CC list...]

Am 07.04.2015 um 14:54 schrieb Francois Mauger:

> For now I was not able to find a way (through a special option or
> command) that
> would inhibit this feature and I am forced to add arbitrary vertexes to
> break
> the  'grid data' feature:

There's a much less intrusive possibility: just double up the blank
lines in the data file that separates polylines.  That way each polyline
becomes an "index" of its own, and there is no gridding.

Or, you could update to version 5.0 and see "help surface".

Re: set terminal postscript lw 1.5; set output 'ps_symbols.ps' causes an error (was Re: "ps_symbols.gpi", line 2: unrecognized option during make ps_symbols.ps)

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

> From: sfeam

> To: gnuplot-beta; Tatsuro MATSUOKA 
> Cc: 
> Date: 2015/3/31, Tue 00:38
> Subject: Re: set terminal postscript lw 1.5; set output 'ps_symbols.ps' causes an error (was Re: "ps_symbols.gpi", line 2: unrecognized option during make ps_symbols.ps)
> 
> On Monday, 30 March 2015 03:48:41 PM Tatsuro MATSUOKA wrote:
> 
>>  The same phenomenon occurs on gnuplot on Ubuntu 14.04 LTS.
>>  gnuplot> set terminal postscript lw 1.5; set output 
> 'ps_symbols.ps'
>>  Terminal type set to 'postscript'
>>  Options are 'landscape enhanced defaultplex \
>>     leveldefault monochrome colortext \
>>     dashlength 1.0 linewidth 1.5 butt noclip \
>>     nobackground \
>>     palfuncparam 2000,0.003 \
>>     "Helvetica" 14  fontscale 1.0 '
>>                                           ^
>>           unrecognized option
>> 
>>  gnuplot> 
>> 
>>  The above seem to be platform independent.
>> 
>>  Tatsuro
> 
> Sorry for the error. It is fixed now.
> 


I have confirmed the fix and update the cvs version windows cygwin binary on my site.

Thanks



> This is an example of a tyoe of programming error (failure to
> check for end of command line) that is not exercised or caught
> by running "make check".   Does anyone have suggestions about
> how to add more stringent tests for debugging program changes?
> 
>     Ethan


For me, I do not have any good idea for this matter.

The CVS version is open to the people who would like to use the latest feature.
In the process of build or using gnuplot, they will notice a flaw or flaws and will
do feedback. The feedback will help to the bug fix introducing the new features.

When I notice the flaw like this time, I will report as soon as possible.

Tatsuro