[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goals for 3.1
From: |
Shai Ayal |
Subject: |
Re: goals for 3.1 |
Date: |
Thu, 15 Nov 2007 16:40:55 +0200 |
On Nov 15, 2007 11:48 AM, Daniel J Sebald <address@hidden> wrote:
> Shai Ayal wrote:
>
> > an oct-file is a compiled c++ function file for octave, and is used
> > to define octave functions as an alternative to using an m-file with
> > the m(?) language. Practically what this means is that the current
> > drawnow function just has to be renamed to something more
> > gnuplot_specific, (e.g. __gnuplot_drawnow) and can be used along
> > with other drawnow functions ( e.g. __newbackend_drawnow). I propose
> > that each figure will have a property named "backend" which can have
> > one of several values -- "gnuplot","newbackend", "jhandles", ....).
> > Using this value, the appropriate backend will be called, vie the
> > appropriate drawnow function to render the figure. This way you can
> > have co-existence of many backends, and specifically, we will not
> > have to abandon gnuplot. Each of these back-ends can have specific
> > functions, but these functions should not be in core-octave, and
> > should be used with care since they would break inter-oparability.
>
> I see. In theory then, John's code for building the __plot_stream__ fid's
> and opening the pipes could be moved to some cc file called
> __gnuplot_drawnow__.cc. Rather than __plot_stream__ being part of the figure
> properties, it could be a linked list of (term, __plot_stream__). Then how
> about a similar Oct file routine __gnuplot_f2s__(term) that returns the
> associated plot stream? Those two would both need to be .oct files for
> __gnuplot_f2s__ to access the C++ variables inside __gnuplot_drawnow__.oct.
> So, bundled in the package would be:
>
> __gnuplot_drawnow__.oct
> __gnuplot_f2s__.oct
> __gnuplot_version__.m
> __gnuplot_close_all__.m (currently called __go_close_all__.m)
> __gnuplot_draw_axes__.m (currently called __go_draw_axes__.m)
> __gnuplot_draw_figure__.m (currently called __go_draw_figure__.m)
>
> The m-scripts would require minor tweaks. Pass in the term number and first
> line be
>
> __plot_stream__ = __gnuplot_f2s__(term);
> if (__plot_stream__ < -1)
> return;
>
> I replaced the "go" in the files with "gnuplot" because I think, from the
> previous discussion, that there won't ever be a need for __go_draw_figure__
> other than for gnuplot.
>
> Now, to switch the graphics engine, would all that is required be to simply
> create an operating system link:
>
> drawnow.oct -> __gnuplot_drawnow__.oct
>
I would say drawnow.m -> __gnuplot_drawnow__.m (I think it would need
minimal changes)
remove the __plot_stream__ property
add the "backend" property which is a string containing the backend name
add a generic drawnow which is basically:
eval (sprintf ("__%s_drawnow__ (gcf ());",get (gcf (),"backend")));
and now to switch the graphics engine, all that would be necessary is:
set (gcf (), "backend" , "gnuplot");
Shai
> ?
>
> Would that move in the desired direction John?
>
> Dan
>
>
- Re: goals for 3.1, (continued)
- Re: goals for 3.1, Daniel J Sebald, 2007/11/14
- Re: goals for 3.1, John W. Eaton, 2007/11/14
- Re: goals for 3.1, Shai Ayal, 2007/11/14
- Re: goals for 3.1, Daniel J Sebald, 2007/11/14
- Re: goals for 3.1, John W. Eaton, 2007/11/14
- Re: goals for 3.1, Daniel J Sebald, 2007/11/14
- Re: goals for 3.1, Shai Ayal, 2007/11/14
- Re: goals for 3.1, Daniel J Sebald, 2007/11/14
- Re: goals for 3.1, Shai Ayal, 2007/11/15
- Re: goals for 3.1, Daniel J Sebald, 2007/11/15
- Re: goals for 3.1,
Shai Ayal <=
- Re: goals for 3.1, John Swensen, 2007/11/14
Re: goals for 3.1, Daniel J Sebald, 2007/11/14
Re: goals for 3.1, Muthiah Annamalai, 2007/11/13