Testing octave-4.0.1-rc4

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

Testing octave-4.0.1-rc4

Rik-4
jwe,

I tested the new tarball at ftp://alpha.gnu.org.  As expected for a vanilla Linux system, it passed all tests and all build configurations including in-tree, out-of-tree builds, and 'make install' followed by __run_test_suite__.

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

RE: Testing octave-4.0.1-rc4

John Donoghue-3
>
> Message: 7
> Date: Thu, 10 Mar 2016 20:24:13 -0800
> From: Rik <[hidden email]>
> To: Octave-Maintainers <[hidden email]>, "John W. Eaton"
> <[hidden email]>
> Subject: Testing octave-4.0.1-rc4
> Message-ID: <MTAwMDAwNC5ub21hZA.1457670261@quikprotect>
> Content-Type: text/plain; charset="utf-8"
>
> jwe,
>
> I tested the new tarball at ftp://alpha.gnu.org.  As expected for a
vanilla
> Linux system, it passed all tests and all build configurations including
> in-tree, out-of-tree builds, and 'make install' followed by
__run_test_suite__.
>
> --Rik


Compiling in mxe-octave with new tarball and running win7:

  PASS     13020
  FAIL         0
  XFAIL       27
  SKIPPED     54




Reply | Threaded
Open this post in threaded view
|

RE: Testing octave-4.0.1-rc4

chechu
Good evening,

It compiles and runs make check correctly

Debian amd64, openblas, jit, octave and needed dependencies 64bit



  PASS     13075
  FAIL         0
  XFAIL       25
  SKIPPED      1
Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

John W. Eaton
Administrator
In reply to this post by John Donoghue-3
On 03/11/2016 07:13 AM, JohnD wrote:

>>
>> Message: 7
>> Date: Thu, 10 Mar 2016 20:24:13 -0800
>> From: Rik <[hidden email]>
>> To: Octave-Maintainers <[hidden email]>, "John W. Eaton"
>> <[hidden email]>
>> Subject: Testing octave-4.0.1-rc4
>> Message-ID: <MTAwMDAwNC5ub21hZA.1457670261@quikprotect>
>> Content-Type: text/plain; charset="utf-8"
>>
>> jwe,
>>
>> I tested the new tarball at ftp://alpha.gnu.org.  As expected for a
> vanilla
>> Linux system, it passed all tests and all build configurations including
>> in-tree, out-of-tree builds, and 'make install' followed by
> __run_test_suite__.
>>
>> --Rik
>
>
> Compiling in mxe-octave with new tarball and running win7:
>
>    PASS     13020
>    FAIL         0
>    XFAIL       27
>    SKIPPED     54

I saw this the first time I tried mxe-octave:

