octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DEFVARs in .oct files


From: David Bateman
Subject: Re: DEFVARs in .oct files
Date: Fri, 10 Feb 2006 11:40:44 +0100
User-agent: Mozilla Thunderbird 0.8 (X11/20040923)

John W. Eaton wrote:

On  9-Feb-2006, David Bateman wrote:

| John W. Eaton wrote:
|
| > [I'm posting this to the maintainers list because I'd like to see some
| > additional feedback about this issue before deciding what to
| > do. --jwe]
| >
| > On  9-Feb-2006, David Bateman wrote:
| >
| > | The DEFVAR's in
| > | __gnuplot_raw__.cc just need to be moved from __gnuplot_init__ to
| > | somewhere else that is called at startup. This makes sense to me as
| > | things like automatic_replot can probably be used by other plotters
| > than
| > | gnuplot.
| >
| > Originally, there was a PKG_ADD line that ran __gnuplot_init__.  But
| > that means that the gnuplot code is loaded even when it is not needed.
| > So I removed it, which caused part of the current bug.  We currently
| > have the following DEFVARs in __gnuplot_raw__.l:
| >
| >     DEFVAR (automatic_replot, true, automatic_replot,
| >     DEFVAR (gnuplot_binary, GNUPLOT_BINARY, gnuplot_binary,
| >     DEFVAR (gnuplot_command_plot, "pl", gnuplot_command_plot,
| >     DEFVAR (gnuplot_command_replot, "rep", gnuplot_command_replot,
| >     DEFVAR (gnuplot_command_splot, "sp", gnuplot_command_splot,
| >     DEFVAR (gnuplot_command_using, "u", gnuplot_command_using,
| >     DEFVAR (gnuplot_command_with, "w", gnuplot_command_with,
| >     DEFVAR (gnuplot_command_axes, "ax", gnuplot_command_axes,
| >     DEFVAR (gnuplot_command_title, "t", gnuplot_command_title,
| >     DEFVAR (gnuplot_command_end, "\n", gnuplot_command_end,
| > DEFVAR (gnuplot_use_title_option, octave_env::have_x11_display (),
| >
| I'd say only automatic_replot of these needs to be moved..

But if we only DEFVAR automatic_replot when Octave starts, then if
someone puts

  gnuplot_binary = "/my/gnuplot";

in their ~/.octaverc file, it won't really have any effect?  I think
that would be pretty confusing.

I think the real issue is that external packages may want to define
"automatic" or "built-in" variables, and they can't really do that
unless the variables loaded before a user tries to set them.  My
"require" proposal (see below) would make that possible, but would
require the user to do something extra.  I suppose another possibility
is a mechanism similar to autoload (but for variables instead of
functions) that could go in the PKG_ADD file.

Here is the rest of my previous posting.  I'm including it since I
forgot to change the Subject line on the first post.

I have the tendency to place nothing in my .octaverc file and rely on the defaults being sensible, so I'm less affected by this issue.

If the idea was one or the other of the above solutions, I'd tend to say that the autoload idea was better, as then the control of the variables and their existence is in the hands of the maintainers of octave, and the user doesn't need to do anything. There might be some issue if the user tries to overload one of these autoloaded variables with a function though..

D.


| > Should all of these go in another file that is always loaded?  If we
| > do that, then do we have to do that for every package that wants to
| > define some built-in variables?
| >
| > Is it reasonable to ask users to load the gnuplot library before using
| > the variables that are defined in that file?  Probably by doing
| > something like
| >
| >   gnuplot_init ();
| >   gnuplot_binary = "/my/gnuplot";
| >
| > This would be similar to
| >
| >   (require 'gnuplot)
| >   (setq gnuplot_binary "/my/gnuplot")
| >
| > in Emacs or importing a module in Python.  I know, this is not very
| > Matlab-like, but I think it would solve the problem.
| >
| > Or, we could even introduce a "require" function, so that
| >
| >   require ("PKG");
| >
| > checks for a __PKG_init__ function, and executes it if it is
| > available.
| >
| > Comments?

jwe



--
David Bateman                                address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob) 91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax) The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary



reply via email to

[Prev in Thread] Current Thread [Next in Thread]