Re: [Nix-dev] Problem compiling a rust program without fetchFromGitHub

[stewart mackenzie]

This is _exactly_ the reason why I moved all rust machinery into fractalide
before I deprecated it completely. The upstream nixpkgs rustRegistry wasn't
keeping up with my newly published rustfbp crate. By having the machinery
in fractalide I could bump the registry without making week long turn
around times to nixpkgs.

I asked you to nix-collect-garbage to remove all that crap, the new error
indicates the true source of the problem.

This error is a combination of the idiocy of semantic versioning, a
non-hermetically sealed rust machinery in nixpkgs and cargo's he-man
approach to a build system.

Please update the rustRegistry and try again.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Problem compiling a rust program without fetchFromGitHub

[stewart mackenzie]

I mean rustRegistry now
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Problem compiling a rust program without fetchFromGitHub

[stewart mackenzie]

Okay, progress.

No it's not exactly the same as it's not hermetically sealed.

You need to update the rustIndex in nixpkgs.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Problem compiling a rust program without fetchFromGitHub

[stewart mackenzie]

$ nix-garbage-collect then retry
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Rust prebuilt package overlay.

[stewart mackenzie]

Great stuff Nicolas, much appreciated!
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Why having releases if you break things in it often

[stewart mackenzie]

Welcome Stefan,

Put all that stuff aside for the moment, just a moment, and work your way
through this tutorial https://nixcloud.io/tour/?id=1. If once done, you
decide nix isn't for you then drop it. If something switches on in your
head keep at it cause you'll now have all the tools needed to unlock nix/os.

Any other method other than learning the language is a waste of time IMHO,
fortunately nix is a very nice language and will make your fingertip an
order of magnitude more powerful.

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] purescript takes 4+ hours to build a hello world app on nixos

[stewart mackenzie]

On Mon, Jan 30, 2017 at 1:02 AM, Sergei Trofimovich  wrote:
> On Sun, 29 Jan 2017 18:48:14 +0800

> Your system time
>
> real22m21.918s
> user13m49.982s
> sys 23m1.702s
>
> suggests something is seriously off on your system.
> Perhaps machine is swapping heavily.
>
> If it works that long for you you should be able
> to explore the problem as it goes with tools like
> 'perf top', 'strace' and others.

If I do this:

$ mkdir tempdir
$ cd tempdir
$ npm install bower pulp
$ ./node_modules/.bin/pulp init
$ time ./node_modules/.bin/pulp build
* Building project in /home/stewart/dev/fractalide/capnpc-purescript
* Build successful.

real0m1.127s
user0m1.342s
sys 0m0.188s

Regarding swap:
Also when I checked htop during the `nix-build` in
nix-purescript-skeleton repo swap shows no indication of thrashing.

Kinda nasty using perf top due to permission issues.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] purescript takes 4+ hours to build a hello world app on nixos

[stewart mackenzie]

I'm confounded by this issue, I'd like to know if anyone on nixos can
reproduce this behaviour.

https://github.com/purescript/purescript/issues/2598

There are easy steps to reproduce on the issue description.

Note it doesn't seem to exhibit when using nix on ubuntu etc.

If you can repoduce the issue on nixos please add to the issue
comments, to provide more evidence.

I've tried compiling against nixos-unstable and nixpkgs head.

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[stewart mackenzie]

see https://github.com/NixOS/hydra/issues/444

On Thu, Jan 19, 2017 at 1:53 AM, Christian Theune  wrote:
> Hi,
>
> On 18 Jan 2017, at 18:33, Jean-Pierre  wrote:
>
> New version of hydra (2016-12-09) override gcc to gcc6
>
> https://github.com/NixOS/hydra/blob/aef048b3cb3a7db25b1c48366f266031c5905c0b/release.nix#L127
>
>
> yeah, that’s what I’m using. I’m currently struggling trying to find a good
> base channel for the system (16.09 vs unstable) and a version of hydra,
> either by fetching the full module from the repo, …
>
> The newest version I could manage to get working had problems with the bzip
> perl module …
>
> I’ll give up the yak shaving for today, I guess. I had a working
> intermediate setup where the evaluation was still spinning and we’ll likely
> debug that tomorrow trying to find the part of the change that triggers
> this.
>
> Cheers,
> Christian
>
> --
> Christian Theune · c...@flyingcircus.io · +49 345 219401 0
> Flying Circus Internet Operations GmbH · http://flyingcircus.io
> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
> HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian.
> Zagrodnick
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hydra: infinite CPU and RAM consumption in evaluator

[stewart mackenzie]

The next problem you will have is this:
https://github.com/NixOS/hydra/issues/445

remove those changes and you will be able to add jobsets.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Call For Maintainers - Fractalide BETA release

[stewart mackenzie]

Reusable Functions - They're great, they're just great, you'll love them.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Call For Maintainers - Fractalide BETA release

[stewart mackenzie]

On Thu, Jan 12, 2017 at 8:46 PM, Herwig Hochleitner
 wrote:
> ...

Nix's very existence revolves around solving an insanely hard problem,
that of reproducibility, it's the only project that actually gets it
right.
Reproducible monolith apps have _everything_ to do with Nix/NixOS
Reproducible libraries have _everything_ to do with Nix/NixOS

Reproducible functions adds a new vertical design space to Nix/NixOS,
it's pretty huge in my books, given that monolith apps can be combined
in only a certain amount of ways. Next came the reproducible
libraries, which can be combined into even more ways. Now this new
feature introduces a whole new level of mix-and-matchability.

As for stealing from the community, this is not a zero sum game. I'd
suggest otherwise, it promotes adoption of Nix/NixOS. There are sane
development processes and software architecture principles there.
Should a company choose to adopt developing their servers in this
style it increases the Nix/NixOS community by one more company, it
also saves them boat loads of firefighting, bugs, bad architecture,
bloat and all sorts of nastiness down the line.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Call For Maintainers - Fractalide BETA release

[stewart mackenzie]

So let me understand this clearly.

Reusable and reproducible functions have nothing to do with Nix/NixOS?

What about reproducible libraries?
What about reproducible monolith apps?

This is a _new_ concept to the Nix/NixOS
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Call For Maintainers - Fractalide BETA release

[stewart mackenzie]

On Thu, Jan 12, 2017 at 7:03 PM, Profpatsch  wrote:
> Not sure what this has to do with nix-dev?

tough crowd, tough crowd.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Call For Maintainers - Fractalide BETA release

[stewart mackenzie]

Greetings all,

So after some 946 commits a number of rewrites starting in 2014 when
Fractalide was implemented in a neat programming language called
Mozart Oz, we've gone BETA. At that stage Fractalide was the subject
of a Master thesis for Denis Michiels under Professor Peter Van Roy of
UCL Belgium (Peter is a co-author of the book Concepts Techniques and
Models of Computer Programming). Both Peter and Denis are fantastic
fellows. Since then Fractalide has moved out of academia and into
industry reincarnated as Rust and Nix. I had the good fortune of
meeting Denis face to face in Belgium last year when we had our first
"fraconf" of only two participants! Hopefully this conference can grow
in numbers :-)

It would seem that Fractalide does in fact occupy a very important
part of the industry. Dataflow languages in the form of Ab Initio [0]
serve enterprises and charge a very heavy price tag. A couple of years
ago Google implemented this dataflow programming language called
TensorFlow, it's aimed at Machine Learning but it has other uses. The
NSA also open sourced their dataflow programming language called
Niagrafiles, now renamed to Apache-NiFi.

As each node in Fractalide is essentially a reusable function stuck in
a nix derivation one might say that Fractalide adds "Nixfuncs" to
"Nixpkgs", where nixpkgs are monolith applications that don't
(rarely?) compose and "nixfuncs" are reusable functions that can
compose.

It makes sense this general purpose dataflow language needs to
specialize in creating reusable, reproducible services, the power of
nix makes this quite possible to achieve. It's also a very trendy
area, which can lead into an even trendier area that of the Internet
of S... Things!

