1. 11 Nov, 2019 1 commit
  2. 23 Oct, 2019 1 commit
  3. 22 Oct, 2019 1 commit
  4. 07 Aug, 2019 1 commit
  5. 19 Jul, 2019 1 commit
  6. 16 Jun, 2019 1 commit
  7. 13 Jun, 2019 1 commit
  8. 12 Jun, 2019 2 commits
  9. 10 Jun, 2019 1 commit
    • Ben Gamari's avatar
      base: Mark CPUTime001 as fragile · 1a3420ca
      Ben Gamari authored
      As noted in #16224, CPUTime001 has been quite problematic, reporting
      non-monotonic timestamps in CI. Unfortunately I've been unable to
      reproduce this locally.
      1a3420ca
  10. 07 Jun, 2019 1 commit
  11. 04 Apr, 2019 1 commit
  12. 24 Feb, 2019 1 commit
  13. 31 Jan, 2019 1 commit
  14. 27 Jan, 2019 1 commit
  15. 16 Jan, 2019 1 commit
  16. 07 Nov, 2018 1 commit
    • davide's avatar
      testsuite: Save performance metrics in git notes. · 932cd41d
      davide authored
      This patch makes the following improvement:
        - Automatically records test metrics (per test environment) so that
          the programmer need not supply nor update expected values in *.T
          files.
          - On expected metric changes, the programmer need only indicate the
            direction of change in the git commit message.
        - Provides a simple python tool "perf_notes.py" to compare metrics
          over time.
      
      Issues:
        - Using just the previous commit allows performance to drift with each
          commit.
          - Currently we allow drift as we have a preference for minimizing
            false positives.
          - Some possible alternatives include:
            - Use metrics from a fixed commit per test: the last commit that
              allowed a change in performance (else the oldest metric)
            - Or use some sort of aggregate since the last commit that allowed
              a change in performance (else all available metrics)
            - These alternatives may result in a performance issue (with the
              test driver) having to heavily search git commits/notes.
        - Run locally, performance tests will trivially pass unless the tests
          were run locally on the previous commit. This is often not the case
          e.g.  after pulling recent changes.
      
      Previously, *.T files contain statements such as:
      ```
      stats_num_field('peak_megabytes_allocated', (2, 1))
      compiler_stats_num_field('bytes allocated',
                               [(wordsize(64), 165890392, 10)])
      ```
      This required the programmer to give the expected values and a tolerance
      deviation (percentage). With this patch, the above statements are
      replaced with:
      ```
      collect_stats('peak_megabytes_allocated', 5)
      collect_compiler_stats('bytes allocated', 10)
      ```
      So that programmer must only enter which metrics to test and a tolerance
      deviation. No expected value is required. CircleCI will then run the
      tests per test environment and record the metrics to a git note for that
      commit and push them to the git.haskell.org ghc repo. Metrics will be
      compared to the previous commit. If they are different by the tolerance
      deviation from the *.T file, then the corresponding test will fail. By
      adding to the git commit message e.g.
      ```
       # Metric (In|De)crease <metric(s)> <options>: <tests>
      Metric Increase ['bytes allocated', 'peak_megabytes_allocated'] \
               (test_env='linux_x86', way='default'):
          Test012, Test345
      Metric Decrease 'bytes allocated':
          Test678
      Metric Increase:
          Test711
      ```
      This will allow the noted changes (letting the test pass). Note that by
      omitting metrics or options, the change will apply to all possible
      metrics/options (i.e. in the above, an increase for all metrics in all
      test environments is allowed for Test711)
      
      phabricator will use the message in the description
      
      Reviewers: bgamari, hvr
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #12758
      
      Differential Revision: https://phabricator.haskell.org/D5059
      932cd41d
  17. 23 Oct, 2018 1 commit
  18. 07 Oct, 2018 1 commit
  19. 21 Jul, 2018 1 commit
    • David Feuer's avatar
      Harden fixST · 5a49651f
      David Feuer authored
      Trac #15349 reveals that lazy blackholing can cause trouble for
      `fixST` much like it can for `fixIO`. Make `fixST` work just
      like `fixIO`.
      
      Reviewers: simonmar, hvr, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15349
      
      Differential Revision: https://phabricator.haskell.org/D4948
      5a49651f
  20. 31 May, 2018 1 commit
  21. 28 May, 2018 1 commit
    • Tamar Christina's avatar
      Clean up Windows testsuite failures · 60fb2b21
      Tamar Christina authored
      Summary:
      Another round and attempt at getting these down to 0.
      
      We really should re-enable the CI and not wait for those cloud based ones.
      
      I've disabled the backpack tests on windows as they are too broad, they test
      as much the shell as they do the compiler.
      
      The perf tests have been too long to track down. but the numbers are horrible
      but I don't see them getting fixed so just have to accept them.
      
      T9293 has new windows specific output because a Dyn way only flag was added.
      This will of course not work on non-Dyn way builds.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, hvr, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15107
      
      Differential Revision: https://phabricator.haskell.org/D4668
      60fb2b21
  22. 20 May, 2018 1 commit
  23. 16 May, 2018 2 commits
  24. 03 May, 2018 1 commit
    • Chaitanya Koparkar's avatar
      Move the ResponseFile module from haddock into base · 866525a1
      Chaitanya Koparkar authored
      GHC and the build tools use "response files" to work around the limit
      on the length of command line arguments on Windows. Haddock's
      implementation of parsing response files (i.e escaping/unescaping the
      appropriate characters) seems complete, is well tested, and also
      closely matches the GCC version. This patch moves the relevant bits
      into `base` so that it's easier for other libraries to reuse it.
      
      Test Plan: make test TEST=T13896
      
      Reviewers: bgamari, RyanGlScott, 23Skidoo, hvr
      
      Reviewed By: RyanGlScott
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #13896
      
      Differential Revision: https://phabricator.haskell.org/D4612
      866525a1
  25. 20 Apr, 2018 1 commit
  26. 09 Nov, 2017 2 commits
  27. 25 Oct, 2017 1 commit
  28. 19 Oct, 2017 1 commit
  29. 25 Aug, 2017 1 commit
  30. 22 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Make the Read instance for Proxy (and friends) ignore precedence · 8fd95999
      Ryan Scott authored
      Summary:
      The `Read` instance for `Proxy`, as well as a handful of other data
      types in `base` which only have a single constructor, are doing something
      skeevy: they're requiring that they be surrounded by parentheses if the parsing
      precedence is sufficiently high. This means that `"Thing (Proxy)"` would parse,
      but not `"Thing Proxy"`. But the latter really ought to parse, since there's no
      need to surround a single constructor with parentheses. Indeed, that's the
      output of `show (Thing Proxy)`, so the current `Read` instance for `Proxy`
      violates `read . show = id`.
      
      The simple solution is to change `readParen (d > 10)` to `readParen False` in
      the `Read` instance for `Proxy`. But given that a derived `Read` instance would
      essentially accomplish the same thing, but with even fewer characters, I've
      opted to just replace the hand-rolled `Read` instance with a derived one.
      
      Test Plan: make test TEST=T12874
      
      Reviewers: ekmett, austin, hvr, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #12874
      
      Differential Revision: https://phabricator.haskell.org/D3871
      8fd95999
  31. 31 Jul, 2017 1 commit
  32. 29 Jul, 2017 1 commit
  33. 25 Apr, 2017 1 commit
  34. 23 Apr, 2017 1 commit
  35. 21 Apr, 2017 1 commit
    • Ben Gamari's avatar
      base: Fix hWaitForInput with timeout on POSIX · e5732d2a
      Ben Gamari authored
      This was previously broken (#13252) by
      f46369b8, which ported the fdReady
      function from `select` to `poll` and in so doing dropping support for
      timeouts. Unfortunately, while `select` tells us the amount of time not
      slept (on Linux anyways; it turns out this is implementation dependent),
      `poll` does not give us this luxury. Consequently, we manually need to
      track time slept in this case.
      
      Unfortunately, portably measuring time is hard. Ideally we would use
      `clock_gettime` with the monotonic clock here, but sadly this isn't
      supported on most versions of Darwin. Consequently, we instead use
      `gettimeofday`, running the risk of system time changes messing us up.
      
      Test Plan: Validate
      
      Reviewers: simonmar, austin, hvr
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13252
      
      Differential Revision: https://phabricator.haskell.org/D3473
      e5732d2a
  36. 05 Apr, 2017 2 commits