gnuplot+octave+cygwin-X11

[John W. Eaton]

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 support 
| | 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 = 0;
| 
| we might want
| 
|   // Pipe to gnuplot.
|   static oprocstream *current_plot_stream = 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 = 0;

  // Is this a parametric plot?  Makes a difference for 3D plotting.
  static bool parametric_plot = 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