[build]    nsis
[done]     nsis
generating installer script...
generating installer...
*** Error in `i686-w64-mingw32-makensis': double free or corruption
(!prev): 0x0000000001f3e6d0 ***
bash: line 1: 13395 Aborted                 i686-w64-mingw32-makensis
/scratch/jwe/mxe-octave/dist/octave.nsi >
/scratch/jwe/mxe-octave/dist/nsis.log
/scratch/jwe/mxe-octave/binary-dist-rules.mk:185: recipe for target
'octave-4.0.1-rc4-installer.exe' failed
make: *** [octave-4.0.1-rc4-installer.exe] Error 134

I used

   ./configure --enable-binary-packages --enable-devel-tools
   make JOBS=10
   make binary-dist-files zip-dist nsis-installer

After the failure, I tried again with just

   make nsis-installer

and it seems to have worked.  Odd.

Anyway, testing now, and if my build looks OK I'll upload it to
alpha.gnu.org.

Unless there are any objections, I think this should become 4.0.1 (only
changing the version number).

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

John Donoghue-3
On 03/11/2016 09:20 AM, John W. Eaton wrote:

> On 03/11/2016 07:13 AM, JohnD wrote:
>>>
>>> Message: 7
>>> Date: Thu, 10 Mar 2016 20:24:13 -0800
>>> From: Rik <[hidden email]>
>>> To: Octave-Maintainers <[hidden email]>, "John W. Eaton"
>>>     <[hidden email]>
>>> Subject: Testing octave-4.0.1-rc4
>>> Message-ID: <MTAwMDAwNC5ub21hZA.1457670261@quikprotect>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> jwe,
>>>
>>> I tested the new tarball at ftp://alpha.gnu.org.  As expected for a
>> vanilla
>>> Linux system, it passed all tests and all build configurations
>>> including
>>> in-tree, out-of-tree builds, and 'make install' followed by
>> __run_test_suite__.
>>>
>>> --Rik
>>
>>
>> Compiling in mxe-octave with new tarball and running win7:
>>
>>    PASS     13020
>>    FAIL         0
>>    XFAIL       27
>>    SKIPPED     54
>
> I saw this the first time I tried mxe-octave:
>
> [build]    nsis
> [done]     nsis
> generating installer script...
> generating installer...
> *** Error in `i686-w64-mingw32-makensis': double free or corruption
> (!prev): 0x0000000001f3e6d0 ***
> bash: line 1: 13395 Aborted i686-w64-mingw32-makensis
> /scratch/jwe/mxe-octave/dist/octave.nsi >
> /scratch/jwe/mxe-octave/dist/nsis.log
> /scratch/jwe/mxe-octave/binary-dist-rules.mk:185: recipe for target
> 'octave-4.0.1-rc4-installer.exe' failed
> make: *** [octave-4.0.1-rc4-installer.exe] Error 134
>
> I used
>
>   ./configure --enable-binary-packages --enable-devel-tools
>   make JOBS=10
>   make binary-dist-files zip-dist nsis-installer
>
> After the failure, I tried again with just
>
>   make nsis-installer
>
> and it seems to have worked.  Odd.
>
> Anyway, testing now, and if my build looks OK I'll upload it to
> alpha.gnu.org.
>
> Unless there are any objections, I think this should become 4.0.1
> (only changing the version number).
>
> jwe
>
>

I haven't seen the issue, however I don't usually specify jobs.

There has been a couple of other reports over the months where a random
package in mxe-octave has failed to build - however either rerunning
make, or make JOBS=1 works fine

This doesnt look like that kind of issue though.

4.0.1 gets my vote!



Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

John W. Eaton
Administrator
On 03/11/2016 09:41 AM, John Donoghue wrote:

> I haven't seen the issue, however I don't usually specify jobs.

I only used JOBS=10 for the build, not for the make-dist part.

> There has been a couple of other reports over the months where a random
> package in mxe-octave has failed to build - however either rerunning
> make, or make JOBS=1 works fine
>
> This doesnt look like that kind of issue though.
>
> 4.0.1 gets my vote!

OK.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

PhilipNienhuis
In reply to this post by Rik-4
Rik-4 wrote
jwe,

I tested the new tarball at ftp://alpha.gnu.org.  As expected for a vanilla
Linux system, it passed all tests and all build configurations including
in-tree, out-of-tree builds, and 'make install' followed by __run_test_suite__.
On Mageia-5 Linux I get only two FAILs for osmesa:

:
>>>>> processing /home/philip/devel/octdev/oct4.0.0-rc4/libinterp/dldfcn/__osmesa_print__.cc-tst
***** testif HAVE_OSMESA, HAVE_GL2PS_H
 if (isunix ())
   h = figure ("visible", "off");
   fn = tempname ();
   sombrero ();
   __osmesa_print__ (h, fn, "svg");
   assert (stat (fn).size, 2692270, -0.1);
   unlink (fn);
   img = __osmesa_print__ (h);
   assert (size (img), [get(h, "position")([4, 3]), 3])
   ## Use pixel sum per RGB channel as fingerprint
   img_fp = squeeze (sum (sum (img), 2));
   assert (img_fp, [52942515; 54167797; 56158178], -0.05);
 endif
!!!!! test failed
ASSERT errors for:  assert (stat (fn).size,2692270,-0.1)

  Location  |  Observed  |  Expected  |  Reason
     ()          2798       2692270      Rel err 0.99896 exceeds tol 0.1
***** testif HAVE_OSMESA, HAVE_GL2PS_H
 if (isunix ())
   h = figure ("visible", "off");
   fn = tempname ();
   plot (sin (0:0.1:2*pi));
   __osmesa_print__ (h, fn, "svgis2d");
   assert (stat (fn).size, 7438, -0.1);
   unlink (fn);
   img = __osmesa_print__ (h);
   assert (size (img), [get(h, "position")([4, 3]), 3])
   ## Use pixel sum per RGB channel as fingerprint
   img_fp = squeeze (sum (sum (img), 2));
   assert (img_fp, [59281711; 59281711; 59482179], -0.05);
 endif
