On 12/24/2014 11:22 PM, Karn Kallio wrote:
Attached is another patch removing the old file.
I see Peti pushed (some version of) this, so gnupg21 builds again on
Hydra. Thanks!
Vladimir
smime.p7s
Description: S/MIME Cryptographic Signature
___
So I've packaged together a number of erlang dependencies together,
then compiled them a number of times in a row.
I noticed that the error outputs were different each time.
To me this means nix isn't deterministic.
I'd like to discuss the inclusion of the dataflow language concept into nix.
On 25 December 2014 at 01:13, stewart mackenzie setor...@gmail.com wrote:
So I've packaged together a number of erlang dependencies together,
then compiled them a number of times in a row.
I noticed that the error outputs were different each time.
To me this means nix isn't deterministic.
Hello Moritz,
On Thu, Dec 25, 2014 at 10:39 PM, Moritz Ulrich mor...@tarn-vedra.de wrote:
stewart mackenzie setor...@gmail.com writes:
So I've packaged together a number of erlang dependencies together,
then compiled them a number of times in a row.
I noticed that the error outputs were
On 2014-12-25 17:13, stewart mackenzie wrote:
Hello Moritz,
On Thu, Dec 25, 2014 at 10:39 PM, Moritz Ulrich mor...@tarn-vedra.de wrote:
stewart mackenzie setor...@gmail.com writes:
So I've packaged together a number of erlang dependencies together,
then compiled them a number of times in
Maybe I'm wrong, but I don't think the Nix language itself has any idea
of concurrency as such -- at the manual says
The Nix expression language is a pure, lazy, functional language.
(https://nixos.org/nix/manual/#ch-expression-language)
Actually I recall eelco talking about threads in
It's unclear to me what problem your proposal solves. If the source of
the issue is the package itself is paralleizing builds (i.e. rebar) then
how does making Nix more dataflow solve that?
stewart mackenzie setor...@gmail.com writes:
Maybe I'm wrong, but I don't think the Nix language itself
On 12/25/2014 05:45 PM, stewart mackenzie wrote:
If one uses declarative concurrency I suspect one could essentially
remove much of the build plan logic that's in nix-the-language.
The *.nix evaluation and actual build processes are separate. First
there's evaluation into *.drv derivations
It's unclear to me what problem your proposal solves. If the source of
the issue is the package itself is paralleizing builds (i.e. rebar) then
how does making Nix more dataflow solve that?
My initial problem was non-deterministic error messages. the-kenny and
James helped me realize it is
So bang goes that idea of Declarative Concurrency, as it's already
coarsely implemented and seems to be correct.
Correction, Declarative Concurrency isn't implemented into
nix-the-language but determinism is achieved via another more
procedural means.
Given that the build isn't deterministic, is there any provisions for
Nix to force it to be deterministic? Like automatically forcing a
rebuild if the output resulted in errors? Or is this left to the user to
rerun the command?
On 26/12/2014 4:17 AM, stewart mackenzie wrote:
So bang goes that
What are the advantages and disadvantages?
On 24/12/2014 9:12 PM, Raahul Kumar wrote:
I would strongly prefer systemd-timesync, as the default, since we're
using systemd anyway. Might as well get the maximum use out of it.
Aloha,
RK.
On Tue, Dec 23, 2014 at 10:38 PM, Eelco Dolstra
12 matches
Mail list logo
