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

Re: Bind <space> to builtin_raise in mouse.c

[<tim...@en...>]

> Even still, as this currently works on my X11 system the space bar does=
n't
> even "raise the console"; it merely gives the console focus.  So, one
> presses the space bar on top of a plot and can type a command to
> regenerate a plot.  It works, but if there is some other window origina=
lly
> obscuring the console, one can't see the letters as typed which is
> somewhat dodgy, because then you are forced to go back to the windowing
> menu bar anyway.

Hmm... It may not be what you wanted to say, but we can take that as an
extra argument to remove the feature, i.e .there's another obstacle that
makes it unreliable : the focus-stealing-prevention mechanism that is
activated by default on several desktops.

> Furthermore, wouldn't it be prefered that if one typed a space in the p=
lot
> in question then entered a command that it would be the plot in which t=
he
> space bar was typed that will change (i.e., an inherent "set term x11 #=
")?

That's an interesting idea, which goes along with the fact that the
multiple_plot_windows feature is currently very limited (i.e. only one
really active window).



> It's a reasonable feature to want in some way.  That is, "I have this p=
lot
> and I want to know where the console is that it originated from".  (But
> right, if there is some networking to outside computers and back into a=
n X
> window, then it makes no sense.)  I suppose the X11 manager would be ju=
st
> as good for finding this console.

That makes me think of a different approach to associate a console window
and a plot window : make the prompt and the window title change
accordingly.

Advantage : both of them are really managed by gnuplot, so that is
reliable and cross-platform.
Drawback : not as straightforward,

For example, the first instance of gnuplot would have the prompt
"gnuplot>", and the window would be entitled "gnuplot", a second instance
could have the prompt "gnuplot(2)>", and the window would be entitled
"gnuplot(2)", etc.

Many programs I know are able to recognize if an instance is already
running. So I guess we could be able to do it too, and to use this
information to change the prompt.

Is that satisfying ?

Timoth=E9e

Re: Bind <space> to builtin_raise in mouse.c

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

Ethan Merritt wrote:
> On Wednesday 26 April 2006 11:54 am, Daniel J Sebald wrote:
> 
> 
>>But I can also see the argument of keeping 'q' as close because 
>>then it remains consistent for gnuplot no matter what platform 
>>you move to, say temporarily.
> 
> 
> The consistency I want is among all windows currently on my screen,
> whatever program they might belong to.  If tomorrow I use
> some other computer or desktop where the "close window"
> hotkey is <ctrl-z> rather than <alt-F4>, that's annoying
> but at least it's a global rule.  If every application has
> its own set of bindings, I am bound to type the wrong thing
> to the wrong window and close something I didn't intend.
> 
> So if people want the ability to bind "q" to "quit" or
> "close window", fine.  But it should not be hard-wired;
> it should be just one more "bind" command.

I can go along with that.  Just put the bind commands in one's .gnuplot file and problem solved.

Dan

Re: Bind <space> to builtin_raise in mouse.c

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

On Wednesday 26 April 2006 11:54 am, Daniel J Sebald wrote:

> But I can also see the argument of keeping 'q' as close because 
> then it remains consistent for gnuplot no matter what platform 
> you move to, say temporarily.

The consistency I want is among all windows currently on my screen,
whatever program they might belong to.  If tomorrow I use
some other computer or desktop where the "close window"
hotkey is <ctrl-z> rather than <alt-F4>, that's annoying
but at least it's a global rule.  If every application has
its own set of bindings, I am bound to type the wrong thing
to the wrong window and close something I didn't intend.

So if people want the ability to bind "q" to "quit" or
"close window", fine.  But it should not be hard-wired;
it should be just one more "bind" command.

Mea culpa. I was the one that added a special exception
X-resource to make the hard-wired key <ctrl-q> rather than <q>.
That was a hack rather than a proper fix.
Making it a configurable binding is a much cleaner solution.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Bind <space> to builtin_raise in mouse.c

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