!!!!! test failed
ASSERT errors for:  assert (stat (fn).size,7438,-0.1)

  Location  |  Observed  |  Expected  |  Reason
     ()          2120         7438       Rel err 0.71498 exceeds tol 0.1
:

I get those FAILs with any Octave build on my Linux system.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

Andreas Weber-4
Hi Philip,

Am 11.03.2016 um 15:30 schrieb PhilipNienhuis:

> On Mageia-5 Linux I get only two FAILs for osmesa:
>
> :
>>>>>> processing
>>>>>> /home/philip/devel/octdev/oct4.0.0-rc4/libinterp/dldfcn/__osmesa_print__.cc-tst
> ***** testif HAVE_OSMESA, HAVE_GL2PS_H
>  if (isunix ())
>    h = figure ("visible", "off");
>    fn = tempname ();
>    sombrero ();
>    __osmesa_print__ (h, fn, "svg");
>    assert (stat (fn).size, 2692270, -0.1);
>    unlink (fn);
>    img = __osmesa_print__ (h);
>    assert (size (img), [get(h, "position")([4, 3]), 3])
>    ## Use pixel sum per RGB channel as fingerprint
>    img_fp = squeeze (sum (sum (img), 2));
>    assert (img_fp, [52942515; 54167797; 56158178], -0.05);
>  endif
> !!!!! test failed
> ASSERT errors for:  assert (stat (fn).size,2692270,-0.1)
>
>   Location  |  Observed  |  Expected  |  Reason
>      ()          2798       2692270      Rel err 0.99896 exceeds tol 0.1
> ***** testif HAVE_OSMESA, HAVE_GL2PS_H
>  if (isunix ())
>    h = figure ("visible", "off");
>    fn = tempname ();
>    plot (sin (0:0.1:2*pi));
>    __osmesa_print__ (h, fn, "svgis2d");
>    assert (stat (fn).size, 7438, -0.1);
>    unlink (fn);
>    img = __osmesa_print__ (h);
>    assert (size (img), [get(h, "position")([4, 3]), 3])
>    ## Use pixel sum per RGB channel as fingerprint
>    img_fp = squeeze (sum (sum (img), 2));
>    assert (img_fp, [59281711; 59281711; 59482179], -0.05);
>  endif
> !!!!! test failed
> ASSERT errors for:  assert (stat (fn).size,7438,-0.1)
>
>   Location  |  Observed  |  Expected  |  Reason
>      ()          2120         7438       Rel err 0.71498 exceeds tol 0.1
> :

Can you run the test manually (without unlink which deletes the images)
in Octave and check the generated images? You should see the sombrero
and a simple sin plot.

Which version of libosmesa-dev is installed and do you use proprietary
GPU drivers which doesn't use mesa?

Thanks, Andy

Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

John W. Eaton
Administrator
In reply to this post by John Donoghue-3
On 03/11/2016 07:13 AM, JohnD wrote:

>>
>> Message: 7
>> Date: Thu, 10 Mar 2016 20:24:13 -0800
>> From: Rik <[hidden email]>
>> To: Octave-Maintainers <[hidden email]>, "John W. Eaton"
>> <[hidden email]>
>> Subject: Testing octave-4.0.1-rc4
>> Message-ID: <MTAwMDAwNC5ub21hZA.1457670261@quikprotect>
>> Content-Type: text/plain; charset="utf-8"
>>
>> jwe,
>>
>> I tested the new tarball at ftp://alpha.gnu.org.  As expected for a
> vanilla
>> Linux system, it passed all tests and all build configurations including
>> in-tree, out-of-tree builds, and 'make install' followed by
> __run_test_suite__.
>>
>> --Rik
>
>
> Compiling in mxe-octave with new tarball and running win7:
>
>    PASS     13020
>    FAIL         0
>    XFAIL       27
>    SKIPPED     54

