- ghc-devs - Haskell.org

RE: [Diffusion] [Build Failed] rGHC6ddba64287fe: Improve TcCanonical.unifyWanted and unifyDerived
by Simon Peyton Jones 21 Oct '16

21 Oct '16

I'm still seeing this OSX failure, below. It seems to be to do with T5611 but I have no way to see what the problem is, and I don't think it's any thing to do with me When I click on "unlimited lines" to attempt to see the error, Firefox hangs, and I have to kill it. It's unsettling getting all these failure messages Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 21 October 2016 21:32 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHC6ddba64287fe: Improve TcCanonical.unifyWanted and unifyDerived Harbormaster failed to build B11529: rGHC6ddba64287fe: Improve TcCanonical.unifyWanted and unifyDerived! BRANCHES master USERS simonpj (Author) O11 (Auditor) COMMIT https://phabricator.haskell.org/rGHC6ddba64287fe EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

2 1

Better X87
by Thomas Jakway 21 Oct '16

21 Oct '16

I was looking through compiler/nativeGen/X86/Instr.hs <https://github.com/ghc/ghc/blob/master/compiler/nativeGen/X86/Instr.hs#L71> and it's pretty hard not to notice the (hilarious) diatribe about the horror that is x87. git log -p says this was apparently written in 2009 by Ben.Lippmeier(a)anu.edu.au (92ee78e03c3670f56ebbbbfb0f67a00f9ea1305f). Since this has survived in X86/ all this time I'm guessing this is still an issue (another guess: we've gotten by because of SSE?). Is there any interest in improving x87 code generation? And if so, has anyone tried before? According to the comment there seems to be room for improvement. Sadly I don't think x87 is going away any time soon. -Thomas Jakway

4 4

Compact regions in users guide
by Ben Gamari 21 Oct '16

21 Oct '16

Hello Compact Regions authors, It occurs to me that the compact regions support that is due to be included in GHC 8.2 is lacking any discussion in the users guide. At very least we should have a mention in the release notes (this is one of the major features of 8.2, afterall) and a brief overview of the feature elsewhere. It's a bit hard saying where the overview would fit (parallel.rst is an option, albeit imperfect; glasgow_exts.rst is another). I'll leave this up to you. I've opened #12413 [1] to track this task. Do you suppose one of you could take a few minutes to finish this off? Thanks! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/ticket/12413

2 1

Perf on T10858
by Simon Peyton Jones 20 Oct '16

20 Oct '16

I’m getting this on HEAD on my Linux box (64 bit) cd "./perf/T10858.run" && "/5playpen/simonpj/HEAD-2/inplace/test spaces/ghc-stage2" -c T10858.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output -O +RTS -V0 -tT10858.comp.stats --machine-readable -RTS bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T10858(normal) bytes allocated: 241655120 +/-8% Lower bound T10858(normal) bytes allocated: 222322710 Upper bound T10858(normal) bytes allocated: 260987530 Actual T10858(normal) bytes allocated: 221938928 Deviation T10858(normal) bytes allocated: -8.2 % Does anyone else? It’s good – but why isn’t Harbormaster complaining? Simon

3 2

Master recently broke on OS X
by Ben Gamari 19 Oct '16

19 Oct '16

Hello Simon, It looks like one of the patches that you pushed to master today may have broken the build on OS X. According to Harbormaster something in the range of f148513ccd93..7129861397f8 caused T5611 to fail on the OS X build bot [1]. Could you have a look? Cheers, - Ben [1] https://phabricator.haskell.org/harbormaster/build/14220/?l=100

2 2

Improving GHC GC for latency-sensitive networked services
by Christopher Allen 19 Oct '16

19 Oct '16

It'd be unfortunate if more companies trying out Haskell came to the same result: https://blog.pusher.com/latency-working-set-ghc-gc-pick-two/#comment-286698… (They gave up and rewrote the service in Golang) Most of the state of the art I'm aware of (such as from Azul Systems) is from when I was using a JVM language, which isn't necessarily applicable for GHC. I understand Marlow's thread-local heaps experiment circa 7.2/7.4 was abandoned because it penalized performance too much. Does the impression that there isn't the labor to maintain two GCs still hold? It seems like thread-local heaps would be pervasive. Does anyone know what could be done in GHC itself to improve this situation? Stop-the-world is pretty painful when the otherwise excellent concurrency primitives are much of why you're using Haskell. --- Chris Allen

8 7

Windows build
by Simon Peyton Jones 18 Oct '16

18 Oct '16