On Wednesday 26 April 2006 10:27 am, Timoth=C3=A9e Lecomte wrote:
> I have found another poor alternative : using xterm control sequences.
> [...] the  "<esc>[5t" as "raise the window" when xterm is in  VT100 mode=
=20
> (Does it mean that it won't work if xterm is in a different mode ?

Correct. It does not work if you switch to Tek mode.
Probably no one uses Tek mode any more, but then again not everyone
is using a vt100-style xterm in the first place.  The KDE and Gnome
terminals may be more common.
=20
> On the short-run, I may let it in the wxWidgets terminal as it is
> currently : has to be linked with Xlib (or gdk, as it is already needed
> for raise_plot_window_but_don_t_give_it_the_focus ), or Windows.h (not a
> problem), or os2.h (not a problem either).

It is of course OK for an outboard (external) terminal driver to link
against its own support libraries.
=20
> Any other idea ?

Give up on the whole idea of a generic mechanism for raising the console.
It was not well thought out to begin with, and in fact is not even a
well-defined operation.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Bind <space> to builtin_raise in mouse.c

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

Timoth=E9e Lecomte wrote:

>=20
>>>Any other idea ?
>>
>>Give up on the whole idea of a generic mechanism for raising the consol=
e.
>>It was not well thought out to begin with, and in fact is not even a
>>well-defined operation.

It's a reasonable feature to want in some way.  That is, "I have this plo=
t and I want to know where the console is that it originated from".  (But=
 right, if there is some networking to outside computers and back into an=
 X window, then it makes no sense.)  I suppose the X11 manager would be j=
ust as good for finding this console.

Even still, as this currently works on my X11 system the space bar doesn'=
t even "raise the console"; it merely gives the console focus.  So, one p=
resses the space bar on top of a plot and can type a command to regenerat=
e a plot.  It works, but if there is some other window originally obscuri=
ng the console, one can't see the letters as typed which is somewhat dodg=
y, because then you are forced to go back to the windowing menu bar anywa=
y.