I see almost the same result but I have 26 XFAIL and 13021 PASS.  Here
are my XFAIL counts:

   libinterp\corefcn\conv2.cc-tst   XFAIL   3
   libinterp\corefcn\max.cc-tst     XFAIL   3
   general\num2str.m                XFAIL   1
   polynomial\residue.m             XFAIL   1
   testfun\speed.m                  XFAIL   1
   testfun\test.m                   XFAIL   1
   bug-38236.tst                    XFAIL   1
   classdef.tst                     XFAIL   2
   classes.tst                      XFAIL  11
   jit.tst                          XFAIL   2

Which one(s) are different for you?

Also, it's very nice to see that the packages are all cross compiled and
installed by the installer now!

Uploading the nsis installer and the zip file distribution of the
Windows binary to alpha.gnu.org now.

jwe



Reply | Threaded
Open this post in threaded view
|

RE: Testing octave-4.0.1-rc4

John Donoghue-3


> -----Original Message-----
> From: John W. Eaton [mailto:[hidden email]]
> Sent: Friday, March 11, 2016 10:38 AM
> To: JohnD; [hidden email]
> Subject: Re: Testing octave-4.0.1-rc4
>
> On 03/11/2016 07:13 AM, JohnD wrote:
> >>
> >> Message: 7
> >> Date: Thu, 10 Mar 2016 20:24:13 -0800
> >> From: Rik <[hidden email]>
> >> To: Octave-Maintainers <[hidden email]>, "John W.
> Eaton"
> >> <[hidden email]>
> >> Subject: Testing octave-4.0.1-rc4
> >> Message-ID: <MTAwMDAwNC5ub21hZA.1457670261@quikprotect>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> jwe,
> >>
> >> I tested the new tarball at ftp://alpha.gnu.org.  As expected for a
> > vanilla
> >> Linux system, it passed all tests and all build configurations
> >> including in-tree, out-of-tree builds, and 'make install' followed by
> > __run_test_suite__.
> >>
> >> --Rik
> >
> >
> > Compiling in mxe-octave with new tarball and running win7:
> >
> >    PASS     13020
> >    FAIL         0
> >    XFAIL       27
> >    SKIPPED     54
>
> I see almost the same result but I have 26 XFAIL and 13021 PASS.  Here are
my

> XFAIL counts:
>
>    libinterp\corefcn\conv2.cc-tst   XFAIL   3
>    libinterp\corefcn\max.cc-tst     XFAIL   3
>    general\num2str.m                XFAIL   1
>    polynomial\residue.m             XFAIL   1
>    testfun\speed.m                  XFAIL   1
>    testfun\test.m                   XFAIL   1
>    bug-38236.tst                    XFAIL   1
>    classdef.tst                     XFAIL   2
>    classes.tst                      XFAIL  11
>    jit.tst                          XFAIL   2
>
> Which one(s) are different for you?
>
> Also, it's very nice to see that the packages are all cross compiled and
installed
> by the installer now!
>
> Uploading the nsis installer and the zip file distribution of the Windows
binary to
> alpha.gnu.org now.
>
> jwe
>

I also had:

miscellaneous\zip.m XFAIL 1      -- zip file cannot be found!






Reply | Threaded
Open this post in threaded view
|

osmesa FAIL [WAS: Testing octave-4.0.1-rc4]

PhilipNienhuis
In reply to this post by Andreas Weber-4
Andreas Weber wrote:

