Hello,
Over the last few months I have been questioning some of the choices
that were initially made for Guix. So I finally took the time to
investigate more what could be done about it, and specifically I’ve been
playing with Guile’s ECMAscript front-end.
This is what’s already possible with Gu
I’m delighted to see there’s a synergy around JavaScript with the Nix
folks:
http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html
Ludo’.
Hi Ludo,
I think this sounds like a great plan! I think a year's re-writing of
package definitions is definitely a price worth paying so we can get rid
of the "ivory tower" functional paradigm: just think of all the other
developers we could recruit to Guix!
I might not be able to help though as
Hello,
this is quite outrageous, and if you decide to follow this road, I am certain
to quit the project, and maybe even fork it.
I agree that the choice of using Scheme/Guile was maybe made in a hurry and
prematurely. Scheme dialects seem to follow the paradigm "one language, one
programmer" - a
2014-04-01 4:45 GMT-05:00 Ludovic Courtès :
> Hello,
>
> Over the last few months I have been questioning some of the choices
> that were initially made for Guix. So I finally took the time to
> investigate more what could be done about it, and specifically I’ve been
> playing with Guile’s ECMAsc
Andreas Enge skribis:
> this is quite outrageous
[...]
> there are much more reasonable choices than Ecmascript, with its
> quirky object model, and whose functional features imply that maybe we would
> not completely get rid of the past. Personally, I think we should switch to
> Python.
Right
Hi Ludovic,
As per your suggestion, this new version of the patch simply sets the
CK_DEFAULT_TIMEOUT variable to 120. I've tested it on my YeeLoong, and
it works.
Mark
>From 727c3ed2fba074f3fad38d352d0484d69cc9993b Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 1 Apr 2014 13:53:
On Tue, Apr 1, 2014 at 10:07 AM, Andreas Enge wrote:
> Hello,
>
> this is quite outrageous, and if you decide to follow this road, I am certain
> to quit the project, and maybe even fork it.
>
> I agree that the choice of using Scheme/Guile was maybe made in a hurry and
> prematurely. Scheme diale
l...@gnu.org (Ludovic Courtès) writes:
> 0.6 is getting ready! The remaining items are Mark’s new union.scm, and
> Nikita’s signed-substitutes support.
>
> I think we can expect to have them in shape within a few days, hopefully.
> So it’s definitely time to report any issues you may have.
I'
Mark H Weaver skribis:
> As per your suggestion, this new version of the patch simply sets the
> CK_DEFAULT_TIMEOUT variable to 120. I've tested it on my YeeLoong, and
> it works.
Cool, please push!
Ludo’.
Mark H Weaver writes:
> I've run into a build issue with recent master on x86_64 and Loongson 3A
> (both hosted on Debian wheezy). Python 3 fails in the tests with
> "OSError: out of pty devices" and then the guix-daemon sometimes gets
> stuck in a sleeping state and hangs indefinitely.
>
> My L
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> 0.6 is getting ready! The remaining items are Mark’s new union.scm, and
>> Nikita’s signed-substitutes support.
>>
>> I think we can expect to have them in shape within a few days, hopefully.
>> So it’s definitely time to re
Mark H Weaver skribis:
> Mark H Weaver writes:
>
>> I've run into a build issue with recent master on x86_64 and Loongson 3A
>> (both hosted on Debian wheezy). Python 3 fails in the tests with
>> "OSError: out of pty devices" and then the guix-daemon sometimes gets
>> stuck in a sleeping state
I realized the modules end up in share/guile/site, so commit bf6fcf5
changes that to share/guile/site/2.0.
Ludo’.
l...@gnu.org (Ludovic Courtès) skribis:
> On my machine, ‘guix build emacs n’ with 40 substitutes needed takes
> ~4.8 seconds instead of ~3.5 seconds before (wall clock.)
This is down to ~3.8 seconds with today’s commits.
Ludo’.
Here's another batch of fixes to install man pages and docs in
PREFIX/share. I also cleaned up the 'zip' package build process.
Mark
>From 32699d6c8070522c34e00ddb57d836d6fb0dc3e8 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 1 Apr 2014 16:13:52 -0400
Subject: [PATCH 1/7] gnu: in
> The simplest way to do it would be by walking the package DAG: start
> from ‘foo’, accumulate its ‘package-source’, then traverse its inputs,
> etc. Recursion would stop at the implicit inputs (GCC, glibc,
> Coreutils, etc.), though.
> If you’d like implicit inputs to be taken into account, the
17 matches
Mail list logo