Furthermore, wouldn't it be prefered that if one typed a space in the plo=
t in question then entered a command that it would be the plot in which t=
he space bar was typed that will change (i.e., an inherent "set term x11 =
#")?

>=20
>=20
> I second this, and here are some extra arguments :
> * it will make the bindings system more consistent, as the spacebar wil=
l
> be completely treated as other keys (as the discussed patch was suppose=
d
> to do)
> * it will make the spacebar be a valid key to return from a pause (it i=
s
> not the case on X11 unless you have set the ctrlq resource)
> * it won't break old scripts as it is only an interactive feature
>=20
> If we finally choose this alternative, I would also drop the bound betw=
een
> 'q' and 'close this window' :

This doesn't have the networking problem that Ethan described, but if Alt=
-F4 works that's good.  But I can also see the argument of keeping 'q' as=
 close because then it remains consistent for gnuplot no matter what plat=
form you move to, say temporarily.

Dan

Re: Bind <space> to builtin_raise in mouse.c

[<tim...@en...>]

> On Wednesday 26 April 2006 10:27 am, Timoth=C3=A9e Lecomte wrote:
>> On the short-run, I may let it in the wxWidgets terminal as it is
>> currently : has to be linked with Xlib (or gdk, as it is already neede=
d
>> for raise_plot_window_but_don_t_give_it_the_focus ), or Windows.h (not=
 a
>> problem), or os2.h (not a problem either).
>
> It is of course OK for an outboard (external) terminal driver to link
> against its own support libraries.

Note that currently, the wxWidgets terminal is not external, i.e. it is
compiled in the main executable, so the latter is linked with wxWidgets,
cairo, and friends.

>> Any other idea ?
>
> Give up on the whole idea of a generic mechanism for raising the consol=
e.
> It was not well thought out to begin with, and in fact is not even a
> well-defined operation.

I second this, and here are some extra arguments :
* it will make the bindings system more consistent, as the spacebar will
be completely treated as other keys (as the discussed patch was supposed
to do)
* it will make the spacebar be a valid key to return from a pause (it is
not the case on X11 unless you have set the ctrlq resource)
* it won't break old scripts as it is only an interactive feature

If we finally choose this alternative, I would also drop the bound betwee=
n
'q' and 'close this window' :
* it is the role of the window manager to close the window, usually alt-F=
4
already does it
* it will make the bindings system completely consistent if 'q' is part o=
f
it (not the case on X11 unless you set the ctrlq resource)
* again, it won't break old scripts as it is only an interactive feature

With the wxWidgets terminal, we introduce a brand-new terminal with a
different visual aspect, so it is the right time to make these changes if
we can agree that they make sense.

Timoth=E9e

Re: Bind <space> to builtin_raise in mouse.c

[<tim...@en...>]

> You are relying on a fragile mechanism that happens to
> work on a common configuration.  But "common" is a very long
> way from universal.  As I said, I use gnuplot + x11 every day,
> and every day at least some of those uses do not follow
> the model you are assuming.  If the feature is truely useful,
> then let us try to find a way to make it work for more
> cases than it does now.
>
> --
> Ethan A Merritt

There is something basically strange in this feature : it involves to
control a console, which is not guaranteed to be in a managed window,
except on Windows.

Currently, we rely on WINDOWID for xterm and xterm-like, with a special
case for konsole, because Petr has been willing to implement it. This
implies to link 'something' with Xlib.

I have found another poor alternative : using xterm control sequences. If
you look at this page : http://www.xfree86.org/snapshot/ctlseqs.html or
http://www.isri.unlv.edu/~slumos/hacks/xtctl , you will find that xterm
understand the sequence "=1B[5t" as "raise the window", when xterm is in
VT100 mode (Does it mean that it won't work if xterm is in a different
mode ? I'm not sure of this.)

For example, try the attached script (where I replaced 5 by 6) from a
xterm : it will lower the window.

That means that we can use something like system(echo -n "<something>") t=
o
handle this instead of linking with Xlib. Of course, it may not work on
other terminals (gnome ?, rxvt ?). It does not work on konsole, but we
already have a special case for konsole, using dcop.

In any case, the current patch has a drawback : it relies on the
processing of terminal events by the core, so as far as I understand, the
spacebar would only work when the interactive terminal is the one
currently active in gnuplot. This may be considered as a regression
compared to the current behaviour. Petr, as you seem to be the only one
using it, do you think it is a regression ?


On the short-run, I may let it in the wxWidgets terminal as it is
currently : has to be linked with Xlib (or gdk, as it is already needed
for raise_plot_window_but_don_t_give_it_the_focus ), or Windows.h (not a
problem), or os2.h (not a problem either).


Any other idea ?

Timoth=E9e

Re: Bind <space> to builtin_raise in mouse.c

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

On Tuesday 25 April 2006 11:12 am, Petr Mikulik  wrote:
> It should work as it works now.
> 
> Thus: if you run gnuplot on the computer you sit at, the spacebar raises the 
> gnuplot console.

Try this:

$ ssh localhost
$ gnuplot
gnuplot> set term x11
gnuplot> plot x


You will see the plot as normal, assuming you have
ssh-tunneling enabled for X. 
But the spacebar will not work, because your terminal and your
plot window are using different X-display paths. Same machine,
same executable, but a different connection path for X.
So it really is not a question of where you are sitting,
or which machine gnuplot is running on.

You are relying on a fragile mechanism that happens to
work on a common configuration.  But "common" is a very long
way from universal.  As I said, I use gnuplot + x11 every day,
and every day at least some of those uses do not follow
the model you are assuming.  If the feature is truely useful,
then let us try to find a way to make it work for more
cases than it does now.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Bind <space> to builtin_raise in mouse.c

[Petr M. <mi...@ph...>]

> I think we should remove it and try to find a different way
> of doing what you want.

It should work as it works now.

Thus: if you run gnuplot on the computer you sit at, the spacebar raises the 
gnuplot console.

---
PM

Bind <space> to builtin_raise in mouse.c

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

I'm getting tired of going through the SourceForge patches interface,
so I'm pulling this over to normal Email.

Timoth=E9e wrote>
>So the trick can be :
>* check for WINDOWID, if it is set go on and use the x11 code

But you can't use the existing code, because as you point out
yourself the external program gnuplot_x11 is not running if
the current terminal is set to wx or pm.

And if you pull the code out of gnuplot_x11 and put it in=20
the core code, well.. that's crazy.  There should be no X
dependence in the core code.  Particularly if we all switch over
and use the wxWidgets terminal, since we wouldn't even need to
build in the x11 terminal at all :-) :-)

