On Sat, Sep 10, 2016 at 01:32:22PM +0100, Marius Bakke wrote:
> + (add-after 'disable-asserts 'disable-failing-tests
> + (lambda _
> + ;; One test times out on MIPS, so we need to disable it.
> + ;; The rest is known to fail on non-x86_64 platforms in the
On Sat, Sep 10, 2016 at 02:16:09PM -0400, Leo Famulari wrote:
> On Sat, Sep 10, 2016 at 01:32:22PM +0100, Marius Bakke wrote:
> > Marius Bakke writes:
> >
> > > Leo Famulari writes:
> > >
> > >> Changing the subject, you could disable the tests per-architecture. Look
> > >> for uses of current-t
On Sat, Sep 10, 2016 at 01:32:22PM +0100, Marius Bakke wrote:
> Marius Bakke writes:
>
> > Leo Famulari writes:
> >
> >> Changing the subject, you could disable the tests per-architecture. Look
> >> for uses of current-target-system and current-system for usage examples.
> >> But this is not abs
Marius Bakke writes:
> Leo Famulari writes:
>
>> Changing the subject, you could disable the tests per-architecture. Look
>> for uses of current-target-system and current-system for usage examples.
>> But this is not absolutely required, IMO.
>
> This latest patch series now disables tests on a
Leo Famulari writes:
> Changing the subject, you could disable the tests per-architecture. Look
> for uses of current-target-system and current-system for usage examples.
> But this is not absolutely required, IMO.
This latest patch series now disables tests on a per-arch basis.
There may be ot
On Tue, Aug 30, 2016 at 03:43:05PM +0100, Marius Bakke wrote:
> Shogun failed to build in this run. I don't have time to investigate
> further, so picking the OpenBLAS update is not very appealing.
>
> Instead I opted to disable the test that fails with lapack (and without,
> on Hydra), since it's
Marius Bakke writes:
> Leo Famulari writes:
>
>> On Wed, Aug 24, 2016 at 11:26:28AM +0100, Marius Bakke wrote:
>>> There are a couple of things going on in this thread:
>>>
>>> 1. Segfault on x86_64. This seems to have been resolved simply by
>>> updating OpenBLAS. At least, I'm no longer able
On 24 August 2016 3:08:58 PM GMT-04:00, Marius Bakke
wrote:
>
>>> Adding "#:parallel-build? #f" had no effect on tests, indeed the
>check
>>> phase does not seem to use the previously built dlib; it builds it
>again
>>> without parallel-build. I will try reproducing the
>non-reproducibility
>>
Leo Famulari writes:
> On Wed, Aug 24, 2016 at 11:26:28AM +0100, Marius Bakke wrote:
>> There are a couple of things going on in this thread:
>>
>> 1. Segfault on x86_64. This seems to have been resolved simply by
>> updating OpenBLAS. At least, I'm no longer able to reproduce it even
>> with LA
On Wed, Aug 24, 2016 at 11:26:28AM +0100, Marius Bakke wrote:
> There are a couple of things going on in this thread:
>
> 1. Segfault on x86_64. This seems to have been resolved simply by
> updating OpenBLAS. At least, I'm no longer able to reproduce it even
> with LAPACK in inputs. So, that shoul
Marius Bakke writes:
>> Without OpenBLAS dlib will use an internal BLAS implementation. I'm
>> fairly certain that will at least fix the crash on x86_64, which was
>> a segfault in libopenblasp-r0.2.15.so when we had LAPACK in inputs, but
>> seems to consistently trigger on Hydra regardless.
>>
>
> Without OpenBLAS dlib will use an internal BLAS implementation. I'm
> fairly certain that will at least fix the crash on x86_64, which was
> a segfault in libopenblasp-r0.2.15.so when we had LAPACK in inputs, but
> seems to consistently trigger on Hydra regardless.
>
> I got busy this weekend, b
Ben Woodcroft writes:
> On 21/08/16 16:17, Leo Famulari wrote:
>> On Fri, Aug 19, 2016 at 11:52:37AM +0100, Marius Bakke wrote:
>>> Leo Famulari writes:
>>>
I pushed the patch as 5f0ff6a9e. Hopefully dlib is still useful without
lapack. We should really figure out what the issue is and
On 21/08/16 16:17, Leo Famulari wrote:
On Fri, Aug 19, 2016 at 11:52:37AM +0100, Marius Bakke wrote:
Leo Famulari writes:
I pushed the patch as 5f0ff6a9e. Hopefully dlib is still useful without
lapack. We should really figure out what the issue is and fix it :)
I noticed this fails to buil
On Fri, Aug 19, 2016 at 11:52:37AM +0100, Marius Bakke wrote:
> Leo Famulari writes:
>
> > I pushed the patch as 5f0ff6a9e. Hopefully dlib is still useful without
> > lapack. We should really figure out what the issue is and fix it :)
>
> I noticed this fails to build on Hydra. What's worse is t
Leo Famulari writes:
> I pushed the patch as 5f0ff6a9e. Hopefully dlib is still useful without
> lapack. We should really figure out what the issue is and fix it :)
I noticed this fails to build on Hydra. What's worse is that the i686,
x86_64 and armhf targets fails at completely different thing
On Wed, Aug 17, 2016 at 03:48:24PM +0100, Marius Bakke wrote:
> I've attached a patch with a #t in the disable-asserts phase, and also
> deleting the 6MB static library.
>
> Since `guix build --rounds=2` passes, is there any reason to delay this
> patch? I've built this on GuixSD and a foreign dis
On Wed, Aug 17, 2016 at 01:24:46PM +1000, Ben Woodcroft wrote:
> On 17/08/16 09:45, Leo Famulari wrote:
> > How did it appear non-deterministic to you?
> Just based on guix build --check:
>
> guix build: error: build failed: derivation
> `/gnu/store/sxybcxw64q1ajzq6dysal75ffgq6238i-dlib-19.1.drv'
, is there any reason to delay this
patch? I've built this on GuixSD and a foreign distro and naively
verified that they are the same (the .so and all headers have the same
checksum; some of the recorded cmake input paths are different though).
Thanks,
Marius
>From 77f74972d095aeb08367e00c
On 17/08/16 13:24, Ben Woodcroft wrote:
On 17/08/16 09:45, Leo Famulari wrote:
On Wed, Aug 17, 2016 at 09:31:11AM +1000, Ben Woodcroft wrote:
On 17/08/16 06:47, Leo Famulari wrote:
On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
I initially made this package on a foreign di
On 17/08/16 09:45, Leo Famulari wrote:
On Wed, Aug 17, 2016 at 09:31:11AM +1000, Ben Woodcroft wrote:
On 17/08/16 06:47, Leo Famulari wrote:
On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
I initially made this package on a foreign distro without "lapack" in
inputs and have ve
On Wed, Aug 17, 2016 at 09:31:11AM +1000, Ben Woodcroft wrote:
>
>
> On 17/08/16 06:47, Leo Famulari wrote:
> > On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
> > > I initially made this package on a foreign distro without "lapack" in
> > > inputs and have verified that dropping LA
On 17/08/16 06:47, Leo Famulari wrote:
On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
I initially made this package on a foreign distro without "lapack" in
inputs and have verified that dropping LAPACK makes the tests pass.
I also found some other optional dependencies after di
On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
> I initially made this package on a foreign distro without "lapack" in
> inputs and have verified that dropping LAPACK makes the tests pass.
>
> I also found some other optional dependencies after digging around the
> source, as well a
`.
I initially made this package on a foreign distro without "lapack" in
inputs and have verified that dropping LAPACK makes the tests pass.
I also found some other optional dependencies after digging around the
source, as well as a recommendation to disable/enable asserts:
http://d
On 16/08/16 08:28, Leo Famulari wrote:
On Mon, Aug 15, 2016 at 09:29:11PM +0100, Marius Bakke wrote:
Leo Famulari writes:
Running test_empirical_kernel_map / phase `check' failed after 2043.7 seconds
Strange, I've built this dozens of times now with no test failures
(GuixSD on amd64). Are you
On Mon, Aug 15, 2016 at 09:29:11PM +0100, Marius Bakke wrote:
> Leo Famulari writes:
> > Running test_empirical_kernel_map / phase `check' failed after 2043.7
> > seconds
>
> Strange, I've built this dozens of times now with no test failures
> (GuixSD on amd64). Are you memory constrained by an
Leo Famulari writes:
> On Mon, Aug 15, 2016 at 12:51:15PM +0100, Marius Bakke wrote:
>> Date: Sat, 13 Aug 2016 11:26:10 +0100
>> Subject: [PATCH] gnu: Add dlib.
>>
>> * gnu/packages/machine-learning.scm (dlib): New variable.
>
> Thanks for the updated patch.
On Mon, Aug 15, 2016 at 12:51:15PM +0100, Marius Bakke wrote:
> Date: Sat, 13 Aug 2016 11:26:10 +0100
> Subject: [PATCH] gnu: Add dlib.
>
> * gnu/packages/machine-learning.scm (dlib): New variable.
Thanks for the updated patch.
Does it build for you? On my x86_64 machine, it fails
C++")
>> +(description
>> + "Dlib is a modern C++ toolkit containing machine learning algorithms
>> and tools. It
>> +is used in both industry and academia in a wide range of domains including
>> robotics,
>> +embedded devices, mobile phones, and large high per
Marius Bakke (2016-08-14 22:52 +0300) wrote:
Hello and welcome!
> From 5e30eff1cf24b236a78cc5abed870992e84f443f Mon Sep 17 00:00:00 2001
> From: Marius Bakke
> Date: Sat, 13 Aug 2016 11:26:10 +0100
> Subject: [PATCH] gnu: Add dlib.
[...]
> +(define-public dlib
> + (package
ad of
> chdir-ing back and forth.
>
>> + (add-after 'check 'ascend-to-build-directory
>> + (lambda _ (chdir "../../../../build") #t))
>
> Then, this phase can be removed.
That worked great, thanks!
New patch attached.
>From 5e30eff1cf24b23
On Sat, Aug 13, 2016 at 06:15:59PM +0100, Marius Bakke wrote:
> * gnu/packages/machine-learning.scm (dlib): New variable.
Thanks!
> +(version "19.0")
The released 19.1 yesterday. Will you send an updated patch using the
latest version?
> +(arguments
> + `(#:phases
> + (let ((t
Hi,
This adds the dlib machine learning toolkit.
Cheers,
Marius
>From 9a24f0bfd8a0375928d7accdc0ef744f4fa304a0 Mon Sep 17 00:00:00 2001
From: Marius Bakke
Date: Sat, 13 Aug 2016 11:26:10 +0100
Subject: [PATCH] gnu: Add dlib.
* gnu/packages/machine-learning.scm (dlib): New variable.
---
34 matches
Mail list logo