Re: [Nix-dev] `fast-eval' branch merged
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/12/2010 07:15 PM, Marc Weber wrote: > /me is waiting for JIT now :)) *kidding* Do a Nix -> something JITtable convertor then. Should be simpler.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL631GAAoJEE6tnN0aWvw3WlMH/Aksg1UUggu7dexUC4kOZAoA aS/9yv48EtPwON/pwkSTpvz3TrjebQddWO52rMSmqKZoWAm0caOSxfymqWkpRIEN Uxyapdjke/Ey+V8xPCrEO7YJkcB37Qqvd7jzcjZTi4WgLYYjhjYmHIE3BsOuhmOo vvtPlzCLBBTYVnGMBJ4QUdLPRPOdzRiRg8jOhmPg+sh6HRe5JkJoauO5bFhaMSP/ duj/lKflzG3cdDoTNFzRdieY7vbFkohgHa25xPEqI+0lOtq1DKJr11Ic9ocJoGBh IsXAt1y5vhZcyCLfG3a9pCSS9uTWBQSk//AE29YzENlm3FPxItSYkj/1ksvlyy8= =y0NG -END PGP SIGNATURE- ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: Building an old GHC for a new Cabal...
Oh, I figured it out. You can make `nix-env' spit out the attribute names for packages: nix-env -qa --attr-path '*' | egrep cabal So I was able to install it like this: nix-env --install -A nixpkgs_unstable.haskellPackages_ghc6122.cabalInstall080 The "package within a package" is a concept unfamiliar to me. -- Jason Dusek Linux User #510144 | http://counter.li.org/ ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: Building an old GHC for a new Cabal...
2010/05/12 Yury G. Kudryashov : > You should use nix-env -i -A ... to select the needed cabal. It seems that `-A' wants me to specify an "attribute". What is an attribute? -- Jason Dusek Linux User #510144 | http://counter.li.org/ ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: Building an old GHC for a new Cabal...
2010/05/12 Marc Weber : > In any case using a collection should fix the trouble once and forall > (?) because packages are installed by attr path rather than by name. > I always install by attr path. > http://wiki.nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once I think there must be a typo in there somewhere as "myCollection" is in not in the nix example file. -- Jason Dusek Linux User #510144 | http://counter.li.org/ ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: Building an old GHC for a new Cabal...
Excerpts from Yury G. Kudryashov's message of Wed May 12 23:38:04 +0200 2010: > Marc Weber wrote: > > >> I do have GHC 6.10 still installed; but why does it not build > >> against the new GHC? > > > > Because of a design decision Andres Loeh once made: > > > > try cat `which ghc`. You'll see that ghc finds the packages containing > > ghc libraries by iterating over $PATH. > Marc, did you see the command in the original message? No. I missed it cause it looked like a log line. Thank you for pointing this out. In any case using a collection should fix the trouble once and forall (?) because packages are installed by attr path rather than by name. I always install by attr path. http://wiki.nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: Building an old GHC for a new Cabal...
Marc Weber wrote: >> I do have GHC 6.10 still installed; but why does it not build >> against the new GHC? > > Because of a design decision Andres Loeh once made: > > try cat `which ghc`. You'll see that ghc finds the packages containing > ghc libraries by iterating over $PATH. Marc, did you see the command in the original message? It was `nix-env -- install cabal-install-0.8.0`, and the real question was "why nix-env -i cabal-install pulls cabal-install from ghc-6.10 packages?" The answer is: because of "haskellPackages_ghc6122 = lowPrio" in all- packages.nix. You need to select haskellPackages_ghc6122.cabalInstall manually. And, as Marc said, it is not usefull to have two ghc versions in the same environment (at least, in the current setup). ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Building an old GHC for a new Cabal...
> I do have GHC 6.10 still installed; but why does it not build > against the new GHC? Because of a design decision Andres Loeh once made: try cat `which ghc`. You'll see that ghc finds the packages containing ghc libraries by iterating over $PATH. So the wrong ghc is found and their libraries are found. solutions: keep two different environments: env -i ghc_6_10_and_libs -p ~/ghc-6.10-env env -i ghc_6_12_and_libs -p ~/ghc-6.12-env or such. Then use either PATH=$PATH:~/ghc_6_10_and_libs/bin or PATH=$PATH:~/ghc_6_12_and_libs/bin A more complicated solution is using hack-nix which somewhat tries automating this for you. However I only patch packages to work with new ghcs. HTH Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] `fast-eval' branch merged
On Wed, May 12, 2010 at 04:01:08PM +0200, Eelco Dolstra wrote: > Hi, > > I've merged the Nix `fast-eval' branch into the trunk. Fantàstic! I was waiting the merge :) Thank you. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: Building an old GHC for a new Cabal...
Jason Dusek wrote: > I managed to build GHC 6.12 in Nix on Ubuntu after some help > in an earlier discussion on this list. Now, my old Cabal > (built through Nix) complains about an invalid package format; > this is to be expected if it shells out to `ghc-pkg' to read > the package list. > > When I try to rebuild Cabal, it tries to build it against GHC > 6.10 instead of 6.12: > I do have GHC 6.10 still installed; but why does it not build > against the new GHC? Should I delete the `.drv' files? Perhaps > these cache something about which GHC to build against? Deleting .drv files cannot help as new packages do not depend on the old state of your ~/.nix-profile etc. The key warning is "warning: there are multiple derivations named `cabal-install-0.8.0'; using the first one". You should use nix-env -i -A ... to select the needed cabal. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Building an old GHC for a new Cabal...
I managed to build GHC 6.12 in Nix on Ubuntu after some help in an earlier discussion on this list. Now, my old Cabal (built through Nix) complains about an invalid package format; this is to be expected if it shells out to `ghc-pkg' to read the package list. When I try to rebuild Cabal, it tries to build it against GHC 6.10 instead of 6.12: :; nix-env --install cabal-install-0.8.0 warning: there are multiple derivations named `cabal-install-0.8.0'; using the first one replacing old `cabal-install-0.6.2' installing `cabal-install-0.8.0' the following derivations will be built: /nix/store/48s13mpj6rqvaf3gq3mag8wmbx571kdl-haskell-zlib-ghc6.10.4-0.5.2.0.drv /nix/store/5qhafcrc10a66xg6aayd862fag6jkvk4-cabal-install-0.8.0.tar.gz.drv /nix/store/al2b217ah6hbs89dpj3wkmw968vvd4y8-zlib-0.5.2.0.tar.gz.drv /nix/store/h84yfpg550c8kqiv08pvajdlkijj1ls5-cabal-install-0.8.0.drv the following paths will be downloaded/copied (3.32 MiB): /nix/store/cb84zvm4n5290w185j3xazhkz89fa9wx-haskell-network-ghc6.10.4-2.2.1.7 /nix/store/mxyc0q4r8xyfx995qlrfwr5kx05x8z7p-haskell-HTTP-ghc6.10.4-4000.0.9 /nix/store/qr4hwvbrbpvfx3r9c596grdf3sssbk6f-curl-7.19.7 /nix/store/s60nzmp97k010vxp6hi9j3dbc4pz939w-openssl-0.9.8n I do have GHC 6.10 still installed; but why does it not build against the new GHC? Should I delete the `.drv' files? Perhaps these cache something about which GHC to build against? -- Jason Dusek Linux User #510144 | http://counter.li.org/ ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: `fast-eval' branch merged
Yay, great news indeed! Ludo’. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
RE: [Nix-dev] `fast-eval' branch merged
Merging the sqlite branch will give us another speed up as well (hopefully) :-) -Original Message- From: nix-dev-boun...@cs.uu.nl on behalf of Marc Weber Sent: Wed 5/12/2010 5:15 PM To: nix-dev Subject: Re: [Nix-dev] `fast-eval' branch merged Excerpts from Nicolas Pierron's message of Wed May 12 17:07:44 +0200 2010: > Great News :) I second that. hack-nix will be a nice test case as well. /me is waiting for JIT now :)) *kidding* Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] `fast-eval' branch merged
Excerpts from Nicolas Pierron's message of Wed May 12 17:07:44 +0200 2010: > Great News :) I second that. hack-nix will be a nice test case as well. /me is waiting for JIT now :)) *kidding* Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] `fast-eval' branch merged
Hi, Great News :) On Wed, May 12, 2010 at 16:01, Eelco Dolstra wrote: > Hi, > > I've merged the Nix `fast-eval' branch into the trunk. This replaces the > current Nix expression evaluator by a new, faster implementation. It no > longer > uses the term-rewriting based approach (described in [1]) but a more > conventional functional language implementation based on thunk updating. As a > result, Nix no longer depends on the ATerm library. > > Here are some benchmark results to show the performance improvement. The > benchmarks are: > > - `nix-env -f /etc/nixos/nixpkgs -qa \*' on Nixpkgs r21747. > - `nix-env -f /etc/nixos/nixpkgs -qa \* --drv-path'. > - `nix-instantiate /etc/nixos/nixos -A system --readonly-mode' (also on r21747 > of NixOS). This is what every `nixos-rebuild' operation does. > - `nix-instantiate /etc/nixos/nixos/tests/ -A proxy.test --readonly-mode' > (which > evaluates 4 NixOS system configurations). > > These were done on a 32-bit Linux machine (Intel Core 2 Duo T7700 @ 2.40GHz, 2 > GiB RAM) and on a 64-bit Linux machine (Intel Core i5 750 @ 2.67GHz, 6 GiB > RAM). > Here are the timings in seconds: > > | Old | New | Speedup > -+---+--+ > `nix-env -qa' (32-bit) | 2.96 | 0.60 | 4.9x > `nix-env -qa' (64-bit) | 1.86 | 0.32 | 5.8x > `nix-env -qa --drv-path' (32-bit) | 12.48 | 3.96 | 3.2x > `nix-env -qa --drv-path' (64-bit) | 7.65 | 2.04 | 3.8x > `nix-instantiate -A system' (32-bit) | 6.79 | 1.32 | 5.1x > `nix-instantiate -A system' (64-bit) | 4.63 | 0.71 | 6.5x > `nix-instantiate -A proxy.test' (32-bit) | 23.86 | 3.55 | 6.7x > `nix-instantiate -A proxy.test' (64-bit) | 15.76 | 1.95 | 8.1x > > Another goal of the `fast-eval' branch was to reduce memory consumption by the > evaluator. The old evaluator basically never released memory due to its > normal > form cache. With the new evaluator, we can in principle reclaim garbage > memory. > However, it doesn't actually have a garbage collector yet. I intend to use > the > Boehm GC for that. Nevertheless, the new evaluator already uses less memory > than the old one. For instance, `nix-instantiate -A system' on 64-bit Linux > uses 358.6 MiB with the old evaluator, but only 213.7 MiB with the new > evaluator > (according to Valgrind's `massif' tool). > > [1] http://www.st.ewi.tudelft.nl/~dolstra/pubs/laziness-ldta2008-final.pdf -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] `fast-eval' branch merged
Hi, I've merged the Nix `fast-eval' branch into the trunk. This replaces the current Nix expression evaluator by a new, faster implementation. It no longer uses the term-rewriting based approach (described in [1]) but a more conventional functional language implementation based on thunk updating. As a result, Nix no longer depends on the ATerm library. Here are some benchmark results to show the performance improvement. The benchmarks are: - `nix-env -f /etc/nixos/nixpkgs -qa \*' on Nixpkgs r21747. - `nix-env -f /etc/nixos/nixpkgs -qa \* --drv-path'. - `nix-instantiate /etc/nixos/nixos -A system --readonly-mode' (also on r21747 of NixOS). This is what every `nixos-rebuild' operation does. - `nix-instantiate /etc/nixos/nixos/tests/ -A proxy.test --readonly-mode' (which evaluates 4 NixOS system configurations). These were done on a 32-bit Linux machine (Intel Core 2 Duo T7700 @ 2.40GHz, 2 GiB RAM) and on a 64-bit Linux machine (Intel Core i5 750 @ 2.67GHz, 6 GiB RAM). Here are the timings in seconds: | Old | New | Speedup -+---+--+ `nix-env -qa' (32-bit) | 2.96 | 0.60 | 4.9x `nix-env -qa' (64-bit) | 1.86 | 0.32 | 5.8x `nix-env -qa --drv-path' (32-bit)| 12.48 | 3.96 | 3.2x `nix-env -qa --drv-path' (64-bit)| 7.65 | 2.04 | 3.8x `nix-instantiate -A system' (32-bit) | 6.79 | 1.32 | 5.1x `nix-instantiate -A system' (64-bit) | 4.63 | 0.71 | 6.5x `nix-instantiate -A proxy.test' (32-bit) | 23.86 | 3.55 | 6.7x `nix-instantiate -A proxy.test' (64-bit) | 15.76 | 1.95 | 8.1x Another goal of the `fast-eval' branch was to reduce memory consumption by the evaluator. The old evaluator basically never released memory due to its normal form cache. With the new evaluator, we can in principle reclaim garbage memory. However, it doesn't actually have a garbage collector yet. I intend to use the Boehm GC for that. Nevertheless, the new evaluator already uses less memory than the old one. For instance, `nix-instantiate -A system' on 64-bit Linux uses 358.6 MiB with the old evaluator, but only 213.7 MiB with the new evaluator (according to Valgrind's `massif' tool). [1] http://www.st.ewi.tudelft.nl/~dolstra/pubs/laziness-ldta2008-final.pdf -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
