RC2 / 5.0.91

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

RC2 / 5.0.91

John W. Eaton
Administrator
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.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: RC2 / 5.0.91

PhilipNienhuis
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




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

Reply | Threaded
Open this post in threaded view
|

Re: RC2 / 5.0.91

chechu
Good evening to everyne.

It compiles and checks with some Fails on Debian Stretch 9.0

- Jit Disabled
- 64bit indexing and BLAS
- Openblas 0.3.5 and Atlas 5.4.0


  PASS                            15156
  FAIL                                8
  XFAIL (reported bug)               23
  SKIP (missing feature)            391
  SKIP (run-time condition)          12


Fails on amd.cc-tst
Fails on which.m
Fails on gammainc.m


Kind regards.



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

Reply | Threaded
Open this post in threaded view
|

Re: RC2 / 5.0.91

Rik-4
In reply to this post by John W. Eaton
On 02/06/2019 09:00 AM, [hidden email] wrote:
Subject:
Re: RC2 / 5.0.91
From:
PhilipNienhuis [hidden email]
Date:
02/06/2019 04:34 AM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
[hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
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.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: RC2 / 5.0.91

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

> Rik wrote:
>> On 02/06/2019 09:00 AM, [hidden email] wrote:
>>> Subject:
>>> Re: RC2 / 5.0.91
>>> From:
>>> PhilipNienhuis <[hidden email]>
>>> Date:
>>> 02/06/2019 04:34 AM
>>>
>>> To:
>>> [hidden email]
>>>
>>> List-Post:
>>> <mailto:[hidden email]>
>>> Content-Transfer-Encoding:
>>> 7bit
>>> Precedence:
>>> list
>>> MIME-Version:
>>> 1.0
>>> References:
>>> <[hidden email]>
>>> In-Reply-To:
>>> <[hidden email]>
>>> Message-ID:
>>> <[hidden email]>
>>> 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 | Threaded
Open this post in threaded view
|

Re: RC2 / 5.0.91

PhilipNienhuis
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 &lt;

> pr.nienhuis@

> &gt;
>>>> Date:
>>>> 02/06/2019 04:34 AM
>>>>
>>>> To:
>>>>

> octave-maintainers@

>>>>
>>>> List-Post:
>>>> &lt;mailto:

> octave-maintainers@

> &gt;
>>>> Content-Transfer-Encoding:
>>>> 7bit
>>>> Precedence:
>>>> list
>>>> MIME-Version:
>>>> 1.0
>>>> References:
>>>> &lt;

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

> &gt;
>>>> In-Reply-To:
>>>> &lt;

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

> &gt;
>>>> Message-ID:
>>>> <

> 1549456482083-0.post@.nabble

>>
>>>> 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 | Threaded
Open this post in threaded view
|

Re: RC2 / 5.0.91

Mike Miller-4
On Thu, Feb 07, 2019 at 02:39:57 -0600, PhilipNienhuis wrote:
> 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.

Octave already has the --norc option to prevent loading all system and
user startup files. I think what you're suggesting is covered by that.
If a user wants to run the test suite without any system or user
preferences changing behavior, they can run Octave with --norc.

If a certain test passes with --norc and fails without it, then we can
find the cause and fix that specific test.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RC2 / 5.0.91

apjanke-floss
In reply to this post by PhilipNienhuis


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?

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: RC2 / 5.0.91

Mike Miller-4
On Thu, Feb 07, 2019 at 14:15:04 -0500, Andrew Janke wrote:
> 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?

In that case, you can choose to run the test suite with octave
--no-init-file. This loads the system startup files but avoids loading
user startup files.

I feel like this subthread is trying to define a strict environment that
the test suite should always be run in. IMHO that is not the right
direction at all. The test suite should be run in the user's normal
working environment.

> 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?

Yes, I think this is exactly the right thing.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RC2 / 5.0.91

apjanke-floss


On 2/7/19 2:45 PM, Mike Miller wrote:
> On Thu, Feb 07, 2019 at 14:15:04 -0500, Andrew Janke wrote:
>> 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?
>
> In that case, you can choose to run the test suite with octave
> --no-init-file. This loads the system startup files but avoids loading
> user startup files.

Thanks.

> I feel like this subthread is trying to define a strict environment that
> the test suite should always be run in. IMHO that is not the right
> direction at all. The test suite should be run in the user's normal
> working environment.

I fully agree with this. It would be best if the test suite ran
everywhere, and it used mechanisms to insulate itself from irrelevant
variability in the preference/environment state.

>> 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?
>
> Yes, I think this is exactly the right thing.

Thanks. Will continue to do so.

Cheers,
Andrew