octave-maintainers
[Top][All Lists]
Advanced

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

Re: RC2 / 5.0.91


From: PhilipNienhuis
Subject: Re: RC2 / 5.0.91
Date: Thu, 7 Feb 2019 02:39:57 -0600 (CST)

Rik-4 wrote
> On 02/06/2019 10:23 AM, Philip Nienhuis wrote:
>> Rik wrote:
>>> On 02/06/2019 09:00 AM, 

> octave-maintainers-request@

>  wrote:
>>>> Subject:
>>>> Re: RC2 / 5.0.91
>>>> From:
>>>> PhilipNienhuis <

> pr.nienhuis@

> >
>>>> Date:
>>>> 02/06/2019 04:34 AM
>>>>
>>>> To:
>>>> 

> octave-maintainers@

>>>>
>>>> List-Post:
>>>> <mailto:

> octave-maintainers@

> >
>>>> Content-Transfer-Encoding:
>>>> 7bit
>>>> Precedence:
>>>> list
>>>> MIME-Version:
>>>> 1.0
>>>> References:
>>>> <

> d23ab403-0096-0481-2036-3e921014bb61@

> >
>>>> In-Reply-To:
>>>> <

> d23ab403-0096-0481-2036-3e921014bb61@

> >
>>>> Message-ID:
>>>> <

> address@hidden

>>
>>>> Content-Type:
>>>> text/plain; charset=us-ascii
>>>> Message:
>>>> 3
>>>>
>>>>
>>>> John W. Eaton wrote
>>>>> The second release candidate for Octave 5.1 is now available on
>>>>> alpha.gnu.org in the directory pub/octave.  I uploaded source
>>>>> tarballs,
>>>>> and binaries for 64-bit Windows systems.
>>>> A self-built WIndows binary for Octave-5.0.91 (w. fortran-64 indexing):
>>>>
>>>> Summary:
>>>>
>>>>   PASS                            15499
>>>>   FAIL                                1
>>>>   XFAIL (reported bug)               25
>>>>   SKIP (missing feature)             52
>>>>   SKIP (run-time condition)           9
>>>>
>>>> The FAIL is:
>>>>
>>>>   fixed\bug-45969.tst ............................................ PASS
>>>> 1/2
>>>>
>>>> FAIL    1
>>>>
>>>> and from fntests.log:
>>>>
>>>>>>>>> processing
>>>>>>>>> D:\Octave\OCTAVE~1.91_\mingw64\share\octave\5.0.91\etc\tests\fixed\bug-45969.tst
>>>>>>>>>
>>>> ***** test
>>>>  ascii_filename = tempname ();
>>>>  binary_filename = tempname ();
>>>>  a = 2;
>>>>  b = 10;
>>>>  c = 20;
>>>>  f1 = @ (f, x) f (x) + a;
>>>>  f2 = @ (y) f1 (@ (z) z^2 + b * y, y) + c;
>>>>  f2_arg = 5;
>>>>  unwind_protect
>>>>    save (ascii_filename, "f2");
>>>>    save ("-binary", binary_filename, "f2");
>>>>    ascii = load (ascii_filename);
>>>>    binary = load (binary_filename);
>>>>    assert (f2 (f2_arg), ascii.f2 (f2_arg));
>>>>    assert (f2 (f2_arg), binary.f2 (f2_arg));
>>>>  unwind_protect_cleanup
>>>>    unlink (ascii_filename);
>>>>    unlink (binary_filename);
>>>>  end_unwind_protect
>>>> !!!!! test failed
>>>> save: error while writing 'f2' to MAT file
>>>>
>>>>
>>>> Philip
>>>
>>> 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




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html



reply via email to

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