[Nix-commits] [NixOS/nixpkgs] b88296: libidn2: Correct a broken darwin patch
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: b88296818de1f96745d529317c6047f651bade5b https://github.com/NixOS/nixpkgs/commit/b88296818de1f96745d529317c6047f651bade5b Author: John Wiegley Date: 2017-05-02 (Tue, 02 May 2017) Changed paths: M pkgs/development/libraries/libidn2/fix-error-darwin.patch Log Message: --- libidn2: Correct a broken darwin patch ___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 2df7f1: coq.QuickChick: Update to latest version that work...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 2df7f1b5b5ad5c1a4805f6d756ede50e0930e9eb https://github.com/NixOS/nixpkgs/commit/2df7f1b5b5ad5c1a4805f6d756ede50e0930e9eb Author: John Wiegley Date: 2017-04-23 (Sun, 23 Apr 2017) Changed paths: M pkgs/development/coq-modules/QuickChick/default.nix M pkgs/top-level/all-packages.nix Log Message: --- coq.QuickChick: Update to latest version that works with Coq 8.6 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 6bbddc: xcbuild: Guard a glibc-only postPatch with \!isDar...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 6bbddcf7d1aa4f2365c2ac6383902080340c6ce2 https://github.com/NixOS/nixpkgs/commit/6bbddcf7d1aa4f2365c2ac6383902080340c6ce2 Author: John Wiegley Date: 2017-02-23 (Thu, 23 Feb 2017) Changed paths: M pkgs/development/tools/xcbuild/default.nix Log Message: --- xcbuild: Guard a glibc-only postPatch with \!isDarwin ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 3a0efc: configuration-common: http-api-data is now at vers...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 3a0efcc4ca59cc3ebb3676e47b05f05dfbc6c9d2 https://github.com/NixOS/nixpkgs/commit/3a0efcc4ca59cc3ebb3676e47b05f05dfbc6c9d2 Author: John Wiegley Date: 2017-02-14 (Tue, 14 Feb 2017) Changed paths: M pkgs/development/haskell-modules/configuration-common.nix Log Message: --- configuration-common: http-api-data is now at version 0.3.5 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 129490: lens-family-th_0_4_1_0: Add to hackage-packages.ni...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 1294909c2ae2389135228e5cab6522daefc734ab https://github.com/NixOS/nixpkgs/commit/1294909c2ae2389135228e5cab6522daefc734ab Author: John Wiegley Date: 2017-01-25 (Wed, 25 Jan 2017) Changed paths: M pkgs/development/haskell-modules/hackage-packages.nix Log Message: --- lens-family-th_0_4_1_0: Add to hackage-packages.nix for GHC 7.10 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 35aebd: haskellPackages.servant_09_1_1, servant-client_0_9_...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 35aebd45f236127a6d33ee07e13082b9876b9813 https://github.com/NixOS/nixpkgs/commit/35aebd45f236127a6d33ee07e13082b9876b9813 Author: John Wiegley Date: 2017-01-19 (Thu, 19 Jan 2017) Changed paths: M pkgs/development/haskell-modules/configuration-common.nix Log Message: --- haskellPackages.servant_09_1_1,servant-client_0_9_1_1: update http-api-data reference ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 52e74d: pythonPackages.pyev: Remove duplication from last ...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 52e74ddc628877ac06f653a5d81905392a3a805f https://github.com/NixOS/nixpkgs/commit/52e74ddc628877ac06f653a5d81905392a3a805f Author: John Wiegley Date: 2017-01-05 (Thu, 05 Jan 2017) Changed paths: M pkgs/top-level/python-packages.nix Log Message: --- pythonPackages.pyev: Remove duplication from last commit ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] bae778: pythonPackages.pyev: Fix expression to work on Dar...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: bae778e86c7a946870844c644def9e0f89b2f68d https://github.com/NixOS/nixpkgs/commit/bae778e86c7a946870844c644def9e0f89b2f68d Author: John Wiegley Date: 2017-01-05 (Thu, 05 Jan 2017) Changed paths: M pkgs/top-level/python-packages.nix Log Message: --- pythonPackages.pyev: Fix expression to work on Darwin ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 9a167a: coq_8_6: Use ocamlPackages, rather than a specific...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 9a167a35ff87606f18580780d6b6e2ce3ddd3fcc https://github.com/NixOS/nixpkgs/commit/9a167a35ff87606f18580780d6b6e2ce3ddd3fcc Author: John Wiegley Date: 2016-12-22 (Thu, 22 Dec 2016) Changed paths: M pkgs/top-level/all-packages.nix Log Message: --- coq_8_6: Use ocamlPackages, rather than a specific version Commit: 3876b4dd94f1803652a4a76592ad519b4da4ddd8 https://github.com/NixOS/nixpkgs/commit/3876b4dd94f1803652a4a76592ad519b4da4ddd8 Author: John Wiegley Date: 2016-12-22 (Thu, 22 Dec 2016) Changed paths: M pkgs/top-level/all-packages.nix Log Message: --- coq, coqPackages: Roll default back to 8.4, until ssreflect is building Compare: https://github.com/NixOS/nixpkgs/compare/94fbbb2ed648...3876b4dd94f1___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] f06284: coq_8_6: Use ocamlPackages_4_03 rather than 4_01
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: f06284b0dc28eb7c1a27c57e97bf087ab224a8e7 https://github.com/NixOS/nixpkgs/commit/f06284b0dc28eb7c1a27c57e97bf087ab224a8e7 Author: John Wiegley Date: 2016-12-22 (Thu, 22 Dec 2016) Changed paths: M pkgs/top-level/all-packages.nix Log Message: --- coq_8_6: Use ocamlPackages_4_03 rather than 4_01 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 4888bf: coq_8_6: 8.6 is now default, 8.4 optional, updated...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 4888bfecc28c0b74a18351a08cce5618c5b54868 https://github.com/NixOS/nixpkgs/commit/4888bfecc28c0b74a18351a08cce5618c5b54868 Author: John Wiegley Date: 2016-12-22 (Thu, 22 Dec 2016) Changed paths: A pkgs/applications/science/logic/coq/8.4.nix R pkgs/applications/science/logic/coq/default.nix M pkgs/development/coq-modules/mathcomp/default.nix M pkgs/development/coq-modules/mathcomp/generic.nix M pkgs/development/coq-modules/ssreflect/default.nix M pkgs/development/coq-modules/ssreflect/generic.nix M pkgs/top-level/all-packages.nix Log Message: --- coq_8_6: 8.6 is now default, 8.4 optional, updated mathcomp/ssreflect Addresses #14829 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 838a3b: coq_8_6: 8.6rc1 -> 8.6
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 838a3b4294aa475f686a1d748b8979fca3a8becb https://github.com/NixOS/nixpkgs/commit/838a3b4294aa475f686a1d748b8979fca3a8becb Author: John Wiegley Date: 2016-12-14 (Wed, 14 Dec 2016) Changed paths: M pkgs/applications/science/logic/coq/8.6.nix Log Message: --- coq_8_6: 8.6rc1 -> 8.6 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 629340: coq_HEAD: Update to the latest commit as of 2016-1...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 62934023c3ece9c6339816dd0d8e7cfe0995e0a9 https://github.com/NixOS/nixpkgs/commit/62934023c3ece9c6339816dd0d8e7cfe0995e0a9 Author: John Wiegley Date: 2016-12-13 (Tue, 13 Dec 2016) Changed paths: M pkgs/applications/science/logic/coq/HEAD.nix Log Message: --- coq_HEAD: Update to the latest commit as of 2016-12-13 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 360234: coq_8_6: new package, based on Coq 8.6rc1
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 360234dab6b22d9f05821369a43c10b5faea3b79 https://github.com/NixOS/nixpkgs/commit/360234dab6b22d9f05821369a43c10b5faea3b79 Author: John Wiegley Date: 2016-12-13 (Tue, 13 Dec 2016) Changed paths: A pkgs/applications/science/logic/coq/8.6.nix M pkgs/top-level/all-packages.nix Log Message: --- coq_8_6: new package, based on Coq 8.6rc1 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 113986: gnupg21: Add -lintl on Darwin systems
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 113986f07a9786a58caeb232491463a4870dcf0c https://github.com/NixOS/nixpkgs/commit/113986f07a9786a58caeb232491463a4870dcf0c Author: John Wiegley Date: 2016-11-22 (Tue, 22 Nov 2016) Changed paths: M pkgs/tools/security/gnupg/21.nix Log Message: --- gnupg21: Add -lintl on Darwin systems ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 98092d: gnupg21: 2.1.15 -> 2.1.16
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 98092df84163faf5ff8c089f3e2a27f4cbcd7bce https://github.com/NixOS/nixpkgs/commit/98092df84163faf5ff8c089f3e2a27f4cbcd7bce Author: Lancelot SIX Date: 2016-11-19 (Sat, 19 Nov 2016) Changed paths: M pkgs/tools/security/gnupg/21.nix Log Message: --- gnupg21: 2.1.15 -> 2.1.16 Commit: e8d86ee7b4b94f4eb9e1685d3a8659d3a932ea77 https://github.com/NixOS/nixpkgs/commit/e8d86ee7b4b94f4eb9e1685d3a8659d3a932ea77 Author: John Wiegley Date: 2016-11-21 (Mon, 21 Nov 2016) Changed paths: M pkgs/tools/security/gnupg/21.nix Log Message: --- Merge pull request #20538 from lsix/update_gnupg21 gnupg21: 2.1.15 -> 2.1.16 Compare: https://github.com/NixOS/nixpkgs/compare/18316620735c...e8d86ee7b4b9___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] c4d2d5: emacs: Missed a pluralization...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: c4d2d56f22ea4ada899cd26141b774112b6bfdf7 https://github.com/NixOS/nixpkgs/commit/c4d2d56f22ea4ada899cd26141b774112b6bfdf7 Author: John Wiegley Date: 2016-11-16 (Wed, 16 Nov 2016) Changed paths: M pkgs/applications/editors/emacs/default.nix Log Message: --- emacs: Missed a pluralization... ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 0bf515: emacs: Depend on libselinux only for Linux
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 0bf515c97311a12251d1a33788d31c86cd338e96 https://github.com/NixOS/nixpkgs/commit/0bf515c97311a12251d1a33788d31c86cd338e96 Author: John Wiegley Date: 2016-11-16 (Wed, 16 Nov 2016) Changed paths: M pkgs/applications/editors/emacs/default.nix Log Message: --- emacs: Depend on libselinux only for Linux ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] aa2330: Add a patch for cctools to work with Xcode 8
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: aa23309a39794cd769d473cc8616dc96b872e3f0 https://github.com/NixOS/nixpkgs/commit/aa23309a39794cd769d473cc8616dc96b872e3f0 Author: John Wiegley Date: 2016-11-14 (Mon, 14 Nov 2016) Changed paths: A pkgs/os-specific/darwin/cctools/ld-tbd-v2.patch M pkgs/os-specific/darwin/cctools/port.nix Log Message: --- Add a patch for cctools to work with Xcode 8 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] da68cc: coq: 8.5pl2 -> 8.5pl3
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: da68cc24f087176c576cb7ff0e05faeb4ea7672f https://github.com/NixOS/nixpkgs/commit/da68cc24f087176c576cb7ff0e05faeb4ea7672f Author: Vincent Laporte Date: 2016-11-02 (Wed, 02 Nov 2016) Changed paths: M pkgs/applications/science/logic/coq/8.5.nix Log Message: --- coq: 8.5pl2 -> 8.5pl3 Commit: b840da02cd91a67010826a9f375a02d71eaa7254 https://github.com/NixOS/nixpkgs/commit/b840da02cd91a67010826a9f375a02d71eaa7254 Author: Vincent Laporte Date: 2016-11-02 (Wed, 02 Nov 2016) Changed paths: M pkgs/applications/science/logic/coq/8.5.nix Log Message: --- coq: build and install the votour utility Commit: 7c53518663658db36218fa8f5566442d3f71da99 https://github.com/NixOS/nixpkgs/commit/7c53518663658db36218fa8f5566442d3f71da99 Author: Vincent Laporte Date: 2016-11-02 (Wed, 02 Nov 2016) Changed paths: M pkgs/development/compilers/compcert/default.nix Log Message: --- compcert: patch to build with Coq-8.5pl3 Commit: 5f49eeb935112e69f8992083ca173728a90cbf8c https://github.com/NixOS/nixpkgs/commit/5f49eeb935112e69f8992083ca173728a90cbf8c Author: Vincent Laporte Date: 2016-11-02 (Wed, 02 Nov 2016) Changed paths: M pkgs/top-level/all-packages.nix M pkgs/top-level/ocaml-packages.nix Log Message: --- coq: move out of ocamlPackages Commit: b028b5f4ef03d6c3dae4cdda898c1996348c4e18 https://github.com/NixOS/nixpkgs/commit/b028b5f4ef03d6c3dae4cdda898c1996348c4e18 Author: Vincent Laporte Date: 2016-11-02 (Wed, 02 Nov 2016) Changed paths: M pkgs/applications/science/logic/coq/8.5.nix Log Message: --- coq-8.5: ease the selection of an older (patch level) version Commit: 4008300243c3b8e3a24202feb0057b70f1139ac6 https://github.com/NixOS/nixpkgs/commit/4008300243c3b8e3a24202feb0057b70f1139ac6 Author: John Wiegley Date: 2016-11-03 (Thu, 03 Nov 2016) Changed paths: M pkgs/applications/science/logic/coq/8.5.nix M pkgs/development/compilers/compcert/default.nix M pkgs/top-level/all-packages.nix M pkgs/top-level/ocaml-packages.nix Log Message: --- Merge pull request #20025 from vbgl/coq-8.5pl3 Coq: 8.5pl2 -> 8.5pl3 Compare: https://github.com/NixOS/nixpkgs/compare/b137b8d1aa14...4008300243c3___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] f33fbe: Added support to for OS X to the Electron package.
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: f33fbe5e8258ea2caf89acf762e059ddbb76a892 https://github.com/NixOS/nixpkgs/commit/f33fbe5e8258ea2caf89acf762e059ddbb76a892 Author: Tikhon Jelvis Date: 2016-10-19 (Wed, 19 Oct 2016) Changed paths: M pkgs/development/tools/electron/default.nix Log Message: --- Added support to for OS X to the Electron package. For OS X: 1. I download and extract Electron.app 2. put it in `$out/Applications` 3. link the binary to `$out/bin/electron` Commit: ecbb932957a92212423eb4fa3ea29ae0ba272ef6 https://github.com/NixOS/nixpkgs/commit/ecbb932957a92212423eb4fa3ea29ae0ba272ef6 Author: John Wiegley Date: 2016-10-31 (Mon, 31 Oct 2016) Changed paths: M pkgs/development/tools/electron/default.nix Log Message: --- Merge pull request #19696 from TikhonJelvis/electron-osx Electron: Added support for OS X. Compare: https://github.com/NixOS/nixpkgs/compare/8f680da009c6...ecbb932957a9___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] a12f3d: coqPackages.fiat_HEAD: New package for Coq 8.4pl6 ...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: a12f3d232d5bc99913537e44c25ee16afba628a0 https://github.com/NixOS/nixpkgs/commit/a12f3d232d5bc99913537e44c25ee16afba628a0 Author: John Wiegley Date: 2016-10-31 (Mon, 31 Oct 2016) Changed paths: A pkgs/development/coq-modules/fiat/HEAD.nix M pkgs/top-level/all-packages.nix Log Message: --- coqPackages.fiat_HEAD: New package for Coq 8.4pl6 and 8.5pl2 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] c60b3e: haskellPackages.hakyll: Fix the Darwin build (brok...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: c60b3e4bfc94c567db5d68eaaf6c8c1bbb9d43ee https://github.com/NixOS/nixpkgs/commit/c60b3e4bfc94c567db5d68eaaf6c8c1bbb9d43ee Author: John Wiegley Date: 2016-10-27 (Thu, 27 Oct 2016) Changed paths: M pkgs/development/haskell-modules/configuration-common.nix Log Message: --- haskellPackages.hakyll: Fix the Darwin build (broken tests) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 8a60eb: jhc: Use the cc that's in scope when building
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 8a60ebb81634da9b0e96d84f338236c9832b91cc https://github.com/NixOS/nixpkgs/commit/8a60ebb81634da9b0e96d84f338236c9832b91cc Author: John Wiegley Date: 2016-10-24 (Mon, 24 Oct 2016) Changed paths: M pkgs/development/compilers/jhc/default.nix Log Message: --- jhc: Use the cc that's in scope when building ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Nix - building only some libraries with profiling
> Carlo Nucera writes:
> Hi, I'd like to fine tune my haskell setup with Nix.
> I need to transitively compile a package I'm working on with profiling. For
> the
> time being, I'm compiling all my haskell libraries with libraries enabled,
> with
> the lines:
> overrides = self: super: {
> mkDerivation = drv: super.mkDerivation (drv //
> {enableLibraryProfiling = true;});
> as you can see in this gist:
> https://gist.github.com/meditans/82ded9101c55eb5884d7
> Obviously, this way of doing things is suboptimal, so how can I modify this
> file to transitively build with profiling only a few libraries?
You should be able to enable profiling in the default.nix for your project,
and it will build only the dependencies necessary to honor that.
John
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Using hdevtools in haskellng infrastructure
> Dmitry Malikov writes: > There is a comment at the page added by Goibhniu at February 28th saying > "Warning: this is outdated. It is recommended to use nix-shell instead of > myEnvFun". And this comment seems to be very legit, because in this new > infrastructure hdevtools doesn't see any installed modules any more. > How to use hdevtools in haskellng infrastructure? I'm wondering this too, since it also broke from me since I switched. In the meantime I'm just using GHC itself as a syntax checker, but I'd like to see some docs on the new accepted workflow. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Switch to GHC 7.10.1 is imminent
> Aycan iRiCAN writes: > I am -1 on this. Since some of the packages which I depend doesn't compile > with ghc 7.10 yet, they need upstream fixes (hans, http-streams, > rank1dynamic, jmacro and a few more). Could you please suspend the merge for > one more week? OTOH, I can still use haskell-ng.packages.ghc784 if nobody > supports my idea. Since 'master' is the branch for development, I'm +1 on this even though it will be disruptive for a while, because it's not going into any release channels. I realize some of us actually use 'master' as our distribution channel, but the Nix project shouldn't be impeded by that use. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Let's switch the default shell in Nixpks / NixOS to sch
>>>>> John Wiegley writes: >>>>> Peter Simons writes: >> This makes me wonder whether maybe we should switch all shell scripting in >> Nixpkgs to "csh"? Wouldn't that solve a lot of problems? I've heard experts >> say that "csh" is generally considered superior for scripting tasks because >> of its more intuitive syntax. > I really dislike csh's syntax, and that of tcsh, and having to learn it in > order to write scripts for Nix would be undesirable to say the least. Wait, I just remembered the date. :) John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Let's switch the default shell in Nixpks / NixOS to csh
> Peter Simons writes: > This makes me wonder whether maybe we should switch all shell scripting in > Nixpkgs to "csh"? Wouldn't that solve a lot of problems? I've heard experts > say that "csh" is generally considered superior for scripting tasks because > of its more intuitive syntax. I really dislike csh's syntax, and that of tcsh, and having to learn it in order to write scripts for Nix would be undesirable to say the least. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Please test Nix store auto-optimise
> Vladimír Čunát writes: > Oh, I thought each set of hardlinked files share the single i-node. Is it > not so? Ah, for some reason I thought something else was involved. If that's the case, then being the default is actually fine with me, provided it cures the slowness of times past. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
> Peter Simons writes: > nix-shell "" -A haskell-ng.packages.ghc763.popuplar-package > Is that what you meant? Yep, exactly that, thanks. Here's hoping it work for unpopular packages too. ;) John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
> Peter Simons writes: >> How do I run a nix-shell with a specific version of ghc installed? > $ nix-shell -p haskell-ng.compiler.ghc763 How about starting a shell for a particular package, but having it use ghc763 rather than the default? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Please test Nix store auto-optimise
> Wout Mertens writes: > I feel this optimisation should be turned on by default but there were some > regressions in the past which is why it wasn't. Therefore I'd like to ask > you to turn on auto-optimise and run optimisation once. Your disk space and > memory footprint will thank you. I disagree. The reason why I don't like this optimization is that it doubles i-node consumption on my main volume, for relatively little benefit. This slows down things like rsync-based backup considerably, for example. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell: indexing all packages on Hackage with Hoogle
> Nikita Karetnikov writes: > Has anyone tried that? Most of the guides suggest you to run the following > command, which should download the necessary databases, but it fails for me. Just for what it's worth, I have in the past indexed everything, but it causes far too much noise in the search output. This is why the hoogle-local expression takes the approach of asking for a list of 'packages' to indicate what should be indexed. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
> Daniel Bergey writes: > Looks like maybe you entered a shell with the dependencies for hspec, rather > than for gitlib-libgit2? At any rate, this works for me: Awesome, thanks so much Daniel! John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
> Peter Simons writes: > 2) For recent Hackage packages, you can do that without using cabal2nix, > even, > by running: > $ nix-shell '' -A haskellngPackages.hspec.env I think I'm missing some bit of special sauce, because when I run these commands, `./Setup configure reports that several of the dependencies are missing: --8<---cut here---start->8--- ghc784:[johnw@Vulcan:~/src/gitlib/gitlib-libgit2]$ nix-shell '' -A haskellngPackages.hspec.env \[\][nix-shell:~/src/gitlib/gitlib-libgit2]$\[\] ./Setup configure Configuring gitlib-libgit2-3.1.0.2... Setup: At least the following dependencies are missing: gitlib >=3.0.0, hlibgit2 >=0.18.0.11, missing-foreign >=0.1.1, monad-control <1.0, monad-logger >=0.3.4.1, stm-conduit >=2.3.0, text-icu >=0.6.3 --8<---cut here---end--->8--- Also, would it be much work to get the hoogleLocal expression working within the NG framework? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Haskell NG] Equivalent of the old eval "$configurePhase" && eval "$buildPhase" && eval "$checkPhase" ?
> Peter Simons writes: > We could also add the "runHook setupCompilerEnvironmentPhase ..." bit to the > "nix-shell" variable in the build environment so that these commands are run > automatically when you enter the interactive environment. Does that sound > useful? It does to me. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
> Michael Raskin <7c6f4...@mail.ru> writes: >> While I don't mind that we expand the number of people with commit access, >> I firmly oppose doing changes directly on master, any change should first >> be a PR. If there're more people who can close a PR, those PRs will be open >> for a shorter amount of time. > Many people come and say that. The sad truth is that we lack the resources > to do development like that. Whatever the benefits of this approach, we > cannot afford the costs. > The low observed rate of PR merges means that we need people who do many > correct small updates to perform them directly on master for the project to > be able to actually accomplish something except the trivial updates. I entirely agree, Michael. As one of the people who commits directly to master, I have to say that if every small change/fix I wanted to make had to go through a PR, I'd contribute much less, simply due to lack of energy. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Supported Darwin versions
> Eelco Dolstra writes: > But with a stdenv that doesn't depend on Xcode, we may be able to lower > MACOSX_DEPLOYMENT_TARGET. How low would you like it to be able to go? What is the Nix project's "official position" on least supported Darwin version? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Supported Darwin versions
Hello, I'm setting up a test bed for the upcoming Darwin patches, which led me to want a solution which can work for as many versions of Darwin as we wish to support. Which leads me to the question: How many versions of Darwin do we wish to support? Here are the results of running "curl https://nixos.org/nix/install | sh" right now on various versions: 10.6 sorry, there is no binary distribution of Nix for your platform 10.7 segmentation fault 10.8 error: the group ‘nixbld’ specified in ‘build-users-group’ does not exist Each VM I'm using is a virgin install + updates + Xcode + CLI tools, nothing else Is 10.9 our lowest target now, or should I open new issues for these last two errors? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Can't get anything to build on Mac OS X
> Michael Sperber writes: > I'll give it a try. What's the difference between these repos? > https://github.com/copumpkin/nixpkgs > https://github.com/joelteon/nixpkgs > Or, alternatively, which one should I use? copumpkin (Dan Peebles) is working on the "next gen" Darwin support, where we build with a totally pure build environment, allowing for reproducible builds across machines of the same OS version. The joelteon (Joel Taylor) branch is what you should be using today, if you are less adventurous. Once we get joelteon's stuff merged into the mainline, attention will shift to copumpkin's branch as the next best thing for Darwin. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Can't get anything to build on Mac OS X
> Michael Sperber writes: > I'm (still) running Mavericks, and just pulled from github. I ran against > these problems: > - A large number of packages have indirect dependencies on Kerberos, which > by default is set to be Heimdal - which is marked broken on Mac OS X. I did > this, which allowed me to proceed: I ran into the heimdal issues yesterday, and created the following issue to document them: https://github.com/NixOS/nixpkgs/issues/5512 Using krb5 didn't work for me, but then I'm on Yosemite. > Or should I just give up here and move to the pure, clang-based branch? We'd welcome your testing. :) John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] use cabal2nix to create local nix environment for packages that aren't in nixpkgs
> cdep illabout@gmail com writes: > I posted the following question on Stackoverflow, but I received no > responses, so I thought this list might be more appropriate. Btw, I've been using the following two scripts to great success in my local haskell work: nix-cabal-build Description: Binary data nix-cabal-shell Description: Binary data They will each create the necessary files if they are missing, and then do what you expect to be done. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get ghc-mod to work with nix-shell
> Paul Koerbitz writes: > I want the ghc-mod process to pick up the 'default.nix' file which is > sitting in my projects directory. When I do run 'nix-shell --pure --command > ghc-modi' things work fine. However, the ghc-mod process started from emacs > runs in the global environment and doesn't have the right dependencies. > How do people solve this issue usually? I run Emacs from within the nix-shell environment. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gcc has stopped working on Mac OS X Mavericks
> Alfredo Di Napoli writes: > On the silver lining, nix-1.7 works out of the box on Yosemite :) How is that possible? What are you doing to make it work? There's a major effort underway right now by Joel Taylor and Dan Peebles to get a stdenv working for Yosemite... John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gcc has stopped working on Mac OS X Mavericks
> Michael Sperber writes: > That setting didn't take for me. But your hint made me set SDKROOT in > pkgs/stdenv/nix/default.nix directly, and that did the trick. I had to set this: export SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gcc has stopped working on Mac OS X Mavericks
> Michael Sperber writes: > export SDKROOT=macosx10.9 > Unfortunately, it seems --pure (and nix-env generally) then *unsets* that > environment variable again. Any way I can make Nix have its stick around? I hand-edited pkgs/stdenv/nix/default.nix to have this line in it: export MACOSX_DEPLOYMENT_TARGET=10.9 The SDKROOT is then set from this. Maybe that would help, assuming you have your own nixpkgs clone? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gcc has stopped working on Mac OS X Mavericks
> Michael Sperber writes: > Also, maybe I misunderstood you - what do you mean by "reference"? It seems > the reference is in gcc itself - the C file I'm compiling is trivial: > [nix-shell:~/]$ gcc ~/temp/x.c > ld: file not found: /usr/lib/system/libsystem_coreservices.dylib for > architecture x86_64 > collect2: error: ld returned 1 exit status > [nix-shell:~/]$ which gcc > /nix/store/65yrkjclp6g71j9x16vcglqdw62xbnx7-gcc-wrapper-4.8.3/bin/gcc By reference I mean the dynamic library reference in the gcc executable. I would *think* that this would be solved by rebuilding gcc from sources: rm -fr /nix/store/65yrkjclp6g71j9x16vcglqdw62xbnx7-gcc-wrapper-4.8.3/ nix-env --option build-use-substitutes false -i gcc-wrapper-4.8.3 The problem, if I'm guessing correctly, is that the Hydra build server is referencing a dylib that doesn't exist for you on your system -- a problem which has cropped up a few times in the past. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gcc has stopped working on Mac OS X Mavericks
> Michael Sperber writes: > \[\][nix-shell:~/temp]$\[\] gcc x.c > ld: file not found: /usr/lib/system/libsystem_coreservices.dylib for > architecture x86_64 > collect2: error: ld returned 1 exit status > I'm stumped with this. Just to be sure, I built gccApple from source, but > the problem persists. Has anyone seen this? We haven't used gccApple in several weeks now. It sounds like a system update moving a binary which something in your Nix store depended on. You should try to track down who in your store has that reference, and then rebuild that derivation. In future we are moving toward "pure" Darwin builds, where the Nix store will not rely on anything outside that is not absolutely necessary. This will help to mitigate breakages from system updates. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Our policy for upgrading haskellPackages
> Peter Simons writes: >> Sometimes they get marked as "broken" and left broken for longer than I'd >> like. > That is to be expected, I'm afraid. When I know how to fix a build, I'll > commit the fix. I commit "meta.broken = true" only if I cannot fix it. I'd > guess others do it the same way. So if a package is marked "broken", you > should probably not expect someone else to fix it. I build with allowBroken here now, and try to build a lot of packages nightly, so for my part I'll get more proactive about marking things as unbroken that I'm able to build. > I'll try to make life easier for you by communicating better before I push > intrusive changes. I think in this case I over-reacted, Peter. You're doing a heroic job with little thanks, and all I want to do is ease your path. Keep on doing what you have been doing, and I'll take it as my responsibility to pick up the pieces moreso than I have been doing. Also, is there some way I can be notified about *all* Hydra breakages of Haskell packages, without listing myself as maintainer on all of them? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Our policy for upgrading haskellPackages
> Peter Simons writes: > The recent update to random 1.x, Yesod 1.4, and network 2.6.x was one of the > most disruptive updates we've ever done, and it broke 32 packages out of a > total of 1776 -- less than 2% -- and many of those broken packages are > somewhat obscure ones, really. From point of view, it feels unfair say that > "the degree of breakage in haskellPackages is too much to handle". There are > many ways to deal with the situation. You can ... > - help to fix the builds, > - revoke the offending updates locally, or > - run "nix-env --set-flag keep true ..." on broken packages to keep the >stable version around. I think a lot of what I'm noticing is that packages I care about and rely on fall within those 2%, and sometimes they get marked as "broken" and left broken for longer than I'd like. But if the degree of impact is really that small, and if several of the breakages I'm seeing only affect darwin, then I'll just keep doing what I have been doing, and fix the breakages as they come up. Thanks, John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Our policy for upgrading haskellPackages
This message is a follow-on to a discuss Peter and I were having on GitHub, since I believe it is of more general interest: >> Peter Simons writes: > Generally speaking, the two goals > > 1. have recent versions of all major Haskell packages and > 2. all Haskell packages should compile > > are contradictory. The 2.6.x version of network has been out there since Tue > Sep 2 18:14:36 UTC 2014, i.e. for more than 1,5 months. Since 2.5.x and > 2.6.x have incompatible APIs, many package authors don't bother supporting > the old version: they update their packages to compile against 2.6.x and > never look back. Now, in that situation, we must switch to 2.6.x eventually, > because network 2.5.x cannot compile many available updates. At the same > time, the switch to 2.6.x breaks the packages of all those people who didn't > update their libraries. > > So what are we supposed to do? Forgo the available updates to keep a stable > system or update at the cost of breaking packages that are sort-of > unmaintained? > > I try to keep as many packages building as possible, and getting those ~200 > updates into master was a major effort for me, i.e. I worked on those > commits several hours per day for the better part of a week. Even with all > that effort spent, however, I cannot remedy the fundamental conflict of > interest between a system that's up-to-date and a system that's stable. At > some point, I just push whatever I have come up with and I rely on other > people, like yourself, to help finding the best balance between those two > contradictory goals. Hi Peter, First, let me state how much I appreciate the contribution you're making to nixpkgs. Its support of Haskell is superb, and that is in large part due to your time and effort. My hope is to support you as best I can, and not to criticize your efforts in any way. You are exactly right that we have a tension between those two goals. I can think of two things that might be done to remedy this, and perhaps make updates to master more smooth: 1. We keep a dedicated branch, "haskell-updates", to which only your Hackage updates get pushed, or fixes to those updates. I will personally pull and rebuild this branch every day on my machine, just as I presently rebuild master nearly every day -- compiling more than 2,000 packages that I keep locally updated through --leq. I (and hopefully others) will help to discover which packages can be fixed by inserting references to older packages, which requires patches, and which must truly be marked as "broken" until the maintainer of that package can be contacted. Further, I'll help you to maintain a list of outstanding "broken" packages, and see what can be done to make sure this list decreases over time. 2. The second option is to create a new haskellPackages set, called 'stackage'. The Stackage maintainers already do a lot of the work implied by #1, ensuring that every package within the Stackage set can build together. Further, they only upgrade a package once they've either created a patch, or worked with upstream to update the package. Of course, the downside to this is: - less frequent updates of packages - a smaller available package set - life-draining maintenance of a mostly parallel package set The upside being that all patching/curating work is done for us, likely for as long as FP Complete keeps funding people to maintain Stackage. Most of the time I can resolve breakages that occur on master, and I'm getting up to speed with pushing the right fixes back to you via cabal2nix. However, I still rely on 'master' to be working overall on a daily basis, and sometimes the degree of breakage in haskellPackages is too much to handle all at once, forcing me to stop tracking 'master' -- which then delays my involvement in getting those breakages fixed. I think if we had a separate channel for haskell updates, and that if you and I both worked together to get that channel ready for inclusion into master, we could make this upgrade effort smoother for everyone involved, and hopefully less stressful for you in particular. The only important part, then, is that we be sure this branch gets on Hydra, as another check of suitability. It would also be really nice to see you on IRC more, for asking question about upgrade decisions more quickly than through GitHub. But I understand if that's not possible. Yours, John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Mac build machine upgraded
> Eelco Dolstra writes: > FYI: The Mac machine in the hydra.nixos.org build farm has been upgraded to > OS X > 10.9.5 (was 10.6.x). Xcode has been upgraded to 6.0.1. And there was much rejoicing!!! John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS "small" channel
>>>>> John Wiegley writes: > Here's what the machine was trying to do when nixos-rebuild got "hung": > https://gist.github.com/e2e69a41a2dfea23ebc3 Just FYI: I left it running all night long, and it did at some point complete normally, so I guess whatever it was trying to do was just slow. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS "small" channel
>>>>> John Wiegley writes: > Do you have any recommendations for debugging? Here's what the machine was trying to do when nixos-rebuild got "hung": https://gist.github.com/e2e69a41a2dfea23ebc3 John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS "small" channel
> Eelco Dolstra writes: > To switch an existing system to this channel: > $ nix-channel --add https://nixos.org/channels/nixos-14.04-small nixos > $ nixos-rebuild switch --upgrade Hi Eelco, I followed these steps, but after building many things it appears to be hung with "nix-daemon" pegging CPU at 100%, and nothing else happening on the system except for about 8 zombie bash processes. The nixos-rebuild never completed. Do you have any recommendations for debugging? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS "small" channel
> Eelco Dolstra writes: > Since last week there is a new NixOS channel: > https://nixos.org/channels/nixos-14.04-small > This is a variant of the regular NixOS 14.04 channel mainly intended for > servers that need fast security updates. It differs from the regular 14.04 > channel in the following ways: > * It builds way, way fewer packages. In particular, there is no desktop > stuff, and no gazillion Python/Perl/Haskel/... packages. > * It has fewer release-critical tests. For instance, it doesn't require any > of the X11 tests to succeed. > * It only builds x86_64 binaries. This is great, Eelco! Just want I wanted for my file server at home, which fits exactly into this use case. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Zero Hydra Failures (ZHF) project for NixOS
> Domen Kožar writes: > http://hydra.nixos.org/build/14709824 Ok, then nix-prefetch-git is simply broken. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Zero Hydra Failures (ZHF) project for NixOS
> Domen Kožar writes: > - ledger: wrong hash Which ledger? I just updated yesterday. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] RFC: three dying pull requests (let's keep them alive)
> Shea Levy writes: > Recursive nix is unused because it was unfinished and it was too much > potential work to keep going without some sign it would be merged. Then I vote for a review of recursive nix, and to merge in the other two as they stand. Can you help me understand recursive nix a bit more? I'm willing to dig into it with some intro. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] RFC: three dying pull requests (let's keep them alive)
> Daniel Peebles writes: > I've noticed a bit of a pattern recently on the nix github and wanted to try > to stop it before Shea Levy decided this sort of work wasn't worth his time > anymore. I'm not proposing that we insta-merge all his changes, but can > anyone interested at least chime in with feedback so that these pull > requests don't die on the vine? I heartily agree. Shae, would you be willing to create an experimental-shlevy branch that contains these three changes merged against current master? Then perhaps Joel, Daniel and I can switch to using it for couple weeks, and if everything looks good and remains working, we simply merge it to master. Sadly, I'm not qualified yet to judge the merits of these changes -- although they sound like something I might want in future -- so I say we bring them in solely based on all the work you've done, and because you think they will improve Nix as a platform. I'm willing to trust your judgment in lieu of having time to work through them in detail. That is, of course, unless Eelco or others think they lack technical merit. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix users going to Haskell Hackathon in Berlin?
> Daniel Bergey writes: > I'm planning to be in Boston. Great! hnix is what I plan on focusing on in Boston, if you want to join me. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix users going to Haskell Hackathon in Berlin?
> Peter Simons writes: > does anyone else intend to visit the Berlin Haskell Hackathon? How about the one in Boston in two weeks? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Writing a Nix evaluator in Haskell
> Peter Simons writes: > At some point, however, I felt like Parsec became a bit of a burden, i.e. > adding features like full support for antiquotation ceased to be fun. :-) Interesting. I'll work on this next, so that I know whether the path I've chosen is viable or not. > Anyway, the code is online again. I hope it's useful in one way or another! I've downloaded it and will look it over for reference. Thanks! John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Writing a Nix evaluator in Haskell
> Steven Shaw writes: > "modeled very simply as a > loeb function over memoized IO actions" > > John, that might be simple for you :). Would you say a few words to > demystify for the rest of us? Well, for me at least :$. So, after trying to implement this idea, I discovered that loeb is too one-dimensional for this to work. But in case it helps, below is the blog post I was going to upload about it. Now I'll have to modify it to remove the parts about Nix. John --- title: Demystifying the loeb function description: desc here tags: haskell date: [2014-06-18 Wed 21:07] category: Haskell --- Recently I was reading some articles by Chris Done, Dan Piponi and others about a mysterious, yet curiously useful function: the `loeb` function: ``` haskell loeb :: Functor f => f (f a -> a) -> f a ``` The type of this function models a logical proposition by ___ Loeb, which states ___. Most explanations of one use of function involves an analogy about spreadsheets, but this never clicked for me, until I realized that something else I use often is actually a loeb function in disguise. So I wanted to share my alternate insight, in case it might offer clarify for others. But first, the loeb function can be stated plainly as: Given a list of functor algebras (i.e., evaluators), produce a list of pending evaluations. These pending evaluations, when forced, take that same list of pending evaulations as input, and evaluate recursively until a result is produced. There are some immediate consequences of this: 1. Self-referencing elements (unless they are themselves lazy) will result in non-termination. 2. If any evaluation terminates, the total set of evaluations performed will describe a directed, acyclic graph. 3. Only those elements required to satisfy the evaulation of the requested element (and so on, recursively) are evaluated. The place where I encounter this every day is when I use the Nix package manager. Consider: Nix is a purely functional language that defines a system's package set as a mapping of names to values, which describe each package. Those values are lazy (that is, left unevaluated until forced), and many of them are functions which take as input that same, entire package set. When you ask to install a package, Nix needs to know is what build actions to perform, so it forces evaluation of the package's function to determine the source URL, build scripts, etc. That package almost always has dependencies, which themselves are defined by attributes in that same, global package set. Since these may need to be installed too, Nix forces their evaluation and performs the same install step, recursively, until it works it way through the dependency graph, and finally is able to install the top-level dependencies that you initially asked for. This process of dependency resolution: by evaluating lazy, pure functions from a list of "pending evaluations" that each take as input the entire list, is precisely the loeb function. Another thing I've noticed about the loeb function is that unless self-references are themselves lazy, the only interesting functors for loeb to act on are those in which the type mapped by the Functor occurs more than once, as with lists. This means that for `Identity`, `Maybe`, the tuple functor, `Reader`, `State`, etc., there is really not much interesting that `loeb` can do. For example: ``` haskell main = print $ take 10 $ runIdentity $ loeb (Identity ((1 :) . runIdentity)) ``` This is just a fancy way of writing the `cycle` function. The innermost function, when evaluated, is passed an `Identity` value that contains itself, so all it can do is lazily build some value that ties the knot. You would think functions might provide an interesting `loeb`: ``` haskell f_loeb :: (e -> (e -> a) -> a) -> e -> a f_loeb f x = f x g where g y = f y g ``` But this is just `fix . flip`: ``` >>> :t fix . flip fix . flip :: (a -> (a -> c) -> c) -> a -> c ``` What if we move to `Comonad`? ``` haskell w_loeb :: Comonad w => w (w a -> a) -> w a w_loeb w = fix (flip extend w . flip extract) ``` This seems to be not much more useful than plain loeb, except that now we're forced to use something which "contains" at least a single evaluator: ``` haskell import Control.Comonad import Data.List.NonEmpty as NE w_loeb ( (\xs -> NE.length xs) :| [ (\xs -> xs NE.!! 0) , (\xs -> xs NE.!! 1 + 3) ] ) -- prints: 3 :| [3,6] ``` ## An ordering-independent parser Another way that loeb could be used is to parse a language syntax where declarations are ordering independent, such as Haskell. Instead of parsing each construct into its AST, parse the definitions into pending AST reductions, and then use loeb to reduce it to ASTs. This will give you "graph reduction" on the declarations such that they occur in naturally sorted order if possible. ___ nix-dev mailing list nix-dev@l
Re: [Nix-dev] Writing a Nix evaluator in Haskell
> Marc Weber writes: > AFAIK Peter Simons has written a parser previously, too. Maybe search in the > mailinglist archives to join efforts Ah, very interesting! But his repository is not longer extant. Peter, did it move to someplace else? I would love to combine efforts and compare notes. I don't handle any of the operators yet, and my next is going to be to really clean up the structure of the code and writing out some documentation showing the BNF, to encourage contributors to join in. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Writing a Nix evaluator in Haskell
Since the Nix language is such a nice and simple pure functional language, I thought it would be nice to have tooling support for it in Haskell, to aid writing lint utilities, etc. As such, I've started a project call hnix which will implement a parser and evaluator for Nix in Haskell. I have the parser working for simple expressions already (using either Parsec or Trifecta, it works with both). My first goal is a syntax verification and linting tool; after that to see I want to see if I can get an evaluator working for Nix programs. I have a strong feeling that a Nix evaluator can be modeled very simply as a loeb function over memoized IO actions, which is a theory I want to explore in this code. http://github.com/jwiegley/hnix John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell: eval "$checkPhase" fails until nix-shell is re-entered
> Mateusz Kowalczyk writes: > When hacking on Haskell projects with tests, the tests ofter depend on > the project itself: that is, test-suite blocks will have itself in > dependencies. This works fine with cabal and such. However, if I run: Doing "unset GHC_PACKAGE_PATH" should do it. This variable get exported during the buildPhase by the cabal builder, and really should be unset in the postBuild. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Staging branch
> Eelco Dolstra writes: > I've set up a Nixpkgs/NixOS branch named "staging", intended to bunch > changes that cause rebuilds/redownloads of many packages (such as stdenv > changes). The idea is that this branch can be merged into master > periodically (e.g. every few weeks). Thank you, Eelco, this helps my overall workflow considerably. I like to keep up-to-date with master often so I can test/push small changes, but since really testing a change means updating with --leq, a large destabilizing change to stdenv can wipe out my ability to test the small stuff for a day or more. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to install ruby gems?
> Mateusz Kowalczyk writes: > Did you manage to figure anything out? There's a Ruby program that I'd like > to package and use but I have no idea where to even start: I'm definitely > not a Ruby user! Here's what the gemspec file shows in case it's relevant: I think we need a way to do rubyPackages, the way that we have for perl and python. Any Nix+ruby users willing to do that work? John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix on Mavericks currently completely broken
>>>>> John Wiegley writes: > This is just a heads up that if you're on Mavericks running the latest OS X > and compiler, you should not update your nixpkgs repository. There was a > merge yesterday (commit 1b78ca5) which makes several of the core packages > (zlib, gccApple, and more) unable to compile. I've finished pushing the changes needed to get the package set that I use to build on Mavericks. It looks like the new gcc destablized quite a few things, so I'm sure there are other issues lurking. Here's a summary: - gdb_pixbuf: one of the tests now crashes with a bus error, so I switched to using clang to build this derivation - python2.7-gyp: the no-xcode patch that was being used would no longer apply, so I removed it (but will this break the Hydra build machine?) - swig: the swig-ccache tests now fail, so I pass a configure flag to disable the building of swig-ccache - gccApple: needed several new patches to libstdcxx, which is more than a bit troublesome. - ncurses: needed a patch for a bug in clang, though I'm not sure why this crept in just now. - zlib: do not use the new static-libgcc flag, as it doesn't exist on darwin If anyone discovers any other breakages, please let me know here on the list or via GitHub issues. Thanks, John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hdevtools does not find installed modules
> Thomas Strobel writes: > I've got a question for those using Haskell under NixOS. I'm trying to > use hdevtools to check my Haskell source file, but hdevtools does not > find any modules. ghc-pkg does, as does ghc-mod. From what I have read > it might be necessary to set some environment variables. > Can someone maybe give me an example of how to use hdevtools under NixOS? I use both ghc-mod and hdevtools on Nix (under OS X) and they work equally well. You shouldn't have to anything manual, so if you are having to do so, let me know so that we can get it fixed. hdevtools nowadays uses the same kind of wrapper script as ghc-mod in order to setup the correct environment with all packages installed into the environment visible. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Nix on Mavericks currently completely broken
This is just a heads up that if you're on Mavericks running the latest OS X and compiler, you should not update your nixpkgs repository. There was a merge yesterday (commit 1b78ca5) which makes several of the core packages (zlib, gccApple, and more) unable to compile. Hydra passes on these, but I suspect this is due to Hydra being an older environment than what is currently available. I have several tickets and pull requests open to address this, but I am still not out of the woods yet. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Error on creating hoogle database (permission denied)
> Thomas Strobel writes: > I was trying to create a hoogle database with 'hoogle data', but there > is no way to specify where to write the database to. So I get the > following error: > '' > hoogle: > /nix/store/jl9j7s3s69q8l1imr9caxbxfc4cpg2g9-haskell-hoogle-ghc7.6.3-4.2.32/share/hoogle-4.2.32/databases: > createDirectory: permission denied (Read-only file system) > '' Also see the new "hoogle-local" expression, which builds databases for any packages listed in its 'packages' attributes (taking the current HP as a default). John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Recent change to stdenv in 4cb43d2
My apologies to all for changing stdenv everwhere by merging 4cb43d2 without waiting to batch it with other, pending stdenv changes. It was a minimal, correct fix to the way ppl is compiled, but shouldn't have been merged in by itself. If it should be reverted, can someone please do so? I'm flying to Boston today and will be out of contact. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Using Nixpkgs outside of NixOS
> Wout Mertens writes: > I think there is room for improvement for installing and using nixpkgs on > another distribution. > I see two big problems: > 1. installation > 2. environment variables Also: setting up services to run when the system boots. For example, Homebrew tells you how to add a symlinks in ~/Library/LaunchAgents so that PostgreSQL can start when the machine boots (it simply prints the command to the terminal as an informational message). We can do the same thing with Nix, it's just a question of informing the user how. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Using Nixpkgs outside of NixOS
> Wout Mertens writes: > I think there is room for improvement for installing and using nixpkgs on > another distribution. > I see two big problems: > 1. installation > 2. environment variables Also: setting up services to run when the system boots. For example, Homebrew tells you how to add a symlinks in ~/Library/LaunchAgents so that PostgreSQL can start when the machine boots (it simply prints the command to the terminal as an informational message). We can do the same thing with Nix, it's just a question of informing the user how. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] New NixOS module: grsecurity
> Raahul Kumar writes: > Do we still need SElinux with Grsecurity? If we want to harden Nixos, what > is our best bet right now? I'm not sure the two are even compatible. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Move to GHC 7.8.2
> Oliver Charles writes: > At work, we still can't build with GHC 7.8.2 because various dependencies > are still broken. However, that's not really the end of the world - I can > just change our expressions to use haskellPackages_ghc763 rather than > haskellPackages. Just wanted to note that I've been building the Haskell packages I use with the following compilers daily (they often all rebuild after nixpkgs updates, since I use -u --leq): GHC 7.4.2 GHC 7.6.3 GHC 7.6.3-profiling GHC 7.8.2 GHC 7.8.2-profiling So far I've the following not work with 7.8.2 (though things could have changed): Agda cabal2nix hasktags lambdabot threadscope The way I work around this is to simply build those specific tools using 7.6.3, until they are updated to support 7.8.2. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
