Buildbot Progress

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

Buildbot Progress

Rik-4
jwe,

Making progress.  Clang on Mac OSX is now green.  The package of-control
now compiles which, alas, just uncovered the next problem further down with
of-signal.

[build]    of-signal

Failed to build package of-signal!
------------------------------------------------------------
  File
"/scratch/buildbot/slaves/jwe-debian-x86_64-0/mxe-native-on-debian/src/tools/pkg-install.py",
line 237, in configure_make
    raise Exception, "make failed during build - stopping install"
Exception: make failed during build - stopping install
/scratch/buildbot/slaves/jwe-debian-x86_64-0/mxe-native-on-debian/src/Makefile:855:
recipe for target 'build-only-of-signal' failed
make[1]: *** [build-only-of-signal] Error 1
make[1]: Leaving directory
'/scratch/buildbot/slaves/jwe-debian-x86_64-0/mxe-native-on-debian/src'
real    0m19.185s
user    0m16.296s
sys    0m2.949s
------------------------------------------------------------
[log]     
/scratch/buildbot/slaves/jwe-debian-x86_64-0/mxe-native-on-debian/src/log/of-signal


--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Buildbot Progress

PhilipNienhuis
Rik-4 wrote

> jwe,
>
> Making progress.  Clang on Mac OSX is now green.  The package of-control
> now compiles which, alas, just uncovered the next problem further down
> with
> of-signal.
>
> [build]    of-signal
>
> Failed to build package of-signal!
> ------------------------------------------------------------
>   File
> "/scratch/buildbot/slaves/jwe-debian-x86_64-0/mxe-native-on-debian/src/tools/pkg-install.py",
> line 237, in configure_make
>     raise Exception, "make failed during build - stopping install"
> Exception: make failed during build - stopping install
> /scratch/buildbot/slaves/jwe-debian-x86_64-0/mxe-native-on-debian/src/Makefile:855:
> recipe for target 'build-only-of-signal' failed
> make[1]: *** [build-only-of-signal] Error 1
> make[1]: Leaving directory
> '/scratch/buildbot/slaves/jwe-debian-x86_64-0/mxe-native-on-debian/src'
> real    0m19.185s
> user    0m16.296s
> sys    0m2.949s
> ------------------------------------------------------------
> [log]     
> /scratch/buildbot/slaves/jwe-debian-x86_64-0/mxe-native-on-debian/src/log/of-signal

Yes, control was bug #52820.
Somewhere further along the line you'll hit issues with instrument-control,
see bug #52821.

Philip



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

Reply | Threaded
Open this post in threaded view
|

Re: Buildbot Progress

John W. Eaton
Administrator
In reply to this post by Rik-4
On 01/09/2018 12:25 PM, Rik wrote:
> jwe,
>
> Making progress.  Clang on Mac OSX is now green.

Thanks.

The package of-control
> now compiles which, alas, just uncovered the next problem further down with
> of-signal.

I pushed the following changeset which seems to fix the problem for me:

   http://hg.octave.org/mxe-octave/rev/50aebe534e42

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Buildbot Progress

John W. Eaton
Administrator
In reply to this post by PhilipNienhuis
On 01/09/2018 03:32 PM, PhilipNienhuis wrote:

> Somewhere further along the line you'll hit issues with instrument-control,
> see bug #52821.

Thanks, I think that problem should be fixed by this change:

   http://hg.savannah.gnu.org/hgweb/octave/rev/28a4037d10ab

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Buildbot Progress

John W. Eaton
Administrator
On 01/09/2018 05:42 PM, John W. Eaton wrote:
> On 01/09/2018 03:32 PM, PhilipNienhuis wrote:
>
>> Somewhere further along the line you'll hit issues with
>> instrument-control,
>> see bug #52821.
>
> Thanks, I think that problem should be fixed by this change:
>
>    http://hg.savannah.gnu.org/hgweb/octave/rev/28a4037d10ab

In addition to that and the problem with signal that Rik mentioned, I
also found problems with communications, linear-algebra and odepkg but
they should be fixed now with these changes:

   http://hg.octave.org/mxe-octave/rev/43de7d9113e7
   http://hg.octave.org/mxe-octave/rev/705d0432dbf1
   http://hg.octave.org/mxe-octave/rev/cfce5c9ba320

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Buildbot Progress

John W. Eaton
Administrator
In reply to this post by Rik-4
On 01/09/2018 12:25 PM, Rik wrote:

> Making progress.  Clang on Mac OSX is now green.  The package of-control
> now compiles which, alas, just uncovered the next problem further down with
> of-signal.

It is all green now.  I'm sure that's the first time this has happened
for this set of builds.

Thanks, especially for your help with the OS X build.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Buildbot Progress

Dmitri A. Sergatskov
On Wed, Jan 10, 2018 at 11:31 AM, John W. Eaton <[hidden email]> wrote:
On 01/09/2018 12:25 PM, Rik wrote:

Making progress.  Clang on Mac OSX is now green.  The package of-control
now compiles which, alas, just uncovered the next problem further down with
of-signal.

It is all green now.  I'm sure that's the first time this has happened for this set of builds.


​Somebody jinxed it :) ​



libinterp/corefcn/bsxfun.cc-tst ............................. PASS     75/76  
                                                                  FAIL    1