There has been a few guiding principles along the path.

1) ensure we have a language that cooperates with a congruent
configuration system.
2) safety both within and outside the application boundary.
3) primitives that make executing in a distributed environment easier
to reason about.
4) fast, fast as greased lightning.

Going BETA means it's a signal to the public that underlying nodes are
headed for stable and their public APIs won't change with a high
probability. After stabilization they won't ever be deleted or
changed. In other words Fractalide is going to be a rock solid
platform to build things on, for decades to come.

We're not yet ready to go STABLE because there are a few things in Nix
that need to happen such as the landing of this [1], which has this:
[2] and nixcrates needs a final round of work elbow work.

We're adopting the Pieter Hintjens style of community, whereby, should
jobs come in they get farmed out to trusted contributing members of
the community. This approach is more like forming an IETF group who
ralley around problems and solve them quickly, efficiently then share
the spoils, going back to their daily lives. These brilliant types of
people rarely tolerate enterprise environments and prefer working
independently or in small groups. Basically our company Noware Ltd. is
giving the Fractalide codebase away to the community, copyright is
spread far and wide to prevent corporate takeover and lockins, so as a
whole the community grows it into highly evolved software. As
Fractalide is so heavily dependent on Nix, it's fair to hand over a
percentage of the earnings to the Nix Foundation to help keep the
lights on.

On that note, if you're in business and you have expensive problems
you want to solve that fit Fractalide's domain please lets get in
touch. I'd like to start repaying favours the nix community has
offered me.

Onto some code.

So this is a contrived example of an NAND `agent`, (it's not a real world node):

#[macro_use]
extern crate rustfbp;
extern crate capnp;

agent! {
  input(a: prim_bool, b: prim_bool),
  output(output: prim_bool),
  fn run( self) -> Result {
let a = {
let mut msg_a = try!(self.input.a.recv());
let boolean: prim_bool::Reader = msg_a.read_schema()?;
boolean.get_bool()
};
let b = {
let mut msg_b = try!(self.input.b.recv());
let boolean: prim_bool::Reader = msg_b.read_schema()?;
boolean.get_bool()
};

let mut out_msg = Msg::new();
{
  let mut boolean = out_msg.build_schema::();
  boolean.set_bool(if a == true && b == true {false} else {true});
}
try!(self.output.output.send(out_msg));
Ok(End)
  }
}

Here is the associated nix code that sets up the dependencies needed
to build the above NAND `agent`

{ agent, edges, crates, pkgs }:

agent {
  src = ./.;
  edges = with edges; [ prim_bool ];
  crates = with crates; [ rustfbp capnp ];
  osdeps = with pkgs; [];
}

This code can be executed by running:

$ git clone https://github.com/fractalide/fractalide.git
$ cd fractalide
$ nix-build --argstr node test_nand
$ ./result
boolean : false

The arguments `--argstr node test_nand` build a file that looks like this:

$ cat /nix/store/kzw9p6a1snkhswwlnzb0i2a5rzg9vymd-test_nand

Re: [Nix-dev] permission problems

[stewart mackenzie]

Oh great, look forward to that landing.

On Wed, Jan 11, 2017 at 7:00 PM, Domen Kožar  wrote:
> https://github.com/NixOS/nixpkgs/issues/20156
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] permission problems

[stewart mackenzie]

Peter, Bas,

Thank you so much for this information. :-)

Is anybody working on bringing in the new systemd? Can I get started on it?

kr/sjm

On Wed, Jan 11, 2017 at 6:26 PM, Peter Hoeg  wrote:
> Hi Stewart,
>
>> I don't suppose there is some sort of convention, i.e. for lightweight
>> throw away services? See I'm creating a programming language aimed at
>> making tiny services, kinda like trensorflow, not applied to machine
>> learning but applied to this new fangled concept called microservices
>> - complete hype atm but it's fun. I'm kinda hoping these tiny services
>> are created and shared with the community, but they'd need not
>> conflict with each other.
>>
>> In other words I think I'm going to need some kind of id namespace
>> allocation or something to that effect.
>
>
> When systemd 232 hits nixpkgs, you get it for free:
>
> https://github.com/systemd/systemd/blob/master/NEWS#L53
>
> --
> Regards,
> Peter
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] permission problems

[stewart mackenzie]

On Wed, Jan 11, 2017 at 4:11 PM, Bas van Dijk  wrote:
> Hi Stewart,
>
> config.ids.uids.workbench doesn't seem to exist in:
>
>   https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix
>
> Why do you assume it's there? Which revision of nixpkgs are you using?

Good question, I suppose, I don't know why I assumed it, I thought it
would be generated or something. I don't recall seeing this:
.../nixos/modules/misc/ids.nix anywhere in the docs. Anyway the only
service I've contributed is zerotierone so experience is limited
there.

Though this does explain why I get my error, and will hopefull solve
my permission problem!

I don't suppose there is some sort of convention, i.e. for lightweight
throw away services? See I'm creating a programming language aimed at
making tiny services, kinda like trensorflow, not applied to machine
learning but applied to this new fangled concept called microservices
- complete hype atm but it's fun. I'm kinda hoping these tiny services
are created and shared with the community, but they'd need not
conflict with each other.

In other words I think I'm going to need some kind of id namespace
allocation or something to that effect.

How to proceed forward?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] permission problems

[stewart mackenzie]

greetings,

If I enable this:
https://github.com/fractalide/fractal_workbench/blob/master/service.nix#L72

I get

$ sudo nixos-rebuild test -I fractalide=/home/stewart/dev/fractalide/fractalide
[sudo] password for stewart:
building Nix...
building the system configuration...
error: attribute ‘workbench’ missing, at
/home/stewart/dev/fractalide/fractals/fractal_workbench/service.nix:72:13
(use ‘--show-trace’ to show detailed location information)

why can't I add` uid = config.ids.uids.workbench;`?

---

I'm trying to debug a permission problem in that the application
doesn't have permission to access the database.

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Remapping Console Key Bindings

[stewart mackenzie]

services.xserver.xkbOptions = "grp:alt_space_toggle, ctrl:swapcaps";
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Introducing Nixpkgs Overlays

[stewart mackenzie]

Hello Nicolas,

I support this work.

It would make layering of fractalide on nixpkgs easier, also the layering
of a developer's set of agents on top of fractalide would be easier and
cleaner.

I really hope this lands.

kudos

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Usability: Nixpkg > NixOS

[stewart mackenzie]

For me the crux is the nix expression language, everything revolves
around this, this is where real tangible value (read as eye opening,
toe curling power) is obtained.

It might be a good idea creating a nixmake.com or xmake.com site which
has a page for most popular languages detailing documentation on the
subject. The name nixmake is close to make, cmake and every other make
system. It's not alien and that name is humble enough to be installed
on a programmer's system.

Promote nixmake as a viable language level build system, every
language needs such a system. Now here's the key point. It's a helluva
lot easier getting into nixos, nixpkgs, hydra, nixops once you learn
the nix expression language, make the nixmake concept the gateway
drug, as you're proposing a nice solution to a problem close to many
programmer's daily work, shortly they end up seeing the whole picture.

Now when I say make nix as a language package manager, I mean do
things like this: https://github.com/fractalide/nixcrates (I
contracted the awesome https://nixcloud.io team to make nixcrates for
Fractalide, btw they also made https://nixcloud.io/tour/?id=1 so this
tour of nix should have a prominent place on this hypothetical
nixmake.com). Hence programmers would write default.nix files instead
of CMakeLists Makefile Cargo.toml etc files.

Get nix to schew language level build systems and construct arguments
for the different compilers directly.

my 2c worth

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Reproducibility testing in Hydra

[stewart mackenzie]

Massive achievement! Congrats to all involved!
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] getting dependencies

[stewart mackenzie]

okay this bit of code did it:

...
  propagatedBuildInputs = importedContracts;
  installPhase = ''
runHook preInstall
mkdir -p $out/src
mkdir -p $out/nix-support
for i in $importedContracts; do
  echo $i >> $out/nix-support/propagated-build-inputs