>* if WINDOWID is not set, do :
>     HSWITCH hswitch =3D WinQuerySwitchHandle(0,getpid());
>  then check for errors with WinGetLastError, which would  =20
>  mean that the console window is not managed by PM, and
>  continue with WinSwitchToProgram if it's ok.

WINDOWID not set can mean many things. It certainly is not
proof that you are not running on x11.

Let me give you a real-world example, one that I encounter
almost every day.  I work from home in the evening, but often
log in to the lab computers to do so.  In that case I am=20
running in an xterm session *on my home computer*, from which
I have used ssh to log in to a lab computer.  If I need to
check a job result quickly, I will run gnuplot on the lab
computer with the display set back to my home machine.
But there is no WINDOWID in gnuplot's environment because
it is not running on the same machine as the window it is
running in. =20

=46urthermore, even when sitting at my desk in the lab, I
often ssh to other machines and use gnuplot over the ssh
link.  Again WINDOWID does not exist, or if it does it
points to a window on the wrong X-server. =20

This whole mechanism *DOES NOT WORK* in the general case,
and by that I mean in my normal daily use.


Petr:=20
You obviously are running gnuplot in a certain
configuration where this "raise window XXX" makes sense,
so you think everything is functions reasonably.  But it doesn't.
Really it doesn't.

I think we should remove it and try to find a different way
of doing what you want.

Can we step back and start over again with a clear=20
statement of what is the capability that you need?
Maybe it requires a Raise event and maybe it doesn't.
Labels?  Spatial proximity?  Tabbed windows?=20
Color-coded windows?

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: What's left for a 4.2 release? [drivers]

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

Some comments on the Windows bugs:
Since I only have access to Win XP and Win 2000 I can only test on these
machines. Especially the printing problems seem to be related to Win 9x.
I cannot reproduce them on Win XP.

Petr Mikulik wrote:
> Thanks for these reports ...
>>> Bugs:
>>>
>>> windows:
>>> #1413021        [Wgnuplot] pause 1;reread; blocks interaction
This is reproducible. Question is if it qualifies as a bug.
wgnuplot cannot handle any user interaction while it is
running a script. That's a design issue which would need some
effort to change. At least does current behaviour seem to
be non-obvious to users. I'll have a look at it when time permits.

>>> #561418         (MS Windows) 100% CPU Usage during pause
I have never seen a behavior like this.

>>> #982293         can't print color in win32 gnuplot 4.0
>>> #233405         WGNUPL32.EXE crashes when printing directly (Win 95)
All of this works just fine on my system. But that's XP...

