Re: gnuplot+octave+cygwin-X11

[Shai A. <sh...@gm...>]

Maybe while doing these changes, the much talked about "split" of the
plotting code from octave could also be implemented? I have no idea
how, but it seems that the gnuplot interface will undergo not so minor
changes so it's a good time to at least do it in way which will be
consistent with the future plan to split the gnuplot code.

Shai

On 10/11/05, John W. Eaton <jw...@be...> wrote:
> On 11-Oct-2005, John W. Eaton wrote:
>
> | On 10-Oct-2005, Paul Kienzle wrote:
> |
> | | Any idea how difficult it would be to extend octave/gnuplot to suppor=
t
> | | multiple figures natively?
> |
> | The fix for Octave, independent of any changes to gnuplot, would be to
> | open a separate connection to gnuplot for each figure (i.e., one
> | gnuplot process per figure).  In the current sources, you'd need to do
> | this in the src/DLD-FUNCTIONS/gplot.l file.  Instead of
> |
> |   // Pipe to gnuplot.
> |   static oprocstream *plot_stream =3D 0;
> |
> | we might want
> |
> |   // Pipe to gnuplot.
> |   static oprocstream *current_plot_stream =3D 0;
> |
> |   std::map<int,oprocstream *> plot_stream_map;
> |
> | to map figure numbers to plot stream objects.
> |
> | The current figure.m should maybe become a built-in function that
> | handles opening plot streams and manages the plot_stream_map and the
> | variable __current_figure__.  Currently this variable is only defined
> | as a global in the scripting language, but that should probably become
> | a variable in gplot.l that is exported to the scripting language.
>
> I looked at this a bit more and I think the variables
>
>  // The number of lines we've plotted so far.
>  static int plot_line_count =3D 0;
>
>  // Is this a parametric plot?  Makes a difference for 3D plotting.
>  static bool parametric_plot =3D false;
>
>  // The gnuplot terminal type.
>  static std::string gnuplot_terminal_type;
>
> will also need to be per-process variables, and the functions that
> handle opening and closing the plot stream will need to be changed.
> Probably all the per-process data should go in a separate class.
> You'll want to be able to look up a process given a figure number or a
> PID (for the plot_stream_event_handler).  The oprocstream object contains
> the PID, so you shouldn't need to duplicate that, but you will need to
> be able to go from PID to oprocstream object.  Etc.  There are quite a
> few details.  I think the current code could use some cleaning up.
>
> jwe
>
>