Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-13 22:07:35
|
While I was trying to use the term->suspend() and term->resume()
API to implement Harald Harders' treatment of front/back text labels
in epslatex, I discovered that it is pretty much useless.
The suspend() and resume() functions are only called if you are
in interactive mode. That makes them pretty much worthless,
so far as I can see.
On terminals that actually need use routines (amiga svga pm vgagl),
has mulitplot never worked in scripts or via load commands?
Documentation in term/README is not very enlightening. It says
TERM_CAN_MULTIPLOT - driver can do multiplot fully-interactively
when output is not redirected.
I had never imagined this was meant to imply that a terminal could
*not* multiplot if the output *is* redirected.
Is there any reason we should not correct this oversight, and
call suspend/resume regardless of whether the interactive flag
is set?
If that would for some reason make one of these old drivers unhappy,
we could add a new terminal flag TERMINAL_ALWAYS_MULTIPLOTS
to indicate that multiplot mode is possible in both interactive
and non-interactive mode.
Alternatively, the terminal drivers themselves could make the
decision whether to ignore suspend() if not in interactive mode.
The caller would not have to guess the drivers preference.
Or more radically, can we remove suspend() and resume() altogether?
The small number of terminals that use them could be modified to
instead implement the same new API call I blocked out for epslatex.
I previously used the name term->sync(), but it could as well be
term->private() or term->miscellaneous or term->layer() or whatever.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Robert H. <en...@no...> - 2005-07-14 10:20:54
|
On Wed, 2005-07-13 at 15:07 -0700, Ethan Merritt wrote: > The suspend() and resume() functions are only called if you are > in interactive mode. That makes them pretty much worthless, > so far as I can see. I was bitten by this early on when writing my opengl terminal -- whatever the original purpose of these commands doesn't seem to fit well with whatever it was I was trying to do. I think I now have it that GL_graphics calls GL_resume and GL_suspend calls GL_text (yes I know this is odd, but GL_graphics does some stuff before calling GL_resume that only needs to be done once). This seems to work for both interactive and scripted operation. Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Dave D. <dde...@es...> - 2005-07-14 11:01:22
|
Ethan Merritt <merritt@u.washington.edu> writes:
> While I was trying to use the term->suspend() and term->resume()
> API to implement Harald Harders' treatment of front/back text labels
> in epslatex, I discovered that it is pretty much useless.
>
> The suspend() and resume() functions are only called if you are
> in interactive mode. That makes them pretty much worthless,
> so far as I can see.
>
it was probably me that added them.
IIRC it was for things like linux vga mode, or kermit tektronix
mode, where there is one physical display, but separate logical
text and graphics displays (whose contents are maintained
independently). Switching to text mode does not clear the graphics,
just selects the text mode. This allows the user to type in the
next command without clearing the graphics that have been rendered so
far (which is required for multiplot mode).
> On terminals that actually need use routines (amiga svga pm vgagl),
> has mulitplot never worked in scripts or via load commands?
>
sure. Since it doesn't need to prompt the user for more input, it can
just stay in graphics mode and continue generating graphics.
definitely worked when I added that feature, but that would have been
a long time ago (3.6 era).
> Documentation in term/README is not very enlightening. It says
>
> TERM_CAN_MULTIPLOT - driver can do multiplot fully-interactively
> when output is not redirected.
>
> I had never imagined this was meant to imply that a terminal could
> *not* multiplot if the output *is* redirected.
>
No. My assumption was that if the output is redirected to a file, it
does not conflict with interactive mode.
eg postscript :
gnuplot> set term post
gnuplot> set multi
lots of output generated, followed by
showpage
Must set output to a file or put all multiplot commands on one input line
gnuplot>
because postscript cannot suspend the graphics when the output is
going to stdout.
But if I do
gnuplot> set multi ; plot sin(x) ; plot cos(x) ; unset multi
I get the whole (useless) graph on stdout, because there was no need
to collect more input during the generation of the output.
> Is there any reason we should not correct this oversight, and
> call suspend/resume regardless of whether the interactive flag
> is set?
Well, with linux vga, it would mean the monitor switching back and
forth to text mode, which ISTR was rather unpleasant.
dd
--
Dave Denholm <dde...@es...> http://www.esmertec.com
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-14 14:03:03
|
Ethan Merritt wrote:
> While I was trying to use the term->suspend() and term->resume()
> API to implement Harald Harders' treatment of front/back text labels
> in epslatex, I discovered that it is pretty much useless.
I strongly suspect that to be a premature conclusion.
> The suspend() and resume() functions are only called if you are
> in interactive mode.
Not so.
Here's the relevant snippet from term.c:term_check_multiplot_ok(),
reindented for legibility.
if (!f_interactive
|| (term->flags & TERM_CAN_MULTIPLOT)
|| ((gpoutfile != stdout)
&& !(term->flags & TERM_CANNOT_MULTIPLOT)
)
) {
/* it's okay to use multiplot here, but suspend first */
term_suspend();
return;
}
So term->suspend, if it exists, will be called on entering multiplot
mode, in each of the following cases:
*) if non-interactive
*) if the terminal driver says it wants it to be called (even in
interactive mode), by setting the "TERM_CAN_MULTIPLOT" mode.
*) if the terminal driver supports multiplot at all.
> On terminals that actually need use routines (amiga svga pm vgagl),
That list appears to be missing aquaterm, ggi, linux, mac, windows and
x11. Now, ggi and linux could perhaps be subsumed under "svga", but the
others are for real: they actually do something in term->suspend(): they
update the partially finished multi-plot to the canvas.
> has mulitplot never worked in scripts or via load commands?
It has worked.
> I had never imagined this was meant to imply that a terminal could
> *not* multiplot if the output *is* redirected.
That's not what it implies. It only implies that such a terminal
driver needs special attention to implement interactive multiplot in a
sensible manner.
In a nutshell, the terminals that strictly need these functions are
those where the interactive command prompt and the graph must not be
output to the default device simultaneously: the full-screen terminals
that alternate between text and graphic modes, and possibly some others
that output graphic as a metafile to stdout by default (unixplot and GNU
libplot output).
The calls are also useful for interactive GUI terminals where people
would naturally expect to see the first plot in the graph window while
they compose the second. These calls may not be wanted in
non-interactive mode on such terminals, though, because they slow down
operation by causing redundant re-draws (i.e. time for a multiplot of N
individual plots becomes O(N^2)).
|
|
From: Dave D. <dde...@es...> - 2005-07-14 17:10:09
|
Hans-Bernhard Broeker <br...@ph...> writes:
> Ethan Merritt wrote:
>> While I was trying to use the term->suspend() and term->resume()
>> API to implement Harald Harders' treatment of front/back text labels
>> in epslatex, I discovered that it is pretty much useless.
>
> I strongly suspect that to be a premature conclusion.
>
>> The suspend() and resume() functions are only called if you are
>> in interactive mode.
>
> Not so.
>
> Here's the relevant snippet from term.c:term_check_multiplot_ok(),
> reindented for legibility.
>
> if (!f_interactive
> || (term->flags & TERM_CAN_MULTIPLOT)
> || ((gpoutfile != stdout)
> && !(term->flags & TERM_CANNOT_MULTIPLOT)
> )
> ) {
> /* it's okay to use multiplot here, but suspend first */
> term_suspend();
> return;
> }
>
I think the comment just above that block is possibly even more
legible :
/* make sure that it is safe to issue an interactive prompt
* it is safe if
* it is not an interactive read, or
* the terminal supports interactive multiplot, or
* we are not writing to stdout and terminal doesn't
* refuse multiplot outright
*/
> So term->suspend, if it exists, will be called on entering multiplot
> mode, in each of the following cases:
>
Don't think so. This function is called just before attempting to
issue a prompt while already in multiplot mode. It is there to decide
if it is safe to issue a prompt while in multiplot mode, or if the
display driver cannot preserve graphics content across a switch to
text mode.
I think the point is that the following will work with *any* terminal
driver :
set multi ; plot sin(x) ; plot cos(x) ; unset multi
because we enter graphics mode once, issue a sequence of calls, then
leave. The terminal driver need never know it has done a multiplot.
This is why the checks are deferred until we try to issue a prompt,
because it is only then that things can go wrong.
I can't remember right now what TERM_CANNOT_MULTIPLOT means : probably
referring to issuing a prompt during multiplot at all. (Many direct
graphics drivers don't honour the output redirection. Eg X11, linux
vga)
It's not clear why we call suspend at all for a non-interactive
read. Ah - non-interactive read means from stdin without
prompting. Presumably interactive means isatty(stdin) or something
like that.
dd
--
Dave Denholm <dde...@es...> http://www.esmertec.com
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-14 16:21:17
|
On Thursday 14 July 2005 07:04 am, Hans-Bernhard Broeker wrote: > > The suspend() and resume() functions are only called if you are > > in interactive mode. > > Not so. > > Here's the relevant snippet from term.c:term_check_multiplot_ok(), > reindented for legibility. Yes. But term_check_multiplot_ok() itself is only called in interactive mode. Try it and see :-) -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-14 18:48:26
|
Ethan Merritt wrote: > Yes. But term_check_multiplot_ok() itself is only called in > interactive mode. Ooops, should have checked that. Well, given the new evidence, either its interface is quite completely wrong, or it's not used in the way. So, let's see what my conclusions would be so far: * This is not a particularly urgent issue. * Removing suspend()/resume() completely would be a Very Bad Idea[TM]. * suspend()/resume() could help more if they were called in more cases, but probably should not be called in non-interactive mode to avoid excessive redraws. Benefits could include drivers that want to know which graphical elements belong to which plot, for grouping purposes. SVG, e.g., could usefully open a new group for each plot of a multiplot page, for more meaningful manipulation by third-party tools. * The above may necessitate a factorization of what suspend() does into two jobs: informing the driver that a new plot in a multiplot has started, and telling the driver that the interactive user now needs the text interface, not the graphics, to be shown. * TERM_CAN_MULTIPLOT shouldn't decide on whether or not term->suspend() gets called at all. It may be superfluous, i.e. replacable by a test that term->suspend() and term->resume() exist. * TERM_CANNOT_MULTIPLOT has to be tested earlier than it is, possibly from inside "set multiplot" itself. * we may need a way to have redirected stdin sources decide for themselves whether they want to act like interactive or not, as far as multiplot is regarded --- the command source could itself be interactive, or it could just be a script generator, and currently gnuplot has no way of distinguishing between the two. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-14 17:31:06
|
On Thursday 14 July 2005 10:09 am, Dave Denholm wrote: > > I can't remember right now what TERM_CANNOT_MULTIPLOT means : probably > referring to issuing a prompt during multiplot at all. I don't know what it was intended to mean, but there is no driver in the current code base which uses it. Furthermore, the code segment that tests it can never be reached. > Ah - non-interactive read means from stdin without > prompting. Presumably interactive means isatty(stdin) or something > like that. It means (1) no files on shell command line and isatty(fileno(stdin)) or (2) we are inside a load command and the filename is '-' or (3) (AMIGA && IsInteractive(Input()) == DOSTRUE) Note that (1) and (2) potentially contradict each other. I'm not sure which one wins out :-) -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-14 18:23:36
|
Ethan Merritt wrote: > On Thursday 14 July 2005 10:09 am, Dave Denholm wrote: > >>I can't remember right now what TERM_CANNOT_MULTIPLOT means : probably >>referring to issuing a prompt during multiplot at all. > Furthermore, the code segment that tests it can never be reached. For that I'd like to see proof. >>Ah - non-interactive read means from stdin without >>prompting. Or from a file. Anything but "from stdin with a prompt", really. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-14 19:08:57
|
On Thursday 14 July 2005 11:24 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> > On Thursday 14 July 2005 10:09 am, Dave Denholm wrote:
> >
> >>I can't remember right now what TERM_CANNOT_MULTIPLOT means : probably
> >>referring to issuing a prompt during multiplot at all.
>
> > Furthermore, the code segment that tests it can never be reached.
>
> For that I'd like to see proof.
My bad.
There is in fact one way to the code path, which is piping to gnuplot
with no arguments on the command line, and no load command involved:
gnuplot < somefile
This is distinct from 3 other cases which one might expect to behave
similarly:
gnuplot somefile
echo "load somefile" | gnuplot
gnuplot
gnuplot> load "somefile"
Here is the analysis:
term_check_multiplot_ok() has only one caller: com_line()
com_line() occurs in only 4 places. Here they are:
misc.c (load_file):
} else if (fp == stdin) {
/* DBT 10-6-98 go interactive if "-" named as load file */
interactive = TRUE;
while (!com_line());
plot.c (main):
618:
if (strcmp(*argv, "-") == 0) {
/* DBT 10-7-98 go interactive if "-" on command line */
interactive = TRUE;
/* will this work on all platforms? */
while (!com_line());
631:
#ifdef _Windows
if (noend) {
interactive = TRUE;
while (!com_line());
}
#endif
} else {
/* take commands from stdin */
while (!com_line());
}
That last "else" condition corresponds to (argc < 1), and is the only
site at which interactive is not guaranteed to be TRUE.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-14 19:19:08
|
On Thursday 14 July 2005 11:49 am, Hans-Bernhard Broeker wrote: > > So, let's see what my conclusions would be so far: > > * This is not a particularly urgent issue. Agreed. > * Removing suspend()/resume() completely would be a Very Bad Idea[TM]. Removing them would save about 400 bytes of permanent storage in TERM_TABLE. Other than that it's all cosmetic. > * suspend()/resume() could help more if they were called in more cases, > but probably should not be called in non-interactive mode to avoid > excessive redraws. Benefits could include drivers that want to know > which graphical elements belong to which plot, for grouping purposes. I am perfectly happy to leave suspend/resume as they are. The cause of my confusion was the implication in the existing documentation that these routines could be used to detect the change between one multiplot plot and the next. They cannot. So I will modify term/README to make it clearer that they are only relevant to interactive plots. This whole line of inquiry started because I was trying to minimize or eliminate the need for a new terminal API function to implement Harald Harders clever treatment of front/back text in epslatex.trm. I already have a working version (posted to SourceForge) that makes explicit calls between multiplot segments. I was hoping to do even better by using suspend/resume instead, but it doesn't work. End of story, I think, other than clarifying the text in term/README -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-14 19:28:44
|
Ethan Merritt wrote: > On Thursday 14 July 2005 11:49 am, Hans-Bernhard Broeker wrote: >>* Removing suspend()/resume() completely would be a Very Bad Idea[TM]. > Removing them would save about 400 bytes of permanent storage in > TERM_TABLE. Other than that it's all cosmetic. It would also render 5 more-or-less independent terminal drivers unusable for interactive multi-plotting. That's what would make it bad. > The cause of my confusion was the implication in the existing > documentation that these routines could be used to detect the > change between one multiplot plot and the next. They cannot. Yet they are. See the X11, OS/2 PM, Windows, mac and aquaterm drivers. But if we do add a "term->next_multiplot()" call or similar, then yes, these should probably be modified to move that functionality to the new call. For good measure, such a call should also carry the current "interactive" state as an argument, so the driver can decide whether to trigger a replot or not. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-14 19:39:55
|
On Thursday 14 July 2005 12:30 pm, Hans-Bernhard Broeker wrote: > Ethan Merritt wrote: > > On Thursday 14 July 2005 11:49 am, Hans-Bernhard Broeker wrote: > > >>* Removing suspend()/resume() completely would be a Very Bad Idea[TM]. > > > Removing them would save about 400 bytes of permanent storage in > > TERM_TABLE. Other than that it's all cosmetic. > > It would also render 5 more-or-less independent terminal drivers > unusable for interactive multi-plotting. That's what would make it bad. You misunderstood me. I was proposing to replace the separate TERM_TABLE entries with sub-options to term->private() or whatever this new API entry would be called. So existing calls to term->suspend() would become calls to term->private(SUSPEND). > > The cause of my confusion was the implication in the existing > > documentation that these routines could be used to detect the > > change between one multiplot plot and the next. They cannot. > > Yet they are. See the X11, OS/2 PM, Windows, mac and aquaterm drivers. ??? The point is that I cannot use them for the purpose of detecting such a change *in general*, because they are only called under certain conditions. > But if we do add a "term->next_multiplot()" call or similar, then yes, > these should probably be modified to move that functionality to the new > call. Exactly. Except that it should be folded into a more generic API. > For good measure, such a call should also carry the current > "interactive" state as an argument, so the driver can decide whether to > trigger a replot or not. Terminal drivers can test for "if (interactive)" on their own. They don't need to have it passed to them as a separate parameter. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-15 13:11:53
|
Ethan Merritt wrote: > You misunderstood me. I was proposing to replace the separate > TERM_TABLE entries with sub-options to term->private() or whatever > this new API entry would be called. So existing calls to > term->suspend() would become calls to term->private(SUSPEND). I'm wildly against this. The term API is supposed to be "add-only". Changes to existing calls, and certainly removals of entire entries, are out of the question. > ??? The point is that I cannot use them for the purpose of detecting > such a change *in general*, because they are only called under certain > conditions. As I said: the number of conditions in which term->suspend() is called could, and possibly should be extended. There's no really good reason why the plot would *have* to be interactive for term->suspend() to ever be called. It may just take some more caution (e.g. those GUI drivers that have it trigger a graph window update may want to support incremental updates instead of full redraws). > Terminal drivers can test for "if (interactive)" on their own. No, they can't --- the 'interactive' flag is outside the realm of the terminal layer, and should remain there. Two drivers (amiga, post) already blundered ahead and referred to this global variable. That's a serious no-no. It's practices like this that have kept gnuplot the tangled mess we're still facing. Such abuse has to be *reduced*, not added to. |