done
propagated=""
for i in $importedContracts; do
findInputs $i propagated propagated-build-inputs
done
echo $propagated
cp ${contractText} $out/src/contract.capnp
${capnproto}/bin/capnp compile
-o${capnpc-rust}/bin/capnpc-rust:$out/src/  $out/src/contract.capnp
--src-prefix $out/src/ -I "/"
  '';
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] getting dependencies

[stewart mackenzie]

Greetings,

The actual code in question is here:
https://github.com/fractalide/fractalide/blob/master/contracts/list/command/default.nix
Notice all the duplication!

My problem: Achieve Contract Composition!

This is where Command should be - without the Tuple duplication!:
https://github.com/fractalide/fractalide/blob/master/contracts/command/default.nix

This is where Tuple should be:
https://github.com/fractalide/fractalide/blob/master/contracts/tuple/default.nix


Each derivation will generate a *.rs file from a *.capnp file.

This is the technique capnproto uses to import another capnproto file:

```

# /nix/store/...-bar/src/contract.capnp
@0x8744595ef8d1c0ed;

struct Bar {
  a @0 :Text;
}
```

and in a separate derivation

```
# /nix/store/...-qux/src/contract.capnp
@0x99055c3145684b93;

using Bar = import "${bar}/src/contract.capnp";
struct Qux {
  a @0 :List(Bar.Bar);
}
```
(that ${bar} is nix code! I'm omitting the { bar }: at the top of the file)

The compilation of Qux works but when a component imports the
generated Qux.rs code and compiles Qux it will fail because there is
no generated Bar.rs code present, and therefore there are unresolved
dependencies on Bar.

A possible way to work around this is:

What I need to do is have a list of all the dependencies of Qux and
then concatenate the results of all the dependency derivation's *.rs
together into one final Qux.rs file.

This would then satisfy any component that uses Qux.rs

My question: how do I get a *unique* list of all the dependencies of
Qux? If it's not unique I could run into name collisions when
compiling the concatenated list.

This has to be a common issue and there must be a simple solution in nix.

Now I need help with my incompetence please.

I looked at propagatedBuildInputs, but it doesn't seem to work. Why?

Z depends on Y
Y depends on X

When I compile Z, X does not appear in any of the env-vars fields!
Only Y appears in an environment variable called
propagatedNativeBuildInputs (whatever that is, there doesn't seem to
be any documentation on propagatedNativeBuildInputs) Despite the
documentation saying otherwise. Secondly I cannot find a
nix-support/propagated-build-inputs file anywhere.

here is the documentation:

"propagatedBuildInputs

Like buildInputs, but these dependencies are propagated: that is, the
dependencies listed here are added to the buildInputs of any package
that uses this package as a dependency. So if package Y has
propagatedBuildInputs = [X], and package Z has buildInputs = [Y], then
package X will appear in Z’s build environment automatically."

Using this logic, I would need to include any dependent contract in
both the buildInputs and propagatedBuildInputs, so that contracts
would propagate "upstream". This also doesn't seem to work.

What am I missing?

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] svanderburg/disnix migrate to nixos/disnix

[stewart mackenzie]

I'm exploring this software now and it excites me, I'm currently
trying to get dysnomia installed, would be perfect if there was a
disnix/default.nix that'll just automate all that away (for those
nixos users).

I keep shying away from building subnets that are services in
github.com/fractalide/fractalide because services need the nixos layer
to automate everything. It would seem that by using disnix I'll be
able to deploy fractalide services in a destributed environment. Is
this accurate?

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] svanderburg/disnix migrate to nixos/disnix

[stewart mackenzie]

Hi Sander + all,

Disnix looks like a very interesting piece of software, would it be a
good idea to move disnix to the main nixos/ organization?

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] obtaining the drv from an imported object

[stewart mackenzie]

ah yes, this is my solution: https://github.com/fractalide/frac_example_wrangle

{ fractalide ? import  {}
  , pkgs ? fractalide.pkgs
  , support ? fractalide.support
  , contracts ? fractalide.contracts
  , components ? fractalide.components}:
let
  publicComponentOrSubnet = allComponents.example_wrangle; # expose
your public reusable subnet
  exeSubnet = allComponents.example_wrangle; # a subnet containing
non-generic IIPs you don't want to expose to the community
  allContracts = contracts // import ./contracts {inherit pkgs support
allContracts;};
  allComponents = components // import ./components {inherit pkgs
support allContracts allComponents;};
in
if fractalide == null then publicComponentOrSubnet
else import ( + "/support/vm/") {inherit pkgs support;
  contracts = allContracts;
  components = allComponents;
  exeSubnet = exeSubnet;}

it was late, cause my brain wasn't working properly.

Thanks mate

kr/sjm


On Mon, Oct 24, 2016 at 3:38 PM, zimbatm  wrote:
> I think what you want is something in this effect:
>
> let src = fetchTarball ...; fractalide = import src {};
> ...
> else import "${src}/support/vm" {}; ...
>
> Alternatively you could require the user to set the fractalide source into
> the NIX_PATH which gives her the choice of using a remote or local checkout.
> NIX_PATH="$NIX_PATH fractalide=https://...;
> In the code you can then access that using the  notation.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] obtaining the drv from an imported object

[stewart mackenzie]

Greetings,

I have a specialization repo for fractalide i.e. the repos may import
each others components and contracts. They are just specializations /
experimental places
(https://github.com/fractalide/fractalide_external_opensource_example)

I want the specialization repo to be importable by canonical i.e:
https://github.com/fractalide/fractalide/blob/master/components/vendor/external/opensource/example/default.nix#L11

and I also want the programmer to be able to `cd specialization/` and
then build a vm right there instead of having to go into the
fractalide repo to build the vm.

This is the code I have so far for this repo
https://github.com/fractalide/fractalide_external_opensource_example/default.nix

{ fractalide ? import (fetchTarball
https://github.com/fractalide/fractalide/archive/master.tar.gz) {}
  , pkgs ? fractalide.pkgs
  , support ? fractalide.support
  , contracts ? fractalide.contracts
  , components ? fractalide.components}:
let
  publicComponentOrSubnet = allComponents.vendor_test_nand;
  allContracts = contracts // import ./contracts {inherit pkgs support
allContracts;};
  allComponents = components // import ./components {inherit pkgs
support allContracts allComponents;};
  componentOrSubnetOrVm = if fractalide == null then publicComponentOrSubnet
  else import fractalide { inherit pkgs support allContracts
allComponents; exeSubnet = publicComponentOrSubnet;};
in
componentOrSubnetOrVm

The line in question is this one:   else import fractalide { inherit
pkgs support allContracts allComponents; exeSubnet =
publicComponentOrSubnet;};

I want to find the drv of fractalide so I can `else import
fractalide.drv/support/vm { ...} (to that effect)

where the path points to this file:
https://github.com/fractalide/fractalide/blob/master/support/vm/default.nix

How do I obtain the drv?

Kind regards
Stewart
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] error: stack overflow (possible infinite recursion) && builtins.match isn't documented

[stewart mackenzie]

Hello,

I've just stumbled on a treasure:

https://github.com/NixOS/nix/blob/master/src/libexpr/primops.cc#L1937

I'm curious to know why such an important builtin isn't documented
here: http://nixos.org/nix/manual/

I'm unusually excited about find, as demonstrated by opening the email
with this topic
lest I forget my original problem is:

I'm getting an error:

hydra-eval-jobs returned exit code 1:
error: stack overflow (possible infinite recursion)

when using hydra to build fractalide, the only mention of the above
error is here:
https://github.com/NixOS/nixpkgs/issues/16570

Now I doubt the overflow is due to my splitString usage here:
https://github.com/fractalide/fractalide/blob/master/support/genName.nix#L8
,  as the paths are quite small.

Where typically does one come across hydra stack overflows? I'm using
hydra master head.

These are my nixops parameters:

  deployment.targetEnv = "virtualbox";
  deployment.virtualbox.memorySize = 4096; # Mbytes
  deployment.virtualbox.headless = true;

I really just want to ping the community before I start digging down a
lot of rat holes.

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] pass a text file on the internet through <>

[stewart mackenzie]

Yes you're right a separate arg should be used. Still the <> seems like a
wonderful tool and limiting it just to tarballs seems a bit of a waste.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] pass a text file on the internet through <>

[stewart mackenzie]

Greetings,

In my nix code I make use of a <>, when executing the nix-build
command I use `-I
fractalide_user=https://keybase.io/iElectric/key.asc`

