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

Re: Discussion: What to do if NaN appears in a non-coordinate field?

[Juhász P. <pet...@gm...>]

On Sat, 2012-03-31 at 09:39 -0700, sfeam (Ethan Merritt) wrote:
> Bug #3513138 reports a problem when NaN appears in a data column 
> where gnuplot is expecting to find an extra property.  
> The example given is
>      plot 'foo' using 1:2:3 with points lc palette
> The same problem would happen for
>      plot 'foo' using 1:2:3 with points pointsize variable
> 
> If NaN appears in the x, y, or z coordinate then the point
> is rejected on input.  But what should we do for these 
> cases where the point is in range on x/y/z but a separate
> field is missing or NaN?
> 
> 1) Ignore the point (same as a NaN coordinate).
> 
> 2) Accept the point but assign the property some default value.
> 
> 3) Use the coordinates for auto-scaling but do not draw it.
> 
> 4) Something else
> 
> The current handling of "with image" data provides some precedent.
> A NaN image pixel is either not drawn at all or is rendered
> in the background color. But the issue of auto-scaling does not 
> arise for image plots because omitting a single pixel would not 
> change the range.
> 
> Should an "invisible" point (i.e. one with NaN for pointsize or
> color) contribute to auto-scaling?
> 
> There are probably more obscure cases also, like "with circles" 
> where the radius is NaN.  Can you think of any others?
> 
> 
> 	Ethan
> 

I'd say the cleanest and most consistent solution would be ignoring the
point completely. At least for circles, radius is an essential property,
a circle with a NaN radius is not a circle at all (NaC). Same for
ellipses.

A counterargument could be made for point colors, sizes (and perhaps
some other attributes), because those are optional properties. Still, if
the using specification says "1:2:3 with points lc palette" and
column(3) is NaN for a certain point, then the specification is
incomplete for that point, and thus it is best if it doesn't influence
the plot in any way.

Péter Juhász

Re: Discussion: What to do if NaN appears in a non-coordinate field?

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

On 03/31/12 18:39, sfeam (Ethan Merritt) wrote:
> Bug #3513138 reports a problem when NaN appears in a data column
> where gnuplot is expecting to find an extra property.
> The example given is
>       plot 'foo' using 1:2:3 with points lc palette
> The same problem would happen for
>       plot 'foo' using 1:2:3 with points pointsize variable
>
> If NaN appears in the x, y, or z coordinate then the point
> is rejected on input.  But what should we do for these
> cases where the point is in range on x/y/z but a separate
> field is missing or NaN?
>
> 1) Ignore the point (same as a NaN coordinate).
>
> 2) Accept the point but assign the property some default value.
>
> 3) Use the coordinates for auto-scaling but do not draw it.
>
> 4) Something else
>
> The current handling of "with image" data provides some precedent.
> A NaN image pixel is either not drawn at all or is rendered
> in the background color. But the issue of auto-scaling does not
> arise for image plots because omitting a single pixel would not
> change the range.
>
> Should an "invisible" point (i.e. one with NaN for pointsize or
> color) contribute to auto-scaling?
>
> There are probably more obscure cases also, like "with circles"
> where the radius is NaN.  Can you think of any others?
>
>
> 	Ethan
>
> ----------------

Hi Ethan,

I would have thought that any NaN anywhere was basically :"this is not 
valid data ignore it".

A circle with rad="not a number" is "not a circle".

A point of colour index "not a number" is not a point. Why should it be 
part of scaling or anything?

I can see a limited number or reasons for finding a NaN.

1. divide by zero type error, data is bad don't use it. Using a default 
is almost certainly not the correct result otherwise no one would be 
trying to calculate whatever it was to start with.

2. data file has missing data intentionally marked at non existent: it 
should not be used in any way , that's why it was flagged as non existent.

3. programatically creating a NaN to control output: I require a result 
, I explicitly try to exclude it, don't do something (anything) with it .
plot ...... using ($1<1945)?NaN:$1 :2 ...


 > If NaN appears in the x, y, or z coordinate then the point
 > is rejected on input.

I thought when I brought this up a couple of months back the point I 
raised was that this was NOT happening when NaN was in first column. It 
was not being parsed as NaN but "NaN".

I presume whatever action you decide upon, this will now get corrected. 
So if anyone sees a problem with such a change (like this is a feature 
not a bug) please shout now.

Peter.

Discussion: What to do if NaN appears in a non-coordinate field?

[sfeam (E. Merritt) <eam...@gm...>]

Bug #3513138 reports a problem when NaN appears in a data column 
where gnuplot is expecting to find an extra property.  
The example given is
     plot 'foo' using 1:2:3 with points lc palette
The same problem would happen for
     plot 'foo' using 1:2:3 with points pointsize variable

If NaN appears in the x, y, or z coordinate then the point
is rejected on input.  But what should we do for these 
cases where the point is in range on x/y/z but a separate
field is missing or NaN?

1) Ignore the point (same as a NaN coordinate).

2) Accept the point but assign the property some default value.

3) Use the coordinates for auto-scaling but do not draw it.

4) Something else