> Hi Philip,
>
> Am 11.03.2016 um 15:30 schrieb PhilipNienhuis:
>> On Mageia-5 Linux I get only two FAILs for osmesa:
>>
>> :
>>>>>>> processing
>>>>>>> /home/philip/devel/octdev/oct4.0.0-rc4/libinterp/dldfcn/__osmesa_print__.cc-tst
>> ***** testif HAVE_OSMESA, HAVE_GL2PS_H
>>   if (isunix ())
>>     h = figure ("visible", "off");
>>     fn = tempname ();
>>     sombrero ();
>>     __osmesa_print__ (h, fn, "svg");
>>     assert (stat (fn).size, 2692270, -0.1);
>>     unlink (fn);
>>     img = __osmesa_print__ (h);
>>     assert (size (img), [get(h, "position")([4, 3]), 3])
>>     ## Use pixel sum per RGB channel as fingerprint
>>     img_fp = squeeze (sum (sum (img), 2));
>>     assert (img_fp, [52942515; 54167797; 56158178], -0.05);
>>   endif
>> !!!!! test failed
>> ASSERT errors for:  assert (stat (fn).size,2692270,-0.1)
>>
>>    Location  |  Observed  |  Expected  |  Reason
>>       ()          2798       2692270      Rel err 0.99896 exceeds tol 0.1
>> ***** testif HAVE_OSMESA, HAVE_GL2PS_H
>>   if (isunix ())
>>     h = figure ("visible", "off");
>>     fn = tempname ();
>>     plot (sin (0:0.1:2*pi));
>>     __osmesa_print__ (h, fn, "svgis2d");
>>     assert (stat (fn).size, 7438, -0.1);
>>     unlink (fn);
>>     img = __osmesa_print__ (h);
>>     assert (size (img), [get(h, "position")([4, 3]), 3])
>>     ## Use pixel sum per RGB channel as fingerprint
>>     img_fp = squeeze (sum (sum (img), 2));
>>     assert (img_fp, [59281711; 59281711; 59482179], -0.05);
>>   endif
>> !!!!! test failed
>> ASSERT errors for:  assert (stat (fn).size,7438,-0.1)
>>
>>    Location  |  Observed  |  Expected  |  Reason
>>       ()          2120         7438       Rel err 0.71498 exceeds tol 0.1
>> :
>
> Can you run the test manually (without unlink which deletes the images)
> in Octave and check the generated images? You should see the sombrero
> and a simple sin plot.
No the files are only 2798 (oct-z2vuOE) and 2120 (oct-s9ez4U) bytes,
resp. Much too small for sombrero and a plot. I'll attach them.

When I entered (set (h, "visible", "on") I didn't see the sombrero, just
the axis ticks.
But when I replaced <visible> "off" with "on" in the test sequence, I
did see a complete sombrero plot appear but nevertheless
__osmesa_print__ didn't make a full svg drawing, it was the same as the
attached.

> Which version of libosmesa-dev is installed and do you use proprietary
> GPU drivers which doesn't use mesa?

lib64osmesa8 (+ -devel) are version 10.5.9.

My desktop system has NVidia graphics (proprietary I think), so maybe it
doesn't use osmesa? (as you can guess I know beans about the lower level
graphics SW).
My laptop (w. Intel graphics) has essentially the same results (also
running Mageia-5 64bit).

Philip