(I chose iElectric cause it was convenient)

[stewart@rivergod:~/dev/fractalide/fractalide]$ nix-build  --argstr
debug true --argstr cache $(./support/buildCache.sh)  --argstr subnet
shells_lain_commands -I
fractalide_user=https://keybase.io/iElectric/key.asc
downloading ‘https://keybase.io/iElectric/key.asc’... [2/2 KiB, 1.5 KiB/s]
unpacking ‘https://keybase.io/iElectric/key.asc’...
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
error: program ‘tar’ failed with exit code 2
(use ‘--show-trace’ to show detailed location information)

Surely one should be able to pass text files over this medium?

Kind regards
Stewart
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Rust: "error: failed to load source for a dependency on ..."

[stewart mackenzie]

Hi,

I've `sudo nixos-rebuild --upgrade switch` 'ed and things stopped working.

steps to reproduce:

$ nix-build  --argstr debug true --argstr cache
$(./support/buildCache.sh)   -A components.nucleus_find_contract

(this command currently won't work on HEAD as

Please note there is no mention git repositories in the Cargo.toml
file, which seems to be the common source of this error on nix.

Does someone know what's going on with this error?


CARGO.TOML

[package]
name = "component"
version = "0.1.0"
authors = ["test "]

[lib]
name = "component"
crate-type = ["dylib"]

[dependencies]
capnp = "*"
rustfbp = "*"


CARGO.LOCK

[root]
name = "nucleus_find_contract"
version = "0.1.0"
dependencies = [
 "capnp 0.7.4 (registry+file:///dev/null)",
 "rustfbp 0.3.18 (registry+file:///dev/null)",
]

[[package]]
name = "byteorder"
version = "0.4.2"
source = "registry+file:///dev/null"

[[package]]
name = "capnp"
version = "0.7.4"
source = "registry+file:///dev/null"
dependencies = [
 "byteorder 0.4.2 (registry+file:///dev/null)",
]

[[package]]
name = "dtoa"
version = "0.2.2"
source = "registry+file:///dev/null"

[[package]]
name = "itoa"
version = "0.1.1"
source = "registry+file:///dev/null"

[[package]]
name = "kernel32-sys"
version = "0.2.2"
source = "registry+file:///dev/null"
dependencies = [
 "winapi 0.2.8 (registry+file:///dev/null)",
 "winapi-build 0.1.1 (registry+file:///dev/null)",
]

[[package]]
name = "lazy_static"
version = "0.2.1"
source = "registry+file:///dev/null"

[[package]]
name = "libloading"
version = "0.2.4"
source = "registry+file:///dev/null"
dependencies = [
 "kernel32-sys 0.2.2 (registry+file:///dev/null)",
 "lazy_static 0.2.1 (registry+file:///dev/null)",
 "target_build_utils 0.1.1 (registry+file:///dev/null)",
 "winapi 0.2.8 (registry+file:///dev/null)",
]

[[package]]
name = "num-traits"
version = "0.1.36"
source = "registry+file:///dev/null"

[[package]]
name = "rustfbp"
version = "0.3.18"
source = "registry+file:///dev/null"
dependencies = [
 "capnp 0.7.4 (registry+file:///dev/null)",
 "libloading 0.2.4 (registry+file:///dev/null)",
 "threadpool 1.3.2 (registry+file:///dev/null)",
]

[[package]]
name = "serde"
version = "0.8.11"
source = "registry+file:///dev/null"

[[package]]
name = "serde_json"
version = "0.8.2"
source = "registry+file:///dev/null"
dependencies = [
 "dtoa 0.2.2 (registry+file:///dev/null)",
 "itoa 0.1.1 (registry+file:///dev/null)",
 "num-traits 0.1.36 (registry+file:///dev/null)",
 "serde 0.8.11 (registry+file:///dev/null)",
]

[[package]]
name = "target_build_utils"
version = "0.1.1"
source = "registry+file:///dev/null"
dependencies = [
 "serde_json 0.8.2 (registry+file:///dev/null)",
]

[[package]]
name = "threadpool"
version = "1.3.2"
source = "registry+file:///dev/null"

[[package]]
name = "winapi"
version = "0.2.8"
source = "registry+file:///dev/null"

[[package]]
name = "winapi-build"
version = "0.1.1"
source = "registry+file:///dev/null"

[metadata]
"checksum byteorder 0.4.2 (registry+file:///dev/null)" =
"96c8b41881888cc08af32d47ac4edd52bc7fa27fef774be47a92443756451304"
"checksum capnp 0.7.4 (registry+file:///dev/null)" =
"476c6a1bba39763a198092e54dec50113c48478dbe031385acfecbae70bac1bd"
"checksum dtoa 0.2.2 (registry+file:///dev/null)" =
"0dd841b58510c9618291ffa448da2e4e0f699d984d436122372f446dae62263d"
"checksum itoa 0.1.1 (registry+file:///dev/null)" =
"ae3088ea4baeceb0284ee9eea42f591226e6beaecf65373e41b38d95a1b8e7a1"
"checksum kernel32-sys 0.2.2 (registry+file:///dev/null)" =
"7507624b29483431c0ba2d82aece8ca6cdba9382bff4ddd0f7490560c056098d"
"checksum lazy_static 0.2.1 (registry+file:///dev/null)" =
"49247ec2a285bb3dcb23cbd9c35193c025e7251bfce77c1d5da97e6362dffe7f"
"checksum libloading 0.2.4 (registry+file:///dev/null)" =
"eceb2637ee9a27c7f19764048a9f377e40e3a70a322722f348e6bc7704d565f2"
"checksum num-traits 0.1.36 (registry+file:///dev/null)" =
"a16a42856a256b39c6d3484f097f6713e14feacd9bfb02290917904fae46c81c"
"checksum rustfbp 0.3.18 (registry+file:///dev/null)" =
"fbb4e3c922b153ace2c8094b9fb0d03cbbd9f751886e3669fb0e46350bac0c84"
"checksum serde 0.8.11 (registry+file:///dev/null)" =
"15db662ce4b837aac5731c52fe732d84a00f909763236289587cb7ca6985f6d8"
"checksum serde_json 0.8.2 (registry+file:///dev/null)" =
"e5b3bb42fa42265df8a1822b3db2090bc8f9e17e8142599c76a5b854bc4e7b5b"
"checksum target_build_utils 0.1.1 (registry+file:///dev/null)" =
"7a1be18d4d908e4e5697908de04fdd5099505463fc8eaf1ceb8133ae486936aa"
"checksum threadpool 1.3.2 (registry+file:///dev/null)" =
"59f6d3eff89920113dac9db44dde461d71d01e88a5b57b258a0466c32b5d7fe1"
"checksum winapi 0.2.8 (registry+file:///dev/null)" =
"167dc9d6949a9b857f3451275e911c3f44255842c1f7a76f33c55103a909087a"
"checksum winapi-build 0.1.1 (registry+file:///dev/null)" =
"2d315eee3b34aca4797b2da6b13ed88266e6d612562a0c46390af8299fc699bc"

---
ERROR MESSAGE:
---

warning: custom 

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

Aye, generally one hopes he rests in peace, but if the cryonics option was
chosen then resting in piece is preferable. (I've interacted with him
enough to know that he'd laugh like a drain at that and he really wouldn't
want us getting all soppy on him.)

Domen, just studying the C4 might be insufficient, please can you read the
Psychopath Code, Social Architecture, and the Zeromq Manual. For a more
general understanding read Culture and Empire. All his material is freely
available online, but it might be a good gesture for people who are
seriously considering shifting Nixpkgs to C4 to buy his books. The website
will probably go down in a couple of years and having hard copies of his
thought patterns is good, plus it helps his children to purchase the books.

Kind regards
Stewart
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 16.09 released

[stewart mackenzie]

Congratulations!
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra.cryp.to will go offline by the end of this year

[stewart mackenzie]

Never used it, but it very much inspired me! Well done on this work!

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOps usage survey.

[stewart mackenzie]

Yes, you're deliberately breaking purity, but if you're going to be using
it as part of the development infrastruction (he could mean many things,
does he mean *code deployment infrastructure* or implicitly implying CDI
and explicitly mentioning part of the development infrastructure.)

If he means he wishes to use nix as the main way to build the project,
(I.e. make replacement, so to say) then he'll very very quickly hit a wall
in that he'll be waiting long periods for the project to compile from
scratch each time. This is infuriating and incremenal compilation can have
a significant positive impact on your development flow.

So yes, I will recommend him to break purity in this case, I should have
mentioned, when you actually deploy, make sure you haven't enabled this
incremenal compilation feature. Keep it pure, but I was going to mention
that to him if/when he gets to that bridge so that he doesn't get
information overload now.

On 6 Sep 2016 06:31, "Shea Levy"  wrote:
> Please don't recommend turning off
> the sandbox unless you are very sure you know what you're doing and that
> the person you're recommending it to understands the relevant issues.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOps usage survey.

[stewart mackenzie]

On 6 Sep 2016 00:01, "Aloïs Cochard"  wrote:
> We do plan to use it for our development infrastructure

You'll need to implement incremental recompilation (IR) to reduce
compilation times. It's not too difficult to implement if you know _not_ to
set nix.useSandbox = true; .

Ping me when/if you get to that bridge and I'll assist.

Kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

Was that offensive? Sorry I thought it was funny. Forgive me I shan't
mention nipples again.

On 1 Sep 2016 03:51, "Jookia" <166...@gmail.com> wrote:

> On Thu, Sep 01, 2016 at 01:17:02AM +0800, stewart mackenzie wrote:
> > Throw beers at Garbas! Shower him in the best beer possible!
> >
> > *Garbas rubs his nipples*
>
> 2.7.5:
>
> Administrators SHOULD block or ban "bad actors" who cause stress and pain
> to
> others in the project. This should be done after public discussion, with a
> chance for all parties to speak. A bad actor is someone who repeatedly
> ignores
> the rules and culture of the project, who is needlessly argumentative or
> hostile, or who is offensive, and who is unable to self-correct their
> behavior
> when asked to do so by others.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] typed nix

