Re: __gnuplot_set__ fails as function call 2.9.1

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: __gnuplot_set__ fails as function call 2.9.1

Dmitri A. Sergatskov
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
b) I believe __gnuplot_set__ is also deprecated and it is preferred
     to use __gnuplot_raw__("set mouse;\n")

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.
For one thing this substitution breaks mesh() and related
commands, so __gnuplot_set__ will hang around for at least short
while.

I think discussion should go to maintainers list.

Regards,

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: __gnuplot_set__ fails as function call 2.9.1

John W. Eaton-6
On 30-Mar-2005, Dmitri A. Sergatskov <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: __gnuplot_set__ fails as function call 2.9.1

Daniel Sebald
John W. Eaton wrote:

> 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?

Could you please clarify the big picture on this?  My understanding was that instead of having a
plotting device at the core of Octave, it would be moved to the "__plot__", etc. m-scripts.  There
there could be any plotting utility.  So what this would require is a unique set of m-scripts for,
say, gnuplot commands.  In those scripts would be a way to launch gnuplot and do the things you
mention above.

I assume there will be other types of graphics packages put together this way.

But how then does someone indicate their selection of which plotting utility to use?  Is this
something selected when installing?

How does one close gnuplot if it is launched from a plotting m file?  Is there to be some hook into
Octave that can call a command upon exit, just like .octaverc?

Dan


Reply | Threaded
Open this post in threaded view
|

Re: __gnuplot_set__ fails as function call 2.9.1

John W. Eaton-6
On  1-Apr-2005, Daniel J Sebald <[hidden email]> wrote:

| Could you please clarify the big picture on this?  My understanding
| was that instead of having a plotting device at the core of Octave,
| it would be moved to the "__plot__", etc. m-scripts.  There there
| could be any plotting utility.  So what this would require is a
| unique set of m-scripts for, say, gnuplot commands.  In those
| scripts would be a way to launch gnuplot and do the things you
| mention above.
|
| I assume there will be other types of graphics packages put together
| this way.

Yes, I think there already are.  The one in Octave based on gnuplot
was the only special one.

Other code that is not part of a specific graphics package should use
the high-level plotting functions, not the low-level things like
__gnuplot_raw__.  That way it can work with any graphics package.

Eventually, maybe we will converge on a single preferred package for
doing graphics from inside Octave.  But until then, we should try to
make it easy to experiment with different options.  If people need
additional features (line widths, etc.) then we should agree on how to
get that into the higher-level plotting functions.  It makes sense
for compatibility to provide a handle-graphics interface for that, but
that does not have to be the only way (in the past, we've discussed
things like

  h.property = value;

as an alternative to

  set (h, property, value, ...);

for setting graphics properties.

| But how then does someone indicate their selection of which plotting
| utility to use?  Is this something selected when installing?

I think it should be selectable at run-time, using LOADPATH.

| How does one close gnuplot if it is launched from a plotting m file?
| Is there to be some hook into Octave that can call a command upon
| exit, just like .octaverc?

Use closeplot.  The code to interface with gnuplot is still in C++.
Commands like __gnuplot__ (i.e., the current __gnuplot_raw__) would
include the necessary magic to automatically (re)start gnuplot if
needed and kill it when Octave exits.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: __gnuplot_set__ fails as function call 2.9.1

Daniel Sebald
John W. Eaton wrote:

> On  1-Apr-2005, Daniel J Sebald <[hidden email]> wrote:
> | I assume there will be other types of graphics packages put together
> | this way.
>
> Yes, I think there already are.  The one in Octave based on gnuplot
> was the only special one.
>
> Other code that is not part of a specific graphics package should use
> the high-level plotting functions, not the low-level things like
> __gnuplot_raw__.  That way it can work with any graphics package.

OK, then we had the same general arrangement in mind.

> Eventually, maybe we will converge on a single preferred package for
> doing graphics from inside Octave.  But until then, we should try to
> make it easy to experiment with different options.

Yes.

>  If people need
> additional features (line widths, etc.) then we should agree on how to
> get that into the higher-level plotting functions.  It makes sense
> for compatibility to provide a handle-graphics interface for that, but
> that does not have to be the only way (in the past, we've discussed
> things like
>
>   h.property = value;
>
> as an alternative to
>
>   set (h, property, value, ...);
>
> for setting graphics properties.

Perhaps, but that then makes things tricky.  I've stated before I'm not a fan of
handle graphics, but "set" is a function that could be routed to an m-script.
h.property = value can't be done that way.  Wouldn't that only work with an
internal graphics driver?

>
> | But how then does someone indicate their selection of which plotting
> | utility to use?  Is this something selected when installing?
>
> I think it should be selectable at run-time, using LOADPATH.

Yes, definitely.  It would be difficult to experiment if configuration were done
at install time.

>
> | How does one close gnuplot if it is launched from a plotting m file?
> | Is there to be some hook into Octave that can call a command upon
> | exit, just like .octaverc?
>
> Use closeplot.  The code to interface with gnuplot is still in C++.
> Commands like __gnuplot__ (i.e., the current __gnuplot_raw__) would
> include the necessary magic to automatically (re)start gnuplot if
> needed and kill it when Octave exits.

OK.

Dan