octave-maintainers
[Top][All Lists]
Advanced

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

DEFVARs in .oct files (was: Re: More Sparse QR)


From: John W. Eaton
Subject: DEFVARs in .oct files (was: Re: More Sparse QR)
Date: Thu, 9 Feb 2006 12:56:57 -0500

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.

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



reply via email to

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