The current handling of "with image" data provides some precedent.
A NaN image pixel is either not drawn at all or is rendered
in the background color. But the issue of auto-scaling does not 
arise for image plots because omitting a single pixel would not 
change the range.

Should an "invisible" point (i.e. one with NaN for pointsize or
color) contribute to auto-scaling?

There are probably more obscure cases also, like "with circles" 
where the radius is NaN.  Can you think of any others?


	Ethan

Re: Qt terminal

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

On 2012-01-08, Jérôme Lodewyck wrote:
> Le Dimanche 8 Janvier 2012 17:45:08 vous avez écrit :
>> I had to replace Cocoa/Cocoa.h with Carbon/Carbon.h. Import of Cocoa
>> doesn't work and I have no idea why (maybe because it is in Objective
>> C and some compiler flags bail?). I also have no idea how safe it is
>> to use Carbon, but apparently it worked this time.
>
> Just for the fun, here is a version that should compile with Cocoa. Beware
> it
> breaks the build systems on non-OSX systems (I don't know how to
> conditionally
> add sources for a given OS in Makefile.am...). As far as I understand, the
> problem with Carbon is that it is somehow obsolete and apperently does not
> work on 64 bits systems.

I have prepared a patch against latest sources using your idea. I'm
attaching two files:
- gnuplot-qt-maconly.patch which attempts to solve this issue
- gnuplot-qt-all.patch which additionally solves three other issues
(trivial patches)

Now my latest observations:
1.) If I run ./prepare myself, the patch seems to work fine.
2.) I wanted to prepare a patch for MacPorts against 4.6.0 and since I
have a newer version of autotools, I wanted to include only the
relevant changes (leaving out all the parts that only have to do with
newer version of autotools). The funny part is that compiling the
result with CC=clang CXX=clang++ OBJC=clang worked fine, while the
compilation using the default compiler choked with with

c++ -DHAVE_CONFIG_H -I. -I..  -I../term -I../term
-DBINDIR=\"/path/to/gnuplot/inst/bin\"
-DX11_DRIVER_DIR=\"/path/to/gnuplot/inst/libexec/gnuplot/4.6\"
-DQT_DRIVER_DIR=\"/path/to/gnuplot/inst/libexec/gnuplot/4.6\"
-DGNUPLOT_SHARE_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6\"
-DGNUPLOT_PS_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/PostScript\"
-DGNUPLOT_JS_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/js\"
-DGNUPLOT_LUA_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/lua\"
-DCONTACT=\"gnu...@li...\"
-DHELPFILE=\"/path/to/gnuplot/inst/share/gnuplot/4.6/gnuplot.gih\"
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"
-DXAPPLRESDIR=\"/etc/X11/app-defaults/\"
-DQTGNUPLOT_DATA_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/qt\"
-I/Library/Frameworks/QtCore.framework/Headers
-I/Library/Frameworks/QtGui.framework/Headers
-I/Library/Frameworks/QtNetwork.framework/Headers
-I/Library/Frameworks/QtSvg.framework/Headers  -g -O2  -MT qt_term.o
-MD -MP -MF .deps/qt_term.Tpo -c -o qt_term.o `test -f
'qtterminal/qt_term.cpp' || echo './'`qtterminal/qt_term.cpp
In file included from qtterminal/qt_term.cpp:49:
In file included from ./plot.h:46:
./mouse.h:189:6: error: variable has incomplete type 'void'
void set_ruler __PROTO((TBOOLEAN on, int mx, int my));
     ^
./mouse.h:189:25: error: use of undeclared identifier '_Bool'; did you
mean 'QBool'?
void set_ruler __PROTO((TBOOLEAN on, int mx, int my));
                        ^
./syscfg.h:368:18: note: expanded from macro 'TBOOLEAN'
#define TBOOLEAN bool
                 ^
./syscfg.h:352:15: note: expanded from macro 'bool'
# define bool _Bool
              ^
./syscfg.h:189:25: note: expanded from macro '__PROTO'
# define __PROTO(proto) proto
                        ^
In file included from qtterminal/qt_term.cpp:49:
In file included from ./plot.h:46:
./mouse.h:197:50: error: unknown type name '_Bool'; did you mean 'QBool'?
void bind_process __PROTO((char* lhs, char* rhs, TBOOLEAN allwindows));
                                                 ^
./syscfg.h:368:18: note: expanded from macro 'TBOOLEAN'
#define TBOOLEAN bool
                 ^
./syscfg.h:352:15: note: expanded from macro 'bool'
# define bool _Bool
              ^
./syscfg.h:189:25: note: expanded from macro '__PROTO'
# define __PROTO(proto) proto
                        ^
/Library/Frameworks/QtCore.framework/Headers/qglobal.h:1976:7: note:
'QBool' declared here
class QBool
      ^
In file included from qtterminal/qt_term.cpp:49:
./plot.h:53:8: error: unknown type name '_Bool'; did you mean 'QBool'?
extern TBOOLEAN interactive;
       ^
./syscfg.h:368:18: note: expanded from macro 'TBOOLEAN'
#define TBOOLEAN bool
                 ^
./syscfg.h:352:15: note: expanded from macro 'bool'
# define bool _Bool
              ^
