Re: __gnuplot_set__ fails as function call 2.9.1

[John W. Eaton]

On 30-Mar-2005, Dmitri A. Sergatskov <address@hidden> wrote:

| Quentin Spencer wrote:
| > Is this expected behavior? I had the second command below in my 
| > ..octaverc file, and it works in 2.1.69. I had believed that it was 
| > preferred programming style to treat things like function calls if 
| > possible. Does 2.9.x differentiate more strictly between functions and 
| > commands?
| > 
| > octave:1> __gnuplot_set__ mouse
| > octave:2> __gnuplot_set__("mouse")
| > octave:3>
| > gnuplot> set ("mouse")
| 
| Only John, of course, can have an authoritative aanswer, but FWIW:
| 
| a) This is an expected behavior with the new gnuplot parser

Yes.  The reason is that the commands

  __gnuplot_plot__
  __gnuplot_set__
  __gnuplot_splot__
  __gnuplot_replot__

are "raw" commands.  They differ from ordinary commands in that they
simply pass everything between the command name and the first newline
character (that is not in a string constant) to the function.  This
way, __gnuplot_plot__ can accept a language that doesn't have to look
like the language normally parsed by Octave.

Although there are some problems with this approach, I think this is a
reasonable step to take to allow us to remove the gnuplot parser from
the main Octave language parser.

| b) I believe __gnuplot_set__ is also deprecated and it is preferred
|      to use __gnuplot_raw__("set mouse;\n")

Yes, I think this is best.

| One of the reasons is that new gnuplot command format is to use
| "set/unset value" rather than "set value"/"set novalue"
| So if you are fixing things, I would recommend changing all
| __gnuplot_set__ to __gnuplot_raw__()
| 
| Unfortunately it is not as straightforward since octave does
| some parsing of __gnuplot_set__ arguments, while _raw__ does not.

Right, __gnuplot_set__ checks for "set term" and "set parametric".
For parametric, it chooses the type of data to write out for gnuplot
to read.

| For one thing this substitution breaks mesh() and related
| commands, so __gnuplot_set__ will hang around for at least short
| while.

Perhaps we should also eliminate __gnuplot_plot__ and
__gnuplot_splot__ and only have a function to send commands to the
gnuplot stream.  Then we can eliminate the (always doomed to be broken
in some way or another) parser.  That would mean that you would have
to write out the data files yourself:

  x = (-10:0.01:10)';
  data = [x, sin(x)];

  [fid, name] = mkstemp (sprintf ("%s/XXXXXX", P_tmpdir), 1);
  fprintf (fid, "%f %f\n", data');
  fclose (fid);

(though we might want to provide some convenience functions for the
common types of files).

then issue commands like

  gnuplot (sprintf ("plot \"%s\" using 1:2\n", name));

Of course, if you want to do something simple like this, you should be
using "plot" instead, and then these details would be hidden from you
and your scripts would continue to work even if Octave's default
plotting engine changes to something other than gnuplot.

Comments?

jwe