This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 28 Sep, 2017 4 commits
  2. 27 Sep, 2017 3 commits
  3. 26 Sep, 2017 12 commits
  4. 25 Sep, 2017 1 commit
    • kristenk's avatar
      Remove the package instance from D.Solver.Modular.Var (closes #4142). · e1ca9dcf
      kristenk authored
      This change has several effects:
      
      - The solver no longer includes the package version in messages that relate to
        a package's flags, stanzas, or dependencies.  However, the solver always
        chooses the package version before choosing any flags, stanzas, or
        dependencies for the package, so it should be easy to find the version
        by looking earlier in the log.
      - In conflict counting, the solver treats flags with the same name in different
        versions of a package as the same flag.  This change in the conflict counting
        heuristic can improve the solver's efficiency when the same flag causes the
        same conflicts in different versions of a package.  The same applies to
        enabling tests or benchmarks.
      - Each flag or stanza can only appear once in a conflict set.  This has no
        effect on behavior, but it simplifies the message containing the final
        conflict set.
      
      Here is an example of the change in a log message.  It only prints
      hackage-server's version once, when it first chooses the package.  The conflict
      set also has one fewer variable, but that is probably due to the change in
      conflict counting.
      
       Resolving dependencies...
       cabal: Could not resolve dependencies:
       trying: hackage-server-0.5.0 (user goal)
      -trying: hackage-server-0.5.0:+build-hackage-build
      -trying: unix-2.7.2.1/installed-2.7... (dependency of hackage-server-0.5.0
      +trying: hackage-server:+build-hackage-build
      +trying: unix-2.7.2.1/installed-2.7... (dependency of hackage-server
       +build-hackage-build)
      -next goal: aeson (dependency of hackage-server-0.5.0 +build-hackage-build)
      +next goal: aeson (dependency of hackage-server +build-hackage-build)
       rejecting: aeson-1.2.2.0, aeson-1.2.1.0, aeson-1.2.0.0, aeson-1.1.2.0,
       aeson-1.1.1.0, aeson-1.1.0.0, aeson-1.0.2.1, aeson-1.0.2.0, aeson-1.0.1.0,
       aeson-1.0.0.0, aeson-0.11.3.0, aeson-0.11.2.1, aeson-0.11.2.0, aeson-0.11.1.4,
       aeson-0.11.1.3, aeson-0.11.1.2, aeson-0.11.1.1, aeson-0.11.1.0,
       aeson-0.11.0.0, aeson-0.9.0.1, aeson-0.9.0.0, aeson-0.8.1.1, aeson-0.8.1.0,
       aeson-0.8.0.2, aeson-0.7.0.6, aeson-0.7.0.4, aeson-0.6.2.1, aeson-0.6.2.0
       (conflict: hackage-server +build-hackage-build => aeson==0.6.1.*)
       rejecting: aeson-0.6.1.0 (conflict: unix => time==1.6.0.1/installed-1.6...,
       aeson => time<1.5)
       rejecting: aeson-0.6.0.2, aeson-0.6.0.1, aeson-0.6.0.0, aeson-0.5.0.0,
       aeson-0.4.0.1, aeson-0.4.0.0, aeson-0.3.2.14, aeson-0.3.2.13, aeson-0.3.2.12,
       aeson-0.3.2.11, aeson-0.3.2.10, aeson-0.3.2.9, aeson-0.3.2.8, aeson-0.3.2.7,
       aeson-0.3.2.6, aeson-0.3.2.5, aeson-0.3.2.4, aeson-0.3.2.3, aeson-0.3.2.2,
       aeson-0.3.2.1, aeson-0.3.2.0, aeson-0.3.1.1, aeson-0.3.1.0, aeson-0.3.0.0,
       aeson-0.2.0.0, aeson-0.1.0.0, aeson-0.10.0.0, aeson-0.8.0.1, aeson-0.8.0.0,
       aeson-0.7.0.5, aeson-0.7.0.3, aeson-0.7.0.2, aeson-0.7.0.1, aeson-0.7.0.0
       (conflict: hackage-server +build-hackage-build => aeson==0.6.1.*)
       After searching the rest of the dependency tree exhaustively, these were the
      -goals I've had most trouble fulfilling: aeson, hackage-server,
      -hackage-server-0.5.0:build-hackage-build,
      -hackage-server-0.4:build-hackage-mirror, template-haskell
      +goals I've had most trouble fulfilling: aeson,
      +hackage-server:build-hackage-build, hackage-server, template-haskell
      
      I ran hackage-benchmark to compare this commit with master (two commits
      earlier).  I used --min-run-time-percentage-difference-to-rerun=10 to only rerun
      packages if the run times differed by more than 10% in the first trial, and
      defaults for the rest of the options (10 trials, p-value of 0.05, 90 second
      timeout). The index state was "2017-09-24T03:35:06Z".
      
      1 is master, and 2 is this commit:
      
      package            result1       result2             mean1       mean2     stddev1     stddev2     speedup
      CC-delcont-ref     Solution      Solution           1.467s      1.505s      0.019s      0.100s      0.975
      ascii-cows         Solution      Solution           1.827s      1.758s      0.159s      0.012s      1.040
      opaleye-classy     NoInstallPlan NoInstallPlan      4.588s      4.070s      0.043s      0.032s      1.127
      range-space        NoInstallPlan NoInstallPlan      2.642s      2.299s      0.016s      0.016s      1.149
      rts                PkgNotFound   PkgNotFound        1.323s      1.327s      0.032s      0.033s      0.997
      servant-auth-docs  Solution      Solution           1.968s      1.998s      0.017s      0.074s      0.985
      thorn              BackjumpLimit NoInstallPlan      4.793s      3.141s      0.050s      0.034s      1.526
      unordered-intmap   Solution      Solution           1.502s      1.511s      0.081s      0.047s      0.994
      
      I looked at the solver logs for the three packages with the largest changes in
      run time, opaleye-classy, range-space, and thorn.  Each one showed that the
      solver started preferring a flag in an older version of a package after it had
      caused conflicts in a newer version of the package.
      e1ca9dcf
  5. 24 Sep, 2017 1 commit
    • kristenk's avatar
      Remove D.Solver.Modular.Var.varPI. · efa85a39
      kristenk authored
      This change is necessary to remove the package instance (I) from Var
      (issue #4142).  One of the main uses of the package instance is when varPI is
      called by the linking phase in order to get the dependencies introduced by flags
      and stanzas.  The validation phase also needs to look up dependencies introduced
      by flags and stanzas, but it does so by looking up the dependencies once when it
      chooses a package and then storing the dependencies in a map.  I refactored the
      linking phase to also store dependencies in a map.
      efa85a39
  6. 21 Sep, 2017 4 commits
  7. 20 Sep, 2017 6 commits
  8. 19 Sep, 2017 4 commits
  9. 18 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Differentiate letter for the dist-dir layout of components · e2a52dee
      Herbert Valerio Riedel authored
      This has been a pet-peeve of mine since 1.24 but I forgot to address
      this in time for the 2.0 release, as it conflates all the component
      kinds into an opaque single "c" namespace thereby losing information,
      rather than encoding the component type in a more expressive single
      letter path component.
      e2a52dee
  10. 13 Sep, 2017 4 commits