/Library/Frameworks/QtCore.framework/Headers/qglobal.h:1976:7: note:
'QBool' declared here
class QBool
      ^
In file included from qtterminal/qt_term.cpp:49:

etc.

Even more funny is that:

> c++ --version
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0

> clang++ --version
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0

The gcc compiler fails with

g++ -DHAVE_CONFIG_H -I. -I..  -I../term -I../term
-DBINDIR=\"/path/to/gnuplot/inst/bin\"
-DX11_DRIVER_DIR=\"/path/to/gnuplot/inst/libexec/gnuplot/4.6\"
-DQT_DRIVER_DIR=\"/path/to/gnuplot/inst/libexec/gnuplot/4.6\"
-DGNUPLOT_SHARE_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6\"
-DGNUPLOT_PS_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/PostScript\"
-DGNUPLOT_JS_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/js\"
-DGNUPLOT_LUA_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/lua\"
-DCONTACT=\"gnu...@li...\"
-DHELPFILE=\"/path/to/gnuplot/inst/share/gnuplot/4.6/gnuplot.gih\"
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"
-DXAPPLRESDIR=\"/etc/X11/app-defaults/\"
-DQTGNUPLOT_DATA_DIR=\"/path/to/gnuplot/inst/share/gnuplot/4.6/qt\"
-I/Library/Frameworks/QtCore.framework/Headers
-I/Library/Frameworks/QtGui.framework/Headers
-I/Library/Frameworks/QtNetwork.framework/Headers
-I/Library/Frameworks/QtSvg.framework/Headers  -g -O2  -MT qt_term.o
-MD -MP -MF .deps/qt_term.Tpo -c -o qt_term.o `test -f
'qtterminal/qt_term.cpp' || echo './'`qtterminal/qt_term.cpp
In file included from ./plot.h:46,
                 from qtterminal/qt_term.cpp:49:
./mouse.h:189: error: variable or field ‘set_ruler’ declared void
./mouse.h:189: error: ‘_Bool’ was not declared in this scope
./mouse.h:189: error: expected primary-expression before ‘int’
./mouse.h:189: error: expected primary-expression before ‘int’
./mouse.h:197: error: ‘_Bool’ has not been declared
In file included from qtterminal/qt_term.cpp:49:
./plot.h:53: error: ‘_Bool’ does not name a type
./plot.h:54: error: ‘_Bool’ does not name a type
./plot.h:55: error: ‘_Bool’ does not name a type
In file included from ./color.h:72,
                 from ./term_api.h:46,
                 from qtterminal/qt_term.cpp:50:
./eval.h:86: error: ‘_Bool’ does not name a type
./eval.h:129: error: ‘_Bool’ does not name a type
./eval.h:148: error: ‘_Bool’ does not name a type
./eval.h:164: error: ‘_Bool’ has not been declared
In file included from qtterminal/qt_term.cpp:50:
./term_api.h:95: error: ‘_Bool’ does not name a type
./term_api.h:160: error: ‘_Bool’ does not name a type
./term_api.h:249: error: ‘_Bool’ has not been declared
./term_api.h:249: error: ‘_Bool’ has not been declared
./term_api.h:357: error: ‘_Bool’ does not name a type
./term_api.h:367: error: ‘_Bool’ does not name a type
./term_api.h:379: error: ‘_Bool’ does not name a type
./term_api.h:393: error: variable or field ‘term_check_multiplot_okay’
declared void
./term_api.h:393: error: ‘_Bool’ was not declared in this scope
./term_api.h:404: error: ‘_Bool’ has not been declared
./term_api.h:404: error: ‘_Bool’ has not been declared
./term_api.h:404: error: ‘_Bool’ has not been declared
./term_api.h:413: error: variable or field ‘ignore_enhanced’ declared void
./term_api.h:413: error: ‘_Bool’ was not declared in this scope
./term_api.h:416: error: ‘_Bool’ does not name a type


It is possible that I screwed something up during "backporting
configuration" (which is not a very well defined operation), that
there were some weird leftovers from somewhere, but it's also possible
that there are some problems in source code itself (maybe just a
missing header somewhere).

I would like to request somebody to:
- Review the patch and change parts if case that something needs to be changed.
- Confirm that the patch (either of the two) is harmless on platforms
other than Mac OS X.
- Test the patch on Mac OS X (if there is any mac volunteer on the
list at all) with different versions of Qt and different compilers.
- Send me (off-list) a zip of this patch applied + all the files that
get generated with ./prepare script, using the same version of
autotools that is usually used when creating gnuplot distribution. I
would like to figure out if there is a problem in my "backport" or in
some parts of the code. I have also found the following link with
google (claiming a bug in compiler):
   http://stackoverflow.com/questions/7751411/xcode-4-error-unknown-type-name-bool-did-you-mean-bool
but the errors are not exactly the same.

I would still like to stress out that:
- the current code (with qt terminal) doesn't work out-of-the-box at all
- the attached patch kind-of-works; it always works when I run
./prepare myself and doesn't work if I do some weird juggling with
backporting and using the wrong compiler; it is still *a lot better*
than the current state though - at least it works most of the time
- there is most probably no influence in cases when qt is not built
and on non-mac platforms (both compilers that fail in cases above work
perfectly fine under exactly the same configuration, only with qt
disabled)

