Menu
▾
▴
gnuplot-beta
|
From: V. <gae...@en...> - 2005-05-08 19:57:16
|
Hello, I am just forwarding a few issues some friends have had with gnuplot recently : First a non intuitive behavior :=20 set term win plot 'foo' using 1:2 set term post set output 'result.ps' replot (then result.ps is drawn) set term win plot 'foo' using 1:2 (then result.ps becomes blanck A correct way to do the same thing was found : set term win plot 'foo' using 1:2 set term post set output 'result.ps' replot set output 'result2.ps' set term win plot 'foo' using 1:2 That forbids gnuplot to scramble result.ps. This is a rather non natural behavior that must trick a quite a few users. Secondly more interactive terminals : I have never used the win terminal (as I don't have a windows box) but it seems to have nice features for beginners that could be add to the X11 terminal (and the new born Glut terminal ?). These menus should of course be controled by a option for the terminal. There is something I don't really understand : the online help ( http://gnuplot.sourceforge.net/docs/gnuplot.html#mouse_variables ) suggest that "set pause mouse" should work. But it doesn't. It think the actual syntax is "pause mouse". -- Ga=EBl |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-05-09 18:00:46
|
On Sunday 08 May 2005 12:57 pm, Ga=EBl Varoquaux wrote: > There is something I don't really understand : the online help ( > http://gnuplot.sourceforge.net/docs/gnuplot.html#mouse_variables ) > suggest that "set pause mouse" should work. But it doesn't. It think the > actual syntax is "pause mouse". That documentation error was fixed in the documentation source some time ago. This sort of correction doesn't retractively fix the on-line html version, however. If you are working with the cvs version of gnuplot, there is a very recent html version of the docs at =20 http://gnuplot.sourceforge.net/docs_4.1/ =2D-=20 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-05-09 18:19:58
|
On Monday 09 May 2005 11:00 am, Ethan Merritt wrote: > On Sunday 08 May 2005 12:57 pm, Ga=EBl Varoquaux wrote: > > There is something I don't really understand : the online help ( > > http://gnuplot.sourceforge.net/docs/gnuplot.html#mouse_variables ) > > suggest that "set pause mouse" should work. But it doesn't. It think the > > actual syntax is "pause mouse". >=20 > That documentation error was fixed in the documentation source > some time ago. My apologies. It was fixed in one place, but you have found a separate occurance of the error. Fixed now. thanks =2D-=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: <br...@ph...> - 2005-05-10 06:44:22
|
Ga=EBl Varoquaux wrote: > First a non intuitive behavior :=20 =2E.. this is already filed as a bug report on SF.net. > set output 'result.ps' > replot > (then result.ps is drawn) > set term win The problem is here. You only opened the output file, but didn't clo= se=20 it. The correct sequence is =09set term {file-writing driver} =09 set output =09 plot something =09 unset output set term {GUI} > Secondly more interactive terminals : I have never used the win > terminal (as I don't have a windows box) but it seems to have nice > features for beginners that could be add to the X11 terminal (and t= he > new born Glut terminal ?). These menus should of course be controle= d by > a option for the terminal. The majority of interactive features of the windows terminal driver= =20 itself (font selection, line type redefinition) are actually=20 anachronisms. They predate most capabilities of the gnuplot core= =20 controlling such things, and get in the way of implementing the new= =20 terminal API capabilities. So if there's going to be change in this= =20 area, IMHO it should be in the opposite direction of what you're prop= osing. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-05-10 18:25:12
|
> set term post
> set output 'result.ps'
> plot 'foo'
> set term win
> plot 'baz' using 1:2
> (then result.ps becomes blank
> This is a rather non natural behavior that must trick a quite a few
> users.
It does seem to be a recurring complaint.
Can anyone see bad side effects if we were to
1) Give win and x11 an explicit term->flags TERM_NO_OUTFILE
(aquaterm? vgagl? others?)
2) Modify term_init() to check for TERM_NO_OUTFILEE, and if present
then *close* the output file rather than re-opening it; i.e.
call term_close_output() rather than term_set_output().
The following proof-of-principle test works for x11, but I don't
know what wrinkles may exist in doing the same for win.trm
--- gnuplot/src/term.c 2005-04-28 14:34:35.000000000 -0700
+++ gnuplot-cvs/src/term.c 2005-05-10 11:16:04.378445568 -0700
@@ -483,6 +483,10 @@
* resulted in output files being truncated
*/
+ /* If this is an interactive terminal, close previous output file */
+ if (outstr && !strncmp(term->name,"x11",3))
+ term_close_output();
+
if (outstr &&
(((term->flags & TERM_BINARY) && !opened_binary) ||
((!(term->flags & TERM_BINARY) && opened_binary)))) {
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: V. <gae...@en...> - 2005-05-10 18:52:03
|
> It's a little bit trickier than I made it sound. For instance, you can > save the output from the x11 terminal driver to a file so that you can > play it back later (like a recording of the session). I thought it was a different terminal (xlib) ! A simple work around is to reset the output after changing to x11 terminal : set term x11 set output x11_dump replot -- Ga=EBl =20 PS : I sent you my last email privately, but realizing my mistake I resent it to the list. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-05-10 19:44:47
|
On Tuesday 10 May 2005 11:51 am, Ga=EBl Varoquaux wrote: > > It's a little bit trickier than I made it sound. For instance, you can > > save the output from the x11 terminal driver to a file so that you can > > play it back later (like a recording of the session). >=20 > I thought it was a different terminal (xlib) ! Yes, it is xlib. But the two drivers are no longer separate; the xlib and x11 drivers share almost all driver routines. I did not mean to imply that x11/xlib would cause a problem. On the contrary, I meant that I understand how x11/xlib works and so I can be careful to test any possible bad effects of the proposed change. But I am not equivalently familiar with the windows driver, and cannot test it myself to explore possible side-effects. =2D-=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-05-11 11:44:40
|
> > This is a rather non natural behavior that must trick a quite a few > > users. > > It does seem to be a recurring complaint. > Can anyone see bad side effects if we were to > > 1) Give win and x11 an explicit term->flags TERM_NO_OUTFILE > (aquaterm? vgagl? others?) > pm.trm > > 2) Modify term_init() to check for TERM_NO_OUTFILEE, and if present > then *close* the output file rather than re-opening it; i.e. > call term_close_output() rather than term_set_output(). I would like this. Is there any non-screen terminal that has no output file? I wonder whether it makes sense to add flag TERM_SCREEN. --- PM |
|
From: Robert H. <en...@no...> - 2005-05-11 13:14:12
|
On Wed, 2005-05-11 at 13:44 +0200, Petr Mikulik wrote: > Is there any non-screen terminal that has no output file? I wonder whether > it makes sense to add flag TERM_SCREEN. Would it make more sense to add an implicit "set output" before a set term? The current "set output" documentation states it is safer to set term before set output, so it shouldn't break anything. I guess we should only do that if the term type actually changes (rather than if just the options change). 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: Ethan M. <merritt@u.washington.edu> - 2005-05-11 15:18:56
|
On Wednesday 11 May 2005 06:13 am, Robert Hart wrote: > On Wed, 2005-05-11 at 13:44 +0200, Petr Mikulik wrote: > > > Is there any non-screen terminal that has no output file? I wonder whether > > it makes sense to add flag TERM_SCREEN. > > Would it make more sense to add an implicit "set output" before a set > term? That would break some existing uses. For example, if you want to continue writing to an output pipe but change a characteristic such as the default font: set output '| display png:-' set term png font "verdana" plot <something> set term png font "Times" 20 plot <something_else> We are moving towards an alternative command that would let you do this without calling 'set term' set term png font "verdana" plot <something> set termoptions font "Times" 20 plot <something_else> But so far this only works for a small number of terminal options. > I guess we should only do that if the term type actually changes (rather > than if just the options change). Hmm. That comes closer. I don't know if that test is sufficient or not. What would happen in the case of "set term push" and "set term pop"? [I've never gotten those to work as I expect anyhow, so maybe it would be a small loss]. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-05-11 15:31:44
|
> Hmm. That comes closer. I don't know if that test is sufficient or not. > What would happen in the case of "set term push" and "set term pop"? > [I've never gotten those to work as I expect anyhow, so maybe it would > be a small loss]. "push" remembers current terminal's name and options, and "pop" executes "set term <oldterm> <oldopts>" as you would type it on command line. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-05-11 20:44:45
|
> Robert Hart <en...@no...> wrote: > > I guess we should only do that if the term type actually changes (rather > > than if just the options change). > Ethan Merritt <merritt@u.washington.edu> wrote: > >What would happen in the case of "set term push" and "set term pop"? On Wednesday 11 May 2005 08:31 am, Petr Mikulik wrote: > "push" remembers current terminal's name and options, and "pop" executes > "set term <oldterm> <oldopts>" as you would type it on command line. I meant, does "set term push" count as changing the terminal type for the purposes of Robert's proposed test? -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-05-12 08:01:46
|
> > > I guess we should only do that if the term type actually changes (rather > > > than if just the options change). > > > Ethan Merritt <merritt@u.washington.edu> wrote: > > >What would happen in the case of "set term push" and "set term pop"? > > On Wednesday 11 May 2005 08:31 am, Petr Mikulik wrote: > > "push" remembers current terminal's name and options, and "pop" executes > > "set term <oldterm> <oldopts>" as you would type it on command line. > > I meant, does "set term push" count as changing the terminal type for the > purposes of Robert's proposed test? If it works for "set term blabla" from command line or script, then it will work for "set term pop" as well. --- PM |
|
From: <dan...@ie...> - 2005-05-11 18:12:00
|
> On Wed, 2005-05-11 at 13:44 +0200, Petr Mikulik wrote: > >> Is there any non-screen terminal that has no output file? I wonder >> whether >> it makes sense to add flag TERM_SCREEN. > > Would it make more sense to add an implicit "set output" before a set > term? > > The current "set output" documentation states it is safer to set term > before set output, so it shouldn't break anything. > > I guess we should only do that if the term type actually changes (rathe= r > than if just the options change). Since this discussion is going on, I thought I'd toss in something I sent to the list previously, which is the capability to append plots to an existing file. Would that be difficult? The "set output" etc. enables putting several plots in one file, but not openning an existing file and then adding. Perhaps this would be too difficult because there might be = a "footer" at the end of the existing file that would need to be removed. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-05-11 18:24:52
|
dan...@ie... wrote: > Since this discussion is going on, I thought I'd toss in something I sent > to the list previously, which is the capability to append plots to an > existing file. Would that be difficult? Yes, very. It'd mean that gnuplot would need (possibly restricted) reading&parsing capabilities for all the file formats it currently only outputs. Generally, a parser is about one order of magnitude harder to get fully correct than a writer for the same format. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-05-11 18:58:08
|
On Wednesday 11 May 2005 11:11 am, dan...@ie... wrote: > > Since this discussion is going on, I thought I'd toss in something I sent > to the list previously, which is the capability to append plots to an > existing file. Would that be difficult? The "set output" etc. enables > putting several plots in one file, but not openning an existing file and > then adding. For those few terminal types for which this makes any sense at all (output streams to an HP printer?), you can already do this: set output "| cat >> oldfile.dat" -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