[stewart mackenzie]

P "Nix won't be complete until it has static typing." Nice.

> highly nontrivial...

No doubt, but having that speed up would be quite nice. Especially when
using nix as a 'replacement' for make. It's the future!

What would the language even look like?

On 1 Sep 2016 03:29, "Vladimír Čunát"  wrote:
> There's a ticket open:
> https://github.com/NixOS/nix/issues/14
> but IMO someone should first think through the implications,
> as I suspect they'll be highly nontrivial...
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

Just one? A lunatic, now two? A crowd? Three? A rebellion!?

Resist your hatred for SJWs and wear the teeshirt for an email in support
please.

On 1 Sep 2016 01:48, "obadz" <obadz-...@obadz.com> wrote:

> On Wed, Aug 31, 2016 at 6:13 PM, stewart mackenzie <setor...@gmail.com>
> wrote:
>
>> this isn't a technical problem it's a people problem
>
>
> I think there are more people who agree with you on this than you think :-)
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

Throw beers at Garbas! Shower him in the best beer possible!

*Garbas rubs his nipples*

On 1 Sep 2016 01:06, "zimbatm"  wrote:
>
> Related to the original rust frustration, Garbas has started the
https://github.com/garbas/nixpkgs-mozilla repo where Mozilla stuff is being
compiled. There is no hydra building this yet but that could be a nice
place to keep rust nightlies.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

I'm the canary in this goldmine, and this canary is dead.

What I'm about to describe is Amdahl's law biting the ass harder of
maintainers as nixpkgs grows in size. It's the reason why maintainers are
rudely closing PRs, it's the reason why maintainers are cutting corners
themselves yet expect super high standards from contributors.

Yes it's bloody annoying having someone who didn't even understand the PR
close it. Having @globin close the PR without a complete understanding and
he voted against C4 in [2], irritated me. Moritz I beg you to answer this
with blood streaming from my eyes, do you think @globin has any incentive
to solve my problem? Instead I get comments like "If you calm down I might
be interested in putting my time into trying to understand why this isn't
affected but I'm quite sure you misinterpret the meaning of lowprio".
That's after me waiting hours of compile time, no sleep for a long time.
Besides, I could have just created another PR to add lowprio back! Notice
eelco saying lowprio is needed yet [1] has landed in mainline. Yes I would
need to see if it actually worked on hydra, but I'm the one waiting and
learning! If you guys are not prepared to break apart this forming 'in
crowd' with the C4, then what are your procedures on removing cultivated
bad maintainers, or will you just let this become a systemic problem? I am
NOT implying @globin is a bad actor! This current stressful system will
turn good actors into bad actors.

I now don't care how under pressure you maintainers are... your power
structure dictates it, the very power structure you guys uphold and resist
my attempts at breaking. You could totally alleviate your self chosen
stress by adopting the C4.
Maintainers are becoming grumpy, the workload is higher, I had sympathy now
I do not. Shall I reciprocate with the same level of rudeness I receive
when submitting a patch?

I'm getting frustrated not at any individual, you're all, I'm sure, great
people I can have a good amount of beer with. It's your power structure I'm
rebelling against. It needs to change.

Then to have another PR created [1] by the person who didn't take the time
or energy to even read or understand the C4. Yes I have no patience for
people who do not read or understand something, especially when I've spoken
on the topic multiple times, endeavouring to answer questions politely and
nicely [2], and then to have a  habitual response with the "I'm a stressed
maintainer don't bother me" learned attitude. I will no longer write
volumes (doing it again ... damn) arguing with maintainers who don't want
to read, hence the 1+1=2 response. This Moritz is the straw breaking the
camel's back, a long while ago I noticed this rude behaviour of
maintainers, which is a direct result of the power structure and decided
not to commit or maintain packages on nixpkgs or even "aspire" to become a
nix maintainer. Having people go around running algos on your level of
commitment is such utter and total bullshit.

I get people approaching me out of band suggesting technical solutions to
this problem (regarding nixpkgs maintainers), this isn't a technical
problem it's a people problem. It's becoming a fiefdom, the in crowd,
forgive me, but that annoys me. Maybe I should just stop interacting with
the nix crowd? Would you prefer that? If you'll let me maintain 1, only 1
package on nixpkgs - a nix shell I'm developing. That's it I promise. I
won't touch any other code. (See how mental that is?)

[1] https://github.com/NixOS/nixpkgs/pull/18101/files
https://github.com/NixOS/nixpkgs/commit/d4e012780f7eee93f7600d5273edde7470f20c87

[2] https://github.com/NixOS/nixpkgs/issues/17407

[3] https://github.com/NixOS/nixpkgs/pull/18102

Think about it for a second, when has the legal system ever passed laws to
limit it's own power? Passing the C4 will limit even Eelco's power. Imagine
every single maintainer not being able to merge their own commits.

The way lethalman handled this PR of mine is exactly the correct way [3]
except there should have been no dialogue or at least reducing as much
upfront consensus as possible - you can't fight amdahl's law, and it's just
going to get worse the larger nix gets. Indeed, this is exactly what
@globin should have done, cause I would have fixed it if it was broken,
why? Cause that bit of code is in my L1 cache not @globin's. If for example
I broke it and didn't fix it again, revert my commit. Simple.
It's much less trouble on @globin to JUST check a correct patch and merge
it asap.