Mojca

Re: tab filename insertion in Windows

[Tait <gnu...@t4...>]

> BTW if you want to align multi-line plot commands like that I put all 
> the plotted files including the first on the extended lines by 
> assigning a throw-away variable just after plot. That makes all the 
> lines have identical syntax and I can cut and paste to reorder or remove 
> them at will.
> 
> plot s=0 \
> , file1 with lines \
> , file2 with lines \
> , file3 using 1:2 \
> #, file4 tit "test version" \

That's a useful tip; I hadn't thought to put the commas first. Thanks.

Re: tab filename insertion in Windows

[Tait <gnu...@t4...>]

> > Something new as of gp 4.6.0 on Windows is that a tab character, entered
> > into the interactive terminal, expands into a filename. Can this behavior
> > be disabled via some configuration?
> 
> If you are talking about tab completion in the readline library, 
> it can be disabled by putting
>     set disable-completion on
> in the file ~/.inputrc  (or whatever the Windows equivalent is).
> 
> If you are talking about tab completion in the built-in readline code,
> I don't see any way to disable it currently.  That seems like a 
> reasonable feature to add.

GPVAL_COMPILE_OPTIONS = "+READLINE  -LIBREADLINE..."

I think that means it's the built-in version

> Hmm. This doesn't happen under linux because the cut-and-paste operation
> itself replaces tabs with spaces.  ...

Is this a terminal thing? Or gnuplot-specific? I can't fathom that it's
helpful to _always_ replace tabs when pasting.

> > Vim works around issues like this by using paste detection...
> > usual character-escape or ctrl-v quote-literal terminal tricks that would
> > work on *nix do not work on the Windows terminal.
> 
> Forgive my Windows ignorance, but...
> I can understand that ctrl-V doesn't work here because Windows thinks
> that it means "paste" rather than "verbatim".
> But isn't there some other control character that is equivalent 
> to *nix ctrl-V?

In general, no. For vim, when windows behaviors are enabled, the quote-
next behavior of ctrl-v is re-mapped to ctrl-q. Other applications like
PuTTY disable ctrl-v for paste and use it for quote-next (since shift-
insert is still available for paste). The command prompt simply doesn't
have any way to insert special characters (that I know). The filename
completion characters used to be ctrl-d/ctrl-f, so it was rarely a
conflict. Newer Windows versions use tab by default now, but still have
no quote-next behavior.

Re: tab filename insertion in Windows

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

On 03/25/12 00:21, Tait wrote:
> Something new as of gp 4.6.0 on Windows is that a tab character, entered
> into the interactive terminal, expands into a filename. Can this behavior
> be disabled via some configuration?

Isn't this a bug anyway. I thought the idea of tab completion was that 
you had to hit return of something to accept the intervention. If you 
carry on typing it should just disappear.

regards.

Re: tab filename insertion in Windows

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 24 March 2012, Tait wrote:
> 
> Something new as of gp 4.6.0 on Windows is that a tab character, entered
> into the interactive terminal, expands into a filename. Can this behavior
> be disabled via some configuration?

If you are talking about tab completion in the readline library, 
it can be disabled by putting
    set disable-completion on
in the file ~/.inputrc  (or whatever the Windows equivalent is).

If you are talking about tab completion in the built-in readline code,
I don't see any way to disable it currently.  That seems like a 
reasonable feature to add.

> I often develop files with \-continuations, e.g.
> plot '-' title "nzrgrdr" \
> 	'-' title "ghlallaghp" \
> 	'-' title "xyzpthrtk"
> 
> Note the tab-indent on the line continuations. When I 'load' such a file
> into gnuplot, it works fine, but often in the course of development or
> helping others, I copy-and-paste these into the interactive terminal.
> This worked before, but now breaks because the leading tab expands to a
> filename, which is of course a syntax error.

Hmm. This doesn't happen under linux because the cut-and-paste operation
itself replaces tabs with spaces.  I have no idea whether Windows
can be configured to do the same thing, but that would be another 
work-around you might investigate.

> Vim works around issues like this by using paste detection, but the
> easier solution is probably just to disable filename-expansion. The
> current situation makes it impossible to interactively type anything
> containing a tab. For example, print "x    y       result" even fails
> because the tab cannot be inserted without turning into a filename. The
> usual character-escape or ctrl-v quote-literal terminal tricks that would
> work on *nix do not work on the Windows terminal.

Forgive my Windows ignorance, but...
I can understand that ctrl-V doesn't work here because Windows thinks
that it means "paste" rather than "verbatim".
But isn't there some other control character that is equivalent 
to *nix ctrl-V?

Re: tab filename insertion in Windows

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

On 03/25/12 00:21, Tait wrote:
> I often develop files with \-continuations, e.g.
> plot '-' title "nzrgrdr" \
> 	'-' title "ghlallaghp" \
> 	'-' title "xyzpthrtk"
>
> N

I agree that tab completion is probably unhelpful in a context where a 
tab is a possible input character.