oct-s9ez4U (2K) Download Attachment
oct-z2vuOE (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

Carnë Draug
In reply to this post by John Donoghue-3
Tested 4.0.1-rc4 in ubuntu 12.04, CentOS 6, and CentOS 7.  All looks
fine except a test failure in CentOS 6 (very minor, print created a file
smaller than expected).

---

* Ubuntu 12.04.5

** Configuration:
*** disabled sound IO (sndfile and portaudio);
*** disabled GUI;
*** disabled JIT.

** make:
*** finishes build.

** make check (with Xfvb):
*** Fails plotting because osmesa is 8.0.4 (requires >= 9.0).


* CentOS 6.7

** Configuration:
*** disabled sound IO (sndfile);
*** disabled JIT.

** make:
*** finishes build.

** make check (with Xfvb):
*** Fails 1 test from __osmesa_print__.cc which checks the size of print output

    !!!!! test failed
    ASSERT errors for:  assert (stat (fn).size,7438,-0.1)
      Location  |  Observed  |  Expected  |  Reason
         ()          6180         7438       Rel err 0.16913 exceeds tol 0.1


* CentOS 7.2.1511

** Configuration:
*** disabled OSmesa;
*** disabled sound IO (sndfile and portaudio);
*** disabled GUI;
*** disabled JIT.

** make:
*** several warnings about unused parameter 'args' in DECLARE_FUNX and
DECLARE_FUN
*** finishes build.

** make check (with Xfvb):
*** Not failed tests.

Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

Marius Schamschula-5
In reply to this post by Rik-4
On OS X 10.10.5, under MacPorts I get:

  libinterp/corefcn/dlmread.cc-tst ............................ PASS     12/20 
                                                                  FAIL    8
  libinterp/corefcn/file-io.cc-tst ............................ PASS      0/1  
                                                                  FAIL    1
  libinterp/corefcn/mappers.cc-tst ............................ PASS    393/395
                                                                  FAIL    2
  libinterp/corefcn/sparse-xpow.cc-tst ........................ PASS      1/2  
                                                                  FAIL    1
  libinterp/corefcn/str2double.cc-tst ......................... PASS     28/31 
                                                                  FAIL    3
  scripts/io/importdata.m ..................................... PASS     25/26 
                                                                  FAIL    1
  scripts/io/textscan.m ....................................... PASS     34/35 
                                                                  FAIL    1
  scripts/sparse/ichol.m ......................................ans = Compressed Column Sparse (rows = 1, cols = 1, nnz = 0 [0%])

ans = Compressed Column Sparse (rows = 1, cols = 1, nnz = 0 [0%])

 PASS     22/24 
                                                                  FAIL    2
  scripts/sparse/ilu.m ........................................ PASS     40/41 
                                                                  FAIL    1
  scripts/specfun/realpow.m ................................... PASS      7/8  
                                                                  FAIL    1
  scripts/statistics/base/lscov.m ............................. PASS      2/3  
                                                                  FAIL    1
  complex.tst ................................................. PASS      5/7  
                                                                  FAIL    2
  io.tst ...................................................... PASS    112/115
                                                                  FAIL    3
  system.tst .................................................. PASS    107/109
                                                                  FAIL    2

Summary:

  PASS     13063
  FAIL        29
  XFAIL       26
  SKIPPED     45


On Mar 10, 2016, at 10:24 PM, Rik <[hidden email]> wrote:

jwe,

I tested the new tarball at ftp://alpha.gnu.org.  As expected for a vanilla Linux system, it passed all tests and all build configurations including in-tree, out-of-tree builds, and 'make install' followed by __run_test_suite__.

--Rik

Marius
--
Marius Schamschula




Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

Keith Keith

On Sat, Mar 12, 2016 at 7:23 PM, Marius Schamschula <[hidden email]> wrote:
On OS X 10.10.5, under MacPorts I get:

  libinterp/corefcn/dlmread.cc-tst ............................ PASS     12/20 
                                                                  FAIL    8
  libinterp/corefcn/file-io.cc-tst ............................ PASS      0/1  
                                                                  FAIL    1
  libinterp/corefcn/mappers.cc-tst ............................ PASS    393/395
                                                                  FAIL    2
  libinterp/corefcn/sparse-xpow.cc-tst ........................ PASS      1/2  
                                                                  FAIL    1
  libinterp/corefcn/str2double.cc-tst ......................... PASS     28/31 
                                                                  FAIL    3
  scripts/io/importdata.m ..................................... PASS     25/26 
                                                                  FAIL    1
  scripts/io/textscan.m ....................................... PASS     34/35 
                                                                  FAIL    1
  scripts/sparse/ichol.m ......................................ans = Compressed Column Sparse (rows = 1, cols = 1, nnz = 0 [0%])

ans = Compressed Column Sparse (rows = 1, cols = 1, nnz = 0 [0%])

 PASS     22/24 
                                                                  FAIL    2
  scripts/sparse/ilu.m ........................................ PASS     40/41 
                                                                  FAIL    1
  scripts/specfun/realpow.m ................................... PASS      7/8  
                                                                  FAIL    1
  scripts/statistics/base/lscov.m ............................. PASS      2/3  
                                                                  FAIL    1
  complex.tst ................................................. PASS      5/7  
                                                                  FAIL    2
  io.tst ...................................................... PASS    112/115
                                                                  FAIL    3
  system.tst .................................................. PASS    107/109
                                                                  FAIL    2

Summary:

  PASS     13063
  FAIL        29
  XFAIL       26
  SKIPPED     45


On Mar 10, 2016, at 10:24 PM, Rik <[hidden email]> wrote:

jwe,

I tested the new tarball at ftp://alpha.gnu.org.  As expected for a vanilla Linux system, it passed all tests and all build configurations including in-tree, out-of-tree builds, and 'make install' followed by __run_test_suite__.

--Rik

Marius
--
Marius Schamschula




Everything seems to be working well on a Fedora 23 XFCE spin.  I'm running a custom kernel.  The major changes from the standard Fedora 23 kernel are it is configured to be optimized for Core 2 and later processors and it has forced preemption.  Output from uname:

uname -a
Linux localhost.localdomain 4.4.4-301.core2a7.fc23.x86_64 #1 SMP PREEMPT Mon Mar 14 03:48:34 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux


I noticed the configure summary doesn't mention floating point truncation like the versions I clone from the Mercurial repository so I included some output from my configure command. I also included the stderr output because it didn't like something about my llvm setup.  My environment variables were setup like this:

echo $LLVM_CONFIG
/usr/bin/llvm-config-64-3.3


 My configure command is 

../configure --disable-silent-rules --enable-docs --enable-largefile --enable-openmp --disable-float-truncate --enable-fftw-threads --enable-libtool-lock --enable-readline --enable-dl --enable-java --with-qhull --with-z --with-hdf5 --with-fftw3 --with-fftw3f --with-glpk --with-curl --with-sndfile --with-portaudio --with-x --with-opengl --with-OSMesa --with-qt --with-fltk --with-blas=openblaso --with-lapack=lapack --with-qrupdate --with-adm --with-camd --with-colamd --with-ccolamd --with-cholmod --with-cxsparse --with-umfpack --with-arpack --with-openssl --with-java --enable-jit


the output from ../configure:

../../txt/confoct.sh | grep -i float

configure: WARNING: unrecognized options: --with-qt, --with-adm, --with-java
checking whether gfortran accepts -ffloat-store... yes
setting F77_FLOAT_STORE_FLAG to -ffloat-store
configure: WARNING: llvm/IR/Verifier.h: present but cannot be compiled
configure: WARNING: llvm/IR/Verifier.h:     check for missing prerequisite headers?
configure: WARNING: llvm/IR/Verifier.h: see the Autoconf documentation
configure: WARNING: llvm/IR/Verifier.h:     section "Present But Cannot Be Compiled"
configure: WARNING: llvm/IR/Verifier.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------------ ##
configure: WARNING:     ## Report this to http://octave.org/bugs.html ##
configure: WARNING:     ## ------------------------------------------ ##
checking floatingpoint.h usability... no
checking floatingpoint.h presence... no
checking for floatingpoint.h... no
checking where to find the exponent in a 'float'... word 0 bit 23
checking whether isnan(float) can be used without linking with libm... yes
checking whether isnan(float) works... yes
checking whether isnan(float) can be used without linking with libm... (cached) yes
checking whether isnan(float) works... (cached) yes
checking for std::isnan (float variant) in <cmath>... yes
checking for std::isinf (float variant) in <cmath>... yes
checking for std::isfinite (float variant) in <cmath>... yes
checking for std::signbit (float variant) in <cmath>... yes
configure: WARNING: JAVA_HOME environment variable not initialized.  Auto-detection will proceed but is unreliable.
configure: WARNING: unrecognized options: --with-qt, --with-adm, --with-java
configure: WARNING: JAVA_HOME environment variable not initialized.  Auto-detection will proceed but is unreliable.


And the configure summary:

Build Octave GUI:                   yes
JIT compiler for loops:             yes
Build Java interface:               yes
Do internal array bounds checking:  no
Build static libraries:             no
Build shared libraries:             yes
Dynamic Linking:                    yes (dlopen)
Include support for GNU readline:   yes
64-bit array dims and indexing:     no
OpenMP SMP multithreading:          yes
Build cross tools:                  no


I ran make and everything worked fine:

Successfully remade target file 'all'.

 
make check was largely uneventful.  The only thing interesting I saw was an audio test section:

 .build32/libinterp/dldfcn/audiodevinfo.cc-tst ...............ALSA lib pcm_dsnoop.c:614:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1024:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2267:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2267:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2267:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm.c:7046:(snd_pcm_slave_conf) missing field rate
ALSA lib pcm.c:7046:(snd_pcm_slave_conf) missing field rate
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_dmix.c:1024:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
 PASS      4/4  


And the summary:

Summary:

  PASS     13076
  FAIL         0
  XFAIL       25
  SKIPPED      1

This is the first time I was able to get JIT to work so I'm happy.

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

Re: Testing octave-4.0.1-rc4

PhilipNienhuis
In reply to this post by Marius Schamschula-5
Marius Schamschula-5 wrote
On OS X 10.10.5, under MacPorts I get:

....<snip>

  scripts/io/importdata.m ..................................... PASS     25/26
                                                                  FAIL    1
  scripts/io/textscan.m ....................................... PASS     34/35
                                                                  FAIL    1
Could you upload the test results for those 2, please? I'm familiar with the code of those two. Maybe I can mend those FAILs.
Admittedly for textscan.m it's getting moot as a binary textscan is in sight, but maybe this can be fixed for 4.0.1.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

Mike Miller-4
In reply to this post by Rik-4
I was able to get Octave 4.0.1-rc4 built on SPARC Solaris 10, without
the following external libraries:
  arpack, curl, fltk, glpk, hdf5, java, osmesa, qrupdate, suitesparse

On that system I see 40 test failures:

  ** oct-inttypes.cc: 16

    Several failures relating to integer-char conversions, probably due
    to http://hg.savannah.gnu.org/hgweb/octave/rev/b48d65c5df5b.

  ** data.cc: 1

    Little-endian assumption in test of "base64_encode (single (pi))".

  ** file-io.cc: 1

    System-defined P_tmpdir string contains trailing slash, fails string
    comparison.

  ** cplxpair.m: 3

    Two-column tests fail, the number with positive imaginary part
    sometimes appears first in the list depending on the random order.

  ** imwrite.m: 4

    Alpha channel always comes back as an empty matrix (could be a
    limitation of the native ImageMagick library?)

  ** powerset.m: 2

    Little-endian assumption in powerset implementation using bitunpack.

  ** binopdf.m: 4

    Eps-order tolerance errors.

  ** logninv.m: 4

    Eps-order tolerance errors.

  ** io.tst: 4

    Many fread errors, looks like more little-endian assumptions.

  ** system.tst: 1

    File "/dev/core" does not exist, should add exist() check.

Let me know if you want me to test anything, related to these or
otherwise. Open to suggestions as to how to fix the integer-char
conversion problem. I plan to look at fixing most of these on the
default branch soon-ish.

Minor patches needed to compile on Solaris, see
https://bitbucket.org/snippets/mtmiller/arqzA/octave-40-solaris-patches

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

John W. Eaton
Administrator
On 03/16/2016 04:20 PM, Mike Miller wrote:

>    ** file-io.cc: 1
>
>      System-defined P_tmpdir string contains trailing slash, fails string
>      comparison.

Is it supposed to contain a trailing slash?  Maybe this is a job for gnulib?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

John W. Eaton
Administrator
In reply to this post by Mike Miller-4
On 03/16/2016 04:20 PM, Mike Miller wrote:

>    ** data.cc: 1
>
>      Little-endian assumption in test of "base64_encode (single (pi))".
>
>    ** powerset.m: 2
>
>      Little-endian assumption in powerset implementation using bitunpack.
>
>    ** io.tst: 4
>
>      Many fread errors, looks like more little-endian assumptions.

These should definitely be fixed since we shouldn't be making
assumptions about endianness.

>    ** system.tst: 1
>
>      File "/dev/core" does not exist, should add exist() check.

Huh?  We expect /dev/core to exist?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Testing octave-4.0.1-rc4

Mike Miller-4
On Wed, Mar 16, 2016 at 16:26:12 -0400, John W. Eaton wrote:
> Is it supposed to contain a trailing slash?  Maybe this is a job for gnulib?

I think it's best if Octave accurately reflects what the system says
P_tmpdir should be, even if it has a trailing slash. I fixed this in the
tempname test.

On Wed, Mar 16, 2016 at 16:45:36 -0400, John W. Eaton wrote:

> On 03/16/2016 04:20 PM, Mike Miller wrote:
>
> >   ** data.cc: 1
> >
> >     Little-endian assumption in test of "base64_encode (single (pi))".
> >
> >   ** powerset.m: 2
> >
> >     Little-endian assumption in powerset implementation using bitunpack.
> >
> >   ** io.tst: 4
> >
> >     Many fread errors, looks like more little-endian assumptions.
>
> These should definitely be fixed since we shouldn't be making assumptions
> about endianness.

Fixed, except for an actual bug in fwrite on Solaris, see bug #47434.

> >   ** system.tst: 1
> >
> >     File "/dev/core" does not exist, should add exist() check.
>
> Huh?  We expect /dev/core to exist?

Fixed.

--
mike