Re: --norc option

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

Re: --norc option

Rik-4
On 02/07/2019 11:15 AM, [hidden email] wrote:
Subject:
Re: RC2 / 5.0.91
From:
Andrew Janke [hidden email]
Date:
02/07/2019 11:15 AM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
8bit
Precedence:
list
MIME-Version:
1.0
References:
[hidden email] <MTAwMDAwMy5ub21hZA.1549473997@quikprotect> <MTAwMDAyMC5ub21hZA.1549480678@quikprotect> [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
text/plain; charset=utf-8; format=flowed
Message:
4



On 2/7/19 3:39 AM, PhilipNienhuis wrote:
Rik-4 wrote
On 02/06/2019 10:23 AM, Philip Nienhuis wrote:
Rik wrote:
On 02/06/2019 09:00 AM,

This looks like a problem with the the first save() command.  It expects
that save, without options, will save in a text or ascii format, but
that can be overridden.  What is the result for you of executing

save_default_options()

I'm guessing you have switched your default file format to a Matlab
compatible format.

If this diagnosis is correct, then this test just needs to be change to
use "-text" or "-ascii".  I don't know what the original test writer
(Olaf Till) intended so I am adding him to the CC list.

Hmmm, could be, I haven't touched my .octaverc for a looong time so I
have to look it up tomorrow (as it's on my work PC).

In any event I'd think that tests should be robust enough to cope with
local and/or user settings and create a guaranteed environment for
themselves.

Yes, that's right.  And since you can't save function handles with the
-ascii option, it must be that '-text' was desired.  I verified that if I
set my save_default_options to a Matlab format such as '-V7' then I get
the
same error message that you do.

I fixed things up in this cset
(https://hg.savannah.gnu.org/hgweb/octave/rev/b765393dabe6).

It would be an excellent idea to make sure all of the BIST tests are
immune
to local changes in a user's .octaverc file.

Again, not only in a user's .octaverc, but also in system-wide .octaverc
files.

I'm wondering how many BIST tests would be affected by system/user settings;
if any I'd expect them to be more in OF packages than in core Octave as
quality control in the latter is much stricter.
At first sight it appears a daunting task to explore all tests for potential
dependence on user/system settings.
While it's preferrable to have immune tests right away, perhaps we can avoid
it temporarily in e.g., __run_test_suite__.m by first saving all system/user
settings/prefs, setting all prefs to default state, run the test suite, and
then restore all user/system settings/prefs.

Anyway your guess was a good one, in my %USERPROFILE%/.octaverc I have

:
## Aliases
save_default_options ('-v7')
:

Philip

I wonder if, for the test suite, the system and/or site octavercs should be treated differently from the user octaverc, because this might be used to make configuration changes for Octave to work correctly in the environment in which it's installed?

For example, on macOS, to get Octave working right with doc and doco generation, you need to point it to a newer Texinfo than the system Texinfo, like a Homebrew-installed one. Octave.app handles this by creating a site/m/startup/octaverc that uses makeinfo_program() to point to the brewed Texinfo, and to repoint "pkg" at a different installation location. Example:

----------------------------------------
## This file contain commands that should be executed each time Octave starts
## for every user at this site.
makeinfo_program("/Applications/Octave-4.4.1.app/Contents/Resources/usr/opt/texinfo_6.5_0/bin/makeinfo");

% Octave.app special configuration

% Use a distinct arch-specific package dir to avoid crashes with compiled packages
default_pkg_prefix = pkg ("prefix");
octave_app_pkg_prefix = [getenv("HOME") "/Library/Application Support/Octave.app/4.4.1/pkg"];
% Create the directory ourselves to avoid a warning in the console
mkdir (octave_app_pkg_prefix);
pkg ("prefix", octave_app_pkg_prefix, octave_app_pkg_prefix);
pkg ("local_list", [octave_app_pkg_prefix "/octave_packages"]);
clear default_pkg_prefix octave_app_pkg_prefix

% End Octave.app special configuration
----------------------------------------

We'd want these settings to be in effect when the test suite runs, so that makeinfo invocations work, and anything exercising "pkg" is using the redirected location.

For the Texinfo installation, I think we could do this in a --norc compatible way by manipulating $PATH before launching Octave. Not so with the pkg configuration though.

Thoughts on how to handle this? Should site octaverc still be run when doing test suite runs? Is Octave.app doing the Right Thing by relying on the site octaverc to do important tool configuration?

Can't answer all of the questions, but Octave offers fine-grained control over which initialization files are used:

  --no-init-file          Don't read the ~/.octaverc or .octaverc files.
  --no-site-file          Don't read the site-wide octaverc file.
  --norc, -f              Don't read any initialization files.

It would be quite possible to use --no-init-file rather than --norc for 'make check'.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: --norc option

apjanke-floss


On 2/7/19 2:54 PM, Rik wrote:

> On 02/07/2019 11:15 AM, [hidden email] wrote:
>> Subject:
>> Re: RC2 / 5.0.91
>>
>>
>> Thoughts on how to handle this? Should site octaverc still be run when
>> doing test suite runs? Is Octave.app doing the Right Thing by relying
>> on the site octaverc to do important tool configuration?
>
> Can't answer all of the questions, but Octave offers fine-grained
> control over which initialization files are used:
>
>    --no-init-file          Don't read the ~/.octaverc or .octaverc files.
>    --no-site-file          Don't read the site-wide octaverc file.
>    --norc, -f              Don't read any initialization files.
>
> It would be quite possible to use --no-init-file rather than --norc for
> 'make check'.
>
> --Rik

Oh, that's what I needed. I just didn't remember all the options. Thanks!

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: --norc option

Mike Miller-4
In reply to this post by Rik-4
On Thu, Feb 07, 2019 at 11:54:24 -0800, Rik wrote:
> It would be quite possible to use --no-init-file rather than --norc for
> 'make check'.

I'm sorry if I added to the confusion in this thread. There's "running
the test suite" and there's "make check".

I do think it's appropriate to continue using --norc with "make check".
I don't think we should change anything in test/module.mk.

I also think that users should be able to "run the test suite" in an
installed copy of Octave with all of their own preferences, or with any
combination of --norc, --no-site-file, --no-init-file, --no-gui-libs,
--no-window-system, and so on.

The Debian octave package runs "make check" at build time, and also runs
the full test suite with --no-init-file in the CI environment (as a user
who has no startup files anyway).

--
mike

signature.asc (849 bytes) Download Attachment