I repeat, you can't fight amdahl's law, and it's just going to get worse
the larger nix gets.

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] rustc failure on nix only?

[stewart mackenzie]

On 31 Aug 2016 02:01, "Matthias Beyer"  wrote:
> We fixed that in [650] which allowed beta to fail and we reverted that
> patch in [655] as beta was updated and builds now.

okay, thanks. Seems like the new parsers for semver were throwing a
tantrum? I'll take a closer look soon.

Cheers!
/sjm

P.S. take a look at replacing make with nix. You can get some fancy lazy
builds going. It's really quite a fun way to structure code.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

On Tue, Aug 30, 2016 at 8:02 AM, Shea Levy  wrote:
> globin missed the fact that the naming convention is messing up the
> lowPrio logic, and your original PR had nothing to do with that. If rust
> were named properly, your fix would be wrong.

What is the exact naming scheme that rust should adopt?

I will make a pull request to fix this.

> Even in this case where
> your fix is harmless (which globin reasonably missed), it doesn't
> actually fix your issue and in the event that the rust naming is fixed
> it would be harmful then.

Secondly, I want to test this harmful aspect. What is the expected
harmful behaviour if I follow the steps to reproduce i.e.: correctly
name each rust and remove lowprio?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Including "beta" or "unstable" identifiers in package names?

[stewart mackenzie]

Trying to understand your email:

in development/compilers/rust

beta.nix:
current behaviour: the name "beta" is already part of the version ->
see "shortVersion"
"...
  rustc = callPackage ./rustc.nix {
shortVersion = "beta-2016-08-17";
..."
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/rust/beta.nix#L5-L6

in head.nix
current behaviour: the name "master" is already part of the version ->
see "shortVersion"
"...
  rustc = callPackage ./rustc.nix {
shortVersion = "master-1.13.0";
..."

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/rust/head.nix#L5-L6

I don't understand: "IMO the 'beta' and 'master' is part of the
version, not the package name, and so if it exists at all it should be
part of the version string;" as it quite clearly is part of the "shortVersion"
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

rust is a fast moving target, I don't want too much breakage. Recently
upstream decided to shove experimental features into nightly releases
(ie the allocator we're using which broke our build), this would cause
huge breakage and annoyance ameliorating issues.

It's better to keep lockstep with Rust. Once those experimental
features *eventually* hit stable then I'll breathe a sigh of relief.
Till then, it's the march of wicked.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

Sorry guys for showing my anger.

Shea, you're doing a great job and I rely on your great work all the time.
Thanks
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

Okay, then I'm absolutely boggled as to why each and every time I
update I have recompile rustBeta.rustc then rustUnstable.rustc.

I've literally been using nix-build ... -I
nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/125089b6bd360c82cf986d8cc9b17fc2e8ac.tar.gz
for more than a month.
That is the last working revision of Rust.

I really should get sleep. I'm at my wits end.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

I just want this issue resolved.

Every time I update / upgrade I recompile rustBeta then rustUnstable
and it results in 1/2 day lost. This has happened frequently, recently
as rustUnstable and rustBeta have been broken for a long time.
(ie days have been lost finding working revs then compiling rust)

If the lowprio removal doesn't solve this then how can I get it such
that when I issue a `nixos-rebuild --upgrade switch` and my
configuration.nix contains `rustUnstable.rustc`  downloads these
binaries 
http://hydra.nixos.org/job/nixos/release-16.03/nixpkgs.rustUnstable.rustc.x86_64-linux.

What exactly does lowprio do?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

> adversely affect nix-env users in that case.

How?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

1+1=2
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

Why is it like pulling teeth getting a simple pull request into nixpkgs?

Something is _very_very_ broken people.

Can we please fix this asap? No I don't want to hear bullshit reasons
about keeping X Y Z maintainer's powers.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

in the beginning Shea... where it says "Goals"
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

On Tue, Aug 30, 2016 at 7:36 AM, Shea Levy  wrote:
> Perhaps they are not random if you know their origin or justification,
> neither is given at the link though.

Backtrack? Are you kidding me?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

*me
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

Sigh, random rules? Are you kidding me?

Nevermind
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

due to multiple causes, but the latest straw on the camel's back is
this pull request: https://github.com/NixOS/nixpkgs/pull/18101
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

http://rfc.zeromq.org/spec:42/C4/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] 6 month C4 adoption period

[stewart mackenzie]

Dear Nixers,

Please may we start a C4 adoption period of 6 months then do a review
after this?

Kind regards
Stewart
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] typed nix

[stewart mackenzie]

per chance, is there work underway to make nix a typed language?

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Cross development for STM32

[stewart mackenzie]

I'd really like to see a simple nix way to retarget derivations.

So maybe `buildRustPackageForAndroid` or `buildRustPackageForSTM32`.

or maybe

buildRustPackage rec {
   name = "habitat-${version}";
   version = "0.8.0";
   target = "android";
   ...
}

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hardening flags enabled by default

[stewart mackenzie]

Huge kudos for this work guys! Excellent job and much appreciated!

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] bring into scope only required deps

[stewart mackenzie]

Hello,

The fractalide repository consists of N components that can be
combined in Z different ways, called a subnet. A subnet represents a
normal application you are used to executing.

one tells the repository to build Z subnet via this command:

$ nix-build [other args] --argstr subnet test_sjm
or
$ nix-build [other args] --argstr subnet app_growtest
etc

Each component in a subnet connects with another component via a
capnproto contract.

A special component called contract_lookup has knowledge about the
file system path of every contract. This knowledge is needed for the
component oriented language to do "dynamic" lookups.
example: [1] notice the 'maths_boolean:(boolean=true)' that is a
contract called `maths_boolean` [2]

Problem: the component contract_lookup [3] is dependent on all
contracts [4]. When distributing the graph of components I want
contract_lookup to only see contracts that are used within the Z
subnet.

I don't want contract_lookup to be dependent on every single
contracts, because as the system grows and more contracts are added it
would mean I have to distribute every contract for Z subnet.
This is mental.

Is there a way I can somehow query the top level rust program [5] and
ask for only those contracts that are being used, then pass it into
the contract_lookup which will write the rust hashmap? [3]

(currently the rustUnstable.rustc on nixos-unstable is broken so
you'll need to use
$ nix-build --argstr debug true --argstr subnet test_sjm -I
nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/125089b6bd360c82cf986d8cc9b17fc2e8ac.tar.gz
)

Kind regards
Stewart

[1] 
https://github.com/fractalide/fractalide/blob/master/components/test/sjm/default.nix#L9
[2] 
https://github.com/fractalide/fractalide/blob/master/contracts/maths/boolean/contract.capnp
[3] 
https://github.com/fractalide/fractalide/blob/master/support/contract_lookup/default.nix#L11-L13
[4] https://github.com/fractalide/fractalide/blob/master/contracts/default.nix
[5] https://github.com/fractalide/fractalide/blob/master/support/vm/default.nix
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Troubleshooting boot failures & rollbacks

[stewart mackenzie]

Hi,

try using `$ nixos-rebuild boot` to test out your system first.

$ man nixos-rebuild

...
   boot
   Build the new configuration and make it the boot default
(as with nixos-rebuild switch),
   but do not activate it. That is, the system continues to
run the previous configuration
   until the next reboot.

   test
   Build and activate the new configuration, but do not add it
to the GRUB boot menu. Thus, if
   you reboot the system (or if it crashes), you will
automatically revert to the default
   configuration (i.e. the configuration resulting from the
last call to nixos-rebuild switch
   or nixos-rebuild boot).
...

kr/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Windows updates

[stewart mackenzie]

Aye, couldn't agree more with you.

Kudos Eelco + contributors.

On 7 Aug 2016 06:44, "zimbatm"  wrote:

> I'm staring at a spinning update indicator right now and all I wanted to
> do is play a game on Windows. My wife purposely ignores the Windows updates
> because it never happens at a convenient time.
>
> So just to say that NixOS is awesome. Making updates is a background
> activity that doesn't need to affect the currently running system. And if
> it does, the changes are more or less instant. Meaning people would be more
> inclined to update as well.
>
> Thanks Eelco and contributors for this great system :)
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[stewart mackenzie]