On Windows I now get a lot of framework failures, below. I have not tried them all, but some work fine when run individually; e.g. make TEST=AssocTyDef09 Simon Unexpected passes: rts/T7037.run T7037 [unexpected] (normal) Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins07.run plugins07 [bad exit code] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) Framework failures: ./cabal/T5442b.run T5442b [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./codeGen/should_run/cgrun040.run cgrun040 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./concurrent/should_run/conc027.run conc027 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./deSugar/should_run/dsrun010.run dsrun010 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./dph/sumnats/dph-sumnats-vseg.run dph-sumnats-vseg [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./dph/words/dph-words-copy-fast.run dph-words-copy-fast [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./driver/T9963.run T9963 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/scripts/ghci044a.run ghci044a [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/scripts/T4127.run T4127 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/should_run/ghcirun001.run ghcirun001 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./overloadedlists/should_fail/overloadedlistsfail02.run overloadedlistsfail02 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./package/package07e.run package07e [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./parser/should_fail/ParserNoForallUnicode.run ParserNoForallUnicode [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./parser/should_fail/T12051.run T12051 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./perf/should_run/T4830.run T4830 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) ./rts/stack003.run stack003 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./rts/ffishutdown.run ffishutdown [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./simplCore/should_compile/T3234.run T3234 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_compile/tc217.run tc217 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_fail/tcfail013.run tcfail013 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_fail/tcfail110.run tcfail110 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_fail/AssocTyDef09.run AssocTyDef09 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ../../libraries/base/tests/stableptr003.run stableptr003 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ../../libraries/base/tests/IO/ioeGetErrorString001.run ioeGetErrorString001 [runTest] (Unhandled exception: global name 'WindowsError' is not defined)

2 4

Status of GHC testsuite driver on Windows
by Ben Gamari 17 Oct '16

17 Oct '16

So I spent my weekend in the jungles Windows compatibility layers. I'll spare you the details as they are gruesome but here's a brief summary, * There are a few nasty bugs currently in msys2 which affect the GHC testsuite driver: * Mingw Python packages are terribly broken (#12554) * Msys Python packages are also broken, but differently and only with msys2-runtime >= 2.5.1 (#12660) * Both of these issues manifest as a failure to remove test directories; unfortunately this error is hidden by the testsuite driver and you will likely instead see an error of the form, [Error 183] Cannot create a file when that file already exists: ... from os.makedirs. This issue appears to happen more often when threading is enabled in the testsuite driver (e.g. `make test THREADS=4` after disable the check disabling it in runtests.py), but can also happen in single-threaded mode. * If you see this issue do the following, * Check #12554 for comments suggesting that the issue has been fixed upstream. If so, update msys2. * Run `pacman -Q msys2-runtime` and verify that you are running a 2.5-series runtime * If you are running a 2.5-series runtime, you can simply downgrade to the last-known-good version, 2.5.0, by running, $ wget http://repo.msys2.org/msys/x86_64/msys2-runtime-2.5.0.17080.65c939c-1-x86_6… $ pacman -U msys2-runtime-2.5.0.17080.65c939c-1-x86_64.pkg.tar.xz * If you are running any other runtime version then sadly you will need to reinstall msys2. This base tarball, http://repo.msys2.org/distrib/x86_64/msys2-base-x86_64-20160719.tar.xz, is known to work. * After you have an msys installation with function runtime, you'll need to ensure that the testsuite driver runs with the msys python interpreter (located in /usr/bin/python), not the mingw interpreter (located in /mingw*/bin/python). This can be accomplished with `make test PYTHON=/usr/bin/python`. Unfortunately there's no easy way of doing this with `./validate`. The easiest (but terrible) hack is, $ cp /usr/bin/python /mingw64/bin/python * Armed with this knowledge, I should soon be able to bring the Windows build bot back online. * At some point someone is going to need to track down these bugs in CPython and/or msys2 if Windows support is going to remain viable. If you have time and interest in a challenge please get let me know. Now to go drown my sorrows. Cheers, - Ben

1 1

GHC Trac spam filter is rejecting new registrations
by Robert Henderson 17 Oct '16

17 Oct '16

Hi, I've been trying to register a new account on GHC Trac in order to submit a bug report, and I'm getting the following error: Submission rejected as potential spam SpamBayes determined spam probability of 90.82% Could this be a bug or issue with a recent release of the Trac software? I've noticed people complaining about the same problem on other websites that use Trac, e.g.: https://dev.haiku-os.org/ticket/12947 https://forum.openwrt.org/viewtopic.php?id=67711 Thanks, Rob Henderson

2 2

Testsuite threadsafety
by lonetiger＠gmail.com 15 Oct '16

15 Oct '16

Hi *, I’m trying to understand a few pieces of code in the testsuite, As it so happens quite a few tests randomly fail on newer msys2 and python installs: r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run T12407 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run T11463 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run T12478_4 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run T12478_3 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run') (I say random, but the set of tests seem to be the same ones, just within that group a few randomly pass every so often. It’s mostly TH tests.) Anyone have any ideas? I’m not very familiar with the internals of the testsuite. Secondly, I’ve noticed all paths in the testsuite are relative paths. And this hand me wondering, relative to what. I see that in do_test we actually change directories 837 if opts.pre_cmd: 838 exit_code = runCmd('cd "{0}" && {1}'.format(opts.testdir, opts.pre_cmd)) So I am now assuming that the relative paths are relative to the cwd. Which brings up the question.. how is this thread safe and working on Linux? Surely any two tests can change the cwd and then one of them would be writing to the wrong place? Am I missing something here? Cheers, Tamar

2 2