[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnuplot+octave+cygwin-X11
From: |
Shai Ayal |
Subject: |
Re: gnuplot+octave+cygwin-X11 |
Date: |
Wed, 12 Oct 2005 07:28:11 +0200 |
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 <address@hidden> 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 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
>
>