gnuplot+octave+cygwin-X11

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

gnuplot+octave+cygwin-X11

Paul Kienzle
Hi,

The current octave-cygwin package depends on gnuplot which depends on
X11.  I know there is a Windows native terminal for gnuplot so the X11
package isn't strictly required, but I believe the Windows terminal
only allows one figure.

Any idea how difficult it would be to extend octave/gnuplot to support
multiple figures natively?

Thanks,

        - Paul

Reply | Threaded
Open this post in threaded view
|

Re: gnuplot+octave+cygwin-X11

James R. Phillips-2
--- Paul Kienzle  wrote:

> Hi,
>
> The current octave-cygwin package depends on gnuplot which depends on
> X11.  I know there is a Windows native terminal for gnuplot so the X11
> package isn't strictly required, but I believe the Windows terminal
> only allows one figure.
>
> Any idea how difficult it would be to extend octave/gnuplot to support
> multiple figures natively?
>
> Thanks,
>
> - Paul
>

Not really, but I note that similar discussions regarding the use of X vs
native win32 gui's for tk and other apps are now taking place on the cygwin
mailing list; see e.g. http://cygwin.com/ml/cygwin-apps/2005-10/msg00134.html.

gnuplot is under active development, so I think a visit to their mailing lists
might be appropriate.  {OK, I see you've been there already.}

Anyway...for myself, I _like_ X on cygwin.  And, I _like_ cygwin on windows.  I
find that the strength of a cygwin app like octave comes in large part from its
integration with a complete posix environment with the standard scripting,
development tools, and yes, gui.  I drank the kool-aid.

jrp


Reply | Threaded
Open this post in threaded view
|

Re: gnuplot+octave+cygwin-X11

Petr Mikulik
In reply to this post by Paul Kienzle
> The current octave-cygwin package depends on gnuplot which depends on X11.  I
> know there is a Windows native terminal for gnuplot so the X11 package isn't
> strictly required, but I believe the Windows terminal only allows one figure.

It is advantageous to use the X11-gnuplot under windows so that the complete
set of multi-window features (and more) is allowed.

> Any idea how difficult it would be to extend octave/gnuplot to support
> multiple figures natively?

Cross-platform wxWidgets terminal for gnuplot is under development by
Timothée Lecomte, see

http://tipote.free.fr/wxt3.png
http://tipote.free.fr/wxt4.png

http://sourceforge.net/tracker/index.php?func=detail&aid=1267434&group_id=2055&atid=302055

It will have (has...) all the goodies of X11 plus menu's like OS/2 PM
terminal.

---
PM
Reply | Threaded
Open this post in threaded view
|

gnuplot+octave+cygwin-X11

John W. Eaton-6
In reply to this post by Paul Kienzle
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.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: gnuplot+octave+cygwin-X11

Petr Mikulik
> 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).

I would enjoy this change! Gnuplot interactive mousing (e.g. zooming by
mouse) is limited to the current window only (for which "replot" works).

For example, you need to popen() several gnuplots to work simultaneously on
a map and its line cross-section. That way you bypass the octave built-in
gnuplot plotting completely and define all commands through "in userspace".

The proposed built-in solution with
>    static oprocstream *plot_stream = 0;
>    std::map<int,oprocstream *> plot_stream_map;
>    static oprocstream *current_plot_stream = 0;
would be much more elegant and consistent.

---
PM

Reply | Threaded
Open this post in threaded view
|

gnuplot+octave+cygwin-X11

John W. Eaton-6
In reply to this post by John W. Eaton-6
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

Reply | Threaded
Open this post in threaded view
|

Re: gnuplot+octave+cygwin-X11

Shai Ayal-2
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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: gnuplot+octave+cygwin-X11

John W. Eaton-6
On 12-Oct-2005, Shai Ayal wrote:

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

In 2.9.x, the split is mostly complete.

Also, I've checked in some changes that make Octave use a separate
process for each figure window.  It seems to work for me.  If you'd
like to check it out, try the latest version of Octave from the CVS
archive.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: gnuplot+octave+cygwin-X11

Shai Ayal-2
John,

can you point me at the source files which contain all the plot related stuff?

Shai

On 10/14/05, John W. Eaton <[hidden email]> wrote:

> On 12-Oct-2005, Shai Ayal wrote:
>
> | 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.
>
> In 2.9.x, the split is mostly complete.
>
> Also, I've checked in some changes that make Octave use a separate
> process for each figure window.  It seems to work for me.  If you'd
> like to check it out, try the latest version of Octave from the CVS
> archive.
>
> jwe
>

Reply | Threaded
Open this post in threaded view
|

Re: gnuplot+octave+cygwin-X11

John W. Eaton-6
On 14-Oct-2005, Shai Ayal wrote:

| can you point me at the source files which contain all the plot
| related stuff?

Start here:

  scripts/plot
  src/DLD-FUNCTIONS/gplot.l

jwe