There's one more issue: current CVS builds crash on a Win NT4
system on startup. I suspect this has to do with my
'appdata-code' which I just cannot get right :-( I do not
have access to NT4 or Win9x. Could somebody help me out here?

Bastian

Re: Problems with cvs access

[Petr M. <mi...@ph...>]

> I have temporarily placed a tarball snapshot of the cvs source
> on my website
>
> http://www.bmsc.washington.edu/people/merritt/gnuplot/gnuplot-4.1.0.tar.gz

Thus, now it has appeared also on the gnuplot web page, Development => 
Binaries, e.g.

 	http://gnuplot.sourceforge.net/development/binaries/

We may consider to update it from time to time.

> Given the continuing SourceForge problems, it would be nice to
> put such a snapshot somewhere on the project's "Files" web page.
> Unfortunately, I don't know how to do that.

I don't know either, so put it there above.

---
PM

Re: Problems with cvs access

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

Ethan Merritt wrote:
> On Friday 21 April 2006 10:17 am, Koen Smets wrote:
> 
>>After looking at the demo of the beta release 4.1, I was very pleased
>>with the results of the histogram plots.
>>
>>Is there a chance that I can download a snapshot of the beta release?
>>CVS is like many SFs projects not longer available, and I really like
>>to include some nice plots to my master thesis using gnuplot.
> 
> 
> I have temporarily placed a tarball snapshot of the cvs source
> on my website
> 
>  http://www.bmsc.washington.edu/people/merritt/gnuplot/gnuplot-4.1.0.tar.gz
> 
> Given the continuing SourceForge problems, it would be nice to
> put such a snapshot somewhere on the project's "Files" web page.
> Unfortunately, I don't know how to do that.  Anyone?

And a very large notice on the front of the info page about S.F.'s CVS problem to catch people's attention.

Dan

[Fwd: Re: Problems with cvs access]

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

See comments below.

-------- Original Message --------
Subject: Re: Problems with cvs access
Date: Fri, 21 Apr 2006 10:27:10 -0700
From: Ethan Merritt <merritt@u.washington.edu>
Organization: University of Washington
To: gnu...@li..., "Koen Smets" <koe...@gm...>
References: <776...@ma...>

On Friday 21 April 2006 10:17 am, Koen Smets wrote:
> 
> After looking at the demo of the beta release 4.1, I was very pleased
> with the results of the histogram plots.
> 
> Is there a chance that I can download a snapshot of the beta release?
> CVS is like many SFs projects not longer available, and I really like
> to include some nice plots to my master thesis using gnuplot.

I have temporarily placed a tarball snapshot of the cvs source
on my website

 http://www.bmsc.washington.edu/people/merritt/gnuplot/gnuplot-4.1.0.tar.gz

Given the continuing SourceForge problems, it would be nice to
put such a snapshot somewhere on the project's "Files" web page.
Unfortunately, I don't know how to do that.  Anyone?
	

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
gnuplot-beta mailing list
gnu...@li...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: Patch to remove VERIFY_PIXELS

[<br...@ph...>]

Daniel J Sebald wrote:
> Here's a patch that removes the code and configuration for verifying all 
> points of an image form an equispaced grid.  Simple removal.

Checked in.

Re: download problems...

[<br...@ph...>]

John Westbrook wrote:

> I am unable to access the anonymous cvs download -   The login command
> hangs after a 'return' is entered for a password and finally returns
> an abort message.   Any ideas?

Anonymous CVS to SourceForge is still down after a severe server problem 
end of March.  There's nothing you or we could do about it.  SourceForge 
staff has to fix this, but they can't work miracles.

Patch to remove VERIFY_PIXELS

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

Here's a patch that removes the code and configuration for verifying all points of an image form an equispaced grid.  Simple removal.

Dan

download problems...

[John W. <jw...@rc...>]

I am unable to access the anonymous cvs download -   The login command
hangs after a 'return' is entered for a password and finally returns
an abort message.   Any ideas?

cvs -d:pserver:ano...@cv...:/cvsroot/gnuplot login

Logging in to :pserver:ano...@cv...:2401/cvsroot/gnuplot

CVS password:

cvs [login aborted]: end of file from server (consult above messages if any)

Thanks,

John

Re: Problems with cvs access

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

On Friday 21 April 2006 10:17 am, Koen Smets wrote:
> 
> After looking at the demo of the beta release 4.1, I was very pleased
> with the results of the histogram plots.
> 
> Is there a chance that I can download a snapshot of the beta release?
> CVS is like many SFs projects not longer available, and I really like
> to include some nice plots to my master thesis using gnuplot.

I have temporarily placed a tarball snapshot of the cvs source
on my website

 http://www.bmsc.washington.edu/people/merritt/gnuplot/gnuplot-4.1.0.tar.gz

Given the continuing SourceForge problems, it would be nice to
put such a snapshot somewhere on the project's "Files" web page.
Unfortunately, I don't know how to do that.  Anyone?
	

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Problems with cvs access

[Koen S. <koe...@gm...>]

Hello,

After looking at the demo of the beta release 4.1, I was very pleased
with the results of the histogram plots.

Is there a chance that I can download a snapshot of the beta release?
CVS is like many SFs projects not longer available, and I really like
to include some nice plots to my master thesis using gnuplot.

Thanks in advance!

Grtz, Koen

--
Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning.
  --Rich Cook--

Re: "z2range" ?

[<br...@ph...>]

Nathalie Capron-Joubert wrote:

> but I would like to know if there is a possibility
> of "z2range" in order to "splot" 2 series of data
> on the same graph

No.  splot generally has no secondary axes --- no x2, no y2, and no z2 
either.

> "valid set options:  [] = choose one, {} means optional
> 'title', 'view', '[xyz]{2}data', '[xyz]{2}label', '[xyz]{2}range', "

That's shorthand motivated by the need to squeeze all the available 
options into a manageably-sized screen blurb.  If you really want to 
know what there is, please consult the real documentation:
		
	help set

"z2range" ?

[Nathalie Capron-J. <nc...@cc...>]

Dear Developpers,

Sorry to disturb you
but I would like to know if there is a possibility
of "z2range" in order to "splot" 2 series of data
on the same graph

when I write it after the prompt, the "help" gives me this information
but it doesn't seem to be in use :

"valid set options:  [] = choose one, {} means optional
'title', 'view', '[xyz]{2}data', '[xyz]{2}label', '[xyz]{2}range', "

Thank you in advance for your answer
Sincerely yours
Nathalie

***********************************************
Dr Nathalie Capron-Joubert
Maitre de Conferences
Universite Pierre et Marie Curie
Laboratoire de Chimie Physique
11 rue Pierre et Marie Curie
75231 Paris Cedex 05
Tel 01 44 27 62 55
Fax 01 44 27 62 26
http://www.lcpmr.upmc.fr/simulation.html
***********************************************

Re: How to disable/ignore "pause"?

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

On 4/18/06, Hans-Bernhard Br=F6ker  wrote:
> Mojca Miklavec wrote:
> > I have a gnuplot.bat with
> >     c:\path-to-wgnuplot.exe %*
>
> Calling that batch file gnuplot.bat instead of wgnuplot.bat is creating
> smoke screen that hides the crucial detail: that you're doing this on MS
> Windows.

I'm sorry that I forgot to mention that. I wasn't aware that gnuplot
in windows behaves differently from the rest of the terminals in this
respect.

> That's one single gnuplot platform where pause -1 can't detect
> that stdin was redirected (because Win32 GUI apps like wgnuplot don't
> *have* a stdin, so nothing to redirect), and therefore the usual method
> of short-circuiting pause -1 doesn't work.

So is there any remedy for that? Could I set any variable which will
explicitely tell gnuplot to ignore pauses?

> > I'm still using the "old" windows terminal. Perhaps wxwidgets behave be=
tter.
>
> IIRC it doesn't.  Wxwidgets only replaces the graph window, but not the
> text console window, nor the pause window.
>
> > I'm not piping (I guess).
>
> Correctly.  To pipe, you would have to use pgnuplot, not wgnuplot.

How can I compile gnuplot so that I would get pgnuplot instead of
wgnuplot? What's the main difference between the two variants?

Thanks a lot,
    Mojca

Re: How to disable/ignore "pause"?

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

On 4/20/06, Hans-Bernhard Br=F6ker wrote:
> Mojca Miklavec wrote:
> > On 4/18/06, Hans-Bernhard Br=F6ker  wrote:
> >> Mojca Miklavec wrote:
> >>> I have a gnuplot.bat with
> >>>     c:\path-to-wgnuplot.exe %*
> >> Calling that batch file gnuplot.bat instead of wgnuplot.bat is creatin=
g
> >> smoke screen that hides the crucial detail: that you're doing this on =
MS
> >> Windows.
> >
> > I'm sorry that I forgot to mention that. I wasn't aware that gnuplot
> > in windows behaves differently from the rest of the terminals in this
> > respect.
>
> It's not the terminal that behaves differently --- it's the console that
> handles text I/O for the gnuplot command line.  Windows originally
> didn't have the notion of a console program at all, back when gnuplot
> was ported to this platform (16-bit Windows 3.x).  So the people back
> then had to create their own poor-man's equivalent of xterm: the
> wgnuplot text window.  This is a graphical window handling non-graphical
> text input and output.  But it has no connection to the concept of a
> stdin or stdout channel.
>
> I've been working on and off on a re-write of this part of the Windows
> port, to use a genuine Win32 console instead of our home-grown one.  If
> that ever bears fruit, it'll solve this problem.  Until then, you can't
> wgnuplot to pipe in or out.
>
> > So is there any remedy for that? Could I set any variable which will
> > explicitely tell gnuplot to ignore pauses?
>
> No.
>
> > How can I compile gnuplot so that I would get pgnuplot instead of
> > wgnuplot?
>
> You can't.  pgnuplot is not a variant of wgnuplot, it's built as a
> separate, small program that communicates with wgnuplot.
>
> If you want a fully console-compatible gnuplot on Win32, you have to get
> the Cygwin binary.  The delivered package of that uses and requires X11,
> but you can also build a console-only one by disabling X11.

OK, thanks for the explanations. I'll compile the demo files on a
linux box then, write a note to the users of the module about that and
wait for the next & better version of the windows terminal for gnuplot
;)

Mojca

Re: How to disable/ignore "pause"?

[<br...@ph...>]

Mojca Miklavec wrote:
> On 4/18/06, Hans-Bernhard Bröker  wrote:
>> Mojca Miklavec wrote:
>>> I have a gnuplot.bat with
>>>     c:\path-to-wgnuplot.exe %*
>> Calling that batch file gnuplot.bat instead of wgnuplot.bat is creating
>> smoke screen that hides the crucial detail: that you're doing this on MS
>> Windows.
> 
> I'm sorry that I forgot to mention that. I wasn't aware that gnuplot
> in windows behaves differently from the rest of the terminals in this
> respect.

It's not the terminal that behaves differently --- it's the console that 
handles text I/O for the gnuplot command line.  Windows originally 
didn't have the notion of a console program at all, back when gnuplot 
was ported to this platform (16-bit Windows 3.x).  So the people back 
then had to create their own poor-man's equivalent of xterm: the 
wgnuplot text window.  This is a graphical window handling non-graphical 
text input and output.  But it has no connection to the concept of a 
stdin or stdout channel.

I've been working on and off on a re-write of this part of the Windows 
port, to use a genuine Win32 console instead of our home-grown one.  If 
that ever bears fruit, it'll solve this problem.  Until then, you can't 
wgnuplot to pipe in or out.

> So is there any remedy for that? Could I set any variable which will
> explicitely tell gnuplot to ignore pauses?

No.

> How can I compile gnuplot so that I would get pgnuplot instead of
> wgnuplot? 

You can't.  pgnuplot is not a variant of wgnuplot, it's built as a 
separate, small program that communicates with wgnuplot.

If you want a fully console-compatible gnuplot on Win32, you have to get 
the Cygwin binary.  The delivered package of that uses and requires X11, 
but you can also build a console-only one by disabling X11.