octave-maintainers
[Top][All Lists]
Advanced

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

Re: RC2 / 5.0.91


From: Rik
Subject: Re: RC2 / 5.0.91
Date: Wed, 6 Feb 2019 11:17:52 -0800

On 02/06/2019 10:23 AM, Philip Nienhuis wrote:
> Rik wrote:
>> On 02/06/2019 09:00 AM, address@hidden wrote:
>>> Subject:
>>> Re: RC2 / 5.0.91
>>> From:
>>> PhilipNienhuis <address@hidden>
>>> Date:
>>> 02/06/2019 04:34 AM
>>>
>>> To:
>>> address@hidden
>>>
>>> List-Post:
>>> <mailto:address@hidden>
>>> Content-Transfer-Encoding:
>>> 7bit
>>> Precedence:
>>> list
>>> MIME-Version:
>>> 1.0
>>> References:
>>> <address@hidden>
>>> In-Reply-To:
>>> <address@hidden>
>>> 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.

--Rik





reply via email to

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