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?