On 27-Jan-2009, Ben Abbott wrote:
|
| On Jan 27, 2009, at 2:19 AM, Daniel J Sebald wrote:
|
| > John W. Eaton wrote:
| >> On 26-Jan-2009, Ben Abbott wrote:
| >> | I agree, we are missing the checkout date, but I'm not sure
about
| >> checking for it. As it would only be useful for developers of
| >> octave/gnuplot, I think it is safe to assume those running 4.3
| >> (developers sources) are able to keep their gnuplot up to date.
| >> | | >I think we should require the most recent release version of
| >> gnuplot
| >> | >(4.2.4) for the octave development tree. If we can *safely*
| >> determine
| >> | >features of the gnuplot development tree (4.3), those could be
| >> supported
| >> | >too. But I would do this on case-by-case basis.
| >> | | My understanding is that 4.2.4 is required for the developers
| >> sources ... 4.2.3 will work but not display 3D plots correctly
with
| >> shading("interp").
| >> | | >I think it is o.k. to require for a new octave release the
| >> most recent
| >> | >release of gnuplot (4.2.4 at the moment). But others might see
| >> this
| >> | >different.
| >> | >
| >> | >Kai
| >> | | I'd also like see the conditional support for these
| >> improvements (figure position and facealpha) added to the gnuplot
| >> backend.
| >> | | Is there a reason why we wouldn' t want to do that?
| >> I think it would be best to check for individual features, not
| >> version
| >> numbers. Even if you can't find a reliable way to check for
| >> features,
| >> please consider writing something like this in the code that
needs to
| >> do different things depending on what features are available:
| >> if (gnuplot_has_foobar ())
| >> ...
| >> else
| >> ...
| >> endif
| >> ...
| >> function retval = gnuplot_has_foobar ()
| >> persistent retval = compare_versions (__gnuplot_version__ (),
| >> "4.2.2", ">=");
| >> endfunction
| >> This way I think it will be easier to read the code, and
simpler to
| >> remove specific checks when/if it is safe to assume that everyone
| >> will
| >> have a version of gnuplot that supports a given feature.
| >
| > Good idea. Were you thinking to make it generic, like:
| >
| > gnuplot_has_feature('xyz')
| >
| > so there is only one function rather than possibly many? If there
| > were some feedback, one could even send a test script over to
| > gnuplot to check whether is understand a particular syntax.
| >
| > Dan
|
| I see value in both suggestions. I've tried to merge both into one
| function.
|
| The function, __gnuplot_has_feature__(), supports four conditional
| gnuplot features I'm aware of.
|
| "x11_respects_figure_position" - to be used in gnuplot_drawnow.m
|
| "transparency_of_patches" - to be used in __go_draw_axes__.m
|
| "epslatex_implies_eps_filesuffix": conditional exists in print.m
|
| "epslatexstandalone_terminal": conditional exists in print.m
|
| A changeset is attached.
For internal functions like this, please simply document them with
## -*- texinfo -*-
## @deftypefn {Function File} address@hidden = }
__gnuplot_has_feature__ (@var{feature})
## Undocumented internal function.
## @end deftypefn