Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2004-09-29 16:50:52
|
> > PS: Here are some other problems with CVS: > > > 3) In PostScript, the plot two plots after the one titled "Plot 'file' > > with vectors <arrowstyle>" and all plots after don't appear. When > > running 'all.dem', gnuplot hits that plot and then instead of sending > > PostScript code to the file all of a sudden it starts sending it to the > > stdout. > > And PDF stops any more writing. Well, that explains why vector.dem was not previously included in all.dem. I couldn't remember why that was, and it checked out OK with x11, but obviously I should have tested more terminal types. I'll remove it from all.dem again, but probably we should try to fix the underlying problem. > Here is the offending code in vector.dem: > > print "Now create a file with equipotential lines" > pause -1 "Hit return to continue" > set term push > set term table > set out "equipo2.dat" > rep > set out > set term pop > > => it resets output! > > I don't see any easy workaround ... we will probably need new command > "save output" > because the output is not normally saved. I can see some other possibilities, but none are obviously the correct thing to do: 'set term table' could take an optional file name, leaving the value of "set output" unchanged. show output output is set to "original" set term push set term table "equipo2.dat" replot set term pop show output output is set to "original" 'set term push' could push the value of output, and 'set term pop' could restore it. That makes a lot of sense, but I suppose it could break existing scripts. > > 4) Running 'all.dem' in pdf terminal results in > > > > PDFlib I/O error: Resource configuration file 'pdflib.upr' not found That's not a gnuplot error. That's a system configuration problem, specifically an incomplete installation of pdflib. pdflib wants that file to be in some specific search path, and complains if it's not there. > gnuplot> load 'world2.dem' > PDFlib exception (fatal): [2516] PDF_findfont: Metrics data for font '7' not found > > The offending line is: > plot ... with labels notitle point pt 6 lw .1 left offset 1,0 font ",7" > > Ethan, can you please fix it? That's triggered by the new demo file world2.dem, but it looks like the underlying problem is that pdf.trm does not interpret font specs the same way that post.trm and other drivers do. I'll have a look at that. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-09-29 17:50:30
|
Petr Mikulik wrote: >>PS: Here are some other problems with CVS: >> >>1) The color scheme for X11 'all.dem' isn't the same as it once was. >> (Or perhaps the whole of all demos has been changed.) I went back and >>compared against a version from a couple months ago. There used to be >>some hidden line demos where some portions of the 3D surface were green >>and some red. (A whole bunch of them.) Now they are all red the whole >>way through. Perhaps hidden lines isn't working properly. >> >> > >I have a feeling it works for me. There are both red lines and green lines. >(Can you compare your X11 to e.g. postscript output?) > > > >>The plot titled '"fence plot" using separate parametric surfaces' has a >>noticeably different color scheme than the old CVS X11. >> >> > >I have compared this plot to that of gnuplot from June 3, and it is the >same. > > > >>2) postscript output has the same problem with two sides of a 3D >>surface both being red. (So maybe it isn't X11 with the problem.) >> >> > >Aha, you did so. > >For me: load 'hidden.dem', plots nb. 3 to 7, have both red and green lines. >You cann't see it? >It looks the same if loaded from 'all.dem', or in its own. > (CVS just updated, someone must be working on this.) To quote a Split Enz tune, "I see red, I see red, I see red!"... but I only see it when running 'hidden.dem' and other such demos from 'all.dem'. After 'all.dem' and a 'reset', running 'hidden.dem' individually stills stays all red. >>3) In PostScript, the plot two plots after the one titled "Plot 'file' >>with vectors <arrowstyle>" and all plots after don't appear. When >>running 'all.dem', gnuplot hits that plot and then instead of sending >>PostScript code to the file all of a sudden it starts sending it to the >>stdout. >> >> > >And PDF stops any more writing. > >Here is the offending code in vector.dem: > >print "Now create a file with equipotential lines" >pause -1 "Hit return to continue" >set term push >set term table >set out "equipo2.dat" >rep >set out >set term pop > > >=> it resets output! > >Try > grep "set out" *.dem > >I don't see any easy workaround ... we will probably need new command > "save output" >because the output is not normally saved. > So _that's_ why it wasn't in all.dem. I should have thought of that. >>4) Running 'all.dem' in pdf terminal results in >> >>PDFlib I/O error: Resource configuration file 'pdflib.upr' not found >> >> > >I don't have this error. > >However, I can see a crash here: > >gnuplot> load 'world2.dem' >PDFlib exception (fatal): [2516] PDF_findfont: Metrics data for font '7' not found > >The offending line is: >plot ... with labels notitle point pt 6 lw .1 left offset 1,0 font ",7" > > Ah, yes. I forgot that one. The labels in 'world2.dem' do not appear in 'postscript', causing an error message in ghostview. Also, I just ran 'world2.dem' in X11 and the labels appear in the first plot, do not appear in the second plot (which may be the way it is supposed to be), but then running 'world2.dem' again, there are no labels even in the first plot. Typing 'reset' and rerunning fixes this and the labels appear again. Aha. It's 'world2.dem'. I started gnuplot afresh, ran 'animate.dem' (green and red surfaces), ran 'world2.dem', typed 'reset', reran 'animate.dem' (only red this time). Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-09-29 18:14:49
|
Daniel J Sebald wrote: > Aha. It's 'world2.dem'. I started gnuplot afresh, ran 'animate.dem' > (green and red surfaces), ran 'world2.dem', typed 'reset', reran > 'animate.dem' (only red this time). Speaking of 'world2.dem', spinning around the label-free globe on its axis would be a prime candidate for the animate demo. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-09-29 18:44:06
|
On Wednesday 29 September 2004 11:17 am, Daniel J Sebald wrote: > Aha. It's 'world2.dem'. I started gnuplot afresh, ran 'animate.dem' > (green and red surfaces), ran 'world2.dem', typed 'reset', reran > 'animate.dem' (only red this time). very strange. OK, that's definitely a bug I did not catch. I have no thoughts on it at the moment, but I hope it will come to me eventually. > Also, I just > ran 'world2.dem' in X11 and the labels appear in the first plot, do not > appear in the second plot (which may be the way it is supposed to be) This makes no sense to me. I cannot reproduce it here. The whole point of the demo was to show that hidden line removal now works for labels too, but you say you don't get any labels. What happens if you replace that splot ... font ",7" spec with splot ... font "Helvetica,7" instead? -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2004-09-30 06:42:16
|
> > set term push > > set term table > > set out "equipo2.dat" > > rep > > set out > > set term pop > > > > => it resets output! > > > > I don't see any easy workaround ... we will probably need new command > > "save output" > > because the output is not normally saved. Now I think this won't help because there cannot be functionality like "set output append <file>". > 'set term table' could take an optional file name, > leaving the value of "set output" unchanged. I think that's the best solution. -- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-09-30 21:23:33
|
On Wednesday 29 September 2004 11:42 pm, Petr Mikulik wrote: > > > 'set term table' could take an optional file name, > > leaving the value of "set output" unchanged. > > I think that's the best solution. I have been looking at Harald Harder's patch to replace the existing epslatex.trm with a new driver that piggybacks on most of the post.trm driver routines. I will leave general discussion of that to people who actually use the epslatex terminal. The relevant point here is that Harald introduces a new driver entry point to term_api term->set_output(char *outfile) and in the core code he uses it as follows if (term->set_output) (term->set_output)( newfilename ) else term_set_output( newfilename ) Would this approach solve the current problem with using table.trm? It would not fix existing scripts, but it might be more flexible in the long run. Harald: I have some questions about your new terminal entry. Right now it is permitted (though discouraged) to call 'set output' before calling 'set term'. Would we have to forbid this absolutely? Would it be possible to separate the file descriptor opened by (term->set_output) from the one opened by term_set_output? That way a terminal with a private version of the routine would not destroy the current setting of "set output <foo>", which is the issue being raised by the example in vector.dem -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-10-01 05:55:28
|
Ethan Merritt wrote: >On Wednesday 29 September 2004 11:42 pm, Petr Mikulik wrote: > > >>>'set term table' could take an optional file name, >>>leaving the value of "set output" unchanged. >>> >>> >>I think that's the best solution. >> >> > >I have been looking at Harald Harder's patch to replace >the existing epslatex.trm with a new driver that piggybacks >on most of the post.trm driver routines. I will leave general >discussion of that to people who actually use the epslatex >terminal. > No feeling on your main point, but I read through the patch comments because epslatex is one of my fav terminals. For the most part, everything the patch does to enhance or correct problems sounds good to me. Individual comments: > This approach ensures that new developments > of the postscript terminal are available in epslatex, > automatically. This is very nice. > In addition to the old epslatex syntax and the > postscript options for epslatex (for example, rounded, > linewidth, dashlength), the patch supports: > - coloured text with epslatex (which can be switched on > and off locally for one plot or globally in the > preamble of the LaTeX document), xfig added color text a year or two ago. Requires as an additional LaTeX package, but no big deal. Probably more use for colored text in gnuplot than in xfig. I see another there is another patch on SourceForge that may be conflicting: 743667 Epslatex term merged w/ pslatex/pstex Are these related? Can they be combined? The concepts sound the same, i.e., to combine the postscript related terminals in a better fashion. On the subject of PostScript, I recall someone submitting a patch for using grayscale backgrounds in PostScript. Looked promising at the time. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-10-01 10:23:05
|
Daniel J Sebald wrote:
> No feeling on your main point, but I read through the patch comments
> because epslatex is one of my fav terminals.
I suspect I'm the one among the developers who *uses* gnuplot least
frequently, so I don't have much of a favourite terminal driver, but
still, I have some points I'd like to make:
*) we currently have *two* "combined ps + latex" drivers: pslatex
and epslatex. Yet this discussion has been only about epslatex.
That doesn't seem right. In particular, it doesn't seem to make
sense to go about modifying one of them alone, instead of
collecting the best of both into a single, new one (while keeping
an eye on pstex, too).
*) The two drivers have several differences. Some of them are mainly
accidental, others were made intentionally. I.e. there are things
in epslatex, like the particular choice of line type colours, that
were designed the way they are *because* someone wanted them to be
different from what pslatex does. Harald's patch reverts some of
those decisions, which I'm not quite happy with.
*) I don't see why we should need a new term API entry for
setting the output. Yes, the output file is currently a global
variable, which is bad from a structural point of view. But I really
don't see why a modification of a single terminal driver should be
allowed to change the API. If we want to change the API, that's a
separate issue, to be discussed independently.
|
|
From: Daniel J S. <dan...@ie...> - 2004-10-01 18:36:11
|
Hans-Bernhard Broeker wrote: > Daniel J Sebald wrote: > >> No feeling on your main point, but I read through the patch comments >> because epslatex is one of my fav terminals. > > > I suspect I'm the one among the developers who *uses* gnuplot least > frequently, so I don't have much of a favourite terminal driver, but > still, I have some points I'd like to make: > > *) we currently have *two* "combined ps + latex" drivers: pslatex > and epslatex. Yet this discussion has been only about epslatex. > That doesn't seem right. In particular, it doesn't seem to make > sense to go about modifying one of them alone, instead of > collecting the best of both into a single, new one (while keeping > an eye on pstex, too). No doubt there. What about this "pstricks". Way back, I saw that one and thought to update the image drivers in there. Then looking at it, it seemed so outdated that I wondered about its worth. I tried running 'all.dem' under pstricks; that soon failed. I tried 'image.dem'; image don't pass through of course but some other elements in the plots failed. pstricks is falling behind a bit. I also just tried running gnuplot's "test" image through the epslatex terminal. Running the "xdvi" on the compiled output files results in the polyfill not appearing. Doing "dvips test -o test.ps" created a PostScript file that crashed on the polyfill. As you are arguing above, if it works in PostScript, a seemless transition to related terminals should be expected. > *) The two drivers have several differences. Some of them are mainly > accidental, others were made intentionally. I.e. there are things > in epslatex, like the particular choice of line type colours, that > were designed the way they are *because* someone wanted them to be > different from what pslatex does. Harald's patch reverts some of > those decisions, which I'm not quite happy with. From my understanding, EPS supposedly only differs from PS by the presence of the bounding box information. Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-10-01 19:16:17
|
Daniel J Sebald wrote: > a seemless transition seamless |
|
From: Daniel J S. <dan...@ie...> - 2004-10-02 03:28:46
|
Daniel J Sebald wrote: > I also just tried running gnuplot's "test" image through the epslatex > terminal. Running the "xdvi" on the compiled output files results in > the polyfill not appearing. Doing "dvips test -o test.ps" created a > PostScript file that crashed on the polyfill. As you are arguing > above, if it works in PostScript, a seemless transition to related > terminals should be expected. Oh, I see that none of the common definitions are put inside the PS portion of the epslatex terminal scheme. So the "PolyFill" command fails because it isn't defined in the files header. Somewhere epslatex needs to call PS_common_init(). Skimming through Harald's epslatex patch, I don't see that it does that. Should this be fixed before or after the patch is applied? I see the problem doesn't exist in 4.0.0, probably because that code did not use a definition of PolyFill, just straight PostScript code. The post.trm was probably rewritten to use PolyFill. epslatex, like pslatex , uses the routine directly, however pslatex does call PS_common_init(). Dan Sebald |
|
From: Harald H. <h.h...@tu...> - 2004-10-03 14:41:12
|
On Fri, 1 Oct 2004, Daniel J Sebald wrote: > > I also just tried running gnuplot's "test" image through the epslatex > > terminal. Running the "xdvi" on the compiled output files results in > > the polyfill not appearing. Doing "dvips test -o test.ps" created a > > PostScript file that crashed on the polyfill. As you are arguing > > above, if it works in PostScript, a seemless transition to related > > terminals should be expected. Have you used a patched epslatex terminal or the original one? > Oh, I see that none of the common definitions are put inside the PS > portion of the epslatex terminal scheme. So the "PolyFill" command > fails because it isn't defined in the files header. Somewhere epslatex > needs to call PS_common_init(). Skimming through Harald's epslatex > patch, I don't see that it does that. Should this be fixed before or > after the patch is applied? My patch uses PS_init in the TERM_TABLE of the epslatex terminal which itself calls PS_common_init. Thus, my patch should fix this problem. In all test I have done I have compared the output of the postscript terminal with the epslatex output using 'diff'. The only difference was the missing text definitions in epslatex (which of course must be missing there). Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Daniel J S. <dan...@ie...> - 2004-10-03 19:37:15
|
Harald Harders wrote: >On Fri, 1 Oct 2004, Daniel J Sebald wrote: > > > >>>I also just tried running gnuplot's "test" image through the epslatex >>>terminal. Running the "xdvi" on the compiled output files results in >>>the polyfill not appearing. Doing "dvips test -o test.ps" created a >>>PostScript file that crashed on the polyfill. As you are arguing >>>above, if it works in PostScript, a seemless transition to related >>>terminals should be expected. >>> >>> > >Have you used a patched epslatex terminal or the original one? > Original. >My patch uses PS_init in the TERM_TABLE of the epslatex terminal which >itself calls PS_common_init. Thus, my patch should fix this problem. In >all test I have done I have compared the output of the postscript terminal >with the epslatex output using 'diff'. The only difference was the missing >text definitions in epslatex (which of course must be missing there). > Ah... I didn't look at the tables, just in the code. Thanks, Dan |
|
From: Petr M. <mi...@ph...> - 2004-10-01 07:00:35
|
> > > 'set term table' could take an optional file name, > > > leaving the value of "set output" unchanged. > > > > I think that's the best solution. > > I have been looking at Harald Harder's patch to replace > the existing epslatex.trm with a new driver that piggybacks > on most of the post.trm driver routines. I will leave general > discussion of that to people who actually use the epslatex > terminal. > > The relevant point here is that Harald introduces > a new driver entry point to term_api > term->set_output(char *outfile) > > and in the core code he uses it as follows > if (term->set_output) > (term->set_output)( newfilename ) > else > term_set_output( newfilename ) > > Would this approach solve the current problem with > using table.trm? It would not fix existing scripts, but it > might be more flexible in the long run. I think new terminal API is not necessary. It can be organized in the current way using set_termoptions() and term->options(). (And that's how epslatex works until now, without problems.) This new term API won't help the "table" terminal because writing graphs and surfaces is made by the gnuplot core, not by the driver itself. Also, the "FILE *gpauxfile" should be declared in term_api.h, close to declaration of extern FILE *postscript_gpoutfile; I think that the epslatex driver should use postscript_gpoutfile for its aux output, not its new gpauxfile. That's because there are tests within the gnuplot core for this output, and then a postscript-optimized code is shipped out (e.g. pm3d routines). Have you tested your epslatex with pm3d output? I guess it would fail. > Right now it is permitted (though discouraged) to call > 'set output' before calling 'set term'. Would we have to > forbid this absolutely? The compatibity should be kept -- gnuplot cannot depend on the order of these two commands. Finally, this patch should be unified with [ 743667 ] Epslatex term merged w/ pslatex/pstex Harald, please take the best from both. -- PM |
|
From: Harald H. <h.h...@tu...> - 2004-10-02 13:26:47
|
> > The relevant point here is that Harald introduces > > a new driver entry point to term_api > > term->set_output(char *outfile) > > > > and in the core code he uses it as follows > > if (term->set_output) > > (term->set_output)( newfilename ) > > else > > term_set_output( newfilename ) > > > > Would this approach solve the current problem with > > using table.trm? It would not fix existing scripts, but it > > might be more flexible in the long run. > > I think new terminal API is not necessary. It can be organized in the > current way using set_termoptions() and term->options(). (And that's how > epslatex works until now, without problems.) Sure it is problematic. I think it is bad style that set_output opens an output file and the terminal has to change already opened file handles. And the current solution prevents the user from giving a filename without extension for terminals that use more than one output file. And, there is another problem: LaTeX's \includegraphics command does not allow dots within filenames. With the current solution it is not possible to test the filename on validity for LaTeX before it is generated. This is bad style. > Also, the "FILE *gpauxfile" should be declared in term_api.h, close to > declaration of extern FILE *postscript_gpoutfile; This could be done, no problem. I have thaught to provide gpauxfile for other terminals that might want to use an auxfile. But it is not important. > I think that the epslatex driver should use postscript_gpoutfile for its > aux output, not its new gpauxfile. That's because there are tests within the > gnuplot core for this output, and then a postscript-optimized code is > shipped out (e.g. pm3d routines). Have you tested your epslatex with pm3d > output? I guess it would fail. I have never understood the sence of postscript_gpoutfile. What it is ment for? > > Right now it is permitted (though discouraged) to call > > 'set output' before calling 'set term'. Would we have to > > forbid this absolutely? > > The compatibity should be kept -- gnuplot cannot depend on the order of > these two commands. I agree. But 'set output' should not immediately open an output file (see my other posting). > Finally, this patch should be unified with > [ 743667 ] Epslatex term merged w/ pslatex/pstex > Harald, please take the best from both. I agree. Unfortunately I won't have the time to merge these two patches in the next months. We could either wait until I find the time again or any other person could work on it. What about Theo Hopman who programmed patch #743667? Yours Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Petr M. <mi...@ph...> - 2004-10-04 06:25:27
|
> > I think that the epslatex driver should use postscript_gpoutfile for its > > aux output, not its new gpauxfile. That's because there are tests within the > > gnuplot core for this output, and then a postscript-optimized code is > > shipped out (e.g. pm3d routines). Have you tested your epslatex with pm3d > > output? I guess it would fail. > > I have never understood the sence of postscript_gpoutfile. What it is ment > for? Added for the (e)ps(la)tex family: ChangeLog.0-2000-11-20 Petr Mikulik <mi...@ph...> ChangeLog.0- ChangeLog.0- * src/: color.c pm3d.c term.c term_api.h ChangeLog.0- term/: epslatex.trm pslatex.trm post.trm ChangeLog.0: pm3d: added 'FILE *postscript_gpoutfile' which is set to ChangeLog.0- 'PSLATEX_auxfile' or 'gpoutfile' or '0' according to 'set term', ChangeLog.0- i.e. to the file where the postscript code goes to (if outputted). ChangeLog.0: Condition 'if (!postscript_gpoutfile)' can be used to distinguish ChangeLog.0- postscript terminals family (used in postscript optimized output ChangeLog.0- in pm3d). That's why I think your epslatex should use it as well. Now I see that the surrounding #ifdef PM3D ... #endif should be removed, and that postscript_gpoutfile should be always useable. See also here: term_api.h-#ifdef PM3D term_api.h-/* Output file where the PostScript output goes to. term_api.h- In particular: term_api.h: postscript_gpoutfile == gpoutfile term_api.h- for 'set term': postscript, pstex term_api.h: postscript_gpoutfile == PSLATEX_auxfile term_api.h- for 'set term': pslatex term_api.h: postscript_gpoutfile == 0 term_api.h- for all other terminals term_api.h- It is non-zero for for the family of postscript terminals, thus making term_api.h- this a unique check for postscript output (pm3d has some code optimized term_api.h- for PS, for instance). term_api.h-*/ term_api.h:extern FILE *postscript_gpoutfile; term_api.h-#endif -- PM |
|
From: Harald H. <h.h...@tu...> - 2004-10-02 13:26:45
|
On Thu, 30 Sep 2004, Ethan Merritt wrote: Sorry for not answering for such a long time. I have moved to another city and changed my company. > > > 'set term table' could take an optional file name, > > > leaving the value of "set output" unchanged. > > > > I think that's the best solution. > > I have been looking at Harald Harder's patch to replace > the existing epslatex.trm with a new driver that piggybacks > on most of the post.trm driver routines. I will leave general > discussion of that to people who actually use the epslatex > terminal. > > The relevant point here is that Harald introduces > a new driver entry point to term_api > term->set_output(char *outfile) > > and in the core code he uses it as follows > if (term->set_output) > (term->set_output)( newfilename ) > else > term_set_output( newfilename ) > > Would this approach solve the current problem with > using table.trm? It would not fix existing scripts, but it > might be more flexible in the long run. The cause for introducing the new API routine was that it allows some interesting things that were not possible with the standard routine: - The use is able to leave out the file extensions. For the user the question is: Since epslatex generates two files, which of these is the correct one? With the new routine it is possible to give 'outfile.eps', 'outfile.tex', or 'outfile' as output filename. - The option fullheader made it necessary to use another file open routine. The fullheader mode is ment for producing a stand alone postscript or pdf output file that can be included by any application, using TeX texts. This is done by producing a full LaTeX file with the given output file name and an additional eps file with a prefix before the extension. This is done to prevent mixing up the gnuplot-produced eps file without text information and the final ps or pdf file produced by dvips or pdflatex. I think, the new set_output routine could also be interesting for other terminals, escpecially these with binary output or with more than one output file. > I have some questions about your new terminal entry. > > Right now it is permitted (though discouraged) to call > 'set output' before calling 'set term'. Would we have to > forbid this absolutely? Mmh, I think it is a design bug that 'set output' immediately opens an output file before it knows for which terminal the file will be used. For example, it does not know if more than one file will be opened or if the output file is ascii or binary. The result are strange routines that close the outputfile and open it again with different settings (This is worse than an file_open routine for different terminals, in my opinion). There are two possible solutions: - The fopen is postponed to a point where both terminal and output filename are known, for example to the occurance of 'set multiplot' or 'plot' resp. 'splot'. Then, 'set output' can stay before or after 'set terminal'. But this means a reorganisation of the routines. - A terminal change is forbidden after 'set output'. I think the first solution is better. If I remember correctly this has already discussed sometimes. > Would it be possible to separate the file descriptor opened > by (term->set_output) from the one opened by term_set_output? > That way a terminal with a private version of the routine > would not destroy the current setting of "set output <foo>", > which is the issue being raised by the example in vector.dem I am not sure if this works without problems. The terminal that has a private set_output routine could use another FILE variable than the global one. But this leads into trouble if 'set output' is used before 'set terminal'. Yours Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-01 17:59:25
|
On Friday 01 October 2004 03:13 am, Hans-Bernhard Broeker wrote: > *) I don't see why we should need a new term API entry for > setting the output. Yes, the output file is currently a global > variable, which is bad from a structural point of view. But I really > don't see why a modification of a single terminal driver should be > allowed to change the API. If we want to change the API, that's a > separate issue, to be discussed independently. That is the discussion I hoped to trigger. I agree it is not a good thing to change the API for only one driver. But a change to TERM_TABLE might resolve the more general problem seen in vector.dem, that the sequence set term push set term <new> set output replot set term pop loses the original output setting. Adding an actual terminal-specific function may not be useful, but storing the output fd (or maybe the string used to open it) in the TERM_TABLE is an interesting idea. Then each driver would have its own output stream, and you could ' set term push/pop/<new>' all day without having them trample on each other's output. |
|
From: Daniel J S. <dan...@ie...> - 2004-10-01 18:18:26
|
Ethan Merritt wrote: >On Friday 01 October 2004 03:13 am, Hans-Bernhard Broeker wrote: > > >>*) I don't see why we should need a new term API entry for >> setting the output. Yes, the output file is currently a global >> variable, which is bad from a structural point of view. But I really >> don't see why a modification of a single terminal driver should be >> allowed to change the API. If we want to change the API, that's a >> separate issue, to be discussed independently. >> >> > >That is the discussion I hoped to trigger. >I agree it is not a good thing to change the API for only one driver. >But a change to TERM_TABLE might resolve the more general >problem seen in vector.dem, that the sequence > set term push > set term <new> > set output > replot > set term pop >loses the original output setting. > >Adding an actual terminal-specific function may not be useful, >but storing the output fd (or maybe the string used to open it) >in the TERM_TABLE is an interesting idea. Then each driver would >have its own output stream, and you could ' set term push/pop/<new>' >all day without having them trample on each other's output. > Sounds good. Would calling the same terminal after a push be a problem? (Can't think of a reason to use that, but a user might do it by accident and get a resulting "file write" error after popping back the first terminal instance. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-01 20:38:29
|
On Friday 01 October 2004 11:45 am, Daniel J Sebald wrote: > >but storing the output fd (or maybe the string used to open it) > >in the TERM_TABLE is an interesting idea. > > Sounds good. Would calling the same terminal after a push be a problem? No more so than under the current scheme. > (Can't think of a reason to use that, but a user might do it by > accident and get a resulting "file write" error after popping back the > first terminal instance. There wouldn't be any error. It would just continue writing to the most recently specified output file. Same as it does now. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-10-02 01:49:02
|
Ethan Merritt wrote: >>(Can't think of a reason to use that, but a user might do it by >>accident and get a resulting "file write" error after popping back the >>first terminal instance. >> >> > >There wouldn't be any error. It would just continue writing to >the most recently specified output file. Same as it does now. > Ah. That wouldn't be much of a problem. Dan |