I generally find it more productive to think for myself that to have a 
program try to do it for me and keep breaking my concentration by 
second-guessing what I'm trying to do and jumping in to mess with what 
I'm typing.

Perhaps the feature should be limited to a context were it could 
actually be a filename but that would probably be complicated and 
unreliable. My approach would be to bin it.

BTW if you want to align multi-line plot commands like that I put all 
the plotted files including the first on the extended lines by 
assigning a throw-away variable just after plot. That makes all the 
lines have identical syntax and I can cut and paste to reorder or remove 
them at will.

plot s=0 \
, file1 with lines \
, file2 with lines \
, file3 using 1:2 \
#, file4 tit "test version" \


that would work around your tab problem. This a valid bug though.

regards.

tab filename insertion in Windows

[Tait <gnu...@t4...>]

Something new as of gp 4.6.0 on Windows is that a tab character, entered
into the interactive terminal, expands into a filename. Can this behavior
be disabled via some configuration?

I often develop files with \-continuations, e.g.
plot '-' title "nzrgrdr" \
	'-' title "ghlallaghp" \
	'-' title "xyzpthrtk"

Note the tab-indent on the line continuations. When I 'load' such a file
into gnuplot, it works fine, but often in the course of development or
helping others, I copy-and-paste these into the interactive terminal.
This worked before, but now breaks because the leading tab expands to a
filename, which is of course a syntax error.

Vim works around issues like this by using paste detection, but the
easier solution is probably just to disable filename-expansion. The
current situation makes it impossible to interactively type anything
containing a tab. For example, print "x    y       result" even fails
because the tab cannot be inserted without turning into a filename. The
usual character-escape or ctrl-v quote-literal terminal tricks that would
work on *nix do not work on the Windows terminal.

Fwd: plotting problem solved ?

[Robert D. <rob...@gm...>]

Great, looks like the problem is fixed (in Gnuplot CVS) now.

best

Robert Dodier


---------- Forwarded message ----------
From: joaquin borges <ult...@gm...>
Date: Sun, 18 Mar 2012 20:53:54 -0300
Subject: plotting problem solved ?
To: Robert Dodier <rob...@gm...>

