Re: Bug#182000: octave2.1: /usr/share/octave/site/m/startup/octaverc-2.1.45 is useless

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#182000: octave2.1: /usr/share/octave/site/m/startup/octaverc-2.1.45 is useless

John W. Eaton-6
[I'm adding octave-maintainers to the recipieent list.  --jwe]

On 22-Feb-2003, Dirk Eddelbuettel <[hidden email]> wrote:

| Or I could like against
|    /usr/share/octave/<version>/m/startup/octaverc
|
| Do you have any strong preferences?  Arguably, distro-specific mods like the
| one I'm doing here could be construed to be 'site' specific. On the other we
| ship it for every Debian installation.

The order that Octave reads the startup files is:

  /usr/share/octave/site/m/startup/octaverc
  /usr/share/octave/2.1.45/m/startup/octaverc
  ~/.octaverc
  .octaverc

I think the Debian package commands should go in the site file, but
that means you can't override anything that might be set in the other
system-wide startup file.

Both of the system-wide startup files are empty in the current Octave
distribution, but we may eventually put some significant startup code
in the .../<version>/m/startup/octaverc file.  Whatever we put in there, it
should not affect paths or other things like that.  The commands I'm
thinking of adding are just things that we could do in an interpreted
script instead of being in the Octave binary.  So you probably
shouldn't need to override that in another rc file that comes after
those commands.  But if you think that would be useful, we could make
some changes (and also make them easier to change in the future).  For
example, in the current setup, the reading of the rc files is fixed in
the C++ code, in a function in src/octave.cc.  Instead, we could make
things more flexible by changing that so the
.../<version>/m/startup/octaverc file contains something like:

  pre_rc_file = strcat (localfcnfiledir. "/startup/pre-octaverc");
  if (exist (pre_rc_file, "file"))
    source (pre_rc_file);
  endif

  ### Other rc file commands here...

  post_rc_file = strcat (localfcnfiledir. "/startup/post-octaverc");
  if (exist (post_rc_file, "file"))
    source (post_rc_file);
  endif

  if (read_init_files)  ## Need a way to pass this into the octaverc file...
    ## handle sourcing the user init files...
  endif

(It might also be useful to have a way of introducing a new scope, so
we wouldn't have to worry about clearing temporary variables, or
clashing with other variables that already exist.)

Finally, what if we had a way to install built-in variables in the
scripting language?  Then we could move things like the initialization
of things like octave_config_info out of the C++ code and into the
startup files.

What do you think?  Would changes like this be useful?  Are they worth
making?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Bug#182000: octave2.1: /usr/share/octave/site/m/startup/octaverc-2.1.45 is useless

Dirk Eddelbuettel
On Sat, Feb 22, 2003 at 01:23:56PM -0600, John W. Eaton wrote:

> [I'm adding octave-maintainers to the recipieent list.  --jwe]
>
> On 22-Feb-2003, Dirk Eddelbuettel <[hidden email]> wrote:
>
> | Or I could like against
> |    /usr/share/octave/<version>/m/startup/octaverc
> |
> | Do you have any strong preferences?  Arguably, distro-specific mods like the
> | one I'm doing here could be construed to be 'site' specific. On the other we
> | ship it for every Debian installation.
>
> The order that Octave reads the startup files is:
>
>   /usr/share/octave/site/m/startup/octaverc
>   /usr/share/octave/2.1.45/m/startup/octaverc
>   ~/.octaverc
>   .octaverc
>
> I think the Debian package commands should go in the site file, but
> that means you can't override anything that might be set in the other
> system-wide startup file.

Earlier today in a reply off the bug system, I realised that the 'site' file
/usr/share/octave/site/m/startup/octaverc is the same file (and hence with
a potential conflict) between two packages: octave2.0 and octave2.1.  That
doesn't work.  I think that led to my error of appending the version string,
which avoids the conflict, but creates, as the bugreport correctly
identifies, a no-op as the file is never read by octave, due to the changed
name.

I have changed this to have Debian's /etc/octave2.1.conf as a soft link to
/usr/share/octave/$(VERSION)/m/startup/octaverc, and 2.1.45-2, or 2.1.46-1,
will have it.  As there is no harm or malfunction, I won't make a fresh
package just because of this.

> Both of the system-wide startup files are empty in the current Octave
> distribution, but we may eventually put some significant startup code
> in the .../<version>/m/startup/octaverc file.  Whatever we put in there, it
> should not affect paths or other things like that.  The commands I'm
> thinking of adding are just things that we could do in an interpreted
> script instead of being in the Octave binary.  So you probably
> shouldn't need to override that in another rc file that comes after
> those commands.  But if you think that would be useful, we could make
> some changes (and also make them easier to change in the future).  For
> example, in the current setup, the reading of the rc files is fixed in
> the C++ code, in a function in src/octave.cc.  Instead, we could make
> things more flexible by changing that so the
> .../<version>/m/startup/octaverc file contains something like:
>
>   pre_rc_file = strcat (localfcnfiledir. "/startup/pre-octaverc");
>   if (exist (pre_rc_file, "file"))
>     source (pre_rc_file);
>   endif
>
>   ### Other rc file commands here...
>
>   post_rc_file = strcat (localfcnfiledir. "/startup/post-octaverc");
>   if (exist (post_rc_file, "file"))
>     source (post_rc_file);
>   endif
>
>   if (read_init_files)  ## Need a way to pass this into the octaverc file...
>     ## handle sourcing the user init files...
>   endif
>
> (It might also be useful to have a way of introducing a new scope, so
> we wouldn't have to worry about clearing temporary variables, or
> clashing with other variables that already exist.)

That sounds like a nice generalisation.

> Finally, what if we had a way to install built-in variables in the
> scripting language?  Then we could move things like the initialization
> of things like octave_config_info out of the C++ code and into the
> startup files.
>
> What do you think?  Would changes like this be useful?  Are they worth
> making?

Definitely nice-to-have things, but I'd put them at a lower priority than
the (impressive) targets you set out as ideas for octave 3.0.

Dirk

--
Prediction is very difficult, especially about the future.
                                             -- Niels Bohr


Reply | Threaded
Open this post in threaded view
|

Builtin variables [was Re: Bug#182000]

Paul Kienzle
In reply to this post by John W. Eaton-6
John W. Eaton wrote:

>Finally, what if we had a way to install built-in variables in the
>scripting language?  Then we could move things like the initialization
>of things like octave_config_info out of the C++ code and into the
>startup files.
>
I'm in favour of doing as much as possible in m-files,
and doing anything from outside octave that can be
done in octave.

Built-in variables are a little bit strange in that they
appear automatically in every scope.  Maybe they
should be functions instead?  They act like functions
in that a change function is called with the new
value.

 For a couple of my functions (e.g., edit.m) I tried
to set up the equivalent of built-in variables for the
arbitrary defaults by using global variables.  This
mostly works except that it is slightly inconvenient
(you need to say global when initializing them from
octaverc) and it pollutes the global space.  Also,
when I save a value to a file, all global variables are
also saved in the file [is there a way to control this?].

Another approach would be property lists associated
with symbols, so I could set the 'author' property on the
edit symbol and edit could query that property.  This
won't work because edit isn't defined until it is called
the first time, but I want to set the properties from octaverc.

A third approach is to do the matlab like thing and
call the function with property pairs and save the property
values in persistent variables.  This I can do now, but
it is kind of ugly.

Suggestions


Reply | Threaded
Open this post in threaded view
|

Builtin variables [was Re: Bug#182000]

John W. Eaton-6
On 22-Feb-2003, Paul Kienzle <[hidden email]> wrote:

| Built-in variables are a little bit strange in that they
| appear automatically in every scope.  Maybe they
| should be functions instead?

I think that in Matlab, they may actually be functions.  I think this
is how things like "i" are described in the documentation.  But I'm
not sure that Matlab has anything that is really like the built-in
variables that Octave allows users to give new values.  But I suppose
we could use functions to set the values instead.  It's the difference
between using something like

  page_screen_output = false;

and

  more off;

I suppose part of the reason for using variables for things like this
was that I was influenced by the way Emacs works.

| They act like functions in that a change function is called with the
| new value.

This is needed because there are C++ variables that must stay in sync
with the values that are known to Octave, and it is convenient (and a
bit more efficient) if those internal variables are not stored in the
symbol table.

| Also, when I save a value to a file, all global variables are
| also saved in the file [is there a way to control this?].

Can you give an example?  Are you trying to save just one variable and
globals are also saved?  If so, that seems like a bug.

jwe