gnuplot-beta

bug in gnuplot 4.0 ??

[Bernhard S. <se...@it...>]

Dear gnuplot developer team,

i downloaded some days ago gnuplot 4.0 - great! The new features are very 
good!
Maybe i found an error (or strange behavior):
loding the two attached scripts (t1.gpl plots cos(x) on x11 and to 
eps-file; t2.gpl plot sin(x) onx11 and to eps-file):

load "t1.gpl"    # produces test1.eps  -> ok
load "t2.gpl"    # produces test2.eps  -> ok   AND  destroyes test1.eps!!!

I could not observe this on former gnuplot versions. I am using the Linux 
distributions RedHat 9.0 and Debian.


Maybe this can be fixed (or is it already in progress)? Thank you very 
much!


Best regards
Bernhard
-- 
======================================================
   DI Mag Bernhard Seiwald

Office:
   Technische Universitaet Graz
   Institut fuer Theoretische Physik - Computational Physics
   Abteilung fuer Plasmaphysik
   Petersgasse 16
   A-8010 Graz
   Austria

   Phone    :  +43(0)316/873-8194
   Fax      :  +43(0)316/873-8678
   E-Mail   :  Bernhard Seiwald <Ber...@it...>
   Homepage :  http://www.itp.tugraz.at/~seiwald/
   Institute:  http://www.itp.tugraz.at/
======================================================

+---------------------------------------------------------+
This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein.  If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation.
+---------------------------------------------------------+

Re: bug in gnuplot 4.0 ??

[Hans-Bernhard B. <br...@ph...>]

Bernhard Seiwald wrote:

> loding the two attached scripts (t1.gpl plots cos(x) on x11 and to 
> eps-file; t2.gpl plot sin(x) onx11 and to eps-file):
> 
> load "t1.gpl"    # produces test1.eps  -> ok
> load "t2.gpl"    # produces test2.eps  -> ok   AND  destroyes test1.eps!!!

At least part of the responsibility for this problem lies in your 
scripts.  They fail to close the output files.  I.e. before you

	set term x11

you should

	set output

to close the PostScript output file.  The fact that the sequence
you used didn't work is a bug in gnuplot, but your scripts are at
least somewhat incorrect, too.

Re: bug in gnuplot 4.0 ??

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

On Thursday 28 October 2004 03:41 am, Hans-Bernhard Broeker wrote:
> At least part of the responsibility for this problem lies in your
> scripts.  They fail to close the output files.  I.e. before you
>
> 	set term x11
>
> you should
>
> 	set output

That's not what the documentation says.
It says:
	When both `set terminal` and `set output` are used together
	it is safest to give `set terminal` first

It sounds like the bug being reported may be the same one that
is corrupting my PostScript output when I try to use push/pop 
term.  Do you know exactly what bit of the code is doing this?
I have been looking, but failing to find it. 

Re: bug in gnuplot 4.0 ??

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> That's not what the documentation says. It says: When both `set 
> terminal` and `set output` are used together it is safest to give 
> `set terminal` first

That's meant to be talking about when you open a terminal.  My comment
was about how you close it. Bernhard's scripts, executed in the given
order, do this:

	set term post
	set output 'file1'
	# plot something ...
	set term x11
	set term post
	set output 'file2'
	# ...
	reset
	set term x11

What I was suggesting was that there should usually be a 'set output'
to close the file, *before* the 'set term x11'.

> It sounds like the bug being reported may be the same one that is 
> corrupting my PostScript output when I try to use push/pop term.

It may very well be.  "set term pop" and "set term x11" are essentially
the same thing, and they both lack the closing 'set output'.

In a nutshell, 'set term' to a different driver, while output is
directed to a file, has to close that file (i.e. simulate 'set output')
at some point before the new driver writes anything to output file.  The
mechanisms to actually do that are quite intricate (check variable
term_initialised, and watch for calls to term_set_output()).