<clever>
kiloreux: its much simpler to just use nix-shell like this, nix-shell default.nix -A imagemagick2
<clever>
kiloreux: you would need to write a custom package, that makes a renamed version of every binary
<clever>
plll: nix will detect if things have changed, and if its using the cache, then maybe you arent overriding nixpkgs right, or the change you made truely has no effect
<clever>
only one version of imagemagic can be used system wide
<clever>
which means they wont collide
<clever>
kiloreux: this allows you to use both of them, without having to install them
<clever>
and with each step, it applies less overrides, until it has built everything with the defaults in nixpkgs
<clever>
then at 150, it uses that as a normal stdenv to build a binutils/perl, and anything else the next stage asks nixpkgs for
<clever>
then it uses that 1st dummy stdenv as a base, applying a few overrides (lines 128-146) to make a dummy stdenv that just uses the bootstrap tools
<clever>
gchristensen: this file starts out on line 108, to create a dummy stdenv that has no usable tools
<clever>
johnramsden: need to either use 2 files and imports, or switch them all over to a list
<clever>
so you need to add nfs to the nixos config, and then supportedFilesystems isnt required again
<clever>
it shuts the network off before trying to umount, and then its literaly imposible to shut off properly
<clever>
but even then, systemd doesnt like it when i manualy mount nfs
<clever>
about the only time i need supportedFilesystems is when i want to add nfs support
<clever>
yeah
<clever>
johnramsden: boot.supportedFilesystems will default to every fsType listed in fileSystems
<clever>
johnramsden: something else that i see a lot of people overlook is like 215
<clever>
overrideAttrs
<clever>
Ralith: you could maybe make an override that sets outputs=["out"];
<clever>
johnramsden: oh, line 119, if you try to set autoResize=true on an entry, it just adds "x-nixos.autoresize" to the options list instead
<clever>
it will add a device="proc"; for you
<clever>
so if you give it { mountPoint="/proc"; fsType="proc"; }
<clever>
if the fsType is one of the special ones, device defaults to fsType
<clever>
johnramsden: oh, line 63 is neat
<clever>
and since unnamed-1 isnt a valid mountPoint, a new one has to be set
<clever>
so the list items just silently turn into attributes, unnamed-1, and so on
<clever>
on second thought, i think the nixos option framework will silently invent keys, fileSystems.unnamed-1.1.fsTtype
<clever>
but if you pass it a list, it has no key, so you need to set mountPoint directly
<clever>
johnramsden: and line 62 sets the default mountPoint to the key, "/"
<clever>
johnramsden: and line 28, it will call coreFileSystemOpts and pass it the key "/" and config {device="/dev/sda1; fsType="ext4";} for each filesystem
<clever>
johnramsden: the type is set to loaOf, list of attribute something something
<clever>
1 less dependency in the chain, but its still a total of 2 extra ghc's
<clever>
dhess`: but i think i have 802 building directly with 784 now
<clever>
dhess`: 802 was building with 7103, which built with 784
<clever>
configure: error: GHC version 7.8 or later is required to compile GHC.
<clever>
dhess`: i believe i am now building hscolour using 704
<clever>
it will use 32bit everything, and if sandboxes are on, uname will even lie and claim its a 32bit cpu
<clever>
yeah, just set system with argstr
<clever>
oops, i fixed ghchead, then tested 802
<clever>
strange, it grabbed 802 from the binary cache
<clever>
gchristensen: let me throw nix-build at it here and see what happens
<clever>
getting an hscolour right out of the bootstrap would be more complex, but make things more direct
<clever>
and 704 already has a full packageset, so no need to deal with hscolour changes
<clever>
but that depends on if 704 can build 802
<clever>
gchristensen: i'm guessing you can just change the 7103 on line 67, to 704, and that will cut it down to only 1 intermediate ghc
<clever>
gchristensen: it seems simple enough to try changing things and see if it builds, somebody just needs to invest some cpu hours to try building it
<clever>
dhess`: let me double-check some of the expressions
<clever>
dhess`: i'm guessing so ghc can colorize the haskell in error messages
<clever>
they didnt spell color right!
<clever>
dhess`: that lets you access the bootPkgs as the .bootPkgs attribute on the derivation, without it directly impacting the hash of the derivation
<clever>
kk
<clever>
dhess`: yep
<clever>
maurer: or if you can mmap something and use dma
<clever>
maurer: sometimes, the performance is just better if your passing binary to ioctl, rather then writing data to a file directly
<clever>
kiloreux: line 6-16 is an attribute set, and each line inside that uses pkgs.callPackage to load another nix file up
<clever>
then you can use nix-env -iA <attrname> to pick one
<clever>
if the default.nix returns an attribute set with 2 derivations in it
<clever>
you can use it the same way there
<clever>
and in nixos, you may want to avoid installing, and just reference things by absolute paths
<clever>
kiloreux: you would need to rename the binaries, or they will conflict in $PATH and only 1 will ever work
<clever>
but nix-env is an exception, you would need -f '<nixpkgs>' to make it check the path
<clever>
add a package name or -A <attrname> at the end
<clever>
kiloreux: you need to tell it which package to install
<clever>
so it doesnt need a fork to recompile things
<clever>
i have seen some IDE's that merge the compiler into the editor
<clever>
harder to cause syntax errors with the editing, if you just grab the entire tree as one unit
<clever>
Infinisi1: i do think it would be usefull to have the ability to cut&paste chunks of code whole, and having an AST aware editor would let you select a node, and all children at once
<clever>
joachifm: nix wont care, but if the user ever wants to read the file again, they will
<clever>
joachifm: i dont think it supports comments and whitespace
<clever>
Infinisi1: i have been wanting an AST library for nix, so i can parse configuration.nix, programaticaly apply changes, then serialize it back out
<clever>
dtz: and that auto-detection stuff works pretty well so i just left it like that
<clever>
dtz: yeah, i had installed it for c++ code, then never got around to configuring it properly
<clever>
dtz: but its a fairly dumb auto-complete, has no sense of context
<clever>
dtz: so if i open <nixpkgs/lib/lists.nix> with :tabe, i can auto-complete every lib function
<clever>
dtz: youcompleteme in vim is able to auto-complete any word in any file currently open
<clever>
Ivanych: /usr/bin/env doesnt exist in a sandbox, you need to run patchShebangs on the directory the script is in