|
From: Petr M. <mi...@ph...> - 2009-07-14 07:37:29
|
Here is yet another observations: the bug
multiplot> et origin 0, 0
^
line 0: invalid command
appears also
- I copy by mouse to Octave's command line commands
plot(1:10);
plot(1:10);
- I copy these lines by mouse or they can be in a script file
blabla.m:
plot(1:10);
print -deps bla.ps
but it is OK with a delay:
plot(1:10);
pause(1);
print -deps bla.ps
It appears to me that the gnuplot's plot is not yet finished and it wants to
read a char from keyboard but it eats it from the stream of commands
instead.
I've tried to reproduce the bug by means of reading file with gnuplot
commands
f=popen('gnuplot', 'w');
g=fopen('xx.gp', 'r');
while (~feof(g))
s = fgets(g); fputs(f, s);
end
fclose(g);
fflush(f);
but the problem was not reproduced.
I don't know whether this problem can be avoided -- well, the simplest
solution for Octave is to add "\n" into the __go_draw_figure__.m as I've
mentioned earlier. Ben, can you please update the file?
> Here is a more improved bug report compared to that I've sent to Ben and
> bu...@oc...:
>
>
> In Octave 3.2.0, I've noticed a missing ("eaten") character when pasting
> several commands by mouse into Octave or when plotting many plots from a
> script file (under Linux and X11 gnuplot terminal). For example, the
> following is reproducible on my computer -- paste the following by middle
> mouse button:
>
> clf
> subplot(1,2,1); title("fig 1")
> subplot(2,2,2); title("fig 2")
> subplot(2,2,4); title("fig 3")
>
> which leads to:
>
> tmp|16:57:30|11> clf
> tmp|16:57:30|12> subplot(1,2,1); title("fig 1")
> tmp|16:57:31|13> subplot(2,2,2); title("fig 2")
> tmp|16:57:31|14> subplot(2,2,4); title("fig 3")
>
> multiplot> et origin 0, 0
> ^
> line 30: invalid command
>
>
> It happens in this sequence of commands sent to gnuplot:
>
> fputs (plot_stream, "set multiplot;\n");
> fputs (plot_stream, "set origin 0, 0\n");
>
> in octave/3.2.0/m/plot/__go_draw_figure__.m
>
> The problem vanishes if I add \n into the first command, e.g.
> fputs (plot_stream, "set multiplot;\n\n");
> Note that adding ";" or fflush() does not help.
>
> I have tested older gnuplot releases, and it seems that gnuplot earlier than
> the patch below works correctly:
>
> 2008-11-06 Ethan Merritt <merritt@u.washington.edu>
> * term/x11.trm (X11_set_font ENHX11_put_text): Initialize enhanced text
> processing to use most recently requested font rather than the default
> font.
|