[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goals for 3.1
From: |
Daniel J Sebald |
Subject: |
Re: goals for 3.1 |
Date: |
Wed, 14 Nov 2007 20:51:44 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
On Nov 14, 2007 6:52 PM, Daniel J Sebald <address@hidden>
wrote:
[snip]
If the approach I explained in the last post were made to work,
i.e., able to send commands to the __plot_stream__ and have
whatever is on the other end respond accordingly, then that gives
the flexibility needed. One could write their own __gnuplot_X__()
consisting of a dozen commands or less. If we could write a script
as such before 3.0 and verify it works, then post it somewhere that
would put the issue to rest for at least the foreseeable future
Shai wrote:
You are assuming that "whatever is on the other end" will be
something that works by parsing a stream. This would probably not be
the case for any backend other than gnuplot
John wrote:
The problem with this approach is that there might not be a
__plot_stream__ in a future version of Octave.
Note that I said foreseeable future. What I am proposing would require a script file of,
say, a half dozen lines? That'd be not much effort wasted if the scheme changes some
day. What I'm suggesting (and if there is a better alternative, say so) is that the
current __go_draw_axes__, __gnuplot_version__, etc. and some script, say, gpcom() for
"gnuplot command" (a very short little routine) be bundled as a package. If
gnuplot is the only such package that uses __plot_stream__ so be it. Remove the
__gnuplot_raw__ commands from Octave innards.
Comments:
1) The octave/gnuplot community would then have its little pseudo-standard
"gpcom()" routine, or whatever it is to be called, that is detached from
Octave-cvs. __gnuplot_raw__ is somewhat typing-unfriendly, so few would miss it I'm
guessing.
2) I recall now why the example I gave previously doesn't work. "replot" requires data
in a file and now data is streamed through the pipe itself. A "redraw" command is in the
works for gnuplot that will reuse the data it was sent. I'm not sure how that has come along,
however.
As for the __plot_stream__, if not a generic interface that uses pipes, what type of generic interface will it be? I mean, if one wants to interface to some other graphics library it would be easy enough to write something that uses a plot stream as though it were calling library functions.
Or, one could write a set of Octave graphic primitives in C++ (perhaps similar to the
various elements of __go_draw_axes__) that call some library functions---the
gnuplot-target code would have a builtin plot stream in which case one would have to
figure out how to make a "gpcom()" interface to that. If one goes this route,
will it mean compiling different versions of Octave to get the desired graphics backend?
Will it be something like Windows plugins?
The question that often comes to mind is whether it is intended going forward that Octave have
flexibility for multiple graphics engine support or not. Reading the list, sometimes I think
"yes", sometimes "no". There is allusion to some better configuration or
alternative, but what exactly that is hasn't been defined. If there is going to be a choice of one
graphics library, compiled internal to Octave and nothing else, that means a break has to be made
somewhere and for a while (probably quite a long while) the plotting quality won't be the same as
Matlab.
The __plot_stream__ issue is small. Is there that bigger question still?
Dan
- goals for 3.1, John W. Eaton, 2007/11/13
- Re: goals for 3.1, David Bateman, 2007/11/13
- Re: goals for 3.1, Rolf Fabian, 2007/11/14
- Re: goals for 3.1, Joseph C. Slater PE, PhD, 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, John W. Eaton, 2007/11/14
- Re: goals for 3.1, Shai Ayal, 2007/11/14
- Re: goals for 3.1,
Daniel J Sebald <=
- 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, 2007/11/15
- Re: goals for 3.1, John Swensen, 2007/11/14
Re: goals for 3.1, Daniel J Sebald, 2007/11/14