Hi Robert :
This is the output of plot2d(sec(x)*cos(x),[x,-1,1])
with the last changes (less than 60' ago) to gnuplot cvs.
best
joaquin
image attached .

Re: Fwd: [Maxima] still having plotting problem

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 18 March 2012, Yuriy Kaminskiy wrote:
> > Yeah, my suggestion is to run the loop for a number of iterations
> > determined in advance, to avoid floating point problems as much
> > as possible. I've attached a patch -- hope it's useful.

OK. Now in CVS version.

> BTW, I think there should be similar problem with minitics code below.
> And, unlike `tics` case, I don't see any protection against infinite loop there.

But minitics are specified in terms of how many per interval,
not in terms of absolute spacing.  So I think it's safe
(famous last words :-)

	Ethan

Re: Fwd: [Maxima] still having plotting problem

[Yuriy K. <yu...@ma...>]

Robert Dodier wrote:
> On 3/17/12, Ethan Merritt <merritt@u.washington.edu> wrote:
> 
>> So it is annoying that the code, although paranoid about precision,
>> is apparently not paranoid enough.
> 
> Yeah, my suggestion is to run the loop for a number of iterations
> determined in advance, to avoid floating point problems as much
> as possible. I've attached a patch -- hope it's useful.
> 
>> Does it do the same thing if you compile with optimization
>> level -O0 ?
> 
> I dunno -- it's actually somebody else's system, the bug isn't
> triggered on mine.

BTW, I think there should be similar problem with minitics code below.
And, unlike `tics` case, I don't see any protection against infinite loop there.

Re: Fwd: [Maxima] still having plotting problem

[Robert D. <rob...@gm...>]

On 3/17/12, Ethan Merritt <merritt@u.washington.edu> wrote:

> So it is annoying that the code, although paranoid about precision,
> is apparently not paranoid enough.

Yeah, my suggestion is to run the loop for a number of iterations
determined in advance, to avoid floating point problems as much
as possible. I've attached a patch -- hope it's useful.

> Does it do the same thing if you compile with optimization
> level -O0 ?

I dunno -- it's actually somebody else's system, the bug isn't
triggered on mine.

best,

Robert Dodier

Re: Missing demo page: running averages

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

On Sunday, 18 March 2012, Tait wrote:
> 
> The running averages demo for 4.6 seems to be MIA...?
> 
>   http://gnuplot.sourceforge.net/demo_4.6/data_feedback.html
> 
> Sourceforge returns a 404.

Huh. Victim of a demo name-change.
Fixed now.

	Ethan

Missing demo page: running averages

[Tait <gnu...@t4...>]

The running averages demo for 4.6 seems to be MIA...?

  http://gnuplot.sourceforge.net/demo_4.6/data_feedback.html

Sourceforge returns a 404.

Re: Fwd: [Maxima] still having plotting problem

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

On Saturday, 17 March 2012, Robert Dodier wrote:
> Take 2 -- I've now subscribed to gnuplot-beta ...
> 
> Some additional info from Joaquin: he patched axis.c as suggested and
> the observed result is endless repetitions of
> 
> gen_tics: top of loop; start=1.000000e+00, end=1.000000e+00,
> step=1.110223e-16, tic=1.000000e+00
> 
> which shows that Gnuplot is indeed stuck in the loop in axis.c.
> 
> Thanks for any light you can shed on this.

The section of code immediately above the site of your patch
exists exactly for the purpose of preventing such an infinite
loop.  See axis.c lines 1098-1113.
It runs through the same for() loop with an internal
test for making progress through the requested range.

And in fact in your output dump, I can see that the warning
message from this test has been triggered:

     warning: tick interval too small for machine precision

When it issues this warning, the code sets 
	step = end - start;
which is intended to guarantee that the subsequent loop 
	for (tic = start; tic <= end; tic += step)
will terminate the second time through.
This is confirmed by your debug output (at least to the
precision of the values printed).  So it is annoying that
the code, although paranoid about precision, is apparently
not paranoid enough.

Does it do the same thing if you compile with optimization
level -O0 ?

	Ethan



> 
> Robert Dodier
> 
> 
> ---------- Forwarded message ----------
> From: Robert Dodier <rob...@gm...>
> Date: Sat, 17 Mar 2012 14:27:19 -0600
> Subject: Fwd: [Maxima] still having plotting problem
> To: gnu...@li..., ult...@gm...
> 
> Joaquin, thanks for the GDB output.
> 
> Looking at gnuplot/src/axis.c, I see that the call to gprintf
> is within a loop which won't terminate if end + step == end
> or step + end == step (this is possible for very small values of step).
> 
> In order to verify whether that is actually happening, can you
> apply the attached patch (axis.c-patch) and try
> plot "maxout.gnuplot_pipes" in gnuplot again?
> 
> If all is well, you should get a small number of output lines
> and then a plot. If it's actually stuck in that loop, you'll get unending
> output. Let us know how it plays out.
> 
> best
> 
> Robert Dodier
> 
> PS to Gnuplot developers: Maxima generated maxout.gnuplot_pipes
> and then called Gnuplot to plot it. Gnuplot gets stuck.
> gdb_output.txt shows a stack trace. Gnuplot was pulled from CVS
> and compiled on a Ubuntu 10.10 or 11.10 system (I forget which)
> with x86_64 cpu if I remember correctly. When I try the same thing on
> my system (Gnuplot CVS on Ubuntu 8.04 on x86),
> the data are successfully plotted.
> 
> ---------- Forwarded message ----------
> From: joaquin borges <ult...@gm...>
> Date: Sat, 17 Mar 2012 14:15:25 -0300
> Subject: Re: [Maxima] still having plotting problem
> To: Robert Dodier <rob...@gm...>
> 
> On 03/17/2012 02:37 AM, Robert Dodier wrote:
> > Thanks for sending maxout.gnuplot_pipes.
> > When I run gnuplot (4.7 from cvs) it successfully plots the data.
> > So it's hard to figure out what's going on.
> >
> > One idea: can you run Gnuplot within gdb (debugger).
> > If the installed binary has been stripped of symbols,
> > try running the one from the build directory. e.g.
> >
> > $ cd<whatever>/gnuplot
> > $ gdb src/gnuplot
> > <now try the offending data file>
> >
> > When Gnuplot seems to wait forever, hit control-C
> > and then enter the command "where" in gdb.
> > It should give you a stack trace.
> >
> > best
> >
> > Robert Dodier
> >
> Thanks for your reply .
> The output of gdb  is attached
> best
> joaquin
> 

Fwd: [Maxima] still having plotting problem

[Robert D. <rob...@gm...>]

Take 2 -- I've now subscribed to gnuplot-beta ...

Some additional info from Joaquin: he patched axis.c as suggested and
the observed result is endless repetitions of

gen_tics: top of loop; start=1.000000e+00, end=1.000000e+00,
step=1.110223e-16, tic=1.000000e+00

which shows that Gnuplot is indeed stuck in the loop in axis.c.

Thanks for any light you can shed on this.

Robert Dodier


---------- Forwarded message ----------
From: Robert Dodier <rob...@gm...>
Date: Sat, 17 Mar 2012 14:27:19 -0600
Subject: Fwd: [Maxima] still having plotting problem
To: gnu...@li..., ult...@gm...

Joaquin, thanks for the GDB output.

Looking at gnuplot/src/axis.c, I see that the call to gprintf
is within a loop which won't terminate if end + step == end
or step + end == step (this is possible for very small values of step).

In order to verify whether that is actually happening, can you
apply the attached patch (axis.c-patch) and try
plot "maxout.gnuplot_pipes" in gnuplot again?

If all is well, you should get a small number of output lines
and then a plot. If it's actually stuck in that loop, you'll get unending
output. Let us know how it plays out.

best

Robert Dodier

PS to Gnuplot developers: Maxima generated maxout.gnuplot_pipes
and then called Gnuplot to plot it. Gnuplot gets stuck.
gdb_output.txt shows a stack trace. Gnuplot was pulled from CVS
and compiled on a Ubuntu 10.10 or 11.10 system (I forget which)
with x86_64 cpu if I remember correctly. When I try the same thing on
my system (Gnuplot CVS on Ubuntu 8.04 on x86),
the data are successfully plotted.

---------- Forwarded message ----------
From: joaquin borges <ult...@gm...>
Date: Sat, 17 Mar 2012 14:15:25 -0300
Subject: Re: [Maxima] still having plotting problem
To: Robert Dodier <rob...@gm...>

On 03/17/2012 02:37 AM, Robert Dodier wrote:
> Thanks for sending maxout.gnuplot_pipes.
> When I run gnuplot (4.7 from cvs) it successfully plots the data.
> So it's hard to figure out what's going on.
>
> One idea: can you run Gnuplot within gdb (debugger).
> If the installed binary has been stripped of symbols,
> try running the one from the build directory. e.g.
>
> $ cd<whatever>/gnuplot
> $ gdb src/gnuplot
> <now try the offending data file>
>
> When Gnuplot seems to wait forever, hit control-C
> and then enter the command "where" in gdb.
> It should give you a stack trace.
>
> best
>
> Robert Dodier
>
Thanks for your reply .
The output of gdb  is attached
best
joaquin

Re: make install for cvs still make gp450win32-setup.exe

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

Thanks for pointing this out. Fixed in CVS.

   Bastian

Am 12.03.2012 04:38, schrieb Tatsuro MATSUOKA:
> Hello
>
> Because gnuplot 4.6.0 is released, the version of cvs source bumps to 4.7.
> I tried to build using the latest source.
>
> However, make installer
> still builds gp450win32-setup.exe not but gp470win32-setup.exe.
>
> I will try to fix it (config/mingw/Makefile) but I do not aware where to be fixed.
>
> Regards
>
> Tatsuro
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta



-- 
Dr. Bastian Märkisch
Physikalisches Institut, Universität Heidelberg
Philosophenweg 12
69120 Heidelberg
Tel.: +49-6221-549214
Fax: +49-6221-549343

Re: Tarball for 4.6.0 release is available on SourceForge

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

On Mon, Mar 12, 2012 at 04:35, sfeam (Ethan Merritt) wrote:
>
> See above error message. If you mix qt and wxt in a single
> session, the program segfaults.

I saw it, but I thought that whatever patch you applied was supposed
to prevent segfaults.
(Even one explicitly tells users not to do X, the program should still
not segfault.)

Mojca

Re: Qt terminal on Mac & Icon

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

On Mon, Mar 12, 2012 at 04:29, sfeam (Ethan Merritt) wrote:
> On Sunday, 11 March 2012, Mojca Miklavec wrote:
>
>> I think that simply replacing xpm file with svg file either in
>> QtGnuplotResource.qrc or in source code should work
>
> The documentation says:
>  "First, create an ICO format bitmap file that contains the icon image."

Where exactly does it say that?

> So I don't think svg is going to work.

I'm not sure how it is under windows or linux, but it definitely works
under Mac.
(After all, gnuplot includes "export to SVG", so Qt must have SVG support.)

> The documentation then goes on to note that installation of icons under
> OSX and linux varies widely with the platform.  Here's what it says about
> OSX:
>  "To ensure that the correct icon appears, both when the application
>   is being launched, and in the Finder, it is necessary to employ a
>   platform-dependent technique."

Sure. But this is hardly related. I'm not talking about icon "in the
Finder" and I'm not talking about icon under Windows. I'm only talking
about the icon that is seen when Qt window pops up and that one must
be way less platform-dependent if dependent at all.

I have no problem creating Mac-specific icon, but at the moment there
is no single place where I could put it. One has to create a bundled
application and we don't have that, so Mac-specific solution wouldn't
help anyone.

> I have no idea what that means in the context of OSX (isn't it all one
> "platform"?) but anyhow I have no idea how to do anything that works
> cross-platform, and it least from the docs it seems svg is not supported.

I tested it last time and it worked fine for me. But I didn't test on
windows or linux. On the sourceforge page there is a sample program:

#include <QApplication>
#include <QTextEdit>
#include <QIcon>

int main(int argv, char **args)
{
    QApplication app(argv, args);
    QTextEdit textEdit;
    textEdit.show();

    QIcon appIcon;
    appIcon.addFile("icon.svg");
    QApplication::setWindowIcon(appIcon);

    app.exec();
}

I can compile it with (I just copied the flags from gnuplot, some may
not be necessary):
    g++ hello.cpp -I/Library/Frameworks/QtCore.framework/Headers
-I/Library/Frameworks/QtGui.framework/Headers
-I/Library/Frameworks/QtNetwork.framework/Headers
-I/Library/Frameworks/QtSvg.framework/Headers -F/Library/Frameworks
-framework QtCore -framework QtGui -framework QtNetwork -framework
QtSvg -o hello

and when I run it, I get an application with that SVG image as an icon
(when switching between programs with alt-tab and as displayed on
dock). But I can send a patch for gnuplot that does the same.

I didn't test it yet, but in principle it's just about replacing
    setWindowIcon(QIcon(":/images/gnuplot"));
with
    QIcon appIcon;
    appIcon.addFile("icon.svg");
    setWindowIcon(appIcon);
or about changing resource file.

Mojca

make install for cvs still make gp450win32-setup.exe

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

Hello

Because gnuplot 4.6.0 is released, the version of cvs source bumps to 4.7.
I tried to build using the latest source.

However, make installer 
still builds gp450win32-setup.exe not but gp470win32-setup.exe.

I will try to fix it (config/mingw/Makefile) but I do not aware where to be fixed.

Regards

Tatsuro

Re: Tarball for 4.6.0 release is available on SourceForge

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 11 March 2012, Mojca Miklavec wrote:
> On Fri, Mar 9, 2012 at 05:50, sfeam (Ethan Merritt)  wrote:
> > I have uploaded a tarball for the 4.6.0 release to SourceForge,
> > along with the planned release announcement and a PDF copy of the
> > User Manual.  These should propagate to mirrors by tomorrow.
> >
> > You are welcome to test it now, and let me know if you encounter
> > any problems.
> 
> I finally managed to compile Qt after patching gnuplot configuration a
> bit. Here's a simple test that segfaults:
> 
> Terminal type set to 'aqua'
> gnuplot> set term wxt
> Terminal type set to 'wxt'
> Options are '0'
> gnuplot> plot sin(x)
> gnuplot> set term qt
> Terminal type set to 'qt'
>          The qt terminal cannot be used in a wxt session
> 
> gnuplot> exit
> Segmentation fault: 11
> 
> Mojca

See above error message. If you mix qt and wxt in a single
session, the program segfaults. The program tries to prevent
this by refusing to execute the "set term" command in such a
case.  On linux this is sufficient to return you to a normal
prompt and the current terminal type "unknown".  Perhaps
adding "aqua" to the mix makes the problem one notch worse?
I don't know.  Anyhow - for the foreseeable future the answer
is "don't do that".  This is already listed as a known
limitation in the Release Notes, by the way.

	cheers,

		Ethan

Re: Qt terminal on Mac & Icon

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 11 March 2012, Mojca Miklavec wrote:
> On Fri, Mar 9, 2012 at 06:14, sfeam (Ethan Merritt) wrote:
> > On Sunday, 04 March 2012, Mojca Miklavec wrote:
> >>
> >> Also, is there any chance to use some high resolution icon? I have
> >> created some PDF and SVG examples based on the original 16x16 image.
> >> I'm attaching a SVG (it has a tiny flaw though
> >
> > How does one "use" the icon?  Do you just mean we would include it
> > in the distribution, for distro packages to copy into their preferred
> > icon directory during installation?
> 
> No, at the moment Qt terminal uses
>     setWindowIcon(QIcon(":/images/gnuplot"));
> which takes the icon
>     src/qtterminal/images/icon32x32.xpm
> based on information
>     <file alias="images/gnuplot">images/icon32x32.xpm</file>
> from
>     src/qtterminal/QtGnuplotResource.qrc
> 
> I think that simply replacing xpm file with svg file either in
> QtGnuplotResource.qrc or in source code should work

The documentation says:
  "First, create an ICO format bitmap file that contains the icon image."

So I don't think svg is going to work.
The documentation then goes on to note that installation of icons under
OSX and linux varies widely with the platform.  Here's what it says about
OSX:
  "To ensure that the correct icon appears, both when the application
   is being launched, and in the Finder, it is necessary to employ a 
   platform-dependent technique."

I have no idea what that means in the context of OSX (isn't it all one
"platform"?) but anyhow I have no idea how to do anything that works
cross-platform, and it least from the docs it seems svg is not supported.

But as always, if you send a patch I'd be happy to try it out on
my test machines.

	Ethan




> (but I'm currently
> unable to compile Qt terminal to be able to test). Assuming that you
> are happy with the SVG image of course.
> 
> >> : its vertical and
> >> horizontal line widths are slightly distorted, but I can create an
> >> image that is not if that "defect" is visible). The SVG could be used
> >> for icon in Qt. Of course one could try to create a better/nicer/3D
> >> icon, but at the moment having one high resolution (in this cane a
> >> vector image) would already be much better than having 32x32 pixels. I
> >> guess that this is not visible on Linux, but you can see how it
> >> compares with other programs on
> >>     http://sourceforge.net/tracker/download.php?group_id=2055&atid=352055&file_id=432231&aid=3469808
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Tarball for 4.6.0 release is available on SourceForge

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

On Fri, Mar 9, 2012 at 05:50, sfeam (Ethan Merritt)  wrote:
> I have uploaded a tarball for the 4.6.0 release to SourceForge,
> along with the planned release announcement and a PDF copy of the
> User Manual.  These should propagate to mirrors by tomorrow.
>
> You are welcome to test it now, and let me know if you encounter
> any problems.

I finally managed to compile Qt after patching gnuplot configuration a
bit. Here's a simple test that segfaults:

Terminal type set to 'aqua'
gnuplot> set term wxt
Terminal type set to 'wxt'
Options are '0'
gnuplot> plot sin(x)
gnuplot> set term qt
Terminal type set to 'qt'
         The qt terminal cannot be used in a wxt session

gnuplot> exit
Segmentation fault: 11

Mojca