This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 05 Apr, 2016 1 commit
  2. 03 Mar, 2016 1 commit
    • Andres Löh's avatar
      Improve goal reorder heuristics. · 150d6ca9
      Andres Löh authored
      This change primarily does two things:
      
      1. For `--reorder-goals`, we use a dedicated datatype `Degree`
         rather than an `Int` to compute the approximate branching
         degree. We map 0 and 1 to the same value. We then use a
         lazy ordering and a shortcutting minimum function to look
         for the "best" goal.
      
         The motivation here is that we do not want to spend
         unnecessary work. Following any goal that has 0 or 1 as degree
         cannot really be "wrong", so we should not look at any others
         and waste time.
      
         This will still not always make the use of `--reorder-goals`
         better than not using it, but it will reduce the overhead
         introduced by it.
      
      2. We use partitioning rather than sorting for most of the other
         goal reordering heuristics that are active in all situations.
         I think this is slightly more straightforward and also slightly
         more efficient, whether `--reorder-goals` is used or not.
      
      I have run some preliminary performance comparisons and they
      seem to confirm that in both cases separately (with or without
      `--reorder-goals`), these changes are a relative improvement
      over the status quo. I will run additional tests before
      merging this into master.
      150d6ca9
  3. 20 Feb, 2016 1 commit
  4. 17 Dec, 2015 2 commits
  5. 31 Jul, 2015 2 commits
  6. 01 Jun, 2015 2 commits
  7. 31 Mar, 2015 1 commit
    • Edsko de Vries's avatar
      Fine-grained dependencies in solver input · a5a823d4
      Edsko de Vries authored
      The modular solver has its own representation for a package (PInfo). In this
      commit we modify PInfo to keep track of the different kinds of dependencies.
      
      This is a bit intricate because the solver also regards top-level goals as
      dependencies, but of course those dependencies are not part of any 'component'
      as such, unlike "real" dependencies. We model this by adding a type parameter
      to FlaggedDeps and go which indicates whether or not we have component
      information; crucially, underneath flag choices we _always_ have component
      information available.
      
      Consequently, the modular solver itself will not make use of the ComponentDeps
      datatype (but only using the Component type, classifying components); we will
      use ComponentDeps when we translate out of the results from the modular solver
      into cabal-install's main datatypes.
      
      We don't yet _return_ fine-grained dependencies from the solver; this will be
      the subject of the next commit.
      a5a823d4
  8. 27 Mar, 2015 3 commits
  9. 07 Jun, 2014 1 commit
  10. 23 May, 2014 1 commit
    • Andres Löh's avatar
      Configurable strong/weak flags. · f950e8d7
      Andres Löh authored and tibbe's avatar tibbe committed
      This adds a mechanism in the modular solver to store whether a flag
      is "strong" or "weak". A weak flag is deferred during solving, a strong
      flag is not.
      
      By default, flags are now weak unless they're manual. This is a change
      in behaviour, but I think it's probably the better default, because many
      automatic flags are used to figure out what's on the system rather than
      to impose hard constraints.
      
      There's a new flag --strong-flags that restores the old behaviour. I do
      not think such a global flag is particularly useful, but it may be
      of interest to compare build plans between the new and old behaviour.
      
      With these preparations, it's easy to make the distinction between
      strong and weak flags more sophisticated. We can either add more
      heuristics as to when flags should be treated as strong or weak, or we
      can add syntax to .cabal files that allows package authors to specify
      explicitly how they intend a flag to behave.
      
      This is related to various cabal-install issues, e.g. #1831, #1864,
      and #1877.
      
      (cherry picked from commit 3dcddea4)
      
      Conflicts:
      	cabal-install/Distribution/Client/Dependency.hs
      f950e8d7
  11. 19 May, 2014 1 commit
    • Andres Löh's avatar
      Configurable strong/weak flags. · 3dcddea4
      Andres Löh authored
      This adds a mechanism in the modular solver to store whether a flag
      is "strong" or "weak". A weak flag is deferred during solving, a strong
      flag is not.
      
      By default, flags are now weak unless they're manual. This is a change
      in behaviour, but I think it's probably the better default, because many
      automatic flags are used to figure out what's on the system rather than
      to impose hard constraints.
      
      There's a new flag --strong-flags that restores the old behaviour. I do
      not think such a global flag is particularly useful, but it may be
      of interest to compare build plans between the new and old behaviour.
      
      With these preparations, it's easy to make the distinction between
      strong and weak flags more sophisticated. We can either add more
      heuristics as to when flags should be treated as strong or weak, or we
      can add syntax to .cabal files that allows package authors to specify
      explicitly how they intend a flag to behave.
      
      This is related to various cabal-install issues, e.g. #1831, #1864,
      and #1877.
      3dcddea4
  12. 31 May, 2012 2 commits
  13. 05 Apr, 2012 1 commit
    • Andres Löh's avatar
      adding the possibility for index-disabled packages · 7db70840
      Andres Löh authored
      In the modular solver, it's now possible to mark packages
      as disabled in the index conversion phase. This can be used
      to mark broken packages (with missing dependencies) in such
      a way that they can still be seen by the solver and reported
      in error messages.
      
      Furthermore, the feature could be used to implement
      shadowing restrictions. Currently, there are some things
      that can go wrong if multiple installed instances of
      the same version and package exist on the system. However,
      I've not enabled the use of shadowing for now, as it's
      hard to match the restrictions exactly, and we can end up
      excluding perfectly valid cases. Enabling shadowing
      selectively by a solver flag would be an option.
      7db70840
  14. 12 Feb, 2012 1 commit
  15. 27 Oct, 2011 2 commits
    • Andres Löh's avatar
      collapse repeated flag choices · a0ffe5fb
      Andres Löh authored
      In the build phase, we allow the same flag choice to occur multiple times.
      This makes it easy to handle the situation where the same flag occurs
      several times in the condition tree, and hence new goals and dependencies
      might be introduced depending on the choice.
      
      Previously, we have ensured during validation that repeated flag choices
      are consistent. This behaviour has now been replaced by the new approach
      to collapse repeated flag choice nodes completely during validation.
      
      The advantage is that the tree is less deep, and that the trace output looks
      less strange. Repeated flag choices are no longer seen, which I think avoids
      confusion.
      a0ffe5fb
    • Andres Löh's avatar
      fixing warnings · a2e0f7bc
      Andres Löh authored
      a2e0f7bc
  16. 04 Jul, 2011 4 commits
  17. 03 Jul, 2011 2 commits
  18. 30 Jun, 2011 1 commit
  19. 21 Jun, 2011 2 commits
    • Andres Löh's avatar
      debug output for backjumping · f823278f
      Andres Löh authored
      f823278f
    • Andres Löh's avatar
      maintain chains of GoalReasons · 2eab1f8e
      Andres Löh authored
      Bugfix: conflict sets now contain the transitive closure of goal reasons,
      which is required for completeness.
      
      We now finally have sufficient info to produce good error messages, too.
      At a failure site, we can trace which parts of the tree are relevant to
      the failure, via the correctly generated conflict sets.
      2eab1f8e
  20. 20 Jun, 2011 4 commits
  21. 15 Jun, 2011 1 commit