***** test
 funs = {@plus, @minus, @times, @rdivide, @ldivide, @power, @max, @min, ...
         @rem, @mod, @atan2, @hypot, @eq, @ne, @lt, @le, @gt, @ge, ...
         @and, @or, @xor };

 float_types = {@single, @double};
 int_types = {@int8, @int16, @int32, @int64, ...
              @uint8, @uint16, @uint32, @uint64};

 x = rand (3) * 10-5;
 y = rand (3,1) * 10-5;

 for i=1:length (funs)
   for j = 1:length (float_types)
     for k = 1:length (int_types)

       fun = funs{i};
       f_type = float_types{j};
       i_type = int_types{k};

         assert (bsxfun (fun, f_type (x), i_type (y)), ...
                 fun (f_type(x), i_type (y)));
         assert (bsxfun (fun, f_type (y), i_type (x)), ...
                 fun (f_type(y), i_type (x)));

         assert (bsxfun (fun, i_type (x), i_type (y)), ...
                 fun (i_type (x), i_type (y)));
         assert (bsxfun (fun, i_type (y), i_type (x)), ...
                 fun (i_type (y), i_type (x)));

         assert (bsxfun (fun, f_type (x), f_type (y)), ...
                 fun (f_type (x), f_type (y)));
         assert (bsxfun (fun, f_type(y), f_type(x)), ...
                 fun (f_type (y), f_type (x)));
     endfor
   endfor
 endfor
!!!!! test failed
ASSERT errors for:  assert (bsxfun (fun, f_type (x), i_type (y)),fun (f_type (x), i_type (y)))

  Location  |  Observed  |  Expected  |  Reason
   (1,3)       52597681     52597680     Abs err 1 exceeds tol 0 by 1


​I thought Mike Miller addressed this particular problem, but I could not find the thread / bug report.
..
​Should we just fix a seed for rand() in this test?


jwe


​Dmitri.
--

Reply | Threaded
Open this post in threaded view
|

Re: Buildbot Progress

Rik-4
On 01/10/2018 01:39 PM, Dmitri A. Sergatskov wrote:
On Wed, Jan 10, 2018 at 11:31 AM, John W. Eaton <[hidden email]> wrote:
On 01/09/2018 12:25 PM, Rik wrote:

Making progress.  Clang on Mac OSX is now green.  The package of-control
now compiles which, alas, just uncovered the next problem further down with
of-signal.

It is all green now.  I'm sure that's the first time this has happened for this set of builds.


​Somebody jinxed it :) ​



libinterp/corefcn/bsxfun.cc-tst ............................. PASS     75/76  
                                                                  FAIL    1
***** test
 funs = {@plus, @minus, @times, @rdivide, @ldivide, @power, @max, @min, ...
         @rem, @mod, @atan2, @hypot, @eq, @ne, @lt, @le, @gt, @ge, ...
         @and, @or, @xor };

 float_types = {@single, @double};
 int_types = {@int8, @int16, @int32, @int64, ...
              @uint8, @uint16, @uint32, @uint64};

 x = rand (3) * 10-5;
 y = rand (3,1) * 10-5;

 for i=1:length (funs)
   for j = 1:length (float_types)
     for k = 1:length (int_types)

       fun = funs{i};
       f_type = float_types{j};
       i_type = int_types{k};

         assert (bsxfun (fun, f_type (x), i_type (y)), ...
                 fun (f_type(x), i_type (y)));
         assert (bsxfun (fun, f_type (y), i_type (x)), ...
                 fun (f_type(y), i_type (x)));

         assert (bsxfun (fun, i_type (x), i_type (y)), ...
                 fun (i_type (x), i_type (y)));
         assert (bsxfun (fun, i_type (y), i_type (x)), ...
                 fun (i_type (y), i_type (x)));

         assert (bsxfun (fun, f_type (x), f_type (y)), ...
                 fun (f_type (x), f_type (y)));
         assert (bsxfun (fun, f_type(y), f_type(x)), ...
                 fun (f_type (y), f_type (x)));
     endfor
   endfor
 endfor
!!!!! test failed
ASSERT errors for:  assert (bsxfun (fun, f_type (x), i_type (y)),fun (f_type (x), i_type (y)))

  Location  |  Observed  |  Expected  |  Reason
   (1,3)       52597681     52597680     Abs err 1 exceeds tol 0 by 1


​I thought Mike Miller addressed this particular problem, but I could not find the thread / bug report.
..
​Should we just fix a seed for rand() in this test?

We could do that, but that would be our option of last resort.  Can we figure out which test is failing first and understand why it is failing?

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Buildbot Progress

Mike Miller-4
On Wed, Jan 10, 2018 at 15:10:45 -0800, Rik wrote:
> On 01/10/2018 01:39 PM, Dmitri A. Sergatskov wrote:
> > I thought Mike Miller addressed this particular problem, but I could not
> > find the thread / bug report.
> > ..
> > Should we just fix a seed for rand() in this test?
>
> We could do that, but that would be our option of last resort.  Can we
> figure out which test is failing first and understand why it is failing?

Reported but not fixed.

https://savannah.gnu.org/bugs/?51779

I believe Rik's last comment summarizes the possibilities, but we have
not decided what to do. Previous versions of Octave did promote the
operands to double and demote the result back to single.

This may not have been intentional. But in the future we may want to do
this more universally. There have been other bug reports, not related to
bsxfun, but about whether operations in general should be performed in
single or double precision.

--
mike

signature.asc (849 bytes) Download Attachment