This project is mirrored from Pull mirroring updated .
  1. 03 May, 2017 1 commit
  2. 02 May, 2017 3 commits
  3. 01 May, 2017 1 commit
  4. 30 Apr, 2017 4 commits
  5. 28 Apr, 2017 4 commits
  6. 27 Apr, 2017 4 commits
  7. 26 Apr, 2017 2 commits
    • Mikhail Glushenkov's avatar
      Merge pull request #4463 from hvr/pr/issue-4461 · 051eac2b
      Mikhail Glushenkov authored
      Don't consume result in `waitAsyncFetchPackage`
    • Herbert Valerio Riedel's avatar
      Don't consume result in `waitAsyncFetchPackage` · 3b0390e8
      Herbert Valerio Riedel authored
      IOW, treat the result-MVar like an IVar
      The less optimal properties of `readMVar` prior to base-4.7 shouldn't
      be a problem for this use-pattern (I hope).
      A smallish repro-case which triggers the problem is e.g.
            build-depends:       hspec-discover
            build-tool-depends:  hspec-discover:hspec-discover
      as this results in `waitAsyncPackageDownload` (which is a wrapper
      around `waitAsyncFetchPackage`) being invoked twice for `hspec-discover`,
      which results either in a `BlockedIndefinitelyInMVar` or in a
      `BlockedIndefinitelyOnSTM` (depending on `-j`-level).
      This is because our install plans can now use the same tarball for many builds,
      e.g. different components and/or qualified goals, and these all go through the
      download phase so we end up using `waitAsyncFetchPackage` twice on the same
      This should fix #4461
  8. 24 Apr, 2017 3 commits
  9. 23 Apr, 2017 3 commits
  10. 21 Apr, 2017 2 commits
  11. 15 Apr, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Fix CPP in FileLock.hsc · 2701c2ed
      Herbert Valerio Riedel authored
      with this fix, `cabal` can be built with GHC 8.2.1RC via
        cabal new-build -w ghc-8.2.1 exe:cabal \
  12. 12 Apr, 2017 2 commits
  13. 07 Apr, 2017 1 commit
  14. 02 Apr, 2017 1 commit
  15. 01 Apr, 2017 6 commits
    • Duncan Coutts's avatar
      Planning and building phases use the new store functions · b75a1624
      Duncan Coutts authored
      This should mean that concurrent updates to the store are now safe.
      In practice it means working on separate projects at the same time is
      safe, not concurrent builds within the same project.
    • Duncan Coutts's avatar
      Add unit tests for the new store code · 0a3c9623
      Duncan Coutts authored
      Sadly we cannot do proper parallel tests within a single process
      becuase our fancy inter-process file locking code is thrwarted by the
      stricter normal intra-process file locking.
    • Duncan Coutts's avatar
      New module for store handling, with concurrent updates · b05b9ae7
      Duncan Coutts authored
      A new module with utilities for managing the store. This includes a new
      approach for store updates that allows for concurrent updates to the
      store from different processes.
      This relies on the new file locking code. We log a message if we wait
      for a store file lock. This should be a rare occurrence in practice,
      but would help debugging if some other zombie process was holding the
      file lock.
    • Duncan Coutts's avatar
      Create package DBs in building phase not planning phase · 83a42061
      Duncan Coutts authored
      Adjust things so that instead of creating the store package db during
      planning, we instead create them at the beginning of the building phase
      along with the other package dbs we create at that point. That is,
      create it in a write operation rather than in what is morally a read
      Originally we had to do it in the planning phase because we used to read
      the compiler package db to see what was installed, whereas now we just
      use the store dir listing.
      In fact we were already creating some package dbs during the building
      phase, just not all of them, so this cleans things up in that respect.
    • kristenk's avatar
      Replace a use of PSQ with []. · bf551a7d
      kristenk authored
      This change will make it easier to replace PSQ with WeightedPSQ in solver
      GoalChoice nodes.
    • kristenk's avatar
      Refactor solver goal types. · 2245c9d9
      kristenk authored
      This commit should have no effect on behavior.  It splits the OpenGoal type into
      OpenGoal and PotentialGoal.  Both types are only used when building the search
      tree.  While PotentialGoal can represent any dependency or constraint, OpenGoal
      only represents dependencies that introduce goals (solver variables).  Limiting
      OpenGoal to only represent goals simplifies the code.
      This commit also removes OpenGoal and FlaggedDep's 'comp' type variables.  The
      two types had only been used with 'comp' equal to () or Component.  Now
      FlaggedDep always uses Component, and OpenGoal does not need a Component.
  16. 31 Mar, 2017 2 commits