On 26 Jul 2016 22:22, "Wout Mertens"  wrote:
> Anybody up for C4?

Finally some sanity! Yes! (FFS!)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nix as a library

[stewart mackenzie]

Hmm on second thoughts, it's probably best to expose a nix-repl... it
would be much more powerful. Thanks for than Vladimir!

The user interface (ie compile button, whatever) could just write
strings directly into the repl then linefeed, or you could just type
it yourself.

This would simplify things quite a lot actually.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nix as a library

[stewart mackenzie]

Ohh exciting, I'll investigate :-)

On Sun, Jul 10, 2016 at 12:25 AM, Vladimír Čunát  wrote:
> I think there are some APIs, but without guarantees of their stability:
> libnixexpr.so libnixformat.so libnixmain.so libnixstore.so libnixutil.so
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nix as a library

[stewart mackenzie]

Yeah, doable, but undesirable. Anyway, there is no API, i'll roll with
calling executables.

cheers Vladimír and zimbatm.

On Sat, Jul 9, 2016 at 8:53 PM, Vladimír Čunát  wrote:
> Communication with a single instance of nix-repl might be more efficient
> for some use cases, as it can retain evaluated sub-expressions between
> individual "commands".
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nix as a library

[stewart mackenzie]

Hmm okay, I have a use case then.

We're building a data flow editor in fractalide. As component oriented
styles of programming makes the concept of data flowing through a system to
be a first class citizen, the editor merely enhances this data flow
manipulation to a few points and clicks. It's what allows for trivial
reusability of components.

Now if we couldn't load a nix library we'd have to make every single
component a dependency of this editor. This is undesirable, as the build
time would be too long. Besides, Fractalide is designed to have 1000s of
components and you'll only compile what you need per app.

It's much better to make this hypothetical nix library be the only
dependency of the editor, thus when you need/create a (new) component in
the editor, the editor fires up the component build via the nix library.
The editor would have adequate intelligence to libload once the build
succeeds, or allow you to debug the code. (vapourware)

This way, we wouldn't have to 'pop' fractalide out of nix to allow such
dynamic editor behaviour, but instead we'd completely embrace nix.

Why a C interface? Well most languages can handle the C ABI, so it would be
useful, otherwise only C++ apps could load the library. Besides, we're
using Rust and that won't interact with the C++ ABI. (C++ ABI is a complete
train smash). Probably http://www.swig.org could do a nice enough job of
providing an interface to whatever language needs access to nix
functionality.

Would be great to hear if anyone else has this use case.
On 9 Jul 2016 05:52, "Vladimír Čunát" <vcu...@gmail.com> wrote:

> On 07/08/2016 12:53 PM, stewart mackenzie wrote:
> > Are there any plans to make nix's functionality into a library so that
> > a programmer could include these libraries and affect change to the
> > system via a program they made?
> >
> > (keeping a C ABI so that it'll work with libffi)
>
> There's been some discussion on that point already, but AFAIK noone has
> produced a use case where using C interface would be significantly
> superior to using CLI interface (which has to be maintained reasonably
> stable anyway).
>
> --Vladimir
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] nix as a library

[stewart mackenzie]

Are there any plans to make nix's functionality into a library so that
a programmer could include these libraries and affect change to the
system via a program they made?

(keeping a C ABI so that it'll work with libffi)

kind regards
/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] hydra and nixos versions/commits at hydra.nixos.org

[stewart mackenzie]

On 20 Jun 2016 17:53, "Domen Kožar"  wrote:
> I do agree it's additional work, but it's better than current state where
we all maintain our Hydra from carefully picked commits and that's REALLY
some additional work.

Completely agree, it's kind of annoying going through the commits
determining which one is good. Once selected you're hesitant to move to a
more recent commit as it could blow up.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] wordpress

[stewart mackenzie]

I would switch in a heartbeat, using ubuntu, docker+virtualbox(inside
virtualbox), virtualbox screen size issues, something called
docker-machine I have to install manually into /usr/local/bin/ is not
fun, and I'm actively suppressing grumpiness ... it's times like this
I really appreciate nix. My time to help out contributing beyond
testing is severely limited. I foresee this wordpress project
lingering for 6~8 months. Thereafter we'll be developing a different
solution completely based on Rust and Nix.

I think I'll pause on ubuntu to try out your approach.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] wordpress

[stewart mackenzie]

Naa time critical nature, just decided to spin up an ubuntu virtualbox.

Ah I recognize the email address from the code you wrote :-)

It would seem it's very centered around deploying stock releases not
amenable for developing on wordpress. But I didn't get that far.

Is there a faster route?

On 10 Jun 2016 02:06, "Joachim Schiele"  wrote:
> got it working?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] wordpress

[stewart mackenzie]

Ah I see this: https://nixos.org/wiki/Wordpress

I'll need to override the src of wordpress with my own version of wordpress.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] wordpress

[stewart mackenzie]

Hi,

I see there's a wordpress package:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/web-servers/apache-httpd/wordpress.nix

There are no available wordpress attributes.

How do I install wordpress?

Kind regards
Stewart
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 6b9c67: elm: 0.16.0 -> 0.17.0 (#15383)

[Stewart Mackenzie]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 6b9c67333fe62c38f1231dd5339b776c7c3d7172
  
https://github.com/NixOS/nixpkgs/commit/6b9c67333fe62c38f1231dd5339b776c7c3d7172
  Author: Stewart Mackenzie <setor...@gmail.com>
  Date:   2016-05-11 (Wed, 11 May 2016)

  Changed paths:
M pkgs/development/compilers/elm/packages/elm-compiler.nix
M pkgs/development/compilers/elm/packages/elm-make.nix
M pkgs/development/compilers/elm/packages/elm-package.nix
M pkgs/development/compilers/elm/packages/elm-reactor-elm.nix
M pkgs/development/compilers/elm/packages/elm-reactor.nix
M pkgs/development/compilers/elm/packages/elm-repl.nix
M pkgs/development/compilers/elm/packages/release.nix

  Log Message:
  ---
  elm: 0.16.0 -> 0.17.0 (#15383)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Nixbot - a little helper for pull requests

[stewart mackenzie]

Hi Louis,

I really hope the community rolls this out!

Great work!

/sjm

On Fri, May 6, 2016 at 12:27 PM, Louis Taylor  wrote:
> code talks a lot louder than words:
>
> https://github.com/kragniz/nixbot
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Incremental recompilation

[stewart mackenzie]

Isn't the simplest solution this:

declare an output

`outputs = ["out" "cache"];`

now the word cache is hardcoded to create a directory
/tmp/${derivation-name}-cache/ this name doesn't change.
Now, in your derivation you can set the build tool (via env var if it
supports that) to use this cache folder as a place to store the build
artifacts.
You may then copy the final build product from `$cache` to `$out` at
some in the `installPhase`.

The last thing about `cache` is that it is _not_ deleted after the
derivation builds.

kr
/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Incremental recompilation

[stewart mackenzie]

It would be great to deploy the build product without the caches.

Preferably expose the API as part of mkDerivation.
This way I could pass in a 'develop' flag and if true, switch the cache on,
else leave it off. Now I'll be able to deploy without caches.

i.e.: if develop == true then cache = true else "";

IMHO, incremental compilation is a strong boon for nix adoption. It is the
only serious issue I can see which prevents Nix being a Make replacement.
Many projects start with a Make file, right away there is a dependency. Why
not just install Nix instead of Make as your project dependency,
immediately your project gets access to needed deps and do a whole bunch of
really powerful things to your source code.

We use Nix as a Make replacement, and I'm hooked to the point where I'm
able to endure no IR. So, this IR feature will upgrade Nix to a class A
drug, without the hazardous effects, from where I'm sitting.

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] haskell structure for all of nixpkgs

[stewart mackenzie]

Understood.

The comments regarding name finding in this post are interesting:
http://www.tweag.io/blog/stack-nix-portable-reproducible-builds seems
like a common issue.

(a lot of weight just to support incremental recompilation for Haskell!)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] haskell structure for all of nixpkgs

