gnuplot development

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.

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?

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.

> > 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.

> 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.

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 <robert.dodier@...>
> Date: Sat, 17 Mar 2012 14:27:19 -0600
> Subject: Fwd: [Maxima] still having plotting problem
> To: gnuplot-beta@..., ultradenso@...
> 
> 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 <ultradenso@...>
> Date: Sat, 17 Mar 2012 14:15:25 -0300
> Subject: Re: [Maxima] still having plotting problem
> To: Robert Dodier <robert.dodier@...>
> 
> 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
>

On 3/17/12, Ethan Merritt <merritt@...> 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

Robert Dodier wrote:
> On 3/17/12, Ethan Merritt <merritt@...> 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.

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

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

best

Robert Dodier


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

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 .

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

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
> gnuplot-beta@...
> 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

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

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

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

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 (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

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
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

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