This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 17 Dec, 2013 9 commits
  2. 16 Dec, 2013 1 commit
  3. 15 Dec, 2013 1 commit
  4. 14 Dec, 2013 3 commits
  5. 13 Dec, 2013 1 commit
    • Sergei Trofimovich's avatar
      cabal upload: use ByteString instead of String · dbb5088e
      Sergei Trofimovich authored
      
      
      The difference is seen nicely on Raincat package (9MB tarball):
          $ /usr/bin/time cabal upload --check Raincat-1.1.1.3.tar.gz
          39.92user
          0.38system
          4:02.50elapsed
          16%CPU (0avgtext+0avgdata 1855712maxresident)k
      
      Insane amounts of used RAM (1.8GB) seem to stem from 'String'
      inefficiency especially on 64-bit platforms where overhead is
      about 16 times:
      
       - 97% of CPU time is taken by GC scans (according to +RTS -sstderr)
       - 9MB tarball would take ~150MBs of RAM, 100MB tarball would...
      
      Attempt to pack them into HTTP headers leads to further growth.
      
      The patch only changes underlying structure to ByteString.Lazy.Char8:
          $ /usr/bin/time patched-cabal upload --check Raincat-1.1.1.3.tar.gz
      
          0.25user
          0.16system
          4:28.61elapsed
          0%CPU (0avgtext+0avgdata 66864maxresident)k
      
      In short: 1.8GB -> 66MB RAM reduction + 16% -> 0% CPU usage.
      Reported-by: default avatar"Mikhail S. Pobolovets" <styx.mp@gmail.com>
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      dbb5088e
  6. 09 Dec, 2013 2 commits
  7. 08 Dec, 2013 1 commit
    • barmston's avatar
      Top-level `freeze` command freezes dependency versions · c6138e81
      barmston authored
      Add new top-level `freeze` command, which resolves the dependencies to exact
      versions and writes a `constraints` section to `cabal.config`. This causes
      future builds to use the same fully constrained dependencies.
      
      The command takes a number of options related to resolving dependencies,
      namely, `--solver`, `--max-backjumps`, `reorder-goals` and
      `--shadow-installed-packages`. These are used to create an `InstallPlan` in
      much the same way that `install` does so. The `InstallPlan` is converted to a
      list and all `PlanPackage`s are inspected to determine their exact version.
      These versions are then either written to `cabal.config` or to standard output
      depending on the presence of `--dry-run`.
      
      Limitations in resolving dependencies
      -------------------------------------
      
      In order to keep the initial implementation of this new command simpler, a
      number of options are not yet supported.  There should be no great difficulty
      in supporting the options `--flags`, `--enable-{tests,benchmarks}`,
      `--constraint` and `--preference`.  However, the options concerned with
      compilers may prove more difficult.
      
      Different versions of GHC ship with different library versions, the
      constraints that are written currently include all dependencies, including
      `base`. This prevents the constraints, as written, from being used with
      alternate versions of GHC.
      
      There are three solutions to this problem: 1) have the user edit the
      constraints section, 2) exclude certain packages from the list of constraints,
      3) develop a mechanism for per-arch-os-compiler constraining. As neither (2)
      nor (3) have been developed we default to (1).
      
      The lack of a good story for per-compiler constraints has lead to the options
      `--with-compiler`, `--ghc`, `--uhc` et al, not being supported.
      
      Further limitations:
      --------------------
      
       - The `cabal.config` file is completely overwritten. Just the `constraints`
         section should be overwritten.
      c6138e81
  8. 06 Dec, 2013 6 commits
  9. 05 Dec, 2013 14 commits
  10. 04 Dec, 2013 2 commits