[stewart mackenzie]

Ah I see, Haskell grepping is quite useless.

Categorization using hierarchy generally is a good idea and makes
sense for large amounts of information. This naturally ties in with a
folder hierarchy. I personally find it refreshing information is
stored in the directory structure aka the hierarchy. It also allows
making little stateless expressions that can be copied and pasted
around, they are intelligent enough to look at the folder structure
and derive meaning. This helps when refactoring the hierarchy.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] haskell structure for all of nixpkgs

[stewart mackenzie]

I see,

What would that tooling look like?
Can anyone else see any other drawbacks of this approach?
How do Haskellers deal with searching for packages?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] haskell structure for all of nixpkgs

[stewart mackenzie]

On Tue, Apr 26, 2016 at 2:02 AM, Ericson, John  wrote:
> I'd say https://github.com/NixOS/nixpkgs/pull/14000 was the first big step
> in this direction, and hopefully
> https://github.com/NixOS/nixpkgs/issues/10874 will lead to the second.

Thanks John for the links, fantastic stuff.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] haskell structure for all of nixpkgs

[stewart mackenzie]

Okay Domen's a +1, maybe the guys and girls who implemented haskell
like PL level package systems could weigh in with insight. For example
ICIUC, Erlang packages adopts the same approach. The gained knowledge
could be helpful to start with this document.

Could someone with experience please write, in this thread, a few
words about this approach? Keep it small and simple.

Hopefully this gets more people interested by understanding it. Domen
says it's advanced and simple... why is it advanced and simple?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[stewart mackenzie]

Hi Oliver,

Here is a minimal example stripped of all the other crap:

https://github.com/fractalide/recompilation

Cheers!

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[stewart mackenzie]

Okay, I'm having a few problems implementing this, if you wouldn't
mind taking a look at this please:

This is the package level default.nix which calls
`buildFractalideComponent`: http://nixpaste.lbr.uno/ZTwRzV0-?nix
Typically found here:
https://github.com/fractalide/fractalide/blob/master/components/drop/ip/default.nix

Here is the implementation of `buildFractalideComponent.nix`:
http://nixpaste.lbr.uno/GmbsNjmk?nix
Found here: 
https://github.com/fractalide/fractalide/blob/master/build-support/buildFractalideComponent.nix

Here's my error message:

[stewart@rivergod:~/dev/fractalide/fractalide]$ nix-build --argstr
debug true -A components.drop_ip
error: value is a function while a set was expected, at
/home/stewart/dev/fractalide/fractalide/components/drop/ip/default.nix:15:21
(use ‘--show-trace’ to show detailed location information)

The error arises on the last line of default.nix

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] haskell structure for all of nixpkgs

[stewart mackenzie]

Every time I come into contact with Peter Simon's work on Haskell I
find myself growing green with envy.

This approach seems to be a much better way of structuring nixpkgs in general.

Now closure-size, a monumental job was undertaken successfully, what's
the feasibility of implementing the Haskell approach across the entire
nixpkgs.

How does one even start thinking about this?

Is it even worth it?

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[stewart mackenzie]

Oliver, what is in prelude/shell.nix? (nix-build -E '(import
prelude/shell.nix { nixpkgs = import /home/ollie/nixpkgs {}; }).dist')

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[stewart mackenzie]

You will save me hours of waiting in the future, definitely beer worthy!

Much appreciated Oliver!
On 23 Apr 2016 02:33, "Oliver Charles" <ol...@ocharles.org.uk> wrote:

> It's certainly possible, because I just did it with Haskell ;)
>
> https://gist.github.com/ocharles/cbd5d7ce63bb570abb86e655f36435ab
>
> On Fri, Apr 22, 2016 at 7:16 PM stewart mackenzie <setor...@gmail.com>
> wrote:
>
>> Yeah, I'm not so sure it's possible because one cannot copy from a
>> precompiled derivation output to a new derivation output, ie copy
>> cross derivation.
>>
>> As these multiple outputs (outputs = [x y z]) are seen as different
>> derivations, this cannot happen right?
>>
>> Have you actually managed to make progress beyond the copying part of
>> your example (preConfigure = "cp ${artefacts}/* .'';) in your
>> experimentation?
>>
>> (I'm still thought experimenting)
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[stewart mackenzie]

Yeah, I'm not so sure it's possible because one cannot copy from a
precompiled derivation output to a new derivation output, ie copy
cross derivation.

As these multiple outputs (outputs = [x y z]) are seen as different
derivations, this cannot happen right?

Have you actually managed to make progress beyond the copying part of
your example (preConfigure = "cp ${artefacts}/* .'';) in your
experimentation?

(I'm still thought experimenting)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[stewart mackenzie]

Ah, okay, I get your drift, I'll think how to make it succinct and
tidy in the code :-)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[stewart mackenzie]

Interesting Oliver, though this sounds like it'll throw a recursive
error. I'll investigate! cheers!
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] break purity

[stewart mackenzie]

Hi,

I've got a bunch of artifacts being built in the
/tmp/nix-build-component_name.drv-0

now I want to point the build manager, in this case cargo using the
CARGO_TARGET_DIR env var to put the artifacts into a directory I make
directly in the /tmp/target_${name}

This way any further compilations will reuse the artifacts and they
won't need to be rebuilt.

obviously nix doesn't allow me to do this.

Is there a dirty hack to allow creating and writing artifacts directly
to /tmp/target_${name}?

Why? We're using nix as a replacement for make, one major drawback is:
every time we change a line of code the entire component + trans deps
needs to be rebuilt. This takes a long time when transitive deps go
deep.

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] ANN: closure-size hitting master

[stewart mackenzie]

On Wed, Apr 13, 2016 at 4:02 PM, Vladimír Čunát  wrote:
> What kind of numbers? (on what?)

numbers on closure size reduction
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] ANN: closure-size hitting master

[stewart mackenzie]

*rub hands together*

great job!

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Did we just get windows support for free?

[stewart mackenzie]

Does windows support symlinks in non-administrator mode?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOps rasta ;-)

[stewart mackenzie]

Forgive my ignorance, but why does this brighten your day?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] download-from-binary-cache.pl: still waiting for ... is chewing time.

[stewart mackenzie]

This is quite annoying, I'm waiting about 30 seconds or more each time
I want to recompile the project and the network is flaky. Is there a
way to disable this cache.nixos.org/.narinfo seek?

```
$ nix-build --argstr debug true --argstr subnet example_wrangle
download-from-binary-cache.pl: still waiting for
‘https://cache.nixos.org/zh0gxqk936a7cw0kcfn96ny9cy6ccv2g.narinfo’
after 5 seconds...
download-from-binary-cache.pl: still waiting for
‘https://cache.nixos.org/csxcfgvjdxvbhapdyn0fmbpcfxhza0k1.narinfo’
after 5 seconds...
download-from-binary-cache.pl: still waiting for
‘https://cache.nixos.org/qgn83b8n256f3smy41zi1wrb8x5rjzjz.narinfo’
after 5 seconds...
these derivations will be built:
  /nix/store/6dx1w352pi3p0qc6i8rv8fmqksmlrk2y-fs_dir_list.drv
  /nix/store/7l7dwfb0zmcmssp3q32yd8k5456ihkq5-example_wrangle.drv
  /nix/store/97r16a6kxnlrlqj75xcqr9ffiga2vpqw-example_wrangle.drv
  /nix/store/rjxgfx3a4nhcqp9fy4jill51djry8cbi-example_wrangle.drv
building path(s) ‘/nix/store/qgn83b8n256f3smy41zi1wrb8x5rjzjz-fs_dir_list’
unpacking sources
```

/sjm
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev